[zxspectrum] Re: dimensioni schermo

Ed ecco le previste rettifiche... (sigh!)

Se il quarzo del Chrome e' 14.3 MHz allora devo dedurre che la velocita' 
sara' 3.575 MHz anziche' 3.58 MHz come avevo scritto io.

Tragicamente FBZX fa passare solo 13488 T-states prima di tracciare il 
primo dei 256x192 pixel a video (solo 60 scanline piu' 96 pixel); 
questo lo posso correggere ma resto sempre con un'approssimazione 
perche' li' l'unita' di misura per il video sono "otto pixel in quattro 
T-states".

Ehm... anche se io non fossi tifoso dei Ramsoft, mi fiderei piu' delle 
loro misurazioni "sul campo" che dei calcoli altrui.

Infatti i 14336 T-states tanto famosi delle FAQ ufficiali sono 64 
scanline (ossia vertical retrace, e la parte visibile piu' alta dello 
schermo). Ma poi c'e' il bordo della sessantacinquesima (prima che la 
ULA abbia bisogno di leggere il primo byte video), bordo che io avevo 
erroneamente calcolato in 64 pixels e stabilito uguale per entrambi i 
lati del video (cioe' 32 T-states ognuno), e quindi con quello potevo 
arrivare a 14368 T-states. Se Ramsoft dice 14347 (cioe' 14336+11) posso 
dedurre che il bordo sinistro parte dopo 22 pixel (anziche' i miei 64).

Riassumo:

mia tabella originale:
448x312 con un bordo di 96 pixel a sx, 96 a dx, 60 su, 60 giu' (immagine 
teoricamente centrata; in realta' il vertical retrace succhia un po' di 
tempo e quindi alcune scanline delle prime 60, per giunta con l'ultima 
che non e' intera, non sarebbero da conteggiare come tali!!). E dire 
che mi era venuto, il dubbio... conoscere la durata dei retrace 
verticale e orizzontale avrebbe aiutato a non prendere la cantonata;

versione Ramsoft (cioe'quella giusta) della generazione del frame video:
* parte l'interrupt
* la ULA genera 64 scanline (durante le prime c'e' il vertical retrace)
* 22 pixel di bordo a sinistra (in realta' era gia' iniziato il bordo!),
  256 pixel della scanline grafica,
  170 pixel di bordo a destra,
  ripetere per 192 volte
* 56 scanline sotto; totale: 312 scanline da 448 pixel, in 69888 Tstates

Cosi' descritta, l'immagine sembrerebbe spostata assai a sinistra e un 
pelino piu' in basso; in realta' questo e' dovuto al vertical retrace, 
che "occupa" circa poco piu' di tre scanline di tempo, cioe' 1418 
pixel, ossia 709 cicli di clock, ovvero 0,2027 millisecondi (!!). 
Quindi non e' che l'estrema sinistra del frame video sia sincronizzata 
con l'interrupt...

Fra parentesi il centraggio della scanline non poteva essere esattamente 
di 96 pixel a sinistra e 96 a destra, perche' sulla destra c'e' la 
pausa dell'horizontal retrace, e quindi per centrare perfettamente 
l'immagine occorrerebbe dare qualche pixel in piu' al bordo destro a 
scapito del sinistro. Per fortuna non c'e' bisogno di fare sul TV o sul 
monitor il centraggio perfetto al pixel...!

Purtroppo ho problemi a far girare Aquaplane nel mio emulatore, dovro' 
modificare l'FBZX originale per verificare queste ipotesi (c'e' da dire 
che FBZX, cosi' com'e', tiene il bordo di Aquaplane parecchi pixel piu' 
su, assai piu' di quelle fatidiche quattro scanline...!)

Rifacendo lo stesso ragionamento per il 128k,  con 14368 T-states per la 
prima lettura, otterremmo:
* parte l'interrupt
* la ULA genera 63 scanline (durante le prime c'e' il vertical retrace)
* 8 pixel di bordo a sinistra (in realta' era gia' iniziato il bordo!),
  256 pixel della scanline grafica,
  192 pixel di bordo a destra,
  ripetere per 192 volte
* 56 scanline sotto; totale: 311 scanline da 456 pixel, in 70908 Tstates

Le dimensioni curiose del bordo destro mi suggeriscono che per tracciare 
un frame video occorre aspettare davvero il vertical retrace. Cioe', 
quando "parte l'interrupt", aspettare un po' di tempo prima di 
tracciare (per evitare di avere la sinistra del border larga solo otto 
pixel!!)

Per "normalizzare" le tabelle allora suggerirei:

48k (frame: 448x312)
* pausa iniziale di 74 pixel (37 T-states)
* tracciare 311 scanline da 448 pixel con 96+96 pixel ai bordi
* tracciare l'ultima scanline di 448-74=374 pixel
* totale: 69888 t-states; puo' partire l'interrupt successivo

128k (frame: 456x311)
* pausa iniziale di 92 pixel (46 T-states)
* tracciare 310 scanline da 456 pixel con 100+100 pixel ai bordi
* tracciare l'ultima scanline di 456-92=364 pixel
* totale: 70908 t-states; puo' partire l'interrupt successivo

alf

Other related posts: