[zxspectrum] Re: x Alessandro: riguardo alla ZXMMC...

["Alessandro" <apoppi@xxxxxxxx>]

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!

• Follow-Ups:
  • [zxspectrum] Re: x Alessandro: riguardo alla ZXMMC...
    • From: Paolo Ferraris

• References:
  • [zxspectrum] x Alessandro: riguardo alla ZXMMC...
    • From: Paolo Ferraris

Other related posts:

[zxspectrum] x Alessandro: riguardo alla ZXMMC...

[zxspectrum] Re: x Alessandro: riguardo alla ZXMMC...

[zxspectrum] Re: x Alessandro: riguardo alla ZXMMC...

[zxspectrum] Re: x Alessandro: riguardo alla ZXMMC...

[zxspectrum] Re: x Alessandro: riguardo alla ZXMMC...

[zxspectrum] Re: x Alessandro: riguardo alla ZXMMC...

[zxspectrum] x Alessandro: riguardo alla ZXMMC...