Alcuni termini ricorrono spesso nella letteratura informatica, specialmente per i sistemi più datati dove il contatto diretto con l’hardware era ordinaria amministrazione, e non c’erano diversi strati software che si frapponevano col codice delle applicazioni.
Se di DMA, ad esempio, abbiamo sentito parlare diverse volte (ancora oggi il termine fa capolino ogni tanto quando viene recensito qualche dispositivo che ne fa uso), davanti a riga di raster si comincia un po’ a storcere il naso, anche se la traduzione letterale aiuta un po’ chi ha avuto a che fare con immagini bitmap. Color clock, però, può lasciare letteralmente basiti.
Il motivo è semplice: si tratta di termini tecnici legati alla generazione delle immagini (e non) di dispositivi hardware che dalla seconda metà degli anni ’70 fino alla seconda metà degli anni ’90 hanno letteralmente dominato la scena. Di color clock, tra l’altro, si parla in una remota e oscura sezione dell’Amiga Hardware Manual (anche se il concetto sarà stato probabilmente presente in altre macchine), quindi è altamente specifico.
Quello che bisogna tenere a mente in questi casi è un fatto ben preciso: a regolare il funzionamento della piattaforma era il “video” (notare le virgolette), e più precisamente l’apposito clock che serviva al chip che si faceva carico di generare correttamente l’output (tenendo conto degli standard televisivi dell’epoca: NTSC, PAL e SECAM).
Tutto si riassumeva, quindi, nelle immagini che venivano visualizzate, e misurate in fotogrammi al secondo, anche se è più corretto parlare di quadri e semiquadri visualizzati nell’arco di un secondo (userò comunque i termini in maniera intercambile). A discriminare fra semiquadro e quadro era l’uso della modalità interlace (interlacciamento) o meno, di cui però preferisco parlare più avanti, in chiusura. Al momento tratterò il segnale non interlacciato e in questo contesto per quadro intendo grossolanamente un fotogramma visualizzato.
Per il nostrano segnale PAL avremo pertanto 50 quadri al secondo generati, e parleremo di “immagini a 50Hz”, termine questo molto in uso a cavallo fra gli anni ’80 e ’90: “quel gioco è a 50Hz!” (e a seguire la faccia meravigliata con la mascella da raccogliere da terra) significava che visualizzava 50 immagini al secondo; di conseguenza un “gioco a 25Hz” ne visualizzava 25 al secondo, anche se in realtà i quadri erano sempre 50, e semplicemente due di fila ripetevano a video la stessa immagine.
Il termine più appropriato sarebbe quello di fotogrammi al secondo (FPS), che è in uso oggi e deriva dal fatto che, passando dai giochi 2D a quelli 3D, è difficile riuscire a renderizzare i fotogrammi impiegando lo stesso tempo o, comunque, a generare sempre l’immagine prima che la circuiteria video ricominci a leggerne i dati. Non mi addentrerò nello specifico perché non è l’argomento dell’articolo, per cui ritorno ad assumere che le immagini generate siano sincronizzate col famigerato pennello elettronico.
Sì, perché se oggi si può smanettare con le impostazioni del gioco o della scheda video per impostare il famigerato vsync, a quei tempi il suo uso era assolutamente la norma, pena il presentarsi di fastidiosi sfarfallamenti delle immagini (leggasi: quel gioco “faceva schifo”) che in gergo vengono chiamati anche tearing (se è visibile un “taglio” dell’immagine) o flickering (se la scena ha poco o nessun movimento dello scenario, mentre oggetti come i personaggi si muovono).
Per la precisione e per chi non lo sapesse, questo difetto si verifica nel momento in cui il pennello elettronico sta disegnando il fotogramma attualmente elaborato, e durante il suo lavoro di aggiornamento dello schermo la grafica viene alterata coi dati del fotogramma successivo. In pratica il video presenta due zone orizzontali distinte: quella superiore che visualizza la grafica dell’attuale fotogramma, e di quello successivo quella inferiore. Questo “scollamento” viene percepito dall’occhio e genera quel fastidioso effetto che è tanto più marcato quanto più movimento e/o diverse risultano le due zone.
Tutto ciò permette di entrare nello specifico sul funzionamento del segnale video e su come veniva generata dalle applicazioni la grafica e “data in pasto” al chip video per visualizzarla. Tornando al concetto di quadro / fotogramma, l’obiettivo è di visualizzare un’immagine bitmap, quindi costituita da un certo numero di righe, a loro volta divise in colonne, con un determinato colore.
E’, quindi, intuitivo pensare che il chip video debba leggere queste righe, e passarle in qualche modo al pennello elettronico della TV (o del monitor), ovviamente sincronizzando opportunamente le operazioni e facendo sì che la prima riga non risulti visualizzata in fondo allo schermo o, peggio ancora, che una parte sia visualizzata sulla destra, e la rimanente a sinistra.
La sincronizzazione avviene usando un clock “comune” e alcuni segnali che il circuito video del sistema genera per “pilotare” la TV e dirle cosa deve fare. L’operazione di disegno di una riga a video è semplice: il pennello elettronico preleva i dati sul colore da visualizzare, e pixel dopo pixel provvede, da sinistra verso destra, a renderli a video.
Una volta giunti alla fine della riga bisogna passare all’inizio della successiva, e a ciò serve il cosiddetto periodo di horizontal retrace; si tratta di un tempo “morto” (non viene visualizzato nulla) necessario al pennello elettronico per spostarsi da destra a sinistra, arrivando al contempo alla riga successiva. Al completamento dello spostamento si può, quindi, procedere con la visualizzazione dei colori dei pixel della nuova riga, e così via fino a quando non viene resa l’ultima riga.
A questo punto il pennello elettronico ha completato il tracciamento dell’immagine che gli era stato sottoposto, e deve tenersi pronto per quella successiva. A tale scopo provvede la fase di vertical retrace, cioè lo spostamento del pennello elettronico dall’angolo in basso a destra in cui si trova, a quello in alto a sinistra. Si tratta, quindi, di un altro “tempo morto” in cui non risulta visualizzato nulla a video (è il classico “bordo”). La seguente immagine riassume questo funzionamento:
Tutta l’area che riguarda la visualizzazione di una riga dell’immagine, ivi compreso l’intervallo di horizontal retrace associato (dall’estrema sinistra verso il centro per posizionare il pennello elettronico sui nuovi dati da visualizzare, mentre dalla fine della riga visualizzata fino all’estrema destra per farlo spostare verso la nuova riga; in parole povere: i due bordi, sinistro e destro) viene chiamata “riga di raster” e copre proprio il periodo per le tre operazioni.
Parlo di periodo non a caso perché innanzitutto richiede un ben preciso tempo (63,7us) per realizzare tutto ciò che nell’Amiga viene misurato in color clock (chiamato anche memory cycle), appunto, e la cui singola unità (280ns) corrisponde esattamente a uno “slot” utilizzabile dal chipset oppure dalla CPU (quest’ultima ha la priorità minima, ma ne parlerò meglio in futuro), e poi perché era considerata l’unità di misura delle prestazioni dai programmatori (anche di questo ne parlerò in futuro).
Per slot s’intende un accesso alla memoria (16 bit; in lettura o scrittura), e corrisponde a due cicli del clock principale di una macchina a 7Mhz (Amiga 1000, 500, 500+, 600; tralasciando al momento le altre, 3000, 1200 e 4000, per non complicare il discorso) utilizzabili a seconda del contesto.
Una riga di raster è costituita da 227 color clock (pari, quindi, a 454 cicli del clock “principale”) per il segnale PAL, che scandiscono in maniera precisa tutte le fasi che portano dalla generazione del bordo sinistro, alla grafica, al bordo destro, passando anche per audio, disco, refresh della memoria e ovviamente gli sprite. Tutti questi elementi hanno degli slot assegnati (anche questo lo vedremo meglio in un prossimo articolo), e si capisce quindi perché all’inizio ho affermato che era il video a regolare il funzionamento di tutto.
Abbiamo, quindi, che un quadro (completo) è costituito da 625 righe di raster, che moltiplicate per 25 quadri fanno 15.625 righe al secondo. In termini di color clock ne abbiamo 15.625 * 227 = 3.546.875, che sono pari a 7.093.750 cioé circa 7,09Mhz del clock principale. Per gli altri segnali televisivi il concetto è simile (tranne per l’NTSC dove c’è un’alternanza di righe di raster di 228 e 227 color clock).
Le 625 righe riguardano, però, un quadro completo, come detto, perché si fa sempre riferimento a un’immagine interlacciata. Infatti il segnale PAL è normalmente interlacciato e provvede a visualizzare due semiquadri di 312,5 righe, ciascuno che concorre alla formazione del risultato finale.
Più precisamente, lo schermo prevede 625 righe (di cui quelle visualizzabili sono di meno a causa del vertical retrace) che devono essere disegnate, ma il pennello elettronico ne traccia soltanto la metà ogni volta, perché lavora sempre su un semiquadro, quindi nel primo semiquadro disegna le righe pari e nel secondo quelle dispari; l’occhio umano fa il resto “fondendole” e ricevendo l’immagine completa.
Di giochi interlacciati per Amiga, però, non se ne ricorda nessuno (per lo meno io non ne ricordo, a parte le splendide immagini introduttive dei livelli usate in Agony, ad esempio) e le retine degli occhi, infatti, ringraziano; inoltre 25 quadri completi portano a pensare che questo fosse il limite massimo in termini di frequenza (di visualizzazione) dei giochi, mentre sappiamo che il Santo Graal è stato sempre rappresentato dal gioco che girava a 50Hz (o FPS che dir si voglia).
Il “trucco” per non usare l’interlace e disporre di 50, diverse, immagini al secondo visualizzabili era quello di sfruttare solamente semiquadri “pari”, quindi non visualizzando mai quelle dispari (che rimangono ovviamente nere), e ottenendo quello che in gergo viene chiamato effetto scanline:
Questo si ottiene non inviando al pennello l’elettronico un apposito segnale che gli indica di passare alle righe dispari, e pertanto, continuerà pedissequamente a disegnare sempre e soltanto quelle pari. L’effetto scanline rimane un artefatto visivo, ma diverse generazioni di giocatori sono sopravvissute a esso e, anzi, viene particolarmente apprezzato.
Tornando ai famigerati giochi a 25Hz vale esattamente lo stesso, nel senso che il segnale generato non è certo interlacciato, ma continuano a essere visualizzati sempre e soltanto semiquadri pari, anche se a due a due vengono visualizzate esattamente le stesse immagini. L’unica differenza (non da poco), rimane quindi nella fluidità del gioco, che risulta nettamente inferiore.
Per il momento è tutto. Questi elementi sono indispensabili per capire meglio come funzionava l’Amiga (ma anche altre macchine, siano essi home computer, console o coin-op, il meccanismo era simile o addirittura lo stesso), di cui parleremo in maniera molto più approfondita (e di più basso livello) più avanti, quando vedremo in che maniera grafica, audio, disco, sprite, Blitter, Copper e CPU si “spartivano” gli slot disponibili per i loro compiti.
