Col precedente articolo il funzionamento delle varie componenti dell’Amiga dovrebbe essere sufficientemente chiaro, ma ho volutamente lasciato fuori dalla disquisizione la generazione della grafica dello schermo, che meritava una trattazione a parte.
Fondamentale rimane ancora la pagina dell’Amiga Hardware Manual che ho riportato nell’articolo (e della quale fornisco il link), che mostra la precisa suddivisione di una riga di raster fra le varie parti del sistema, ma in questo caso c’interessa capire cosa avviene quando dev’essere visualizzata una linea dello schermo all’interno della riga di raster corrente.
Dei 227 color clock, fino a 160 slot sono riservati per la grafica dello schermo, che a questo punto è evidente che faccia la parte del leone (o dell’ingordo, a seconda dei punti di vista; quest’ultimo è quello dei programmatori, ovviamente), fatta eccezione per i bordi dove non viene visualizzata grafica e, quindi, non vengono caricati dati dalla memoria.
I 160 slot sono soltanto teorici, in quanto bisogna sempre fare i conti con due importantissimi parametri: la risoluzione (alta o bassa) e il numero di bitplane. Il caso peggiore, per OCS ed ECS , è rappresentato da uno schermo in alta risoluzione a 16 colori.
In questa modalità il numero di pixel per riga è pari a 640, che equivalgono a 640 / 16 = 40 word (ricordo che una word equivale a 16 bit, e quindi 16 pixel di un bitplane). Poiché 16 colori richiedono 4 bitplane, arriviamo subito al sodo: servono 160 slot per caricare tutte le 40 word per ogni singolo bitplane dello schermo, che equivalgono alla totalità di quelli a disposizione.
Normalmente i dati dello schermo cominciano a essere letti a partire dallo slot 56 ($38 in esadecimale), per proseguire fino ad arrivare allo slot 216 ($D8) escluso. Durante questo periodo il bus dati della chip ram viene impiegato esclusivamente dalla logica di visualizzazione dello schermo per prelevare i dati dei bitplane, tagliando completamente fuori CPU, Copper e Blitter, che potranno contendersi un po’ di accessi esclusivamente durante gli intervalli di horizontal e vertical retrace.
La cosa che salta immediatamente all’occhio è la sequenza con la quale vengono caricati i bitplane: prima il 4, poi il 2, il 3 e infine l’1. Apparentemente questa politica di assegnazione / priorità sembra inutile e confusionaria; dopo tutto i bitplane devono comunque essere caricati tutti e 4, e non ha importanza l’ordine col quale ciò viene fatto.
Se questo è vero per uno schermo (in alta risoluzione) a 4 bitplane, non lo è più con un numero inferiore, e si comincia a comprenderne il motivo. Con 3 bitplane e partendo sempre dallo slot 56 ($38), vediamo che lo slot 56 è libero, il 57 è impiegato per leggere la word del bitplane 2, il 58 per quella del bitplane 3, e infine il 59 per la word del bitplane 1; e così via ripartendo dallo slot 60.
Anche questa, data la disposizione degli accessi dei bitplane, sembra una soluzione bislacca, ma notiamo già che lo slot 56, prima occupato dall’accesso alla word del bitplane 4, adesso risulta libero; inoltre, essendo pari, è utilizzabile dalla CPU (come già detto nell’altro articolo, il 68000 è una CPU che impiega sempre gli slot pari per accedere eventualmente alla memoria, e quelli dispari per le elaborazioni interne).
Quindi con 3 bitplane il processore ha la possibilità di sfruttare ben 40 accessi alla memoria, e dunque non risulta più tagliato del tutto fuori. Lo sarà se e solo se il Copper sfrutterà sistematicamente tutti questi slot liberi per leggere le sue istruzioni, oppure se il Blitter funzionerà in modalità “nasty / hog“, riservandoli per sé e non cedendone nessuno al microprocessore.
Con 2 bitplane avremo gli slot 56 e 58 liberi, ed essendo entrambi pari sarebbero potenzialmente sfruttabili tutti e due dalla CPU. Con un solo 1 bitplane anche lo slot 57 sarà libero, ma in quanto dispari non utilizzabile dalla CPU per quanto già detto, mentre sarà a completa disposizione di Copper o Blitter.
Adesso è chiaro che quella che sembrava inizialmente una stramberia, in realtà è un intelligente sistema nato per ottimizzare al massimo lo sfruttamento degli accessi alla memoria da parte delle periferiche. Per rendercene conto basta riflettere sullo scenario che verrebbe fuori dando accesso in sequenza dei bitplane a partire dal primo: anche con un solo bitplane lo slot 56 risulterebbe sempre impegnato per leggere la word del bitplane 1, e alla CPU verrebbe a mancare la possibilità di sfruttare questo prezioso slot.
Con la bassa risoluzione lo scenario è analogo a quello dell’alta, ma questa volta il fetch dei bitplane è spalmato su 8 slot consecutivi, opportunamente schedulati in base al numero di bitplane da visualizzare, che varia da 1 a 6 (quest’ultimo solo con le modalità EHB a 64 colori, HAM a 4096, oppure il Dual Playfield con 2 schemi a 8 colori ciascuno, di cui ho parlato nell’articolo sull’OCS).
Nel caso peggiore, con 6 bitplane avremo gli slot 56 e 60 liberi (ed essendo pari, sfruttabili dal processore), mentre 57, 58, 59, 61, 62 e 63 assegnati rispettivamente ai bitplane 4, 6, 2, 3, 5 e 1. Rispetto all’alta risoluzione con 4 bitplane, dove non c’era nessuno slot a disposizione, qui ogni 8 ce ne sono 2, per cui il 25% degli accessi (2 su 8) è disponibile per CPU, Copper o Blitter. Risultato identico a uno schermo in alta risoluzione a 3 bitplane (1 slot libero ogni 4).
Scendendo a 5 bitplane (32 colori), gli slot 56, 58 e 60 saranno liberi (e tutti pari, quindi utilizzabili dalla CPU), e tutti gli altri assegnati ai bitplane 4, 2, 3, 5 e 1. Pertanto il 37,5% sarà sfruttabile dalla triade precedentemente menzionata. Rispetto allo schermo con 6 bitplane siamo passati da 2 a 3 slot liberi, quindi con un bell’aumento pari al 50%.
Questi numeri fanno capire perché generalmente i giochi per Amiga erano a 32 colori (al netto degli effetti del Copper) anziché a 64: la banda a disposizione era notevolmente superiore, e quindi si poteva muovere più grafica. Questo senza considerare altri vantaggi: con un bitplane in meno si risparmia sia sullo spazio in memoria (preziosissima all’epoca, specialmente la chip ram, dove stava generalmente la grafica), sia sulla banda per trasferire i dati (si copiano / manipolano 5 bitplane anziché 6).
Nel prossimo articolo dedicato all’Amiga parleremo finalmente dei limiti del chipset (purtroppo la trattazione delle righe di raster e dei color clock ha richiesto più del dovuto, ma era necessario approfondire per capire meglio l’argomento).
