[zxspectrum] Re: Filmati DivIDEo su ZXMMC+

  • From: Eugenio Ciceri <eugenio.ciceri@xxxxxxxxx>
  • To: zxspectrum@xxxxxxxxxxxxx
  • Date: Wed, 14 Dec 2011 23:42:01 +0100

Il 14 dicembre 2011 22:35, Alessandro <alessandro.poppi@xxxxxxxxx> ha scritto:

> Guarda, piu' ci penso e piu' mi sembra assurdo quanto affascinante :-)

Di solito ciò che è assurdo è facilmente anche affascinante :-)


> Per cambiare lo stato di un bit di una porta occorre che si presenti sul
> bus una operazione di scrittura a quell'indirizzo (nel nostro caso tutti
> gli indirizzi pari), ovvero devono andare giu' contemporaneamente IORQ,
> WR e A0.
>
> La zxmmc non e' in grado di eseguire operazioni del genere, perche'
> tutte e tre queste linee sono INGRESSI. Lei si limita a pilotare il
> databus quando viene letta una delle porte che le competono, ma non puo'
> in nessun modo forzare lo stato del bus indirizzi ne' tantomeno una
> linea di controllo in uscita allo Z80, comportamento che porterebbe
> certamente a risultati abbastanza orribili :-)
>
> Se non sbaglio hai detto che disattivando l'audio, il disturbo sparisce.
> Vedo nello stralcio di sorgente che 'disattivare l'audio' significa
> tenere basso D3 prima di scrivere sulla $FE.

Mi fido :-)


> Se cio' e' vero, significa che in realta' e' *il bit D3 stesso*
> contenuto nel byte che stai per scrivere ad essere alterato gia' in
> partenza, altrimenti non basterebbe certo mascherarlo per togliere il
> rumore.

Non può essere il bit D3 ad essere alterato perché uso gli stessi file
.dvo sia sulla DivIDE sia sulla ZXMMC+ e il problema sulla DivIDE non
si presenta.
E quando dico "gli stessi file" intendo proprio gli stessi file, non
delle copie: sulla DivIDE utilizzo un adattatore SD->CF, in tal modo
il supporto fisico è di fatto lo stesso su entrambe le interfacce.


> Non ci sara' qualcosa di strano a monte? Non mi e' troppo chiaro perche'
> tu legga un byte dalla sd-card per poi inviarlo indifferentemente ad una
> porta AY oppure, tale e quale, sulla $fe (dove e' valido un solo bit su
> otto, o meglio due bit su otto).
>
> Cos'e' quel byte? Un campione audio a 8 bit? Per usarlo in quel modo
> dovrebbe essere un campionamento a 1 bit in cui solo D3 e'
> significativo.


Il codice originale di Matt è stato progettato per funzionare con l'AY
e nei filmati .dvo è presente un campione a 8 bit per tale chip ogni
video packet.
Io ho soltanto adattato il codice originale per fargli utilizzare la
ZXMMC+ anziché la DivIDE e nei miei esperimenti ho provato a vedere se
inviando il campione tal quale alla porta $fe si ottenesse un effetto
accettabile.
Il fattore C ha fatto in modo che la qualità del suono risultante
fosse più che accettabile :-)
E meglio così, dato che dovendo restare nel periodo di flyback non c'è
il tempo materiale per convertire in alcun modo il dato letto dalla
card.

In realtà inizialmente filtravo soltanto i bit D0, D1 e D2 per evitare
di avere effetti colorati sul bordo durante lo streaming. E' stato
dopo aver sentito il rumore spurio sulla ZXMMC+ che ho deciso di
lasciare soltanto il bit D3.

Tra l'altro, per aggiungere una cosa ancora più assurda, i campioni
presenti nei filmati hanno tutti il nibble alto = $8, così, di fatto,
si tratta di campioni a 4 bit con un range da $80 a $8F.
Questo significa che il bit D4 è SEMPRE = 0.
Eppure è proprio lui quello deputato ad attivare lo speaker ed è
proprio lui che, se non mascherato, produce il rumore a maggior
intensità; quello residuo sul bit D3 sembra essere più un'interferenza
di tipo analogico.

Resta poi anche il fatto che la porta $fd risulta in qualche modo
inibita, infatti inviando il sample audio a tale porta non produce
alcun effetto.
Il codice di gestione del chip AY è lo stesso identico utilizzato nel
player per la DivIDE e l'ho copiato così com'era...

Come dicevi tu, assurdo e affascinante, ma anche un po' disarmante...

Other related posts: