[zxspectrum] Re: dimensioni schermo

Ho moltiplicato i frames per 50 perche'... ehm... da qui si vede chi 
nasce informatico (come me) e chi nasce elettronico :-)

Assumendo che il clock da 3,5MHz dello Spectrum tiri fuori davvero 
3.500.000 cicli al secondo (in natura i quarzi non saranno cosi' 
rigorosamente precisi) volevo vedere perche' non riuscivo a 
sincronizzare quel benedetto emulatore software.

Sullo Spectrum 48k il tracciamento di un frame video dovrebbe richiedere 
in teoria 70000 cicli di clock (quindi tre milioni e mezzo di cicli al 
secondo); al termine di ogni frame parte un interrupt (che quindi 
comincia ad eseguire istruzioni durante l'inizio del tracciamento del 
nuovo frame video; la ULA contenderebbe dunque la RAM solo durante il 
tracciamento dell'area piu' interna da 256x192 pixels). La ULA continua 
a generare autonomamente l'immagine, anche se un po' di pixel vengono 
ignorati (le parti laterali piu' esterne per l'horizontal retrace, e 
qualcosa delle scanline iniziali per il vertical retrace).

In realta' sul 48k il frame dura solo 68988 cicli (otto pixel ogni 
quattro cicli di clock, perche' la ULA genera 448x312 pixel totali), 
cioe' lo Spectrum traccia i frame video ad un po' piu' di 50Hz: 
sarebbero circa 50,73 Hz, ma siamo appena sotto l'1,5% di tolleranza... 
Tutto questo sempre assumendo che il quarzo del 48k sia assolutamente 
preciso nei suoi tre milioni e mezzo di cicli al secondo; eventuali 
differenze andrebbero ad aumentare quell'1,5% (se il clock e' piu' 
veloce) oppure a diminuirlo (se il clock e' piu' lento). Ci vorrebbe 
infatti un clock da 68988*50 = 3.449.400 Hz per generare con quel 
formato frame esattamente 50 Hz (il problema finale e' comunque solo 
del televisore o del monitor; i demo andranno benissimo perche' il 
tempo lo misurano su "quanti cicli di clock sono passati", non su "a 
quanti Hz vengono generati i frame video").

Sullo Spectrum 128k e successivi ci sono 3.546.900 cicli al secondo 
(sempre assumendo un clock rigoroso) contro 3.545.400 cicli richiesti 
per generare 50 frame (parlo dello schermo a 311 scanline), ognuno in 
70908 cicli di clock. Dunque il frame rate finale sara' assai piu' 
preciso del 48k, perche' 3546900/70908 = 50,021 Hz.

Sul Chrome il clock e' da 3,58 MHz (la meta' di 7.160.000 Hz, esatto?), 
e per questo potresti essere tentato di generare i frame un pochino 
piu' grandi. Tracciando il frame in stile "128k/+2/+3" (311 scanlines, 
ossia 70908 cicli) ottieni 3580000/70908 = 50,4879 Hz, che e' poco 
sotto l'uno per cento di tolleranza del televisore (e comunque meglio 
dello Spectrum 48k originale).

Con 312 scanlines anziche' 311 (tua possibile "licenza poetica" sul 
formato video del Chrome; infatti in realta' solo il 48k della Sinclair 
generava 312 scanline) i pixel di un frame, border compreso, sarebbero 
456*312=142272, che richiedono 71136 cicli per frame, ossia 3556800 
cicli per 50 frame: 50,3261 Hz; non e' il rigore dei 128k ma e' 
comunque un certo miglioramento rispetto ai 50,48 Hz di cui sopra. 
Infatti per andare vicino ai 50 Hz occorrerebbe generare non 311 o 312 
scanlines, ma frame da circa 3580000/50 = 71600 cicli di clock, ossia 
da 314 scanline!! In questo caso, al prezzo di un impercettibile 
spostamento verso l'alto nel TV dell'area grafica 256x192, avresti 
71592 cicli per frame, cioe' 50,00558 Hz, meglio degli stessi Spectrum 
128/+2/+3... Ma io ovviamente non lo consiglio.

Tutte queste considerazioni di oggi mi hanno fatto capire varie cose:

1)  anche ammettendo di avere un clock assolutamente esatto, generare 
un'immagine video a 50 Hz precisi e' un'impresa alquanto ardua perche' 
bisognerebbe farla rientrare in x/50 cicli di clock (con x = frequenza 
del quarzo); e' assolutamente normale che il TV si "beva" poco piu' o 
poco meno dei canonici 50 frame al secondo, e non ci sono altre 
controindicazioni. Al contrario, nello scrivere un emulatore software, 
il problema e' di sincronizzare al tempo reale la macchina virtuale 
(che puo' comodamente seguire in modo rigoroso il numero esatto di 
cicli di clock);

2)  nel peggiore dei casi (lo Spectrum 48k reale) siamo a 50,73 Hz, che 
e' poco meno dell'1,5% di tolleranza. Grazie alla buona combinazione di 
dimensioni del frame video e velocita' del quarzo dei vari 128k/+2/etc, 
la generazione dei frame e' assai piu' precisa (50,02 Hz);

3)  tutto questo significa che degli ipotetici demo che tengono conto 
della lunghezza esatta del frame video (anche se aspettano con HALT 
l'inizio del frame successivo per risincronizzarsi), se sono fatti per 
il 48k allora non gireranno bene sul 128k, e se sono fatti secondo le 
temporizzazioni del 128k non gireranno bene sul 48k; i due computer 
hanno frame video di lunghezza diversa (nel primo caso si aspettano un 
frame video lungo 68988 cicli con scanline larghe 448 pixel, nel 
secondo si aspettano un frame video di 70908 cicli con scanline larghe 
456 pixel); questo ragionamento e' indipendente dai clock di sistema;

4)  per essere perfettamente compatibile coi demo 128/+2/+3 il Chrome 
dovrebbe generare frame video da 70908 cicli; in questo modo i demo 
gireranno un po' piu' veloci (lo 0,933% in piu') a causa del clock di 
sistema da 3,58 MHz, ma resteranno rigorosamente allineati al frame 
video (anche se questo arriva al TV un filino piu' frequentemente);

5)  se il Chrome generasse frame da 456x312 (o da 456x313 o da 456x314) 
anziche' da 456x311, il tracciamento del frame video richiederebbe 
centinaia di cicli di clock in piu' anziche' i "canonici" 70908; per i 
programmi che aspettano con HALT non c'e' differenza, ma per chi conta 
esattamente su quei 70908 allora sballa tutto; data l'ampia tolleranza 
dei TV e monitor, direi che si puo' lasciar perdere questa ipotesi;

6)  per l'emulazione perfetta dei frame 48k e 128/+2/+3 occorrerebbe 
purtroppo implementare entrambe le logiche video: quella 448x312 dello 
Spectrum originale e quella 456x311 dei successori (se proprio sul 
Chrome ci dovra' essere per forza un secondo PLD, allora... no, eh? :-) 
Nel caso peggiore, cioe' del 48k con un clock da 3,58 MHz (il Chrome in 
modalita' 48k, insomma) avremmo certamente l'immagine video generata 
come ULA Ferranti comanda, ma con 3580000/68988 = 51,893 Hz sul TV; 
ricordo vagamente di aver sentito da qualche parte che monitor 
"compositi" e TV si bevevano fino a 52-53Hz (ossia 6% di tolleranza) ma 
non posso giurarlo;

7)  l'audio che si sente sul beeper e' generato "man mano" (non come sui 
nostri PC dove prepari un blocco dati e poi lo passi in pasto alla 
scheda sonora, la quale provvede a fare l'output a velocita' esatta a 
44.5 KHz o 48 KHz o che altro, e tu devi avere un altro blocco pronto 
non appena questa dice che ha finito, e potrebbe finire non proprio 
quando te lo aspetti... per questo funziona ad interrupts). Quindi 
avere uno Spectrum 48k con un clock da 3,58 MHz (il Chrome in modo 48k) 
significa che le frequenze in uscita sul ronzatore saranno il 2,28% 
piu' alte. Penso che all'orecchio non sara' facile distinguere un 
Chrome in modo 48k da uno Spectrum originale. Il guaio e' certamente di 
chi scrive un emulatore perche' deve "ridistribuire" su 44.5 KHz o 48 
KHz l'uscita audio "raccolta man mano"... questo puo' essere facile se 
si fa "a posteriori", ma e' una cosa complicata farlo "in tempo reale"; 
l'ideale sarebbe una scheda sonora programmabile con decente precisione 
tra i 300 e i 400 KHz in uscita, perche' cosi' ad ogni bit sul beeper 
(che richiede non meno di 11 cicli di clock per una OUT sulla porta 
giusta: per questo ho detto 300-400 KHz, circa un decimo del clock 
originale) corrisponderebbe un byte in uscita sulla scheda sonora del 
PC (sto sprecando un byte quando il ronzatore piezoelettrico e' di un 
solo bit, ma questo e' un altro discorso);

8)  l'audio dell'AY, da quel che mi e' dato di capire, pure dipende dal 
clock di sistema, e quindi un AY sul Chrome/48k genererebbe al nostro 
orecchio frequenze il 2,28% piu' alte di quelle che i programmatori, e 
sul Chrome/128k genererebbe al nostro orecchio frequenze del 0,933% 
piu' alte; stesso ragionamento che per il beeper: e' arduo emulare a 
software la macchina reale, ed il Chrome sara' solo un filino piu' 
veloce. Sarebbe invece un bel guaio se l'AY avesse delle sue 
temporizzazioni autonome (come invece le nostre adorate schede audio 
dei PC). Suppongo che anche il piu' isterico dei programmatori conceda 
almeno l'1% di tolleranza quando si tratta di aspettare un chip... :-)

9)  video e audio sono i punti su cui piu' ci accorgeremmo che qualcosa 
non quadra (un pixel di troppo o un "click-click" durante l'output 
audio sono assai fastidiosi); lo stesso discorso si propaga alle altre 
periferiche, su cui l'uno o due per cento in piu' di velocita' puo' 
essere niente (attesa di un settore da microdrive) o molto (attesa di 
una condizione di "ready").
Mi spiego: immagina un driver di una periferica che ha un suo clock 
autonomo; il programmatore sa che dopo la OUT sulla porta, prima di 
leggere il risultato e dare un nuovo comando, deve aspettare due 
millisecondi esatti: sul 48k della Sinclair sono 7000 cicli di clock, 
dunque il baldo programmatore scrive un ciclo a vuoto che spreca 7057 
cicli a suon di NOP, va a rileggere la porta e trova ancora la 
periferica "busy" (infatti non erano passati 2msec, perche' ai 3,58 MHz 
del Chrome, in due millisecondi c'entrano 7160 cicli! e 103 cicli a 
3,58 MHz fanno ben 0,028msec)... allora lui, tutto obbediente alle 
specifiche del suo hardware paranoico, aspetta di nuovo altri 7057 
cicli di clock (o addirittura lanciare un nuovo comando che non verra' 
eseguito perche' e' ancora in fase di completamento il precedente), e 
alla fine trova finalmente "ready", avendoci pero' impiegato quasi il 
doppio del tempo! Subito creera' un sito per dichiarare a tutto il 
mondo che il Chrome e' lento e incompatibile, convochera' conferenze 
stampa, apparira' in TV la sera del 31 dicembre alle 23:00 per un 
messaggio a reti unificate per denigrare il Chrome, intentera' causa a 
chiunque dice che era colpa sua che non aveva aspettato un centinaio di 
cicli di clock in piu'... :-)


Ah, in tutto questo non ho parlato della memoria contesa (per la mia 
ignoranza e confusione in materia) sulla quale certamente qualche demo 
va a bruciare deliberatamente cicli di clock... :-)


N.B.: potrei rinnegare parte di quanto ho detto qui nel caso qualcuno 
dimostrasse che ho sbagliato a considerare il frame del 48k di 448x312, 
il frame del 128k/+2/+2A/+3 di 456x311, etc.

Other related posts: