[zxspectrum] Re: x Alessandro: riguardo alla ZXMMC...
- From: "Alessandro" <apoppi@xxxxxxxx>
- To: <zxspectrum@xxxxxxxxxxxxx>
- Date: Sat, 3 Feb 2007 18:45:44 +0100
On Saturday, February 03, 2007 6:06 PM [GMT+1],
Paolo Ferraris <pieffe8@xxxxxxxxx> wrote:
1) La voglio !!!! :-) Possibilmente montata, ma direi che ne parliamo
quando hai le schede.
Ok, ti faccio sapere. Mi ricordo che qualcuno mi aveva chiesto qualcosa del
genere: eri tu?
2) Volevo sapere quali sono le differenze, in pratica, tra la ZXMMC e
la divIDE, a parte il fatto che la divIDE supporta piu' tipi di
memoria di massa e che la ZXMMC e' interna.
La DivIDE e` molto piu` complessa della zxmmc. La zxmmc non ha alcun chip di
memoria a bordo: essenzialmente permette di accedere alla sd/mmc mediante
lettura/scrittura su di un singolo port I/O, se non si tiene conto del
secondo port che serve a selezionare uno dei due slot a bordo.
Programmando la cpld con il file "integrale", tuttavia, si implementano le
caratteristiche aggiuntive che si trovano nella corrispondente cpld del
badaloc dalla quale deriva: la porta rs-232 a 115K2 baud ed un joystick
kempston. Queste funzionalita` sono semplicemente riportate su uno strip sul
pcb, non c'e' nessun connettore seriale o joystick. Lancaster ha preferito
la versione "light" :-) perche` dice che non e` giusto avere una roba
interna che puo` andare in conflitto con una interfaccia kempston che
l'utente potrebbe infilare sul pettine.
La zxmmc non e` quindi in grado di far girare il software scritto per la
DivIDE. Data l'assoluta semplicita` dal punto di vista software (tu scrivi
un byte sulla porta I/O e questo arriva alla sd card) e grazie agli esempi
di roba gia` scritta, non e` difficilissimo (a mio parere) modificare altri
sistemi operativi (a patto di avere i sorgenti, ovviamente).
STARTLOOP:
outi
... (16 istruzioni outi in totale)
outi
jr nz,STARTLOOP
L'istruzione OTDR e' piu' onerosa di una sequenza di OUTI per via del
salto indietro per la ri-esecuzione che OTIR fa. D'altra parte, dato
che il numero di scritture (256) e' un multiplo di 16, e' inutile
controllare se siamo alla fine del ciclo se il numero di output che
abbiamo eseguito non e' un multiplo di 16.
Questo e` molto interessante!
Al di la' che convenga farlo o meno, sarei curioso di sapere (almeno
dal punto di vista teorico) se l'interfaccia riuscirebbe a reggere
questo aumento di velocita' anche sul Badaloc con la CPU a 21MHz.
Dunque: in effetti questo e` il punto critico di tutta la faccenda.
Se funziona su uno spectrum a 3.5MHz, allora funziona di sicuro anche sul
badaloc a 21. Il motivo e` presto detto: e` solo una questione di clock alla
CPLD, la quale deve serializzare 8 bit ogni volta che il processore scrive
(o legge) un byte dalla porta I/O. Dato che la cpld non puo` lavorare su
entrambi i fronti del clock, ne consegue che ogni operazione richiede 16
CPLD clocks.
Sullo spectrum la cpld funziona a 3.5MHz. Sul badaloc, funziona SEMPRE a
21MHz, forniti appositamente dalla cpld principale a prescindere dalla
velocita` selezionata per lo Z80, che invece e` modificabile via software in
ogni momento. Questo per evitare di cambiare il baudrate della seriale ogni
volta che si cambia il clock dello Z80, come accadeva nella prima
implementazione (usavo la stessa uscita per il clock Z80 e CPLD).
Purtroppo la OUTI impiega proprio 16T-states. Se fossero stati 17, non avrei
avuto dubbi. 16 pero` sono pericolosamente vicini al punto critico. Il
motivo per cui se funziona sullo spectrum funziona anche sul badaloc a 21MHz
e` proprio perche` c'e' lo stesso rapporto di clock fra Z80 e CPLD, anche
nel caso peggiore (Z80 a 21MHz) mentre e` in vantaggio la CPLD quando lo Z80
lavora a frequenze piu` basse. In altre parole, la tua tecnica sarebbe
senz'altro utilizzabile con successo quando lo Z80 gira a 14MHz e
consentirebbe di avvicinarsi moltissimo alle attuali prestazioni dell'OTIR
@21MHz (21MHz/21T-states, 14MHz/16T-states).
Questo diagramma, preso dal file di descrizione del badaloc (che tra l'altro
ho aggiornato proprio pochi giorni fa e quindi comprende anche la modalita`
hi-res), mostra l'esecuzione di una OTIR. Il contenuto dei registri al
momento dell'esecuzione e`:
B = 2; C = porta SPI; HL = $4000; ($4000) = $55; ($4001) = $0F. La frequenza
dello Z80 e` 21.25Mhz, ovvero la stessa della CPLD. Queste temporizzazioni
sono quindi identiche (in senso reciproco) a quelle che si verificano su uno
spectrum a 3.5MHz, a parte la velocita` assoluta che e` 6 volte maggiore:
http://www.zxbada.bbk.org/SPI_OTIR.gif
Si puo` vedere la serializzazione del $55 sul primo ciclo di 8 colpi di CPLD
clock (il pin SPI OUT cambia livello ad ogni bit) e si puo` vedere
successivamente il byte $0F (basso per 4 bit, alto per i restanti 4).
Il clock verso la SD CARD e` la meta` di quello operativo, dato che il
relativo contatore avanza sul rising edge del clock a 21MHz (dividendolo
quindi per 2).
Tutto il ciclo e` innescato dal ciclo I/O in scrittura da parte dello Z80
(vedi segnali IORQ, WR e anche CS_9572, che e` il chip select della cpld di
I/O fornito da quella principale). Sul cs_9572 questo c'e' una cosa strana,
ovvero va attivo in ritardo. Questo serve quando lo Z80 gira lentamente, per
evitare LATCH multipli per tutta la durata del WR+IORQ (il latch interno
alla cpld avviene in modo sincrono al suo clock). Pilotando opportunamente
in cs_9572 in modo che sia attivo in corrispondenza di UN SOLO rising edge
del 9572_clock, avverra` sempre un solo latch. Questo mi ha permesso di
salvare un pin dalla cpld principale, perche` in questo modo il segnale di
WR proviene direttamente dallo Z80 mentre il CS dovevo metterlo in ogni
caso.
Cosi` ad occhio, temo che una serie di OUTI consecutive non lascino
abbastanza tempo. Basterebbe 1T-state in piu`, probabilmente. Faro`
sicuramente una prova!
Ciao e grazie dell'idea!
Other related posts:
