Definite le fondamenta per l’incarnazione a 32 bit della nuova piattaforma, si può pensare anche a come si sarebbe potuto evolvere l’Amiga tenendo conto di bus dati di capacità più elevata, nuove tipologie di memoria (VRAM, in particolare), frequenze più elevate, funzionalità più avanzate e ottimizzazione di quelle esistenti (che fanno sentire il peso degli anni, ormai).
D’altra parte la concorrenza dei PC si è ormai fatta schiacciante a tutto tondo da un lato, e le console hanno insidiato pesantemente i nostri amati computer “casalinghi” dall’altro lato, per cui delle risposte erano assolutamente necessarie, e di un certo calibro pure, per poter rimanere competitivi.
Dalla sua Commodore ha avuto quello che si può considerare un pregio e un difetto allo stesso tempo: computer più economici dei primi per poter lavorare seriamente, ma anche più costosi dei secondi per il puro intrattenimento. In medio stat virtus, dicevano gli antichi latini, ed è il motivo per cui, nonostante le difficoltà, gli Amiga hanno saputo ritagliarsi comunque una fetta di mercato che, tra l’altro, poteva contare anche su una base di fedeli utenti (che ancora oggi resistono!). Utenti che, quindi, aspettavano le nuove uscite, e per i quali era doveroso nonché conveniente investire per accontentarli (e far felici anche i bilanci dell’azienda).
1994: il tempo di Amiga 5000 (?), 1300(?), e CD64
A due anni dall’introduzione del chipset a 32 bit, e con in mezzo l’incursione del CD32 e della relativa automazione del tracciamento dei quadrilateri (utili anche per il 3D), avrebbe avuto senso pensare all’introduzione dei seguenti miglioramenti alla piattaforma:
- frequenze dei chip a 28Mhz per le macchine low-end/mainstream (home computer, console) e 56Mhz per quelle mid/high-end (computer professionali e workstation);
- bus dati a 64 bit per console e macchine mid/high-end;
- schermi da 640×480 (progressivi / non-interlacciati) a 32 bit fino a 1280×1024 a 8 bit per le macchine low-end, e da 1280×1024 a 32 bit fino a 2560×2048 (teorici: avendo adeguati monitor a disposizione) a 8 bit per quelle high-end;
- modalità Dual Playfield coi due schermi da 320×200 a 32 bit fino a 800×600 a 8 + 8 bit per le macchine low-end, e da 640×480 a 32 bit fino a 1600×1200 a 8 + 8 bit per quelle high-end;
- Blitter con supporto ad alcune operazioni (minimo, massimo, ordinamento, somma e sottrazione con saturazione, blending, ecc.) sui dati in formato packed/chunky;
- flat shading e Gouraud shading per i quadrilateri e clipping;
- supporto al tracciamento di caratteri dei font;
- pipeline ottimizzata delle operazioni del Blitter per migliorarne le prestazioni;
- sprite a 15/16 bit (32/65 mila colori) e 24/32 bit (16 milioni di colori) e con risoluzioni maggiori di 16 pixel orizzontali;
- campioni compressi in ADPCM per i canali audio;
- 64 e 128 canali audio per le macchine a 28 e 56Mhz, rispettivamente;
- fino a 16MB di memoria Chip indirizzabile dal chipset.
Le intenzioni di Commodore per il chipset AAA erano di rilasciarne due versioni per poter coprire i mercati low-end/mainstream e quello high-end, ma in realtà e pur avendo sempre due chipset, sarebbe stato possibile coprire più segmenti di mercato in maniera più granulare e, soprattutto, efficace (offerte più dettagliate consentono non soltanto di coprire meglio i mercati, ma di crearne di nuovi).
Questa è la ragione per cui ho proposto le versioni a 28 e 56Mhz: la prima consente di utilizzare componentistica più economica (in particolare le memorie DRAM), per mantenere molto bassi i costi, mentre la seconda permette di fare molto di più, ma ovviamente dovendone pagare il prezzo. In mezzo si introducono sia la possibilità di usare memorie DRAM o VRAM, sia quella di avere il bus dati a 32 o 64 bit, che aggiungono varietà all’offerta. Quest’ultimo è comodo per fornire un po’ più potenza di calcolo per eventuali console (come il famigerato CD64, basato sul nuovissimo chipset Hombre), senza dover necessariamente utilizzare costose memorie che operano a frequenze molto elevate.
Al solito, una parte dei vantaggi (prestazioni in primis, ma anche schermi a più alte risoluzioni e sprite con più colori) derivano direttamente dall’uso di frequenze superiori ed eventualmente anche dal “bus” dati di dimensione doppia (che porta benefici anche ai dispositivi, come il Copper ad esempio, che non lo usano direttamente, ma che possono sfruttarlo per riempire i buffer interni e, quindi, accedere meno alla memoria). Esistono però delle nuove funzionalità che arricchiscono e potenziano la piattaforma, oltre al fatto che questi fattori (frequenze e bus) possono aprire le porte per migliorare l’esistente.
Sprite più colorati e/o più larghi…
Un esempio, in quest’ultimo caso, è quello degli sprite, per i quali un bus di dimensione doppia consente di caricare più dati e, quindi, di espanderne la cromia grazie al passaggio ai formati packed/chunky a 15/16 bit (32/65 mila colori ). Oppure raddoppiandone la larghezza, passando dai canonici 16 pixel orizzontali a 32 o più, a parità di numero di colori visualizzati, che può essere utile avendo a che fare con schermi con risoluzioni più elevate.
Di seguito le modifiche al registro che si occupa di queste funzionalità:
| Bit 0 | Attach control bit (odd sprites) or packed mode |
| Bit 1 | Which of the two 256 colours palettes should be used or packed mode |
| Bits 7 – 2 | Palette portion to be used for 4 colours sprites |
| Bits 7 – 4 | Palette portion to be used for 16 colours sprites. Bits 3-2 should be zero. |
| Bits | Palette portion to be used for 256 colours sprites. Not used: bits 7-2 should be zero. |
| Bits 9 – 8 | Granularity for horizontal position (e.g.: sprites can be moved 1/4th of pixel in lores and 1/2nd of pixel in hires) |
| Bit 10 | Pure data: no control words are fetched for the sprites to set their start/end positions and additional data. So, only graphics data is fetched. |
| Bits 12 – 11 | Horizontal resolution |
| Bits 15-13 | RESERVED. Should be zero! |
| Bits 30 – 16 | Vertical position |
| Bit 31 | Packed/chunky mode |
L’ultimo bit, il 31, segnala l’utilizzo della grafica packed/chunky al posto di quella planare. Quando è abilitato (a 1), cambia il significato dei primi due bit (che comunque non avrebbero senso in questo caso), in questo modo:
- 00 -> 15 bit + 1 bit di trasparenza
- 01 -> 16 bit (per la trasparenza si usa il colore 0)
- 10 -> 24 bit (per la trasparenza si usa il colore 0)
- 11 -> 32 bit (per la trasparenza si usa il canale alpha)
Mentre i bit 11 e 12 consentono adesso di specificarne la larghezza:
- 00 -> 16 pixel
- 01 -> 32 pixel
- 10 -> 64 pixel
- 11 -> 128 pixel
Come si può vedere, però, il numero degli sprite non è cambiato rispetto alla precedente incarnazione a 32 bit e 14Mhz, mentre abbiamo visto che l’aumento di frequenza ha portato a un proporzionale incremento del loro numero a disposizione, arrivando a un totale di 32. Sarebbe, quindi, stato logico nonché naturale pensare che, potendo contare su frequenze di 28 e 56Mhz, la loro quantità sarebbe potuta arrivare rispettivamente a 64 e 128 oggetti grafici che avrebbero potuto scorrazzare sullo schermo.
Esistono, però, due motivi per cui ho preferito non procedere in tal senso, lasciando intatto il loro numero. Il primo è che aggiungere sprite comporta una maggiore complessità della circuiteria video, che inciderebbe o sulle frequenze/risoluzioni raggiungibili, o introdurrebbe delle latenze nella visualizzazione del segnale. Il secondo, che personalmente trovo più importante, è che tutta l’industria si stava ormai muovendo verso il 3D (la prima console, il 3DO, è stata commercializzata nel ’93: subito dopo il CD32!), per cui non aveva senso appesantire ulteriore la piattaforma per aggiungere oggetti che sarebbero stati sostanzialmente inutili in futuro.
Molto meglio, quindi, sfruttare i nuovi slot (possibilità di accesso alla memoria Chip, nel gergo amighista) per raddoppiare o quadruplicare quelli a disposizione per gli sprite esistenti, consentendo loro di caricare più grafica e, quindi, poter decidere di visualizzare più colori (fino a 32 bit = 16 milioni, con canale alpha annesso eventualmente) oppure allargarli (a 32 o più pixel di larghezza). Entrambe possibilità che sarebbero state certamente utili per arricchire l’esperienza ludica.
… e più canali audio & ADPCM
Discorso diametralmente opposto, invece, per i canali audio, per i quali è molto meglio impiegare l’aumento delle frequenze per aumentarne il numero di due (64) e quattro (128) volte, rispettivamente, visto che la tendenza è quella di avere sempre più sorgenti audio da associare agli oggetti o personaggi che popolano le scene dei videogiochi (la colonna sonora, invece, è divenuta appannaggio del CD-ROM sul quale i giochi sono spesso veicolati).
Il sottosistema audio era già stato ripensato col chipset a 16 bit / 14Mhz per accogliere queste sfide, per cui l’implementazione dei nuovi canali non è complicata né onerosa, poiché richiede soltanto DAC leggermente più precisi, nonché sommatori (che effettuano la miscelazione) ugualmente dotati di maggior precisione nei calcoli.
C’è, però, una differenza: i nuovi registri a 32 bit riservati ai canali audio (che sono stati presentati nell’articolo precedente) sono stati esauriti, perché c’era spazio soltanto per 32 di essi nei 512 byte a disposizione. Serve, quindi, un altro modo per poterli mappare, e in questo caso le soluzioni possibili sono due (o… entrambe).
La prima è quella di utilizzare la stessa tecnica di suddivisione dei canali in banchi (in questo caso di 32 canali alla volta), similmente a quanto proposto con l’estensione a 16 bit / 14Mhz, e che ricalca all’incirca quanto implementato nel chipset AGA per la gestione dei colori (soltanto 32 colori dei 256 in totale sono mappati in un certo momento). Ciò consente anche di risolvere velocemente il problema anche per quanto riguarda i registri addizionali (AUDCON0, AUDCON1, AUDDMA, AUDINT, AUDREQ) che sono stati presentati e che servono alla gestione di tali canali (andando oltre i 4 definiti dal chip originale).
La seconda soluzione è quella di riservare una nuova area di memoria in grado di ospitare tutti questi registri (e pronta anche per successive espansioni). Il problema è che la zona di memoria riservata ai chip custom è andata già del tutto esaurita ($DFF000..$DFFFFF). Per cui si dovrebbe utilizzarne un’altra, come ad esempio $DF8000..$DF8FFF, la quale consente di mappare ben 256 canali (e che si potrebbe anche estendere ulteriormente in futuro).
L’unico intoppo è rappresentato dal fatto che il Copper non sarebbe in grado di accedervi (visto che può farlo soltanto coi registri attuali), ma non sarebbe una grossa limitazione (a meno che non vogliate usare proprio questo coprocessore per programmare i canali audio per riprodurre colonna ed effetti sonori, come ho fatto con USA Racing, il gioco a cui stavo lavorando). Al limite, si potrebbero anche implementare entrambe le soluzioni, in modo da avere piena libertà nel decidere come accedere a questi registri.
Infine, la codifica ADPCM: con l’aumentare del numero di canali e, quindi, anche di campioni utilizzabili (anche a 16 bit), oltre che delle frequenze di esercizio (fino a 56kHz, come sappiamo), lo spazio comincia a farsi tiranno, per cui questa soluzione aiuta in tal senso, consentendo di comprimere i campioni con una qualità accettabile. Cosa non particolarmente onerosa, se consideriamo che il Super Nintendo l’aveva già implementata nel 1990.
In questo caso viene modificato leggermente il registri di controllo dell’audio, impiegando uno dei bit prima inutilizzati:
| Bits 1 – 0 | Samples size: 0 -> 8-bit, 1 -> 16-bit, 2 & 3 -> RESERVED |
| Bit 2 | One shot: only reproduce the samples one time and then stops |
| Bit 3 | Sample from external source |
| Bit 4 | ADPCM |
| Bits 15 – 5 | RESERVED |
| Bits 31 – 16 | Period (number of color clocks) |
Il Blitter cominciare a “fare i conti”… anche col 3D!
Col definitivo sdoganamento della grafica packed/chunky (in questo periodo non ha ormai più alcun senso arrovellarsi nell’usare quella planare, con la relativa povertà cromatica: è tempo di far gioire le pupille!) è possibile pensare di introdurre anche alcune primitive applicabili ai lavori presi in carico dal Blitter, per aiutare in alcuni compiti abbastanza comuni e sollevarne, quindi, il peso dalla CPU.
Cosa che anche l’ultimo chipset in lavorazione in casa Commodore, l’AAA, aveva previsto, e che non sorprende, poiché si tratta di una naturale evoluzione nonché poco costosa in termini implementativi. Se operazioni come minimo, massimo e ordinamento (e altro) possono non suonare tanto attinenti alla grafica (sono di gran lunga più utili per l’elaborazione più “general-purpose“), somma e sottrazione con saturazione e le varie modalità di blending consentono, invece, di implementare velocemente ed efficacemente vari effetti di sicuro impatto:
Estremamente importante è diventata anche l’esigenza di meglio aiutare le elaborazioni 3D, considerato che il mercato ludico si stava fortemente orientando in quella direzione, e la “generazione 32 bit” delle console era ormai rappresentata da modelli il cui principale supporto hardware era riservato a questo tipo di calcoli, tant’è che alcune console nemmeno offrivano supporto al 2D.
Imperativo, quindi, espandere il raggio d’azione delle modifiche al chipset, già iniziate con la versione a 32 bit, e ulteriormente ottimizzata con quello della console di casa (il CD32), implementando in hardware le tecnologie cosiddette di shading per i poligoni da renderizzare.
In particolare risulta molto abbordabile e di semplice implementazione il flat shading:
il quale, come si vede, consiste nell’avere a che fare con una sola sorgente luminosa applicata a ogni singolo poligono.
L’effetto non è male e rappresenta un enorme passo in avanti rispetto alle texture applicate così come sono, senza alcuna illuminazione, ma una soluzione decisamente migliore si ottiene col Gouraud shading:
La differenza è notevole, come si può vedere meglio qui:
Per supportare quest’ultimo tipo di shading sarà necessario introdurre quattro nuovi registri a 32 bit nel Blitter, in cui è possibile specificare i colori ai quattro vertici del quadrilatero da tracciare, e che verranno interpolati durante il suo tracciamento per generare il colore di ogni pixel. Nel caso del flat shading sarà sufficiente, invece, usare soltanto il primo colore (sarà l’unico a venire interpolato con quelli dei pixel del quadrilatero).
Un’altra importante aggiunta in merito alla grafica 3D è quella del clipping. Come abbiamo visto nel precedente articolo, la capacità di tracciamento dei quadrilateri interamente in hardware ha comportato l’introduzione di quattro registri per le coordinate dei quattro punti dei vertici, ma l’operazione vera e propria può sconfinare oltre la dimensione dello schermo, poiché non v’è alcun controllo in merito.
Per questo motivo si possono aggiungere altri due registri a 32 bit, contenenti le coordinate del rettangolo in cui limitare il tracciamento del quadrilatero. Oltre a evitare i problemi già menzionati, questa funzionalità è molto utile perché in questo modo il Blitter può automaticamente saltare il rendering delle parti che non devono venir tracciate, velocizzando notevolmente l’operazione.
Una nuova pipeline per il Blitter
Tutte queste modifiche avrebbero contribuito tantissimo all’accelerazione del tracciamento della grafica 3D (rispetto a quanto disponibile col chipset originale, ovviamente), raggiungendo un limite teorico di circa 7,16Mpixel/s nella versione a 56Mhz, il quale arriva sostanzialmente col passaggio dai 7Mhz (e quasi 0,9Mpixel/s) a questa nuova frequenza (otto volte maggiore).
Sufficienti a coprire le esigenze di rendering di uno schermo 320×240 a 60Hz/FPS (il quale richiede il tracciamento di circa 4,6Mpixel/s), ma sempre nell’ipotesi che ogni pixel dello schermo venga renderizzato una sola volta. Scenario, questo, poco aderente alla realtà, poiché in ambito 3D capita molto più facilmente che un pixel venga sovrascritto più di una volta. Quindi è palese il fatto che serva molta più “potenza di fuoco” per poter mantenere una buona fluidità dei fotogrammi.
D’altra parte basti vedere quanto messo a disposizione dalla concorrenza. Il già menzionato 3DO, commercializzato nel ’93, è in grado di tracciare 9-16Mpixel/s. Per la più famosa Playstation di Sony, arrivata un anno dopo, sono riportati soltanto 360.000 poligoni al secondo in flat shading, 180.000 con texture mapping, e 90.000 con Gouraud shading, per cui confronti diretti non sono possibili, sebbene siano numeri abbastanza grandi e, quindi, lasciano pensare a livelli molto elevati per i Mpixel/s.
Appaiono, dunque, ben poca roba i circa 7MPixel/s raggiungibili con frequenze così elevate (56Mhz), e la motivazione risiede essenzialmente nel fatto che risulta tutto basato sul funzionamento del Blitter, il quale per tracciare un singolo pixel con l’algoritmo di Bresenham per le linee è sempre basato su una sequenza di quattro slot (accessi alle memoria), che equivalgono a 8 cicli di clock (da cui il valore in MPixel).
Tutto aveva perfettamente senso e, anzi, era assolutamente necessario finché si trattava di grafica planare, ma una pipeline che opera in questo modo:
anche con la grafica packed/chunky rappresenta un’enorme limite che tarpa pesantemente le ali alle prestazioni, come abbiamo visto. Urge, quindi, non tanto una sua riprogettazione quando la grafica è in questo formato (in modo da eliminare questi colli di bottiglia e dare finalmente il via libera alle prestazioni), quanto una nuova pipeline ad hoc (lasciando intatta quella originale per continuare a gestire la grafica planare come al solito).
La grafica packed/chunky, infatti, non richiede le classiche operazioni di scorrimento / mascheramento / inserimento che servono quando si ha a che fare con quella planare (dove un pixel rappresenta un bit in memoria, che chiaramente non è direttamente indirizzabile), la quale richiede anche la lettura della grafica dello schermo proprio per questo motivo.
Tutto ciò non serve, perché i singoli pixel altro non sono che byte, word (16 bit) o longword (32 bit) che possono essere direttamente letti da o scritti in memoria. Ecco perché non servono 4 slot (pari a 8 cicli di clock) per poter tracciare un pixel in questo formato, ma soltanto la metà: uno slot per leggere il colore del pixel dalla texture, e un altro per scrivere il pixel generato per il quadrilatero. A conti fatti le prestazioni raddoppierebbero, passando a 14,32MPixel/s: un valore di tutto rispetto e in linea con quello del 3DO.
Qualche altra ottimizzazione sarebbe possibile nei seguenti casi:
- evitando di leggere la texture se il colore da impiegare è lo stesso o fa parte del blocco già letto (ricordo che quando si accede in memoria si leggono ben 16 byte alla volta in un sistema con bus a 64 bit e con memoria in fast page);
- raccogliendo i colori adiancenti (stessa riga, in sequenza) generati per il quadrilatero e che dovrebbero essere scritti in memoria, ma che si potrebbe evitare di scrivere subito e conservarli internamente finché il nuovo pixel da scrivere non farebbe parte di una zona di memoria diversa oppure se siamo arrivati alla fine della linea da renderizzare.
Non è possibile fare stime sui guadagni, perché ovviamente dipende dai vari casi, ma penso che l’implementazione di queste due ottimizzazioni farebbe lievitare sensibilmente il valore dei circa 14MPixel/s.
Uno scenario ibrido: disegnare i caratteri dei font
Un’estensione molto utile della nuova pipeline e, in generale, del modo in cui si disegnano i quadrilateri, è quella di poter disegnare i caratteri dei font per scrivere dei testi. Operazione comunissima nonché indispensabile, ma alquanto lenta con la grafica planare e, soprattutto, interamente a carico della CPU con quella packed/chunky.
In questo caso servirà utilizzare uno dei canali del Blitter, in questo caso il primo (A), per caricare la grafica monocromatica (un bitplane!) che rappresenta il corpo dei caratteri, il quale si scorrerà un bit/pixel alla volta e che indicherà se ci si troverà in presenza di un punto del carattere (che, quindi, dovrà essere disegnato) oppure no (lo schermo non dovrà essere modificato).
Tutto il resto funziona allo stesso modo, perché la grafica del carattere è assimilabile a un quadrilatero da tracciare sullo schermo, per cui sarà possibile ruotarlo e zoomarlo come abbiamo visto anche nell’articolo precedente.
Con la grafica packed/chunky bisogna, però, introdurre anche la modalità in cui i pixel dovranno essere tracciati, e specificamente:
- con un solo colore (sarà il primo dei quattro definiti in precedenza per il Gouraud shading);
- con due colori (in questo caso non ci sarà trasparenza: i pixel non appartenenti al carattere saranno tracciati, ma col secondo colore);
- con una texture associata al canale B (quindi è possibile disegnare font con motivi molto variegati, come ad esempio marmo, fuoco, ecc., senza averne una copia per ogni tipologia, come avveniva coi Kara Colorfont, se qualcuno se li ricorda).
Conclusioni
Con quest’ultima caratteristica si chiude anche questa serie. Da notare che in nessuna parte sono riportati dati sull’eventuale utilizzo della memoria VRAM. La ragione è che l’impiego di questo tipo di memoria non consente automaticamente di raddoppiare le prestazioni, come si potrebbe pensare, ma i vantaggi che ne derivano dipendono dal particolare scenario. Anche alcuni dati forniti con la documentazione dell’AAA non mostrano incrementi strettamente lineari, ma i risultati sono variabili. L’unica cosa certa è che ci sarebbero stati dei consistenti vantaggi nell’impiego di questa memoria (altrimenti non sarebbero state usate!), per cui numeri e speculazioni sono assenti.
A parte questo doveroso chiarimento, tante erano le lacune della nostra amata piattaforma, come s’è ampiamente visto, come pure tante le occasioni per migliorarle e che sono andate sprecate non soltanto per la miopia e inettitudine del management, ma anche del comparto tecnico che, con la dipartita del gruppo originale, ha mostrato incapacità nell’agire e nel decidere in che direzione andare, tra l’altro sdoganando interamente al management la colpa dei fallimenti e lavandosene le mani.
Chi è rimasto, invece, non era all’altezza e ha dimostrato di non avere adeguate capacità, com’è emerso in alcune interviste e racconti che sono stati raccolti e pubblicati in alcuni libri. Un esempio di quanto fossero inadeguati lo fornisce il responsabile a capo dei tecnici, Lew Eggebrecht, il cui giudizio riportato in uno di questi libri è a dir poco impietoso:
He (Eggebrecht, ndr) was also somewhat critical of Commodore’s hardware and software engineers, feeling they were “hardware hackers” and unprofessional…
Li definisce “hacker” e non professionali, e con ottime ragioni direi. Abbiamo visto, infatti, come fossero avvezzi a piazzare qualche brutta pezza per risolvere un certo problema, anziché pensare e implementare soluzioni migliori, più eleganti, e orientate al futuro.
Purtroppo il passato non si può cambiare, e ci teniamo stretti ciò che siamo riusciti a goderci, anche se la mente a volte si sofferma su ciò che si sarebbe potuto fare, perché non si rassegna ancora all’idea dell’enorme vantaggio con cui l’Amiga era partito e dell’immenso capitale che è andato dilapidato per l’incompetenza di tutti.
Lista dei precedenti articoli della serie
Le occasioni mancate per migliorare il chipset dell’Amiga – 1: l’audio
Le occasioni mancate per migliorare il chipset dell’Amiga – 2: la grafica
Le occasioni mancate per migliorare il chipset dell’Amiga – 3: le frequenze
Le occasioni mancate per migliorare il chipset dell’Amiga – 4: ampiezza dei dati in memoria
Le occasioni mancate per migliorare il chipset dell’Amiga – 5: le innovazioni di Commodore
