Finito l’argomento controllore video, adesso trattiamo quello degli sprite. Sebbene siano ovviamente legati strettamente (gli sprite sono gestiti e usati sempre dal controllore video), ho preferito separarne la trattazione perché il controllore video non dipende da loro (ma è il contrario: gli sprite ne sono un’aggiunta) e per semplificare, in ogni caso, la lettura.
Gli Sprite – bitplane
L’Amiga mette a disposizione fino a 8 sprite a 4 colori larghi 16 pixel orizzontalmente e di altezza illimitata. Questi sprite risultano appaiati a due a due, in quanto è possibile combinarne due di seguito (0 e 1, 2 e 3, ecc.), abilitando un apposito bit nei loro registri, in modo da formarne uno a colori (quindi possono esserci fino a 4 sprite a 16 colori).
Essendo larghi sempre 16 pixel e usando 4 colori vengono usate 2 word (16-bit) per memorizzarne la grafica (registri SPRxDATA e SPRxDATB), come descritto nell’Hardware Manual. Due word (registri SPRxPOS e SPRxCTL) vengono anche usate per memorizzare le informazioni di controllo di ogni sprite (le coordinate iniziali x e y, la coordinata finale y, e vari flag, fra cui il bit che consente di combinarli). Oltre a ciò, sono presenti 8 puntatori (registri SPRxPT, divisi in due registri a 16 bit: SPRxPTH e SPRxPTL) per leggere questi dati da ciascuno degli sprite.
Quando viene usato il DMA per gli sprite (perché tutti i registri di cui sopra possono anche essere caricati manualmente, se non si vuol far ricorso al DMA), vengono per prima caricate le due word di controllo. Successivamente (a partire dalla coordinata y iniziale) vengono caricate le due con la grafica, per ogni riga di raster in cui lo sprite viene visualizzato.
E’ importante sottolineare come il canale DMA di uno sprite carichi, quando è attivo e debba leggere dati, sempre e soltanto 2 word per riga di raster, sfruttando i due slot (accessi in memoria) a esso riservati ($16 e $18 per il primo sprite, $1A e $1C per il secondo, e così via, fino a $32 e $34 per l’ottavo e ultimo), come si può vedere dal diagramma che ho già riportato all’inizio. Da notare che gli ultimi sprite siano molto vicini agli slot riservati alla visualizzazione degli schermi, ed è il motivo per cui possono perdere il funzionamento del DMA attivando scroll e/o overscan (come abbiamo già visto nell’apposito articolo).
Tralasciandone per il momento l’impostazione manuale, il meccanismo di visualizzazione di uno sprite è estremamene semplice: una volta impostato il bit per l’attivazione del DMA per gli sprite, vengono per prima cosa caricate le prime due word di controllo, in modo da avere le informazioni necessarie per la corretta visualizzazione.
Se le word sono entrambe zero, allora lo sprite rimane disabilitato. Da notare che, essendo il DMA abilitato per tutti gli sprite, sarà sempre necessario caricare tutti e 8 i puntatori degli sprite e anche per quelli non utilizzati, con questi ultimi che normalmente vengono fatti puntare a due word a zero proprio per tenerli disabilitati (altrimenti verrebbero caricate informazioni spurie, provocando artefatti grafici).
Se uno sprite è impostato correttamente, il controllore video aspetterà la riga di raster in cui deve mostrarlo, leggerà le due word con la sua grafica, e poi aspetterà la posizione orizzontale a partire dalla quale userà i dati letti per iniziare a visualizzarlo (se lo sprite si trova davanti a tutto il resto, e l’indice colore di quel pixel non è zero. Perché se è zero allora verrà visualizzata la grafica di ciò che sta dietro lo sprite, sia esso un altro sprite o uno dei due schermi). Specificamente, estrarrà sempre il bit più significativo dei due registri dati (SPRxDATA e SPRxDATB) in cui i dati letti e conservati, e li combinerà per ottenere l’indice del colore da utilizzare per quel determinato sprite (gli sprite hanno tavolozze dei colori assegnate).
Se due sprite dovessero essere combinati, prenderà i due bit estratti dal secondo “compagno” e li posizionerà rispettivamente nel terzo e quarto bit dell’indice colore.
Quando il controllore video comincia a visualizzare uno sprite, per ogni pixel a partire dall’inizio (posizione orizzontale) utilizzerà poi due barrel shifter a 16 bit da un singolo spostamento per scartare il pixel elaborato dai suddetti registri dati, così da preparare i dati del pixel quello successivo. Si comporta, quindi, esattamente come quando visualizza i pixel dello schermo (in effetti è come se elaborasse 8 piccoli schermi larghi esattamente 16 pixel), fatta eccezione per il fatto che hanno sempre 2 bitplane (tranne quando due sprite sono combinati: in questo caso è come se ne avessero 4, visto che consentono di visualizzare 16 colori).
Gli Sprite – packed
La versione packed degli sprite funziona esattamente come quella planare usata nell’Amiga, con l’unica eccezione ovviamente rappresentata dal fatto che i dati della loro grafica sono memorizzati in formato packed.
Mentre SPRxDATA e SPRxDATB contenevano i dati del primo e secondo “bitplane” dello sprite, e quindi ognuno di essi aveva la specifica informazione per tutti e 16 i pixel dello sprite, con la versione packed ognuno di questi due registri conserva direttamente gli indici dei colori, ma ciascuno soltanto di metà dei pixel. Dunque SPRxDATA conterrà gli indici dei primi 8 pixel e SPRxDATB quelli degli altri 8.
Quando il controllore video dovrà visualizzare il pixel di uno sprite, prenderà sempre i due bit più significativi di SPRxDATA e avrà immediatamente disponibile l’indice colore (non serve estrarre e combinare i due bit più significativi di ). Si comporterà esattamente come per la grafica planare se, invece, due sprite dovessero essere combinati.SPRxDATA e SPRxDATB
Similmente, dovrà poi scartare i due bit più significativi di SPRxDATASPRxDATA e SPRxDATB sono concatenati) con spostamento di due posizioni, che è del tutto equivalente ai due a 16 bit con spostamento di una posizione usati nell’Amiga.
Dunque il costo dell’implementazione è praticamente identico a quello dell’Amiga, ma con un leggerissimo vantaggio rappresentato dal fatto che l’indice colore del pixel da visualizzare è già disponibile nei due bit più significativi di SPRxDATA
Nel prossimo articolo cominceremo (perché ci sarà una serie di articoli a esso dedicati, considerata la sua complessità nonché varie funzionalità) a parlare dell’altro componente più importante del chipset dell’Amiga: il meraviglioso Blitter!
