Il mese scorso è stato annunciato un progetto editoriale di David Pleasance, uno dei manager di Commodore UK (la filiale inglese) che, in collaborazione con alcuni ex ingegneri dell’azienda, ha deciso di scrivere un libro su una visione alternativa della storia se, dopo la bancarotta, il progetto che aveva imbastito per rilevarla fosse andato in porto e Commodore avesse avuto la possibilità di riprendere a lavorare da dove s’era fermata, ma dando un grande impulso alla parte più tecnica di ricerca & sviluppo.
A me piacerebbe pensare, invece, a cosa si sarebbe potuto fare se i dipendenti della casa madre avessero fatto bene i loro compiti e fatto evolvere almeno decentemente la nostra osannata piattaforma, anziché averci regalato tutta la serie di “innovazioni” e progetti poi mai realizzati che sono stati trattati e analizzati nel precedente articolo.
Ovviamente non si tratta di sparate al rialzo, ma di scelte contestualizzate su cosa fosse disponibile in un certo periodo storico, quali fossero i relativi limiti tecnologici, e quali opportunità si sarebbero potute ragionevolmente concretizzare in effettive funzionalità e/o avanzamenti in alcuni comparti dell’hardware. Il tutto sulla base di alcune tappe / periodi che sono stati già presi come riferimento nel suddetto articolo e tenendo anche conto delle esigenze dei programmatori (che a mio avviso sono quelli in grado di meglio comprendere le potenzialità di un sistema e ciò che manchi).
1987: il tempo di Amiga 500 e 2000
A due anni dall’introduzione del primo Amiga, il 1000, alcuni cambiamenti erano già stati effettuati al chipset originale (OCS), con l’introduzione della modalità EHB per visualizzare 64 colori (dimezzando l’intensità dei primi 32 colori della tavolozza) nelle ultime revisioni del chip Denise (deputato alla visualizzazione della grafica) in dotazione alla maggior parte dei 1000, e di Fat Agnus per i successivi modelli 500 e 2000 che supporta 1MB di memoria (anche se purtroppo divisi in 512kB di Chip e 512kB di Slow, come abbiamo già visto).
In questo contesto penso che i seguenti piccoli miglioramenti avrebbero consentito di portare grandi vantaggi alla piattaforma:
- due bitplane in più (quindi si passa da 6 a 8) per estendere la modalità EHB a 128 e 256 colori (con 7 e 8 bitplane, rispettivamente) e quella Dual Playfield a 16 + 15 colori (come l’AGA);
- sprite e Blitter in grado di “specchiare” (flip / mirror) orizzontalmente la grafica;
- Copper in grado di copiare dati su più registri;
- DMA per la tavolozza dei colori (richiede un nuovo puntatore per i dati da leggere, un registro a 16 bit per l’indice del registro a partire dal quale caricare i dati letti, e un altro registro a 16 bit per il numero di valori a 16 bit da leggere);
- volume dei canali audio selezionabile indipendentemente a destra e sinistra;
- supporto a 1MB di memoria Chip.
I 256 colori…
Quasi tutte sono modifiche molto semplici e alcune veramente banali, ma di grande impatto. La prima, in particolare, è quella che ovviamente incide moltissimo dal punto di vista visivo, perché estende enormemente il numero di colori visualizzabili contemporaneamente su uno schermo singolo (EHB) o con due schermi (Dual Playfield), rispetto ai 64 e 8+7 colori della macchina originale.
In particolare avere l’EHB a 128 e 256 colori, mantenendo la stessa tavolozza di 32 colori base (selezionati da 4096), equivale a dare la possibilità di poter utilizzare 4 e 8 gradazioni, rispettivamente, di ognuno di questi colori base.
Niente di trascendentale e, anzi, estremamente semplice, se consideriamo che la modalità EHB sia stata introdotta al volo nell’ultima revisione del chip Denise che è stata utilizzata negli Amiga 1000 (era assente nei primissimi modelli).
Inoltre già alcuni anni prima (1984, per la precisione) ritroviamo esattamente lo stesso meccanismo di 8 gradazioni (intensità/luminosità) di un colore con alcuni computer proprio della casa madre: Commodore 16/116 e Plus4.
I quali avevano una tavolozza fissa da 16 colori, ma era possibile scegliere 8 diverse tonalità per ciascuno di essi, per un totale di 121 colori visualizzabili (il nero era l’unico colore che ovviamente non poteva beneficiare di questa funzionalità).
Anche un contemporaneo degli Amiga 500 e 2000, l’Archimedes di Acorn:
utilizzava un meccanismo simile, anche se un po’ più contorto, ma partendo da una tavolozza di soli 16 colori base e consentendo di impostare i bit più significativi delle tre componenti cromatiche dagli altri 4 bit (uno per rosso e blu, e due per il verde) che erano specificati negli 8 bit (che erano quindi divisi in due parti: 4 bit per il colore base e i 4 bit coi bit più alti delle tre componenti).
Entrambi gli approcci hanno pregi e difetti, ma alla fine sono entrambi abbastanza buoni per generare immagini di 256 colori da una palette di 4096, senza pagare il prezzo molto salato di dover implementare 256 registri interni al chip video per mantenere almeno 12 bit (per i 4096 colori). Fattibile nell’87 (c’era disponibile un nuovo processo produttivo), ma comunque costoso per delle macchine che avrebbero dovuto aggredire principalmente il mercato mainstream / degli home computer.
… ma con un prezzo da pagare
Non sono, però, tutte rose e fiori, poiché aumentare il numero di colori significa anche dover processare più dati, e come dimostrato nel precedente articolo ciò significa che le prestazioni del Blitter sarebbero dovute scalare almeno linearmente (almeno il 33% in più, quindi) con l’aumento dei bitplane.
Cosa abbastanza difficile, come abbiamo visto, perché ci sono soltanto due strade percorribili: o si aumenta la dimensione del bus dati, passando da 16 a 32 bit, oppure si aumenta la frequenza di clock. Nessuna delle due, però, era oggettivamente sostenibile all’epoca, poiché i costi sarebbero stati troppo elevati (i tempi non erano ancora maturi, e l’obiettivo principale era quello di ridurre i costi della nuova piattaforma: il 1000 era fuori scala rispetto al mercato su cui operava Commodore).
Dunque il Blitter sarebbe dovuto rimanere così, e di conseguenza i programmatori avrebbero dovuto sobbarcarsi l’onere di decidere in che modo sviluppare i giochi per sfruttare la grafica con tutti questi colori.
Ad esempio le avventure ne avrebbero sicuramente beneficiato moltissimo, perché non è richiesto un aggiornamento della grafica a 60 (NTSC) o 50 (PAL) fotogrammi al secondo, e quindi il costo computazionale sarebbe stato sostenibile. Altri giochi avrebbero dovuto girare alle metà degli FPS, ma l’Amiga ne ha già parecchi che vanno a 30 o 25 FPS.
Un discorso analogo vale per la modalità Dual Playfield, perché i due schermi da 16 + 15 colori (4 + 4 bitplane) richiedono il 33% in più di potenza di calcolo per essere gestiti rispetto ai classici 8 + 7 colori (3 + 3 bitplane).
In ogni caso e a mio modesto avviso, l’importante era e rimane la possibilità di avere a disposizione queste due innovazioni: sarebbe stata poi cura dello staff tecnico decidere in che modo utilizzarle sapientemente, tenendo conto delle suddette limitazioni.
“Comprimere” i dati
Lo spazio occupato dalla grafica per la memoria Chip è stato sempre uno dei più grossi grattacapi che programmatori e artisti hanno dovuto affrontare, specialmente se l’obiettivo era quello di ottenere giochi con un dettaglio visivo e una variazione cromatica rilevante.
Per questo motivo la possibilità di poter visualizzare sprite o BOB (gli oggetti grafici visualizzati facendo ricorso al Blitter) “specchiati” orizzontalmente avrebbe largamente contribuito a ridurne l’occupazione, dimezzandone lo spazio in parecchi casi:
Una modifica anch’essa banale (spesso implementata anche in console molto più vecchie) che avrebbe potuto ridurre i requisiti di memoria per diversi giochi, non necessitando della costosa espansione di memoria addizionale da 512kB (generalmente si trattava di memoria “Slow”) che è diventata quasi standard proprio per questo motivo.
Ciò non toglie che poter supportare 1MB di memoria Chip avrebbe rappresentato un altro piccolo, ma significativo, cambiamento che avrebbe consentito di realizzare giochi decisamente migliori e più semplici, rendendo anche la vita più facile ai programmatori, come già spiegato nei precedenti articoli.
Sempre in ottica di risparmiare non soltanto preziosa memoria Chip, ma anche la relativa banda di memoria consumata, vanno lette le modifiche al Copper per consentirgli di poter impostare più valori in registri sequenziali, e il nuovo canale DMA che ha lo stesso scopo ma ottimizzato per caricare direttamente i valori dalla stessa memoria senza dover creare lunghe Copper List (così vengono chiamati i programmi eseguiti da questo coprocessore).
Audio spaziale (surround)
Una cosa che mi ha particolarmente dato fastidio, da programmatore, è stata quella di poter ascoltare un canale audio solamente a destra o sinistra, perché quando c’era da dover riprodurre un effetto sonoro dovevo decidere quale traccia musicale togliere di mezzo e riciclare allo scopo.
Il problema è che, a seconda del particolare momento della colonna sonora, magari sarebbe stato preferibile riutilizzare un canale anziché un altro, mentre la scelta che ti semplificava la vita era rappresentata dal decidere preventivamente, qualunque fosse il momento o la colonna sonora, quale traccia sostituire se c’era da riprodurre un effetto a sinistra o a destra, con risultati certamente non ottimali.
La soluzione per risolvere questo problema è semplice, come già descritto nel primo articolo della serie, ma probabilmente di tutte quelle elencate finora è quella che richiede un po’ più transistor per la sua implementazione, dovendo aggiungere altri quattro componenti PWM (mentre non sono richiesti registri addizionali: è sufficiente utilizzare il byte alto del registro deputato al volume, in modo da replicarlo per poter regolare l’altra uscita).
In ogni caso nulla che non fosse fattibile per la tecnologia dell’epoca, e che avrebbe contribuito anche a ripensare alcuni giochi, che con questa funzionalità avrebbero potuto implementare il cosiddetto audio “spaziale”, cioè dando la possibilità di una maggior immersione e realismo, perché si sarebbe potuto ascoltare un suono provenire lontano da destra per avvicinarsi verso il centro e poi allontanarsi a sinistra, giusto per fare un esempio:
Cosa che, se emulata con un normale Amiga, avrebbe ovviamente richiesto due canali audio dedicati allo scopo (uno che riproduce il suono a destra con un certo volume, e un altro a sinistra con un altro volume), lasciando quindi soltanto due dei canali audio rimanenti per fare altro.
Quella dei soli quattro canali audio a disposizione è stata un’altra delle grandi lacune che hanno afflitto la nostra piattaforma, come abbiamo già avuto ampiamente modo di vedere nei diversi articoli che sono stati scritti. Sarebbe stato molto gradito, quindi, porvi rimedio quando la tecnologia lo avesse consentito.
1990: il tempo di Amiga 3000 e 500+
Il che sarebbe potuto avvenire nei successivi tre anni, cioè quando è stato introdotto l’Amiga 3000, ma sarebbe stato ancor meglio commercializzare un modello revisionato del 500, con un hardware ben più avanzato, per meglio cogliere le sfide della concorrenza che s’era fatta ormai estremamente agguerrita, e questo pur rimanendo nell’ambito delle macchine a 16 bit (i 32 bit erano ancora appannaggio di macchine di fascia ben più elevata nonché costosa).
Sempre a mio avviso e affinché ciò fosse stato possibile, il nuovo chipset avrebbe dovuto portare in dote i seguenti miglioramenti:
- frequenza raddoppiata (14Mhz anziché 7) con relative memorie più veloci (passando da 280 a 140ns) ma pur sempre economiche rispetto a quelle disponibili nel ’90, e processore 68000 a 14Mhz (un 12.5Mhz overclockato oppure uno a 16Mhz downclockato);
- controllore grafico in grado di visualizzare uno schermo a 640×200/256 (NTSC/PAL; non interlacciati) fino a 256 colori (come pure EHB e HAM), e due schermi a 320×200/256 (sempre non interlacciati) a 256 colori ma in formato packed/chunky;
- due tavolozze da 256 colori effettive (una per ogni schermo, e con gli sprite che possono scegliere quale usare);
- grafica packed/chunky a 256 colori (8 bit);
- Blitter a 14Mhz con supporto alla grafica packed/chunky a 8 bit (256 colori) e una cache per la maschera fino ad aree di 64×64 pixel;
- 32 sprite, con possibilità di scegliere parte della tavolozza da 256 colori utilizzare;
- 32 canali audio.
Si tratta di parecchia roba, ma per lo più è un’evoluzione in maniera assolutamente naturale della piattaforma (e, quindi, senza particolari complicazioni implementative), con soltanto un’aggiunta “aliena” (la grafica packed/chunky), ma necessaria (la grafica planare è troppo inefficiente e limitante, specialmente quando si ha a che fare con tanti colori o particolari ambiti).
Le modifiche banali (per le quali sono richieste pochi cambiamenti all’implementazione) sono ovviamente quelle che derivano dal raddoppio della frequenza operativa di chipset, memorie, e CPU, ma sono anche quelle da cui si traggono i maggiori benefici, come già evidenziato nei precedenti articoli.
Usare il nuovo processo produttivo
Di tutt’altra portata sarebbe stata, invece, l’introduzione di ben due tavolozze colori, costituite ciascuna da 256 elementi a 16 bit (per memorizzare le componenti di ogni colore), la quale richiede ovviamente parecchi transistor per poter essere implementata.
La tecnologia, però, era andata parecchio avanti da quando il primo Amiga è arrivato sul mercato, e l’avrebbe senz’altro consentito. Infatti bisogna ricordare che i chip custom hanno usato un processo produttivo a 5um, che era già molto vecchio nell’85, in quanto la divisione LSI di Commodore aveva già a disposizione il nuovo processo a 3um.
I numeri di per sé non dicono molto, specialmente se non si hanno delle conoscenze base in questo campo, ma è molto facile comprendere il significato dell’avanzamento nei processi produttivi se si tiene conto del fatto che passare da 5 a 3um vuol dire, rozzamente, che gli stessi transistor presenti in un chip adesso occupano meno spazio proporzionalmente. Il che, procedendo in senso inverso, equivale a dire che un chip che occupasse un certo spazio a 5um, consentirebbe di integrare molti più transistor nello stesso, identico, spazio, ma con un processo a 3um.
Nello specifico, 5 / 3 = 1,67, quindi si potrebbero impacchettare circa il 67% di transistor in più. Ma tenuto conto che questo cambiamento finora ha riguardato una sola dimensione (ad esempio quella orizzontale), mentre la superficie dei chip è bidimensionale, lo stesso incremento ci sarebbe nella seconda dimensione (quella verticale), per cui i due fattori si moltiplicherebbero. In sintesi, l’aumento dei transistor sarebbe di 1,672 = 2,78, pari al 178% di transistor in più negli equivalenti chip, ma a 3um.
Poiché già nell’88 Commodore disponeva di un nuovo processo produttivo a 2um (utilizzato nel nuovo processore 65CE02 che ha trovato posto nella scheda seriale A2232 per l’Amiga, e successivamente nel progetto Commodore 65), si fa presto a fare i conti e vedere come nel ’90 sarebbe stato possibile ottenere il 525% di transistor in più. Direi ben più che sufficienti per accomodare la richiesta di memorizzare i 512 colori totali delle due tavolozze, e molto altro ancora.
Difatti copre anche i costi in termini di transistor per arrivare ad avere 32 sprite e 32 canali audio, anche se in quest’ultimo caso la via maestra da seguire sarebbe stata quella di implementare due circuiterie in grado di effettuare la “miscelazione” di 32 canali audio, da convogliare poi in due DAC ad alta precisione per l’uscita destra e sinistra rispettivamente. Un sistema del genere è necessario per poter scalare agevolmente il numero di canali audio, anziché dover ogni volta aggiungere un DAC e due PWM per ogni nuovo canale audio. Inoltre, se implementato con un po’ di furbizia, non avrebbe richiesto nemmeno grosse risorse (non servono 32 sommatori che lavorano in parallelo, giusto per essere chiari).
Similmente, anche l’implementazione della cache della maschera usata dal Blitter per le operazioni più complesse (ma fra le più comuni) non avrebbe avuto alcun problema a trovare posto grazie alla valanga di transistor a disposizione. Questa modifica è stata già spiegata in un precedente articolo, e serve a evitare di dover caricare ogni volta la stessa maschera per ogni bitplane da processare, la quale rappresenta la “tassa” da dover pagare ogni volta a causa dell’impiego della grafica planare (al posto di quella packed/chunky). In questo modo si sarebbe risparmiato circa il 25% di banda verso la memoria, e migliorate similmente anche le prestazioni del Blitter (sfruttando un bypass della pipeline, essendo la maschera già caricata nella cache).
Sfruttare le due nuove tavolozze dei colori
Un decisivo passo avanti dal punto di vista squisitamente visivo sarebbe stato rappresentato dalla possibilità di avere le suddette due tavolozze dei colori da 256 colori ciascuna. Sono due perché l’Amiga consente di visualizzare anche due schermi completamente indipendenti, che utilizzano due parti separate dell’unica tavolozza che è sempre stata utilizzata per qualunque elemento grafico (inclusi gli sprite), per cui e a mio modesto avviso sarebbe stato certamente molto più utile poterle separare del tutto anche per poter offrire una maggior ricchezza cromatica senza dover necessariamente passare all’uso di modalità packed/chunky a 16 bit.
Ovviamente sarebbe servita anche la possibilità di poter decidere quale delle due tavolozze utilizzare per i due schermi, ed eventualmente quale parte (per schermi dotati di meno di 256 colori). Cosa che è stata in parte realizzata nel successivo chipset AGA col registro BPLCON3 per quanto riguarda i due schermi, a cui sarebbe dovuto esser aggiunto un bit per controllare quale delle due tavolozza utilizzare per il secondo schermo.
Ciò è stato implementato anche per gli sprite, grazie al registro BPLCON4, che permette di selezionare quale parte della tavolozza utilizzare per quelli pari, e quale parte per quelli dispari. Una soluzione che, a mio avviso, è sbagliata, perché sarebbe dovuto esser possibile selezionare la tavolozza direttamente per ogni singolo sprite, come avviene in parecchi sistemi arcade o console, anziché globalmente per tutti (sebbene separati in pari e dispari, nell’AGA).
Per far questo bisognerebbe cambiare il registro di controllo di ogni sprite, SPRxCTL:
usando allo scopo alcuni bit inutilizzati: quelli da 3 a 6. Con questi quattro bit sarebbe stato possibile selezionare i quattro bit più alti per la parte della tavolozza da utilizzare (che si può considerare idealmente suddivisa in 16 tavolozze da 16 colori ciascuna). Considerato che l’Amiga può visualizzare sprite con al massimo 16 colori (soltanto 4 con OCS/ECS, ma sarebbero diventati ben 16 con quest’innovazione, visto che i 32 sprite a 4 colori si possono accoppiare due alla volta per formarne uno a 16 colori), la combinazione risulta perfetta.
In realtà alcuni di questi bit sono utilizzati dal chipset ECS per poter posizionare in maniera più granulare gli sprite orizzontalmente:
e alcuni anche dal successivo AGA:
ma francamente ritengo di gran lunga più utile avere la piena libertà di poter scegliere la tavolozza da utilizzare individualmente per ogni singolo sprite. Inoltre la maggior granularità orizzontale si sarebbe potuta realizzare in una successiva evoluzione del chipset (come vedremo nel prossimo articolo).
Infine, sarebbe stato sufficiente sfruttare un bit inutilizzato in uno dei registri (ad esempio proprio BPLCON4) per selezionare quale delle due tavolozze da 256 colori utilizzare per tutti gli sprite. Quindi la tavolozza indicata sarebbe rimasta la stessa per tutti gli sprite, ma è una limitazione con la quale ci si sarebbe potuti convivere tranquillamente.
A letto con il nemico: la grafica packed/chunky
Veniamo adesso all’innovazione che avevo classificato come “aliena” in precedenza, ossia l’introduzione della grafica packed/chunky a 8 bit, sia nella circuiteria video che si occupa di renderizzare e mandare lo schermo all’uscita video, sia per quanto riguarda il Blitter.
Su quest’argomento ho scritto parecchio in passato, inclusa un’intera (e lunga) serie che tratta l’argomento in maniera approfondita, oltre a un articolo che dimostra (andando anche nel dettaglio) come si sarebbe potuto implementarla velocemente e efficientemente al posto della ridicola circuiteria di conversione del chip Akiko del CD32, e il tutto rimanendo assolutamente coerenti col funzionamento esistente.
Poca roba e poco sforzo di realizzazione nonché in termini di risorse da impiegare, dunque, anche perché si tratta esclusivamente della versione a 8 bit = un singolo byte (che semplifica enormemente il tutto), ma che da sviluppatore di lunga data ritengo un passo assolutamente necessario per meglio supportare diversi scenari nonché ottimizzare l’uso delle (poche) risorse a disposizione.
D’altra parte se n’è resa conto anche Commodore, la quale introducendo le bitmap “interlacciate” (interleaved) con la versione 2.04 del sistema operativo, ha cercato di mettere una pezza, per quanto possibile, al fatto di dover processare separatamente ogni singolo bitplane di uno schermo o immagine, con ricadute negative sia in termini prestazionali sia di spazio e banda di memoria sprecati.
Il nocciolo della questione è, infatti, proprio questo: consentire di effettuare le elaborazioni in un colpo solo, senza richiedere tante passate quante siano i bitplane utilizzati dalla profondità di colore dello schermo, a cui si aggiunge la miglior efficienza.
Quest’ultima forse non è di immediata comprensione per chi non è addentrato sul funzionamento e le limitazioni dell’hardware dell’Amiga in ambito prettamente grafico, ma un esempio dovrebbe chiarire meglio la questione:
Se analizzate in dettaglio gli “spari”, vi rendete conto che i più piccoli sono larghi appena tre pixel, come evidenziato nella seguente immagine (sparo a sinistra):
Eppure nell’Amiga sono memorizzati usando sempre 16 bit (dove un bit corrisponde sempre a un pixel, per ogni bitplane che costituisce l’immagine), quindi sprecando ben 13 bit/pixel di spazio (moltiplicato per ogni bitplane). La stessa immagine in versione packed/chunky occuperebbe, invece, 4 byte per ogni riga, con i primi tre byte contenenti il colore dei tre pixel, mentre soltanto l’ultimo byte sarebbe utilizzato come riempimento per allineare i dati a 16 bit (che è la dimensione del bus di sistema).
Un altro vantaggio di questo formato è che non richiede l’utilizzo di “maschere” per poter disegnare un’immagine. Per semplificare, nell’Amiga viene in genere utilizzato un bitplane aggiuntivo con tutti gli oggetti che devono essere disegnati, dove un bit posto a 1 segnala che per quel pixel la grafica dell’oggetto va disegnata nello schermo, mentre se è a 0 indicherà che si tratta di un’area “trasparente”, per cui quel pixel dovrà continuare a contenere il colore dello schermo. Dunque ogni volta che bisogna disegnare un oggetto dovrà essere letta questa maschera per ogni bitplane dell’oggetto da processare (questo è anche il motivo per cui serve la cache della maschera, come illustrato precedentemente: per evitare di doverla leggere ogni volta, per ogni bitplane, visto che non cambia).
Con la grafica packed/chunky la maschera può, invece, essere calcolata al volo, usando il colore zero per segnalare un pixel trasparente. In questo modo non soltanto si occupa meno spazio in memoria (per gli oggetti grafici sono presenti soltanto i colori dei loro pixel), visto che manca la maschera, ma il processo risulta più efficiente, dovendo utilizzare soltanto tre canali per l’elaborazione grafica, anziché i quattro normalmente necessari, con un risparmio del 25% sulla banda di memoria utilizzata.
Un altro motivo per cui si rende praticamente obbligatoria l’introduzione del formato packed/chunky è che in questo modo la modalità Dual Playfield avrebbe consentito di utilizzare due schermi da 256 colori alla risoluzione di 320×200/256, continuando a leggere i dati del primo schermo dai bitplane dispari e quelli del secondo schermo da quelli pari, ma con la differenza che il formato dei dati letti non sarebbe stato più quello planare. L’alternativa sarebbe stata quella di duplicare i bitplane, portandoli a ben 16, quindi duplicando le inefficienze, come abbiamo già visto in altri articoli: una strada assolutamente da non percorrere.
Volendo aggiungere un po’ più di flessibilità, si sarebbe potuto anche implementare il primo schermo in packed/chunky (quindi visualizzando 256 colori), mentre il secondo sarebbe rimasto con grafica planare (visualizzando 16 colori, perché i bitplane pari sono quattro in totale). In questo modo sarebbe rimasta più banda a disposizione per il Blitter per aggiornare la grafica.
Questo formato consente, inoltre, di accelerare notevolmente la velocità di tracciamento delle linee, arrivando a otto volte le prestazioni rispetto a un equivalente schermo con 8 bitplane. Infatti il Blitter è stato progettato per tracciare un pixel alla volta, ma… su un singolo bitplane, equivalente a poco meno di un milione di pixel al secondo. Quindi per tracciare un pixel in uno schermo da 256 colori si deve disegnare otto volte la stessa linea, ma su ogni bitplane, riducendosi a poco più di 110mila pixel al secondo. Con la grafica packed/chunky è sufficiente, invece, eseguire una sola volta l’operazione per ottenere lo stesso risultato, con innegabili vantaggi non soltanto prestazionali (un milione di pixel al secondo), ma anche di risparmio della banda di memoria (se ne impiega soltanto 1/8, risparmiandone l’88%!).
Non c’è da meravigliarsi se considerazioni analoghe si applichino un po’ ovunque, perché se è vero che il Blitter sia nato per accelerare le operazioni grafiche, è anche vero che è in grado di farlo soltanto per alcuni algoritmi / primitive prestabiliti, per cui in tutti gli altri casi dovrà pensarci la CPU, per la quale gestire la grafica planare è mostruosamente più complicato e inefficiente, sprecando parecchia potenza di calcolo e banda di memoria.
Infine… il 3D. Per le stesse, identiche, ragioni, risulta di gran lunga più veloce effettuare il rendering di una scena con uno schermo in packed/chunky, proprio perché i pixel da disegnare si processano in un solo colpo, mentre con la grafica planare servirebbe dover impostare tutti i bitplane ogni volta, come abbiamo visto. Anche se l’Amiga può contare sul Blitter per tracciare linee per disegnare i triangoli delle scene, per poi riempirne il contenuto (questo coprocessore possiede anche questa funzionalità), non potrà mai competere con la CPU che è in grado manipolare i singoli pixel molto più velocemente, oltre al fatto che è anche in grado di applicare texture o altri effetti speciali.
Non è un caso che siano nate, col tempo, tecniche di conversione della grafica packed/chunky in planare, perché risulta molto più conveniente disegnare la scena in questo formato, e soltanto alla fine convertire il risultato in grafica planare, in modo da poter essere visualizzato dalla circuiteria video dell’Amiga, come abbiamo visto quando abbiamo parlato sempre del chip Akiko presente nel CD32.
Conclusioni
Quelle esposte sono tutte considerazioni che sono state fatte sulla scorta dell’esperienza maturata sviluppando per l’Amiga, e in particolare nel campo dei videogiochi. Non credo di sbagliare se affermo che molti professionisti dell’epoca la pensano allo stesso modo, poiché le esigenze erano le stesse, come pure tante idee su cosa sarebbe servito.
Per questo motivo gli ingegneri della Commodore avrebbero dovuto coinvolgere attivamente alcuni professionisti in ambito videoludico, in modo da comprendere meglio in che direzione andare, anziché perdersi in discussioni e idee balzane.
Il prossimo articolo si sposterà un po’ più avanti nel tempo, inaugurando l’era dei 32 bit.
