Meriterebbero un premio gli Highlander che fossero arrivati fino a quest’ultimo pezzo, il quale serve a chiudere una lunghissima nonché molto tecnica serie di articoli incentrati su un ipotetico Amiga dotato di grafica packed anziché planare.
Elenco articoli
Riporto qui di seguito l’elenco di tutti gli articoli già pubblicati, in modo da ritrovarli facilmente in un solo posto.
Il falso mito dei bitplane più efficienti (della grafica packed/chunky) – Articolo introduttivo / teorico
Amiga “packed” – 1: Introduzione & controllore video (bitplane)
Amiga “packed” – 2: Il controllore video (packed)
Amiga “packed” – 3: Il controllore video (packed) – Esempio, costi, AGA
Amiga “packed” – 4: Il controllore video – Scroll e overscan
Amiga “packed” – 5: Dual Playfield & Costi (planare vs packed)
Amiga “packed” – 6: Gli Sprite
Amiga “packed” – 7: Il Blitter
Amiga “packed” – 8: Il Blitter – “Cookie-Cut” (disegnare “sprite”)!
Amiga “packed” – 9: Il Blitter – Generazione maschere, costi, AGA
Amiga “packed” – 10: Il Blitter – Tracciamento linee (e riempimento)
Amiga “packed” – 11: Il Blitter – Tracciamento linee (packed)
Amiga “packed” – 12: Casi d’uso – Sistema Operativo e applicazioni GUI
Amiga “packed” – 13: Casi d’uso – Videogiochi 2D
Amiga “packed” – 14: Casi d’uso – Videogiochi 3D
Amiga “packed” – 15: Casi d’uso – AGA
Riepilogo
L’obiettivo dichiarato, e inaugurato col primo articolo teorico, era quella di dimostrare che la grafica planare non fosse più efficiente di quella cosiddetta packed (al contrario di quanto circoli ormai da tantissimo tempo). Inutile dire che il pezzo abbia suscitato un vespaio di polemiche e critiche, nonostante le analisi e numeri riportati a corredo sarebbero dovuti essere, da soli, piuttosto chiari nonché sufficienti a togliere di mezzo questa leggenda metropolitana.
Il che ha portato a quest’altra serie di articoli, con lo scopo di rispondere puntualmente e in maniera estremamente dettagliata e precisa a tutte le obiezioni, prendendo come esempio proprio l’Amiga, il quale da sempre rappresenta il punto di riferimento quando si parla di grafica planare e relativa “efficienza”.
L’idea è stata quella di immaginare un Amiga alternativo, ma con l’unico elemento di differenza rappresentato dall’uso della grafica packed al posto di quella planare che ci ha consegnato la storia, esplorando ogni dettaglio dell’hardware che fosse toccato da questo cambiamento, riportando le differenze, le problematiche, le soluzioni, le implementazioni, i costi (in linea di massima) a volte scendendo anche a livello dei singoli transistori utilizzati, e infine alcuni casi d’uso presi da esempi reali.
Nulla, insomma, è stato abbandonato al caso o senza risposta, per non lasciare la porta aperta a eventuali altre critiche: la querelle andava chiusa una volta per tutte e come ritengo di aver portato a compimento (critiche o indicazioni di eventuali punti non corretti non se ne sono viste; almeno finora). La tesi, dunque, dovrebbe essere stata ormai dimostrata.
Ciò che mi preme sottolineare ancora una volta è che lo spirito con cui sono stati scritti tutti i pezzi riguarda quanto qui sopra evidenziato, senza voler strabordare parlando anche d’altro. Per essere più chiari, ho preferito evitare di discutere anche di ulteriori benefici rispetto a quelli trattati (spazio occupato e banda di memoria utilizzata) per cercare di concentrarmi soltanto sulla tesi, anche se in alcuni casi i risultati portavano di per sé ad alcune migliorie che è stato opportuno esplicitare già in quel preciso contesto.
Perché e in effetti molto altro d’interessante si sarebbe potuto aggiungere riguardo ai miglioramenti che vengono fuori dall’adozione di grafica packed e che avrebbero meritato d’esser discussi, ma in separata sede, in quanto necessitavano del completamento di alcune parti della trattazione oppure perché non immediatamente evidenti. Ne ho anche aggiunto qualcuno, qui di seguito, di quelli già trattati, per completezza.
Funzionalità aggiuntive rispetto a OCS
Cominciando col chipset originale (l’OCS), sono quattro le migliorie che sarebbero state possibili grazie all’adozione della grafica packed (e che, quindi, o non sarebbero state possibili oppure avrebbero richiesto molte più risorse per l’equivalente planare).
Abbiamo già visto come il controllore video risulti molto più flessibile rispetto a quello dell’Amiga, in quanto richiede un solo puntatore per indirizzare tutta la grafica di uno schermo (framebuffer), a prescindere dalla profondità di colore (da 1 a 8 bit per pixel).
Questo significa che si sarebbe potuta estendere la modalità Extra Half Brite (EHB) per arrivare a visualizzare 128 (7 bit per pixel) o 256 (8 bit per pixel) colori. Rispetto al normale EHB che consente di visualizzare 64 colori ma col secondo blocco di 32 colori con tonalità dimezzata, con 128 colori avremmo avuto 4 tonalità per i 32 colori della tavolozza, mentre con 256 colori ci sarebbero state a disposizione ben 8 tonalità.
Quindi, sì: sarebbe stato possibile poter visualizzare gli agognati 256 colori già con un Amiga OCS, peraltro molto meglio rispetto all’Archimedes (che ha una palette di soli 16 colore base, ciascuno con 16 tonalità selezionabili, per un totale di 256 colori, per l’appunto).
Ovviamente c’è sempre un prezzo da pagare: più colori significa anche più banda di memoria consumata (oltre allo spazio). Ad esempio con 256 colori = 8 bit per pixel si avrebbe a disposizione soltanto la banda di memoria lasciata libera dagli intervalli di rinfresco orizzontali e verticale.
In ogni caso sarebbe rimasta ai programmatori la possibilità di decidere come meglio utilizzare le risorse a disposizione: l’importante sarebbe stato offrire la possibilità di visualizzare 128 o 256 colori, che a mio avviso avrebbe permesso di realizzare delle avventure grafiche (tanto per fare un esempio di una tipologia di giochi che ha spopolato su Amiga) molto più appaganti cromaticamente.
Per chiudere su questo punto, non mi è chiaro quale potrebbe essere il costo implementativo per queste due nuove modalità estese dell’EHB, ma quest’ultimo fu aggiunto al volo (non era presente soltanto nella prima versione del chipset dell’Amiga 1000) per cui la mia idea è che serva poca logica / transistor allo scopo.
La stessa flessibilità si mantiene anche per il secondo schermo quando abbiamo a che fare con la modalità Dual Playfield, che richiede anch’esso soltanto un altro puntatore. Inoltre (ed è la parte più interessante a mio avviso) non esiste un rigido schema per il quale i bitplane dispari (BPL1PT, BPL3PT, BPL5PT) sono utilizzati esclusivamente per il primo schermo (playfield), mentre quelli pari (BPL2PT, BPL4PT, BPL6PT) soltanto per il secondo, vincolando fortemente, in questo modo, il numero di colori visualizzabili per ogni schermo.
La grafica packed, essendo totalmente scevra da ciò, avrebbe consentito una flessibilità e una varietà di combinazioni per la modalità Dual Playfield potendo definire liberamente fino a 32 colori per il primo schermo e 8 per il secondo (e viceversa), con tutti i “tagli” intermedi che si possano pensare. Quindi sarebbero possibili anche modalità come 16 colori + 8 colori e perfino 16 colori + 16 colori (che arriverà soltanto con AGA!), come pure strane combinazioni come 2 + 32 colori.
Piena libertà, insomma, con l’unico limite rappresentato dalla tavolozza che, essendo costituita da 32 colori, pone un tetto massimo alla profondità di colore di un singolo schermo (5 bit, pari a 32 colori). Ciò non significa che sarebbe stato possibile avere entrambi gli schermi con 32 colori ciascuno: il chipset dell’Amiga non dispone di abbastanza banda di memoria allo scopo! Per cui il limite massimo sarebbe rimasto quello di avere un totale di 8 bit per pixel per la profondità di colore (rappresentato da soluzioni come 32 + 8 colori oppure 16 + 16 colori).
Ovviamente superare i 6 bit per pixel in totale significa anche ridurre di molto la banda di memoria a disposizione per disegnare la grafica col Blitter o anche soltanto per la CPU, come abbiamo visto sopra parlando della modalità EHB estesa a 128 e 256 colori.
L’unica aggiunta necessaria per ottenere questa flessibilità sarebbe stata rappresentata da 3 bit addizionali per specificare la profondità di colore per il secondo schermo, ma i registri del controllore video (BPLCON0, BPLCON1, BPLCON2) hanno un sacco di bit liberi che sarebbero potuti essere impiegati allo scopo, quindi il costo implementativo sarebbe stato nullo (perché non serve altro: il controllore video packed è già predisposto per funzionare in questo modo).
Conseguenza di quanto sopra è che con schermi a 16 colori si potrebbero usare anche tile 8×8, con tutti i vantaggi che abbiamo già visto nell’articolo sui videogiochi 2D (minor banda di memoria consumata e grafica molto più variegata rispetto alle canoniche tile 16×16).
Questo avrebbe aiutato molto i giochi che avessero impiegato schermi (fondali) con questa profondità di colore, poiché la richiesta di banda di memoria per gli aggiornamenti dovuti allo scroll orizzontale sarebbe risultata dimezzata, rendendo molto più fattibile l’uso di 16 colori.
Infine, tutti gli sprite sarebbero stati disponibili anche con scroll orizzontale attivato (mentre sappiamo che si perde l’ottavo sprite con l’Amiga, in questo caso). Quindi si sarebbero potuti definire, ad esempio, due personaggi a 16 colori larghi 32 pixel (che corrispondono al 10% della risoluzione orizzontale usata nell’Amiga: 320 pixel) anziché uno solo.
A titolo di confronto, basti vedere il personaggio utilizzato nel già citato Turrican:
che è largo poco meno di 32 pixel, per comprendere come due personaggi/oggetti di tale dimensione si sarebbero potuti gestire tranquillamente.
Funzionalità aggiuntive rispetto a AGA
Passando all’AGA, si sarebbe potuto contare sulla banda di memoria quadruplicata (si possono caricare dati 64 bit alla volta, anziché i 16 dell’OCS/ECS) per gestire casi molto più complessi.
Ad esempio, con schermi in bassa risoluzione (320×200 per NTSC o 320×256 per PAL) si sarebbe potuta visualizzare grafica a 15 bit (32768 colori più un bit rimasto per il canale alpha / overlay video. Utile con genlock, ad esempio) o 16 bit (65536 colori) oppure 32 bit (16 milioni di colori più 8 bit usati per il canale alpha per poter gestire genlock ancora più avanzati). Ovviamente con l’interlacciamento la risoluzione verticale raddoppierebbe (400 e 512 linee, rispettivamente per NTSC e PAL).
Per lo stesso motivo si sarebbero potuti visualizzare schermi in alta risoluzione (640×200 per NTSC o 640×256 per PAL) a 15 o 16 bit. 640×400 (NTSC) o 640×512 con l’interlacciamento. Le modalità super-alta risoluzione (1280×200 e 1280×256), invece, non avrebbero potuto contare su alcun miglioramento perché utilizzavano già tutta la banda a disposizione (con schermi a 256 colori).
Entrambe queste modifiche per la bassa e alta risoluzione avrebbero richiesto soltanto piccolissimi cambiamenti al controllore video, che è già predisposto per gestire grafica con un singolo byte per rappresentare 256 colori tramite un bypass rispetto al meccanismo alla sua base. Sarebbe bastato, quindi, estenderlo a 2 byte (per la grafica a 15/16 bit) o 4 byte (per la grafica a 32 bit).
Anche il Dual Playfield avrebbe potuto beneficiare di miglioramenti simili ai precedenti due, e ciò senza alcun cambiamento (visto che… funziona già così!).
Ad esempio e in bassa risoluzione (320×200 o 320×256) i due schermi avrebbero potuto utilizzare entrambi fino a 256 colori oppure 15 o 16 bit (in quest’ultimo caso tramite il nuovo bypass spiegato sopra). Similmente, si sarebbero potuti avere anche due schermi ad alta risoluzione (640×200 o 640×256) fino a 256 colori ciascuno.
Infine, anche in questo caso si sarebbero potuti utilizzare tutti gli sprite pur attivando lo scroll orizzontale. Dunque si sarebbero potuti avere fino a 4 sprite a 16 colori larghi 64 pixel, oppure 8 sprite a 4 colori larghi sempre 64 pixel. Per confronto, con l’AGA si potrebbe utilizzare solamente uno sprite a 4 colori largo 64 pixel!
Potete, quindi, immaginare quale enorme flessibilità nonché nuove possibilità avrebbe comportato l’utilizzo di così tanti sprite e di quella dimensione. I programmatori avrebbero avuto, insomma, di che sbizzarrirsi su come impiegarli nei giochi (ad esempio facendone largo uso per i personaggi o, in generale, per alcuni elementi grafici, in caso di giochi 3D).
Tutte queste nuove funzionalità avrebbero comportato l’utilizzo di pochissime risorse per la loro implementazione (soltanto per i due nuovi bypass per il controllore video), ma sappiamo bene che un Amiga AGA in versione packed avrebbe consentito di risparmiare tantissimi transistor che, quindi, avrebbero potuti esser impiegati sia per questo sia per molto altro ancora.
Un altro modo per utilizzarli, infatti, sarebbe potuto essere quello di estendere il Blitter in modo da caricare e leggere dati a 64 bit (anziché a 16, come ha sempre fatto) per velocizzare enormemente le operazioni con la grafica packed a 8, 15/16 o 32 bit…
Conclusioni
Tutte le storie hanno una fine e non fa eccezione questa lunga serie di articoli che arriva alla sua naturale conclusione.
L’obiettivo per cui è nata è stato quello di dimostrare che sarebbe stato possibile realizzare un Amiga in grado di gestire grafica packed anziché planare, oltre che (mediamente) più efficiente in termini di spazio e/o di banda di memoria. Mi sembra che tutto ciò sia stato ampiamente confermato in ogni suo aspetto.
Ovviamente non sono state tutte rose e fiori, tenendo conto che la primitiva di riempimento di aree (rettangolari) risulta difficile da implementare interamente in versione packed, costringendo in quest’ultimo caso a usare una versione “ibrida”. Ma non risulta una grossa carenza, essendo poco utilizzata e poco importante.
Più incisiva è, invece, l’incapacità di poter utilizzare grafica con meno colori su schermi con più colori, operando una sorta di “compressione” che consente di risparmiare sia spazio sia banda di memoria. Un’implementazione totalmente hardware, infatti, sarebbe stata sicuramente possibile, ma utilizzando parecchie risorse addizionali che non sarebbero state compatibili con la dimensione del chip e/o con l’economia dei costi, a meno di fare dei sacrifici (ad esempio rimuovendo la modalità HAM e utilizzandone i transistor allo scopo).
Anche in questo caso, comunque, la capacità della grafica packed di richiedere meno spazio in parecchi casi (grazie alle minori restrizioni in termini di allineamento alla memoria, come abbiamo discusso nell’articolo sui videogiochi 2D) che al contempo fa risparmiare anche banda di memoria, dovrebbero pienamente bilanciare il tutto (se non volgere a proprio favore la situazione), non facendone sentire la mancanza.
L’unico appunto che si potrebbe fare riguarda il costo addizionale necessario all’implementazione della primitiva cookie-cut in versione packed, la quale richiederebbe rozzamente poco meno di 700 transistor. Valore che, a mio modesto avviso, risulta pienamente compatibile coi limiti dei chip dell’epoca (in particolare quelli casa Commodore), considerato che il solo chip Agnus dell’Amiga ha richiesto circa 21 mila transistor. Dunque ne sarebbero serviti circa il 3% in più.
A parte questo, i benefici addizionali che sono stati elencati minuziosamente qui sopra, in questo pezzo, provano senza alcun dubbio che la strada migliore da seguire sarebbe stata proprio quella dell’impiego fin dalla nascita della grafica packed in alternativa a quella planare.
Concetto che viene a dir poco sublimato parlando del chipset AGA, in quanto con una sua versione packed l’Amiga avrebbe potuto godere fin dal 1992 (anno di introduzione dei modelli 1200 e 4000) di caratteristiche che sono rimaste per lo più appannaggio di Macintosh e, soprattutto, PC, a meno di ricorrere a costosissime schede grafiche addizionali (comunque di derivazione PC): la famigerata grafica True color.
Di tutto ciò non rimangono altro che i sogni. La realtà, infatti, ci ha consegnato ben altro, purtroppo…
