[zxspectrum] Re: Filmati DivIDEo su ZXMMC+
- From: Eugenio Ciceri <eugenio.ciceri@xxxxxxxxx>
- To: zxspectrum@xxxxxxxxxxxxx
- Date: Thu, 15 Dec 2011 23:47:54 +0100
Il 15 dicembre 2011 20:59, Eugenio Ciceri <eugenio.ciceri@xxxxxxxxx> ha scritto:
> Il 15 dicembre 2011 19:36, Alessandro <alessandro.poppi@xxxxxxxxx> ha scritto:
>> Sapendo che ogni campione audio ha tassativamente D4 a zero, potresti
>> trappare nel software un BSOD in caso di lettura di un byte con D4 '1' e
>> dirci il risultato, ad esempio il contesto in cui si trova quel campione
>> all'interno dello stream e andare a vedere se era proprio cosi'?
>
> Sì. Più tardi provo e vi faccio sapere.
Ne sai una più del diavolo... ;-)
I byte ci sono e sono quelli di fine settore.
In pratica ad ogni fine settore arrivano i CRC e il data token $FE che
casualmente si trova sempre al posto del sample audio (e ha sia il bit
D3 sia il bit D4 settati).
Il programma però non va in crash perché casualmente (nota che è già
la seconda volta che uso la parola "casualmente" e inizia a fare il
calcolo delle probabilità... ;-)) il registro ix contiene sempre $BEFF
($BE precaricato e $FF letto dalla card) e l'indirizzo $BEFF
corrisponde a un salto indietro proprio all'inizio del ciclo di
lettura dati dalla card che così riprende caricando i dati corretti!!!
Unico danno collaterale quindi il dato spurio finito sulla porta audio
che, nel caso della porta MIC genera il rumore fastidioso, mentre nel
caso della porta AY a quanto pare la inibisce (non so esattamente come
funziona l'AY, in effetti).
Come direbbe Mariello Frapapappo a Colorado Cafè: "Mistero risolto!"
Purtroppo però non ho ancora trovato una soluzione perché se inserisco
un controllo tipo
bit 4,a
jr nz,no_audio
per non far arrivare alle porte audio il byte spurio esco dal flyback
e salto un frame video, con relativo rallentamento dello streaming.
Forse funzionerà soltanto sul badaloc a frequenze superiori...
Other related posts:
