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...