[zxspectrum] Re: Filmati DivIDEo su ZXMMC+
- From: Alessandro <alessandro.poppi@xxxxxxxxx>
- To: zxspectrum@xxxxxxxxxxxxx
- Date: Mon, 19 Dec 2011 22:34:30 +0100
On Fri, 2011-12-16 at 20:26 +0100, Eugenio Ciceri wrote:
> Vabbè...
> Andrò per tentativi.
A proposito di tentativi, stavo rileggendo la routine alla luce delle
tue ultime rivelazioni.
Forse puo' esserti utile sapere che la logica nella cpld impiega
esattamente 16T per deserializzare un byte dalla card e renderlo
disponibile sul registro I/O leggibile dallo Z80 all'indirizzo $3F.
Ogni lettura innesca un nuovo processo di deserializzazione, al cui
termine avremo un nuovo byte disponibile nel registro.
Dato che la cpld non puo' sapere in anticipo che avverra' una operazione
di lettura, il primo read in assoluto (da parte dello Z80) non puo' che
restituire un dummy byte, generalmente $FF. Tale lettura ha pero' il
merito di innescare la prima lettura sulla card, per cui dopo 16T si
potra' leggere il primo vero byte.
Se lo Z80 esegue una ulteriore lettura sulla porta $3F prima che il byte
successivo sia stato trasferito dalla card alla cpld, il byte restituito
e' quello precedente (intonso) perche' la serializzazione avviene in uno
shift register separato da quello leggibile dallo Z80, che viene
aggiornato solo al sedicesimo T-state.
Inoltre, una lettura del genere NON innesca un nuovo trasferimento (in
altre parole: se un trasferimento non e' ancora terminato e lo Z80
esegue un altro accesso in lettura, la cpld lo ignora completamente e
restituisce (di nuovo) il byte precedente).
Dovendo limare dei T-state, e' quindi ovvio che se riesci a stare piu'
vicino possibile a 16T (ma non meno) fra un I/O e l'altro, hai il
massimo dell'ottimizzazione.
Ad esempio, se e' vero che la "in l,(c)" richiede 12T e un nop e' 4T
(non sono sicuro), concatenandoli hai la migliore ottimizzazione
possibile.
La INI e' perfetta, dato che impiega 16T: questo e' il motivo per cui
hai potuto metterle tutte in fila, senza nop.
Vedo che carichi BC alla riga 2125, ma (salvo non mi stia sfuggendo
qualche particolare) il registro B e' inutile dato che non usi la INIR:
forse conviene caricarvi direttamente $3F, per il quale ora usi il
registro 'E' come transito.
Credo che togliendo la 'ld b,e' alla riga 2295 non vi siano
ripercussioni di tempi perche' la IN A, (SPI_PORT) impiega 11T ed e'
seguita da un altra istruzione da 8T, quindi siamo gia' oltre i 16T
minimi prima di eseguire la fatidica lettura del campione audio, alla
riga 2298.
Cosa ne pensi?
Ciao!
Other related posts:
