[zxspectrum] Re: Filmati DivIDEo su ZXMMC+
- From: Eugenio Ciceri <eugenio.ciceri@xxxxxxxxx>
- To: zxspectrum@xxxxxxxxxxxxx
- Date: Tue, 20 Dec 2011 13:00:14 +0100
Il 19 dicembre 2011 22:34, Alessandro <alessandro.poppi@xxxxxxxxx> ha scritto:
> 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.
> [...]
> 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.
Grazie Alessandro.
Sono informazioni molto utili, ma non saprei come sfruttarle in questo caso.
Purtroppo i nop che ho dovuto inserire per raggiungere i 16T tra una
lettura e l'altra non sono sostituibili con operazioni più utili o
preventive perché devo comunque attendere di aver letto il campione
audio (che è l'ultimo prima dei dati video) per poterne controllare il
bit 4.
Durante il flyback ho quindi purtroppo ben 12T state "sprecati" in
attesa della disponibilità dei dati sulla SPI_PORT.
Per quanto riguarda il registro B, in effetti ho mantenuto il codice
originale di Matt anche dove probabilmente non serviva.
A quanto pare sulla DivIDE non è possibile caricare direttamente il
registro B con il valore 0x3F a causa di qualche conflitto sulle
porte, ma non conosco l'hw della DivIDE, quindi non ho capito
esattamente a cosa si riferisse...
Il caricamento di BC alla linea 2125 può essere trasformato in un ld
C,SPI_PORT, ma avviene in un punto non critico, ovvero tra il termine
del caricamento di un frame e l'inizio del successivo.
In ogni caso 3T state risparmiati fanno sempre comodo ;-)
Anzi, caricando in BC direttamente 0x3f3f si possono risparmiare fino
a 7T tra un frame e l'altro e 4T (togliendo ld b,e alla riga 2295)
durante il flyback.
Purtroppo siamo fuori ancora di 16T, dato che le istruzioni
[ 8] bit 4,a
[12] jr nz,wait_ready_2
necessarie per evitare che il campione audio spurio finisca sulle
porte audio pesano ben 20T.
Resta poi comunque da verificare se sia saggio fare affidamento sul
fattore C che probabilmente permette il funzionamento del programma
soltanto sulla mia card, in un dato range di temperature e col vento a
favore ;-)
L'unica possibilità sarebbe quella di riuscire a convincere la ZXMMC
che i settori non sono da 512 byte ma una ventina dii volte più
lunghi.
In questo modo si potrebbe rimandare la gestione di CRC e data token
al termine di ogni frame, dove il timing è meno critico.
Purtroppo pare che 512 sia il numero magico oltre il quale non è
possibile andare.
(Un po' come la velocità della luce... altro fattore C? ;-))
Se ti viene qualche idea che possa permettere di superare questo
scoglio, la chiave di volta è qui...
La via alternativa che sto cercando di seguire prevede la modifica dei filmati.
Andrei a "marcare" l'ultimo video packet di ogni settore per poterlo
riconoscere durante lo streaming e per poter intercettare l'arrivo del
CRC e del data token.
Una volta ottenuto il data token proseguirei con la lettura
dall'inizio del settore successivo.
In questo modo però andrebbero persi i dati video dell'ultimo video
packet, che però nella maggior parte dei casi è ridondante perché
serve soltanto per fare in modo che non ci siano pacchetti che
"sforano" il settore (a quanto pare la DivIDE non li gradisce).
Inoltre i filmati così modificati non funzionerebbero più sulla
DivIDE, a meno di modificare il player originale.
Se trovo del tempo una delle prossime notti faccio un po' di prove.
Chissà mai che per Natale... ;-)
Ciao!
Other related posts:
