[zxspectrum] Re: Chrome VS Spectrum
- From: Luca Bisti <lucbisti@xxxxxx>
- To: zxspectrum@xxxxxxxxxxxxx
- Date: Mon, 06 Dec 2004 14:31:14 +0100
Ciao a tutti!
Vi chiedo immensamente scusa per non essere piu' intervenuto
sull'argomento, sul quale mi sento direttamente coinvolto per ovvi motivi!
:) Cerchero' di rimediare adesso anche se non posso commentare tutto come
vorrei perche' sono di corsa.
Questo e' lo schema generale delle contese sui cicli di I/O e vale per gli
Spectrum classici di filosofia Sinclair, ovvero 16/48K, 128K e +2;
ovviamente nel caso del 48K vanno ignorate le parti che si riferiscono alle
pagine RAM. Queste informazioni derivano dai nostri studi sulla ULA (e sono
quindi quelle implementate in RealSpectrum), anche se suppongo che
coincidano con quelle presenti nella FAQ.
La Z80 puo' subire una contesa in ciascuno dei 4 T-states che compongono il
ciclo di I/O. Il "trucco" per capire cosa succede sta nell'osservare che la
ULA sente un ciclo di I/O unicamente in base allo stato di /ULAIORQ che e'
definito come /ULAIORQ = /Z80IORQ or A0. Insomma la ULA non sente affatto i
vari segnali diretti di /MREQ e /IOREQ e questa semplificazione circuitale
porta ad alcune conseguenze molto particolari. Ecco nel dettaglio cosa
succede ciclo per ciclo.
CICLO DI INPUT:
T1 e T2: qui la ULA non ha ancora sentito che si tratta di un ciclo di I/O
perche' /Z80IOREQ va giu' nella seconda meta' di T2 e quindi applica la
contesa se A15,A14=01 e, attenzione, anche se semplicemente A14=1
(indipendentemente da A15) nel caso in cui la pagina RAM selezionata sia
dispari (cioe' appartenga al pool conteso). Quest'ultima stranezza e'
dovuta al fatto che la ULA riceve A15 ed A14 non dallo Z80 ma dalla PAL che
si occupa della paginazione.
T3 e T4: viene nuovamente applicata una contesa se valgono ancora le
condizioni di prima ma in piu' deve essere anche A0=1. Se stiamo facendo ad
esempio una IN A,(0xFE) adesso finalmente la ULA sente /ULAIORQ attivo e
quindi capisce che non si tratta di un tentativo di accesso in memoria (e
quindi non contende piu').
CICLO DI OUTPUT:
Stesse regole di sopra, ma a T2 viene applicata la contesa anche se A0=0,
cioe' stavolta alla ULA arriva prima l'attivazione di /ULAIORQ.
Ricordo che il pattern delle contese ha due zeri in fondo, quindi quando lo
Z80 riparte dopo una contesa puo' eseguire per lo meno due cicli di clock
indisturbato.
Come esempio di applicazione di queste regole vediamo in dettaglio il
famigerato fenomeno della contesa della porta 0x7FFD, che ha un ruolo
importantissimo nei demo: nella prima meta' di T1 viene applicata subito la
contesa perche' A15/A14 valgono 01; al termine del ritardo lo Z80 riparte e
completa T1 e T2 (la contesa di T2 non ha effetto perche' in quel punto il
pattern prevede sicuramente un delay di 0 cicli di clock). A T3 scatta una
nuova contesa (sicuramente di 6 cicli, per come e' fatto il pattern delle
contese) perche' A15 e A14 valgono ancora 01 e inoltre /ULAIORQ non si e'
attivato perche' l'indirizzo della porta e' dispari; al termine dei 6
t-states viene completato il ciclo di I/O con T3 e T4. In definitiva,
quindi, la scrittura al registro di paginazione comporta ben due ritardi,
di cui il secondo e' sicuramente della durata massima.
Esercizio per casa: disegnare il diagramma delle contese per una OUT alla
porta 0x7FFC (vedere scroller in overscan di Song in Lines 4).
Se avete osservazioni o qualche dubbio chiedete pure, cerchero' di
rispondere il prima possibile (non temete se ci dovessi mettere qualche
giorno, leggo comunque tutto).
Luca.
PS: Tutto questo e molto altro nell'ormai mitologico documento di Ramsoft
sulla ULA, prossimamente online in uno dei prossimi secoli... ;)
Other related posts:
