Le occasioni mancate per migliorare il chipset dell’Amiga – 5: le innovazioni di Commodore

Il precedente articolo sulla dimensione dei dati in memoria che possono essere letti o scritti dal chipset ha concluso la parte delle modifiche che, seppur piccole, avrebbero potuto contribuire a migliorare e a rendere molto più competitiva la nostra favolosa piattaforma, rilanciandola.

In realtà esiste un terzo fattore, oltre la frequenza di clock e al bus di memoria, che avrebbe consentito di andare ben oltre, ma prima di parlarne ritengo sia necessario affrontare un escursus su quanto Commodore ha fatto o abbia pensato di realizzare, per capire in che modo si è mossa con le stesse finalità. Ciò anche perché consente di aprire un velo su questo fattore e capire perché risulti così determinante.

1985-1986: Ranger

Il primo scossone ha provato a darlo lo stesso progettista principale della macchina, Jay Miner, che ha lavorato a un progetto che internamente veniva chiamato Ranger. Sul periodo di lavorazione non ci sono fonti precise, ma si parla del 1985 per gli inizi e si arriva fino al 1989, ma sembra che il progetto sia cancellato internamente verso la metà del 1986 e che alcune sue parti siano confluite in un altro riguardante l’alta definizione.

Purtroppo si trattava di un lavoro troppo ambizioso per l’epoca. I dati che circolano parlano di supporto a risoluzioni fino a 1024×1024 a 128 colori. Numeri esorbitanti se consideriamo i 320×200 a 64 colori (ma con una tavolozza di 32 colori. I 64 si ottengono con la modalità EHB) della macchina originale.

Per rendere l’idea e ipotizzando che lo schermo sia rinfrescato (visualizzato) 60 volte al secondo (60Hz/FPS), Ranger avrebbe richiesto poco più di 14 volte la banda di memoria rispetto a OCS (il chipset originale): un valore a dir poco stratosferico per quei tempi.

Questo è il motivo per cui sarebbe stato necessario far ricorso alle costose memorie VRAM (che idealmente potevano arrivare a raddoppiare la banda di memoria). Le quali, però, da sole non sarebbero bastate, avendo richiesto un bus dati ad almeno 32 bit. Aggiungendo questo si sarebbe arrivato a un fattore 4, che rimane ancora molto lontano dal 14.

A questo punto l’unica altra possibilità sarebbe stata quella di aumentare la frequenza delle memorie almeno di un fattore 3. Quindi sarebbero servite memorie a 90-95ns: forse disponibili all’epoca, ma certamente non in ambito mainstream/consumer.

Credo risulti evidente che non sia fantascienza, ma ci siamo molto vicini: si trattava di obiettivi realisticamente irrealizzabili. Si può essere visionari quanto si vuole, ma i progetti hanno bisogno di essere concretizzati in prodotti commercialmente realizzabili, e questo non lo era sicuramente.

E’ interessante notare (e annotare!), però, che portare la tavolozza dei colori da 32 a 128 avrebbe richiesto una certa quantità di transistor. Sempre a titolo di confronto, 128 colori rappresentano circa la metà di tutti i registri del chipset originale.

Si potrebbe pensare che si tratti anche questo di qualcosa non fattibile, ma fortunatamente i progressi tecnologici nel campo dei processi produttivi ci hanno consentito di raddoppiare ogni due anni il numero di transistor impacchettati nei chip (osservazione che ha portato alla Legge di Moore). Il che risulta compatibile con le tempistiche (il primo Amiga, il 1000, risale al 1985).

1987: Fat Agnus

Con l’arrivo dei modelli 500 a 2000, Commodore introduce anche una nuova versione del chip più importante del trio, Agnus, che in versione PLCC diventa un po’ più grosso:

della precedente versione DIP:

Sebbene siano passati due anni, purtroppo l’unica innovazione che porta è il supporto a 1MB di memoria anziché i precedenti 512kB. Con un grosso mah, perché francamente il lavoro che è stato fatto lascia un grande amaro in bocca.

Ciò perché in realtà questo MB è suddiviso in due parti: 512kB di memoria Chip (sempre presente in un Amiga) e 512kB di memoria Slow (com’è stata chiamata, giustamente) nel caso il sistema sia stato espanso (oppure è già presente, come nel caso dell’Amiga 2000).

La tragedia con quest’ultimo tipo di memoria è che si tratta del peggiore che sia stato concepito, poiché presenta soltanto gli svantaggi della memoria Chip e della memoria Fast, e nessun pregio (a parte mettere a disposizione un po’ di spazio in più).

Infatti lato processore funziona esattamente come la memoria Chip: la CPU è l’ultima ruota del carro, e può accedervi soltanto se nessun altro chip custom lo fa. Lato chipset non vi può accedere in nessun modo, perché soltanto il processore può farlo.

Si tratta, come si può vedere, di un altro “colpo di genio” degli ingegneri Commodore, i quali per risparmiare sul costo della circuiteria di rinfresco della memoria per questa memoria extra ne ha castrato pesantemente l’utilizzo, con un enorme impatto soprattutto in ambito videoludico.

1988: Fat Agnus con 1MB di memoria Chip

Il problema è stato risolto con la successiva versione:

che ha consentito di usare i 512kB extra come memoria Chip (scelta saggia, perché è quella che serviva maggiormente agli Amiga), ma la frittata ormai era stata fatta e i danni provocati enormi.

Questo perché tale memoria addizionale non è stata sfruttata come si sarebbe auspicato, se non dal s.o. e le applicazioni. I giochi, infatti, sono stati comunque sviluppati per la configurazione che si era ormai largamente diffusa: 512kB di memoria Chip, a cui si aggiungevano eventualmente i 512kB di memoria Slow (o Fast, se i programmatori erano abbastanza intelligenti da non considerare esclusivamente la Slow).

Le software house non potevano fare molto, considerato il parco macchine installate per il mercato Amiga, per cui i costi di sviluppo hanno dovuto tener conto di una sola configurazione supportata, e nient’altro.

Questo perché sviluppare un gioco per sfruttare al meglio un sistema con 512kB di Chip + 512kB di Slow/Fast e un altro con soltanto 1MB di Chip è abbastanza diverso e porta a risultati altrettanto distanti.

Con 1MB di Chip tutto diventa enormemente più facile, e in genere i programmatori devono pensare soltanto a come foraggiare i chip custom, dove il ruolo del processore assume soltanto quello di un puro loro servitore.

Con 512kB di Chip e 512k di Slow/Fast, invece, si cambia completamente approccio, in quanto tutti gli asset devono essere divisi sapientemente cercando di sfruttare meglio che si possa i soli 512kB di Chip a disposizione.

Gli altri 512kB di Slow/Fast si useranno per il codice (in genere), le strutture dati, e la partitura musicale, che però occupano poco spazio. Quello rimanente o resta inutilizzato (ed è tanto!) oppure si devono trovare modi ingegnosi per caricarci un po’ di asset, da copiare velocemente in piccoli buffer nella Chip e, quindi, renderli accessibili ai chip custom (cosa che ho dovuto fare, e pesantemente, coi giochi a cui ho lavorato: Fightin’ Spirit e USA Racing).

Un lavoro infernale per gli sviluppatori (che costa tempo e, quindi, soldi per la software house), a cui si aggiungono risultati che possono essere significativamente diversi (ad esempio Fightin’ Spirit avrebbe potuto avere 1/4 dello schermo col parallasse del pavimento, tipo Street Fighter II e diverse animazioni dello sfondo, con 1MB di Chip). Ciò ha scoraggiato a sfruttare come si deve i sistemi con 1MB di Chip, purtroppo.

1990: ECS

La commercializzazione dell’Amiga 3000 ha portato in dote anche il nuovo chipset ECS:

il quale introduce i seguenti cambiamenti e nuove funzionalità:

• fino a 2MB di memoria Chip;
• possibilità di lavorare su regioni rettangolari di 32768×32768 pixel per il Blitter (contro i 1008×1024 della precedente versione);
• supporto al genlock notevolmente migliorato;
• segnale video programmabile (anziché lavorare soltanto con quelli NTSC/PAL) per creare nuove modalità;
• supporto a modalità video con risoluzioni più elevate (VGA / 640×480 progressivo /non-interlacciato e Super-Hires 1280×200/256), sebbene con massimo 4 colori (da una tavolozza di soli 64 nel caso della Super-Hires);
• possibilità di posizionare gli sprite in maniera più granulare orizzontalmente in modalità Super-Hires;
• sprite visualizzabili ai bordi dello schermo;
• aggiunta di uno schermo Ultra-Hires e di uno sprite Ultra-Hires (che utilizzano memoria VRAM, oltre a diversi nuovi registri nei chip custom) per un secondo schermo indipendente.

Si tratta di parecchia nuova roba, come si può vedere, ma in realtà di ben poca utilità generale. L’Amiga è stato usatissimo in ambito di televisivo e di produzione video, per cui migliorare il supporto al genlock era sacrosanto, tenuto conto che la concorrenza non era rimasta ferma a guardare, ma rimane comunque una piccola (sebbene importante!) nicchia di mercato.

La programmabilità del segnale video e il supporto a risoluzioni più elevate è un chiaro tentativo di agganciare l’esplosione che hanno avuto i PC in termini di schede grafiche con l’introduzione della VGA, ma che non impatta molto il mercato Amiga (da sempre legato al segnale televisivo, NTSC/PAL/SECAM). Oltre al fatto che le nuove risoluzioni lasciano parecchio l’amaro in bocca a causa dei soli quattro colori visualizzabili.

Di scarsa utilità anche la possibilità di posizionare in maniera più fine gli sprite orizzontalmente. Alcuni giochi avrebbero potuto sfruttarla per un movimento più morbido di elementi come le nuvole del panorama, ad esempio, ma nulla di così impattante. Idem per la possibilità di visualizzare gli sprite nei bordi: utile magari per qualche demo, ma non per i giochi (che avevano già difficoltà a utilizzare i bordi per visualizzare la normale grafica. Caratteristica, questa, sicuramente più importante).

Ben poche anche le occasioni per poter sfruttare le maggiori aree del Blitter ECS, perché i giochi utilizzavano la bassa risoluzione (320×200 in NTSC e 320×256 in PAL) con al massimo 64 colori. Avrebbe fatto comodo al s.o. per spostare le finestre sullo schermo, ad esempio, ma anche qui con l’alta risoluzione e pochi colori (il Workbench ne usava solo quattro) avrebbe potuto risparmiare giusto qualche programmazione di questo coprocessore.

L’unica novità che sarebbe potuta esser apprezzata è il supporto ai 2MB di memoria Chip, ma essendo il chipset ECS arrivato originariamente solo con l’Amiga 3000, lo scarso numero di modelli venduti non ne avrebbe mai giustificato la produzione di giochi specifici (come già illustrato in precedenza con la versione da 1MB).

Una nota particolare meritano lo schermo e lo sprite Ultra-hires, che molto probabilmente derivano dal lavoro che era stato fatto col summenzionato chipset Ranger (complice anche l’uso della VRAM). Non se ne conosce alcun utilizzo, nonostante il notevole numero di registri a loro dedicati e, probabilmente, diversi transistor utilizzati per la sua implementazione. Talmente inutile che il futuro chipset AAA li aveva rimossi del tutto.

In sintesi e a ben cinque anni dall’introduzione del primo Amiga, la Commodore ha presentato soltanto una minestra riscaldata e niente di più (ricordo nuovamente che l’accesso alla memoria Chip rimane quella del 68000, castrando le prestazioni di tutti i nuovi processori di Motorola), ignorando completamente gli enormi passi avanti che, invece, erano stati fatti dalla concorrenza in tutti i campi/mercati.

1990: Amber

Il 3000 introduce, però, anche un chip nuovo di zecca (alla faccia del presunta direttiva della dirigenza Commodore: “read my lips, no new chips“. Mantra che è stato utilizzato da qualche ingegnere per scaricare la propria incapacità sul management):

che serve unicamente a convertire il segnale video generato da Denise (il chip deputato a questo scopo) da interlacciato a “progressivo” (non interlacciato e che utilizza i monitor multisync a 31khz ormai in voga nel mondo PC).

Si tratta di un pallido (e pure abbastanza costoso) tentativo di offrire risoluzioni come 640×400 (NTSC) o 640×512 (PAL) a 16 colori senza il fastidiosissimo interlacciamento e, quindi, papabili in ambito professionale.

Anziché investire tutte queste risorse in un chip completamente nuovo e riservato a una nicchia (anche se importante), sarebbe stato meglio dirottarle sull’ammodernamento del chipset originale, di cui si sarebbero avvantaggiati tutti, e con risultati di gran lunga migliori.

Infatti è stato un buco nell’acqua, successivamente e agevolmente superato dal chipset AGA, sebbene soltanto dopo due lunghi anni, considerato che nel frattempo la concorrenza sfornava prodotti decisamente migliori da questo punto vista (ricordo che i 640×480 progressivi a 16 colori li aveva già messi a disposizione IBM coi PC dotati di VGA nell’87).

1990-…: il DSP 3210 di AT&T

Per rimettersi in carreggiata in particolare sul versante audio, i suoi ingegneri hanno pensato bene (proprio “benissimo”!) di guardare altrove per risolvere l’ormai enorme divario che era stato scavato, trovandolo nel DSP 3210 di AT&T:

Di questo ne abbiamo già ampiamente parlato nel primo articolo della serie dedicato all’audio, per cui non serve aggiungere altro, se non che si tratta di un altro colpo di genio (!) delle menti brillanti che avevano preso in mano lo sviluppo della piattaforma dopo l’abbandono del gruppo originale.

Un chip che, alla fine, non ha mai visto impiego in nessun prodotto Commodore, in quanto sarebbe dovuto essere utilizzato in futuri prodotti, ma la casa è fallita nel 1994, per cui non se n’è fatto più niente ed è rimasto soltanto un esperimento.

1992: AGA

La commercializzazione degli Amiga 1200 e 4000 vede, invece, l’introduzione di un nuovo chipset:

che porta in dote diverse innovazioni. Ci son voluti ben sette anni (dall’OCS), ma finalmente è stato possibile mettere le mani e sfruttare qualcosa di realmente significativo:

• fino a 256 colori da una tavolozza di 16 milioni per tutte le risoluzioni (quindi anche Super-Hires, VGA, ecc.) grazie alla banda di memoria quadruplicata (fornita dal bus dati a 32 bit anche per il chipset, a cui si aggiunge l’uso della modalità fast page);
• modalità HAM estesa a 8 bit (HAM8) per visualizzare fino a 262 mila colori (sempre da 16 milioni);
• modalità Dual Playfield che arriva finalmente a 16 + 15 colori, con possibilità di scelta della tavolozza di colori da utilizzare dai 256 disponibili per il secondo schermo;
• sprite larghi fino a 64 pixel, con possibilità di scelta della tavolozza di colori da utilizzare dai 256 in maniera indipendente per quelli “pari” e “dispari”, e impostazione della risoluzione orizzontale da utilizzare per loro (es.: sprite in Super-Hires anche se lo schermo è in bassa risoluzione);
• possibilità di posizionare gli sprite e anche gli schermi in maniera più granulare orizzontalmente in tutte le risoluzioni;
• altri miglioramenti al genlock.

Sul genlock, come pure sugli sprite e schermi con posizionamento più granulare orizzontalmente valgono le stesse considerazioni già fatte riguardo l’ECS, a cui si affianca anche la scelta della risoluzione orizzontale degli sprite: caratteristiche di limitata utilità.

La parte del leone la fanno ovviamente le estensioni cromatiche che hanno fatto effettuare un balzo alla parte prettamente visiva (e solamente quella, purtroppo!) della piattaforma, che però rimane ancora parecchio indietro rispetto alla concorrenza, che già da anni ha potuto contare su modalità a 32/64 mila colori (High Color) e 16 milioni di colori (True Color), oltre a risoluzioni molto più elevate (come pure le frequenze di rinfresco del video).

Sempre per dare un’idea, le prime schede video SVGA (parliamo di ben 5 anni prima: il 1987) supportavano già risoluzioni come la 640×480 (progressiva; non interlacciata) con 256 colori, che è il massimo che l’AGA riesce a supportare con la banda di memoria a disposizione.

Ciò che rimane a dir poco imbarazzante è, poi, la capacità computazionale, che è rimasta esattamente la stessa: il Blitter non è cambiato di una virgola rispetto all’ECS (che a sua volta non è che fosse cambiato molto dall’OCS, come abbiamo visto), e quindi anche quello che riesce a fare a livello prestazionale.

L’unico vantaggio gli arriva indirettamente, dal fatto che la banda di memoria quadruplicata per la sola visualizzazione degli schermi gli consente di poter guadagnare più slot liberi per l’accesso alla memoria Chip a parità di risoluzione e numero di colori visualizzati (e manipolati), ma siamo molto lontani dalle sparate che si sono lette anche ai tempi (tipo Blitter a doppia velocità o addirittura quadrupla!).

Da calcoli che ho effettuato tempo fa e condivisi nel forum di Amigaworld (il più grande portale generalista per Amiga e surrogati), in bassa risoluzione (320×200/NTSC, 320×256/PAL) si poteva passare soltanto da 32 a 128 colori (da 5 a 7 bitplane) a parità di oggetti grafici renderizzati (quindi stesso numero e dimensione). Idem passando dal Dual Playfield OCS/ECS (8 + 7 colori) a quello AGA (16 + 15 colori): si potevano muovere all’incirca lo stesso numero di oggetti della medesima dimensione.

Detto in altri termini, preso un qualunque gioco Amiga a 32 colori oppure in Dual Playfield, si sarebbe potuto realizzare esattamente lo stesso gioco a 128 o 16 + 15 colori rispettivamente, ma senza poter aggiungere altri oggetti grafici a video, o visualizzarne di più grandi, ad esempio.

Se ci pensate bene non è certo un gran passo in avanti, a fronte della quadruplicazione della banda di accesso alla memoria (che, però, è stata riservata al solo controllore video. Ed è questa la piaga della piattaforma).

Tra l’altro l’uso della banda più elevata per il solo schermo comporta un salatissimo prezzo da pagare per quanto riguarda i giochi che utilizzano lo scorrimento orizzontale: si perdono 7 degli otto sprite a 4 colori se si usa la banda massima (4x. La più agognata e utile), quindi con un solo sprite a 4 colori utilizzabile. Uno scempio (!), che costringe i programmatori a dover fare a meno di queste preziose risorse e ripiegare sul Blitter (che, però, non può fare molto, come abbiamo visto).

Dulcis in fundo, i “meravigliosi” ingegneri di Commodore ci hanno regalato quanto di più inutile i programmatori di videogiochi potessero desiderare: sprite larghi 64 pixel. Che su uno schermo da 320 pixel orizzontali equivale a occuparne ben 1/5. Si potrebbe pensare che potrebbero andare bene per il cosiddetto “boss finale”, ma a fronte di un enorme spreco di memoria (perché non si può riutilizzare la grafica, come avviene con le tile: ecco perché servono sprite di piccola dimensione, da combinare per formare immagini più grandi, riciclando il più possibile la grafica).

Comunque la cosa più triste è che gli sprite rimangono sempre a 4 colori (tranne se combinati due alla volta, per arrivare a 16), quando sfruttando diversamente il doppio (banda 2x) o il quadruplo (banda 4x) di dati letti, si sarebbero potuti avere sprite rispettivamente a 16 o 256 colori (o, al più, a 16 colori e 32 pixel di larghezza con banda 4x invece dei canonici 16 pixel), che sarebbero stati di gran lunga più utili.

Il resto dei componenti, come già detto, non è assolutamente cambiato, per cui rimane un’altra grande, anzi grandissima occasione persa per far tornare competitiva la nostra piattaforma del cuore.

1992-…: AA+

A coprire almeno in parte le troppe lacune dell’AGA sarebbe dovuto essere il successivo chipset, chiamato AA+, il quale sarebbe dovuto arrivare nel 1994 per le nuove macchine a basso costo (per quelle top di gamma ci sarebbe stato l’AAA) e sarebbe stato anche compatibile al 100% col suo predecessore.

Non si sa molto delle sue caratteristiche (tutta l’attenzione, mediatica e di aspettativa degli utenti, era riservata all’AAA), ma da qualche intervista e presentazioni sono trapelate le seguenti:

• fino a 800×600 a 256 colori grazie alla banda raddoppiata rispetto all’AGA (quindi 8 volte la banda di OCS/ECS);
• modalità packed/chunky a 16 bit (32 mila colori), ma soltanto per risoluzioni fino a 640×480 (sempre a causa della limitata banda a disposizione);
• Blitter al doppio della velocità (con clock aumentato. Perché non si è parlato di versione a 32-bit);
• memoria Chip che arriva fino a 8 MB (rispetto ai 2MB);
• dischetti fino a 4MB a piena velocità;
• porte seriali dotate di buffer FIFO.

Tolte le seriali che finalmente avrebbero ricevuto il buffer FIFO a evitare i supplizi dovuti alla perdita di caratteri/byte durante le trasmissioni, i dischetti da 4MB sarebbero arrivati in un’epoca in cui l’uso dei dischi rigidi era ormai diventato la norma, e i CD stavano ormai prendendo piede come supporti di massa (considerato che il software richiedeva ormai parecchi dischetti per la distribuzione, a causa dei contenuti molto più “pesanti”).

Per il resto si tratta di specifiche appena decenti per delle macchine a basso costo, se teniamo conto del fatto che in altri due anni la concorrenza aveva ormai sfornato di molto meglio. Non è, però, un tentativo da buttare via in toto.

Infatti il Blitter con frequenza raddoppiata sembra andare nella giusta direzione, sebbene appaia un timido tentativo, se consideriamo che il chipset lavora adesso a frequenze doppie rispetto all’AGA, che a sua volta lavora al doppio della frequenza rispetto a OCS/ECS. D’altra parte è anche l’elemento chiave a livello prestazionale: se aumenti risoluzioni e/o colori, ma non hai abbastanza potenza di calcolo per manipolarli, è difficile pensare di utilizzarle proficuamente (come approfondiremo alla fine della sezione AAA).

Soprattutto se non supporti nemmeno la nuova modalità packed/chunky col nuovo Blitter, considerato che non se ne fa menzione da nessuna parte. Dunque a sobbarcarsi tutto l’onere avrebbe dovuto pensarci il processore, andando chiaramente a penalizzare le prestazioni complessive del sistema.

Poca roba, se i giochi fossero rimasti a 256 colori, ma in in questo caso rimane l’intoppo della grafica planare. Infatti si può usare solo questa: non esiste alcun riferimento a grafica packed/chunky a 8 bit / 256 colori, che fenomeni come Wolfenstein 3D prima e, soprattutto, Doom poi hanno usato per aprire fragorosamente le porte del 3D in ambito ludico / di massa.

Infine e pur con banda 8 volte quella di OCS/ECS, non viene riportato nulla riguardo gli sprite, i quali pur passando ai “64-bit” (banda 4x) dell’AGA avevano visto aumentare conseguentemente a 64 pixel la loro larghezza. Coerentemente, ci si sarebbe aspettato un aumento a 128 pixel, ma forse è meglio così: come già detto prima, 64 pixel erano già troppi, e con 128 pixel si sarebbe arrivati al ridicolo (e sempre a 4 colori).

1993: Akiko

A cercare di salvare la nave che navigava ormai in brutte acque avrebbe dovuto pensarci la prima console a 32 bit (e in assoluto) di casa: il CD32.

La quale proprio per cercare di recuperare qualcosa in ambito 3D è stata dotata di una circuiteria in grado di convertire la grafica packed/chunky (a 8 bit / 256 colori) in planare (l’unica in grado di essere usata dal chipset) all’interno di uno dei suoi chip, Akiko:

L’idea non sarebbe stata di per sé malvagia considerato che non c’era nessuna intenzione di modificare i chip per supportare direttamente la modalità packed/chunky (come sarebbe dovuto essere già da parecchio tempo, e con ciò intendo anche molto prima dell’avvento del 3D), ma la sua implementazione è stata clamorosamente sbagliata, in piena “tradizione” di pressapochismo e inettitudine degli ingegneri della casa.

I quali, infatti, hanno deciso di mettere in croce la CPU, costringendola a fornire gli 8 dati a 32 bit della grafica packed/chunky da convertire nei 32 bit per ciascuno degli 8 bitplane, che sempre la CPU avrebbe dovuto poi scrivere in memoria Chip (l’unica a disposizione in questa console).

Soluzione, questa, che ha di fatto castrato le prestazioni dell’operazione di conversione, dimezzandole. Oltre a bloccare completamente la CPU facendo da portantina per i dati che viaggiavano avanti e indietro nella memoria Chip.

La soluzione migliore sarebbe stata quella di fornire ad Akiko l’indirizzo dello schermo con la grafica packed/chunky, quello dello schermo in formato planare (con opportuno modulo per poter indirizzare correttamente gli 8 bitplane), e poi adoperare un canale DMA per la lettura e la scrittura dei dati, velocizzando il tutto (sarebbe stata richiesta la metà del tempo, per l’appunto), e al contempo sollevando completamente la CPU da questo compito ingrato e umiliante.

Gli ingegneri Commodore hanno, invece, “ignorato” (?) il fatto che Akiko fosse già dotato di capacità DMA (per la lettura dei dati provenienti dal CD), e si sono pure vantati di aver pensato alla loro soluzione durante una pausa pranzo nonché averla implementata in un giorno.

Non ci sarebbe altro da aggiungere perché la situazione si commenta da sé, ma una dichiarazione di Dave Haynie (ben noto tecnico che non ha certo bisogno di presentazioni) sull’argomento 3D, che è stata rilasciata in un’intervista, lascia a dir poco esterrefatti e sgomenti:

What was the earilest point you realised that games were going to go heavily into 3D and that the Amiga’s chipset was not going to be right for it (basicly when did you want to start work on a chipset geared up for 3D work?)?

Well, of course, I don’t do “big chip” design. I think the point at which we knew 3D would be important was probably a year or two before the CD32 shipped. 

Quindi i tecnici erano già a conoscenza dell’importanza del 3D nel chipset uno o addirittura due anni prima della commercializzazione del CD32 circa, ma… non hanno fatto assolutamente niente! E si sono ridotti all’ultimo momento con l’orribile pezza che hanno poi inserito in Akiko. Direi che ogni commento sia superfluo, a questo punto…

1988-…: AAA

D’altra parte la rivoluzione che avrebbe dovuto risolvere tutti questi problemi e riportare nuovamente alla ribalta la casa madre sarebbe dovuta arrivare poco dopo, nonostante una lunghissima attesa, visto che il progetto era iniziato già nel 1988 (altre fonti riportano il 1989). Anche se c’è da dire che era stato messo in pausa alcune volte per dirottare gli ingegneri su altri progetti più urgenti da completare, o per mancanza di fondi per continuarne lo sviluppo.

Singolare risulta, però, un’affermazione fatta dal responsabile tecnico di Commodore, Lew Eggebrecht, in un’intervista di Gennaio 1993:

Tell me about AAA – it’s been worked on since 1989?

Yes, we worked on it from an architectural point of view for a long time but it’s only been serious for about a year. It was obvious that AAA was not going to meet our cost targets for the mid to low end systems. We wanted to continue that development an d we also had to have an enhancement quickly so, AA was the solution to that problem. It would have been nice to have AAA at the same time as AA but we just couldn’t get there.

Quindi hanno cominciato a lavorarci seriamente soltanto da un anno (dall’intervista. Quindi il 1992), mentre prima si sono cimentati su discussioni sopra i massimi sistemi, evidentemente. Cosa peraltro nota, perché è trapelato che già da anni gli ingegneri non sapessero quale direzione prendere in merito all’evoluzione dell’hardware: la confusione regnava felice.

Come emerge sempre dalla stessa intervista, e in particolare anche dalla parte qui citata dove viene candidamente ammesso che “ovviamente” (!) l’AAA era un progetto troppo grosso/complesso per i sistemi che erano i principali obiettivi della casa (quelli più economici). Talmente ovvio, da aver richiesto un po’ di anni per prenderne finalmente coscienza…

Comunque lo si può vedere tranquillamente dall’enorme lista di migliorie e nuove funzionalità (prese dal documento tecnico scritto da Haynie) che avrebbe dovuto introdurre (togliendo quelle già citate per l’AA+, che sono qui incorporate e per le quali valgono le medesime considerazioni):

• bus dati a 32 e 64 bit con uso di VRAM e clock fino a 114Mhz, consentendo risoluzioni fino a 1280×1024 a 32768 colori a seconda delle configurazioni (si va dal singolo sistema con memorie DRAM, fino al doppio sistema con VRAM);
• packed/chunky pixel a 2, 4, 8, e 16 bit (4, 16, 256 e 32768 colori, rispettivamente), incluso HAM8;
• modalità “ibrida” packed/planare a 24 bit (3 “byteplane“: uno per componente cromatica, usando un byte per memorizzarne l’intensità) per visualizzare finalmente 16 milioni di colori senza limiti;
• modalità grafiche “compresse”;
• modalità HAM estesa a 10 bit (per immagini con 16 milioni di colori);
• estensione dei bitplane da 8 a 16 per supportare schermi Dual Playfield fino a 256 colori ciascuno (8 + 8 bitplane), e l’HAM10 (che richiede 10 bitplane, per l’appunto);
• frame grabber per catturare immagini & video in modalità packed/chunky;
• genlock integrato e un bitplane addizionale di “overlay” (probabilmente proprio per il genlock);
• sprite fino a 128 pixel di larghezza;
• Blitter a 32 bit e con prestazioni parecchie volte quelle di OCS/ECS (sembra fino a 8 volte, anche se non ci sono informazioni chiare in merito), con supporto a grafica planare e packed/chunky, e a diverse operazioni applicabili in quest’ultimo caso (ordinamento, somma, media, ecc.);
• Copper in grado di impostare i nuovi registri a 32 bit, con possibilità di operare su più registri con una sola istruzione. Inoltre è in grado di lavorare su richiesta del Blitter (quando questi abbia finito un’operazione, per prenderne in carico un’altra);
• 8 canali audio a 16 bit fino a 64kHz, con volume sinistro e destro indipendente fino a 12 bit, e possibilità di campionare audio a 8 bit;
• fino a 16MB di memoria Chip;
• porta per il lettore CD.

Non è difficile rendersi conto del perché sia stato un altro fallimento e non abbia mai visto la luce, dopo tutti questi anni di lavorazione più o meno alacre: un progetto mastodontico, che avrebbe richiesto chip da circa un milione di transistor (quindi molto costoso) e nonostante tutto nemmeno così competitivo.

Peraltro gli stessi ingegneri erano consapevoli che, a fronte di una mostruosa complessità nonché costo elevato, l’AAA non sarebbe stato niente di particolare se fosse stato commercializzato nel 1994. Sempre dalla stessa intervista di Haynie:

During the AAA development, it was pretty clear AAA would be nothing special if it ever did ship, at least not in raw specs. In 1988, a 64-bit chipset that could do 1280×1024@60Hz, with 11 bits/pixel, would have been something. In 1994, the earliest ship date had C= not failed, it would have been an expensive also-ran (four chips for a 32-bit system, six for a 64-bit system, and you needed VRAM for performance).

“Only Amiga Engineers Make it Possible!“

Cosa bolliva in pentola con l’AAA

Comunque, e tornando alle caratteristiche tecniche, è degno di nota l’arrivo dell’agognata grafica packed/chunky, con tutti i tagli fino ai 16 bit. Si colma una gigantesca lacuna, anche se in netto ritardo, ma gli ingegneri hanno deciso di strafare supportando anche il formato a 2 bit (4 colori) e 4 bit (16 colori). Roba che sarebbe servita a fine anni 80′ – inizio anni ’90 (ed esclusivamente per i 16 colori!), ma del tutto irrilevante dopo, quando ormai la grafica s’era spostata come minimo sui 256 colori, e anche più. Si vede che avevano tempo da perdere e transistor da buttare via…

… che avrebbero potuti esser impiegati per supportare il formato True Color a 24 o 32 bit in versione packed, com’è comune trovare in qualunque altro sistema. Invece hanno aggiunto il formato ibrido a 24 bit, ma con le tre componenti cromatiche (rosso, verde e blu) distribuite su quelli che vengono chiamati byteplane, dove ogni byte rappresenta l’intensità della specifica componente colore. Un formato nato per castrare notevolmente le prestazioni del sistema, poiché manipolare pixel in questo modo può comportare fino al triplo di banda necessaria (a seconda dell’operazione), nonché maggiori calcoli a carico della CPU (su questo ci sono maggiori dettagli dopo).

Di scarsa utilità sono le nuove modalità compresse, perché possono essere impiegate soltanto per visualizzare immagini statiche (o animazioni precalcolate), com’è già avvenuto con la famosa modalità HAM (OCS/ECS) e HAM8 (AGA), che qui è stata estesa a 10 bit in modo da dare la possibilità di visualizzare 16 milioni di colori (contro i 262 mila da una tavolozza di 16 milioni della precedente HAM8).

Anche il framegrabber per catturare immagini, il genlock integrato, e il bitplane di overlay rappresentano funzionalità estremamente di nicchia e, quindi, inutili ai più, anche se c’è da dire che da sempre l’Amiga è stato sinonimo di video, per cui avrebbe avuto senso migliorare la piattaforma da questo punto di vista (sebbene in grande ritardo).

Invece al novero delle scelte insensate si aggiunge senz’altro quella di aver raddoppiato il numero di bitplane, portandoli a ben 16 dagli 8 dell’AGA. Se c’è una cosa che tutti gli ingegneri Commodore (nessuno escluso!) hanno dimostrato di non aver mai capito è che la grafica planare ha di gran lunga più svantaggi rispetto a quella packed/chunky, di quanti (modestissimi) vantaggi possa portare, aggiungendo notevole complessità non soltanto al sistema, ma anche ai programmatori per gestirli tutti, e ovviamente con pessime ricadute in ambito prestazionale e di spazio occupato. La scelta probabilmente è stata dettata dall’introduzione della modalità Dual Playfield a 256 + 256 colori (e per l’HAM10), ma sarebbe stato molto meglio se avesse usato due byteplane (e due bitplane + un byteplane per l’HAM10), risolvendo elegantemente ed efficientemente il problema.

Sugli sprite da 128 pixel credo che ci sia veramente poco da aggiungere rispetto a quanto espresso in precedenza sullo stesso argomento riguardo al chipset AGA, a parte che da (ex) sviluppatore di videogiochi trovo veramente deprimente vedere come si siano buttate risorse su funzionalità praticamente inutili, andando in una direzione completamente sbagliata.

E’ stato molto piacevole, invece, scovare nel documento tecnico dell’AAA dei miglioramenti al Copper che sono stati lungamente auspicati, come ho riportato anche in alcuni precedenti articoli. Mi riferisco, nello specifico, alla possibilità di poter impostare più registri con la medesima istruzione di questo coprocessore. Non particolarmente interessante, invece, la sua capacità di essere risvegliato quando il Blitter ha completato il suo lavoro, e questo perché il Copper è nato per “perseguitare” il pennello elettronico, dunque rimanere sincronizzato al video è il suo scopo principale, ed essere interrotto in qualsiasi momento per fare altro lo trovo a dir poco pericoloso; però in assenza di altri dettagli la mia analisi finisce qui.

Anche sul fronte completamente diverso, quello dell’audio, sarebbero finalmente arrivati cambiamenti epocali, considerato che questo componente non ha mai subito alcuna modifica da quando l’Amiga è nato. Oltre ai lungamente sognati 8 canali, infatti, arrivano pure i campioni a 16 bit, e frequenze più elevate (64kHz: si supera la “qualità CD”, che era l’obiettivo minimo da un po’ di anni). Il tutto si arricchisse del controllo più granulare del volume, che passa da 64 a 4096 livelli, nonché dall’altra nonché altrettanto attesa possibilità di riprodurre un canale liberamente a sinistra e/o destra. Innovazioni che sembrano assurde, visto che contraddicono completamente le diverse dichiarazioni di voler passare al DSP di AT&T per migliorare il comparto audio (schizofrenia dilagante?), ma che da sviluppatore di lunga data, invece, approvo senz’altro, perché si mantiene la coerenza e l’identità della piattaforma, sebbene 8 canali nel ’94 siano oggettivamente troppo pochi ormai.

Con grafica e audio parecchio “appesantiti” era inevitabile che si pensasse anche di espandere la quantità di memoria Chip (ricordo che è l’unica accessibile dai chip custom) a ben 16MB, per contenere gli asset sempre più cicciottelli. D’altra parte il supporto al CD-ROM non è stato aggiunto anch’esso per caso, ma per venire incontro alle grandemente mutate esigenze di archiviazione dei dati (in particolare di quelli multimediali). Dunque entrambe le aggiunte sono certamente sacrosante e benvenute.

Focus sul Blitter e le prestazioni dell’AAA

Infine il Blitter. L’ho lasciato per ultimo perché, a mio modesto avviso, rappresenta l’elemento centrale e più importante di tutta l’architettura dell’Amiga: quello che si è sempre occupato del lavoro più oneroso e che, quindi, si è cercato di sfruttare al meglio e il più possibile. Come già riportato qui sopra, non ci sono chiare indicazioni sulle sue prestazioni, ma in qualche intervista si parla di 8 volte la velocità di quello originale (in OCS/ECS), che ovviamente deriva dall’estensione da 16 a 32 bit (che, però, non è sempre sfruttabile, come già dimostrato nel precedente articolo) e da frequenze di lavoro quadruplicate. Inoltre supporta anche le modalità packed/chunky, e nel caso di quella a 16 bit (e solo per questa, per lo meno da ciò che traspare dal documento tecnico di Haynie, che si riferisce esclusivamente alla modalità “Chunky” in questo caso) consentirebbe di applicare diverse operazioni sui dati letti dai canali.

Non v’è dubbio che sia davvero tanta roba, ma questo sempre nell’ottica del confronto con la versione precedente, che però risale a ben 9 anni prima (il 1985). Nel frattempo l’evoluzione tecnologica ha portato prima a passare ai 256 colori, poi ai 32/64 mila (High Color) e infine ai 16 milioni (True Color. In salsa 24 e 32 bit. Quest’ultimo con l’aggiunta del canale alpha per specificare la trasparenza/opacità del colore). Da questo punto vista e mancando il supporto diretto al True Color da parte del controllore video, che è stato implementato soltanto con la suddetta modalità ibrida a 24 bit (3 byteplane = 3 x byte), non è stato implementato nemmeno nel Blitter, per cui non è possibile applicare le nuove operazioni sui canali (che nella modalità ibrida sono trattati come grafica packed/chunky a 8 bit = 1 byte), oltre alle ridotte prestazioni generali che sono causate dalla suddivisione in tre parti della grafica a 24 bit.

Proprio le prestazioni sono l’aspetto cruciale che, purtroppo, non ha avuto un adeguamento corrispondente alle migliorie apportate in termini di colori visualizzati e di risoluzioni. Per capire quanto scarse siano le prestazioni del nuovo Blitter bisogna rapportarle all’incremento dell’aspetto puramente visivo che si è avuto dall’OCS del’85 all’AAA del’94. Se nell’85 si realizzavano giochi con risoluzioni da 320×200 a 60 fotogrammi al secondo e con 5 bitplane = 32 colori (sto prendendo questo scenario come esempio a scopo puramente divulgativo, senza scendere troppo nella complessità dei vari giochi per Amiga), con la versione base dell’AAA (quindi con singolo chipset e memorie DRAM) è possibile arrivare a 800×560 a 10 bitplane, pari a ben 14 volte. Anche nell’ipotesi di utilizzare la grafica packed, che fa risparmiare circa il 25% di banda rispetto a quella planare nelle elaborazioni più complesse, sarebbe comunque un fattore 10 che rimane superiore all’8 del nuovo Blitter. Se poi passiamo alla configurazione massima, con doppio chipset e memorie VRAM, si arriva a 1280×1024 a 16 bit, il fattore diventa quasi 66 e il confronto, a questo punto, diventa imbarazzante.

I numeri forse non rendono chiaro quale sia il problema, ma cambiando prospettiva forse è più facile rendersi conto del perché un Blitter che è al massimo 8 volte più veloce risulti inadeguato. Il concetto su cui bisogna riporre l’attenzione è ciò che si poteva fare nell’85 con l’OCS. Se, ad esempio, si potevano muovere 10 oggetti grafici di una certa dimensione su quello schermo e con quei colori (32), per poter fare la stessa, identica, cosa ma proporzionalmente su uno schermo 800×560 e col doppio di colori (10 bitplane), allora servirà un Blitter 14 volte più veloce. Altrimenti si dovrà necessariamente tagliare qualcosa: muovere meno oggetti e/o ridurne la dimensione e/o ridurre il numero di colori utilizzati. Non si scappa, perché non c’è abbastanza potenza di calcolo.

Ecco perché sarebbe stato fondamentale aumentare molto di più le prestazioni del Blitter, con frequenze d’esercizio più elevate e, nel caso del doppio chipset, anche la dimensione dei dati manipolati. Il problema è che, in quest’ultimo caso, gli ingegneri Commodore hanno ancora una volta pensato bene di semplificarsi la vita, riservando il bus a 64 bit esclusivamente ai chip del controllore video (quindi similmente a quanto fatto con l’AGA) e lasciando agli altri chip (gli equivalenti di Agnus = Blitter & Copper e Paula = audio & disco) soltanto l’accesso a 32 bit.

Se c’è una cosa su cui sono sempre stati molto bravi è stata quella di tirare fuori piattaforme decisamente castrate…

1993-…: Hombre

Se fosse mai arrivato alla luce, l’AAA sarebbe stato comunque l’ultimo chipset per Amiga, in quanto Commodore aveva già deciso di stravolgere tutto e cambiare completamente sistema, dando il benservito all’esistente: sia ai chip custom che hanno inaugurato la bellissima avventura con l’Amiga 1000, sia il processore di casa Motorola.

Infatti era in sviluppo una piattaforma completamente nuova, chiamata internamente Hombre, basata su un versione personalizzata delle CPU PA-RISC di HP, a cui era affiancato uno o più chip custom per gestire la grafica (con una forte vocazione al 3D) e il sonoro.

Mi fermo qui, perché preferisco non andare oltre con una sua disamina, in quanto non sarebbe stata un’evoluzione delle macchine che ben conosciamo, ma qualcosa di totalmente nuovo. Tant’è che il titolo dei documenti tecnici è un eloquente: “Beyond Amiga“.

Conclusioni

Poiché questa serie parla di Amiga, e non di altro, l’analisi delle varie innovazioni, che sono state portate o pianificate da Commodore per la nostra adorata piattaforma, finisce qui. Il prossimo esporrà la mia visione su quando e come probabilmente si sarebbero potute introdurre delle migliorie tenendo conto dei requisiti e dei limiti tecnologici del tempo.