[zxspectrum] Re: dimensioni schermo
- From: Alfonso Martone <a.martone@xxxxxxxxxxx>
- To: zxspectrum@xxxxxxxxxxxxx
- Date: Thu, 29 Jul 2004 22:04:58 +0200
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:
