Amiga AGA: più colori, nuovi limiti e l’ultima evoluzione dei chipset Commodore

Nel 1992 AGA portò sugli Amiga una tavolozza da 16,8 milioni di colori, schermi a 256 colori e nuovi margini per giochi, grafica e demoscene. Fu un aggiornamento importante, ma non una rivoluzione completa: per capire l’A1200, l’A4000 e il CD32 bisogna distinguere ciò che Alice e Lisa cambiarono da quello che rimase legato all’architettura originale.

Per molti appassionati il passaggio da un Amiga 500 a un Amiga 1200 è rimasto impresso prima di tutto nei colori. Immagini più ricche, sfumature più fini, schermate che sembravano appartenere a una generazione diversa. Quella sensazione aveva un fondamento tecnico: AGA ampliava sensibilmente le possibilità della grafica nativa Amiga.

La stessa sigla è però diventata il contenitore di aspettative e delusioni molto diverse. C’è chi la ricorda come un salto incompleto, chi come il punto più alto del 2D Commodore, chi come una piattaforma sfruttata davvero soltanto dopo la fine dell’azienda. Per valutarla serve andare oltre il numero dei colori e osservare il percorso completo: memoria, lettura dello schermo, disegno delle immagini, processore, software e monitor.

AGA non era una scheda grafica autonoma paragonabile a una GPU moderna. Era un’evoluzione del sistema di coprocessori Amiga, costruita per continuare a dialogare con una grande eredità hardware e software. Proprio questa continuità fu insieme il suo vantaggio più immediato e il suo limite più difficile da superare.

1992: l’arrivo di AGA non fu un solo lancio

Advanced Graphics Architecture è il nome con cui conosciamo il chipset che nei materiali tecnici Commodore compare spesso come AA, Advanced Amiga. La documentazione circolata fra gli sviluppatori conserva anche il riferimento a Pandora. Sigle e nomi non identificano necessariamente progetti distinti: bisogna leggerli nel contesto dei documenti.

L’A4000 fu presentato al World of Commodore di Pasadena l’11 settembre 1992. L’A1200 arrivò nell’ottobre dello stesso anno. È quindi scorretto descriverli semplicemente come due macchine annunciate insieme il 21 ottobre. Presentazione, disponibilità commerciale e arrivo nei diversi mercati possono inoltre avere date differenti. Fonte: comunicato Commodore dell’11 settembre 1992, conservato nell’archivio Usenet.

Nel 1993 il CD32 trasferì la stessa generazione grafica in una console su CD. Nel 1994 comparve anche l’A4000T di Commodore; la successiva produzione Amiga Technologies, nell’epoca Escom, mantenne AGA. Il fallimento del 29 aprile 1994 interruppe la continuità dell’azienda originaria, non cancellò l’hardware già venduto né impedì ogni successiva produzione.

La relazione con AAA va trattata con altrettanta cautela. AGA fu la soluzione effettivamente commercializzata mentre lo sviluppo di architetture più ambiziose rimaneva incompiuto. Ridurre tutto alla formula «nel 1991 AAA fu cancellato e sostituito da AGA» nasconde sovrapposizioni, revisioni e tempi di sviluppo diversi.

Alice, Lisa e Paula: che cosa cambiò davvero

Le due novità principali erano Alice, erede di Agnus, e Lisa, erede di Denise. Alice organizzava accessi e temporizzazioni della memoria condivisa e ospitava le funzioni legate a DMA, Copper e blitter. Lisa trasformava i dati grafici in uscita video, gestendo le nuove possibilità di colori, bitplane e sprite.

Paula rimaneva invece sostanzialmente quella della generazione precedente. Continuava a fornire l’audio campionato con quattro canali DMA a 8 bit, oltre alle altre funzioni storiche del chip. L’evoluzione grafica non corrispondeva dunque a un raddoppio automatico delle voci audio o a un nuovo sistema sonoro a 16 bit.

Il sistema completo comprendeva anche logiche specifiche della macchina: per esempio Budgie e Gayle nell’A1200. Parlare di «Alice e Lisa» è utile per identificare il salto grafico, ma non descrive tutta la scheda madre. Un chipset più capace vive dentro un computer, con un proprio processore, collegamenti, arbitraggio e memoria.

Le specifiche e gli schemi di servizio sono importanti proprio perché separano questi ruoli. Evitano di attribuire a Lisa ogni operazione sulla memoria o di trasferire al blitter le nuove capacità del percorso di visualizzazione. Fonte: documentazione di servizio Commodore A1200, specifiche funzionali e schemi.

256 colori scelti da una tavolozza a 24 bit

La differenza più facile da vedere era la palette. OCS ed ECS usavano, per la grafica ordinaria, 32 registri colore RGB a 12 bit: 4.096 combinazioni possibili, con quattro bit per componente. AGA portava la tavolozza a 256 voci RGB a 24 bit: otto bit per rosso, verde e blu, per 16.777.216 combinazioni.

Nel normale schermo indicizzato un pixel non contiene direttamente il suo colore RGB. Contiene un indice che sceglie una voce della palette. Con otto bitplane si possono rappresentare 256 indici differenti; il contenuto dei registri stabilisce i colori associati. Questo spiega perché «palette da 16,8 milioni di colori» non significhi «16,8 milioni di pixel liberamente colorabili in true color».

Per la pixel art il vantaggio era comunque enorme: più sfumature disponibili e una scelta molto più fine per ciascuna. La qualità non dipendeva soltanto dalla quantità, ma da come un artista distribuiva luci, ombre e transizioni. Il dithering rimaneva una scelta espressiva e tecnica, non diventava improvvisamente inutile.

Le funzioni grafiche del sistema operativo vennero estese per le nuove profondità e palette. Non era necessario programmare ogni registro a mano per aprire uno schermo AGA. La documentazione di AmigaOS sottolinea sia le nuove modalità sia l’importanza dei driver e del monitor effettivamente disponibili. Fonte: manuale AmigaOS, sezione Monitors e informazioni AGA.

HAM8: molti più colori, ma non un framebuffer RGB

Hold-And-Modify seguiva un’altra strada. In HAM un pixel può selezionare un colore di base oppure modificare una componente del colore precedente. È un modo per descrivere immagini ricche usando meno dati di un framebuffer nel quale ogni pixel abbia tre componenti indipendenti.

HAM8 usa otto bitplane: due bit specificano l’operazione e sei forniscono l’indice di base o il valore di modifica. Le modifiche agiscono sui sei bit più significativi della componente; i due meno significativi conservano l’informazione precedente. Per questo il consueto riferimento a 262.144 colori, equivalente a sei bit per tre componenti, è una sintesi utile ma non esaurisce tutte le combinazioni raggiungibili usando opportunamente i colori di base a 24 bit.

Il limite decisivo rimane la dipendenza orizzontale. Cambiare un pixel può influenzare il modo in cui si costruiscono quelli successivi. Le frange cromatiche non sono un difetto misterioso della macchina: derivano dal metodo di codifica. HAM8 è interessante per immagini, animazioni e tecniche mirate; non equivale a una superficie true color nella quale aggiornare liberamente ogni punto senza conseguenze sui vicini. Fonte tecnica: HowToCode, sezione AGA/HAM8.

I bitplane restano: perché AGA non era chunky

Il formato dello schermo rimaneva planare. Ogni bitplane contiene un bit per pixel; i bit dei diversi piani, letti insieme, formano l’indice colore. Con quattro piani si rappresentano 16 indici, con cinque 32, con otto 256. Non c’è nulla di «scoperto» o anomalo nell’usare sette piani per 128 colori: è una possibilità ordinaria della nuova architettura.

Questa organizzazione era adatta a molti effetti 2D. Si potevano trattare piani separati, ridurre i dati quando bastavano pochi colori, sovrapporre playfield e sfruttare lo scrolling. Un renderer 3D che calcola il colore completo di ciascun pixel preferisce invece spesso una memoria chunky, con il valore del pixel raccolto in un elemento consecutivo.

Da qui il costo della conversione chunky-to-planar, o C2P: riorganizzare i bit prodotti dal renderer nel formato letto dal display. La conversione è soltanto una parte del problema. Restano trasformazioni geometriche, visibilità, texture, illuminazione e scritture in memoria. Per valutare una demo o un gioco bisogna distinguere il tempo speso a costruire l’immagine da quello speso a convertirla e mostrarla.

Bus più largo e fetch più efficienti non rendono tutto quattro volte più veloce

AGA ampliava il percorso dati e sfruttava le memorie fast-page per leggere più informazioni grafiche. Nei modi di fetch più larghi si ottenevano più dati per la visualizzazione rispetto al vecchio percorso a 16 bit. Questo rendeva praticabili schermi più profondi e sprite più ampi.

Il registro FMODE controlla i modi di prelievo dei bitplane e degli sprite. È importante distinguere un fetch da 64 bit dal bus fisico: la lettura può raccogliere due trasferimenti a 32 bit in page mode. Non ne deriva un bus universale a 64 bit, né un blitter nuovo capace di eseguire ogni operazione a quella larghezza.

Il blitter rimaneva infatti una delle componenti meno rinnovate. L’aumento della capacità di alimentare Lisa non trasformava automaticamente la velocità di copia e combinazione delle bitmap. Il display poteva leggere più dati, ma quegli stessi dati dovevano essere preparati dalla CPU o dal blitter, contendendosi la Chip RAM con gli altri canali DMA.

Per questo cifre isolate come «banda quadrupla» devono indicare quale percorso e quale operazione si stiano misurando. Non sono una misura delle prestazioni generali. Le tabelle che assegnano indiscriminatamente decine o centinaia di megabyte al secondo a tutto il chipset confondono clock, larghezza, burst e banda realmente utilizzabile. Riscontro: documentazione AA/Pandora, riepilogo delle caratteristiche e registro FMODE, conservata nel progetto Minimig-MiST.

Sprite più larghi, due playfield e Copper

I canali sprite restavano otto, ma AGA permetteva larghezze di 16, 32 o 64 pixel e una risoluzione selezionabile indipendentemente da quella del playfield. Le coppie di sprite attached conservavano la possibilità di costruire oggetti con più colori. Migliorava inoltre la scelta delle banche della palette per sprite pari e dispari.

«Otto canali» non significa necessariamente otto soli oggetti in tutto il quadro: il riutilizzo dei canali rimaneva parte del mestiere del programmatore, con limiti di timing e sovrapposizione. Il numero sulla scheda tecnica non descrive da solo una scena completa.

Nel dual playfield si potevano usare due gruppi da quattro bitplane: due superfici con 16 codici ciascuna, dei quali il codice trasparente partecipa alla composizione. Non due superfici indipendenti da 256 colori. La differenza rispetto ai vecchi playfield era utile, ma aveva un costo e regole precise.

Il Copper continuava a sincronizzare modifiche ai registri con la scansione. Cambi di palette, finestre e scorrimenti potevano fare molto più di quanto suggerisse una schermata statica. Questo non significa che ogni effetto fosse un trucco non documentato: spesso era un uso consapevole delle capacità previste. Per le particolarità dei registri occorrono invece codice, condizioni di prova e riscontri riproducibili. Fonte: precisazioni del programmatore Commodore Spencer Shanson, febbraio 1993.

Risoluzione, frequenza e monitor: i numeri vanno letti insieme

AGA non si riassume in una sola «risoluzione massima». Uno schermo PAL a 320×256, uno interlacciato a 640×512 e un modo per monitor a scansione diversa non hanno gli stessi tempi né la stessa banda disponibile. Overscan, numero di colori e frequenze completano il quadro.

La brochure Commodore dell’A4000 elenca modi PAL, NTSC e VGA, compresi 800×600 e risoluzioni orizzontali fino a 1280 pixel. Non è una promessa che ogni monitor possa mostrare qualunque combinazione senza sfarfallio. In particolare, l’interlacciamento alterna i campi e può rendere fastidiosi testi e linee sottili.

Nuovi driver e supporto allo scan-doubling ampliarono le possibilità. Non trasformarono però l’uscita nativa in una moderna porta digitale né eliminarono ogni incompatibilità con i monitor. Parlare genericamente di «1280×1024 AGA» senza modo video, frequenza e condizioni di uscita è meno informativo che descrivere uno schermo realmente utilizzabile. Fonte: brochure tecnica originale Commodore A4000.

Quattro macchine, esperienze molto diverse

Condividere AGA non significava avere le stesse prestazioni. Il processore e la Fast RAM potevano cambiare radicalmente il risultato, soprattutto nel 3D e nelle applicazioni. La Chip RAM era accessibile ai coprocessori; la Fast RAM offriva alla CPU un’area non contesa nello stesso modo dal chipset.

Macchina	Configurazione caratteristica	Che cosa non va confuso
Amiga 1200	68EC020 a circa 14 MHz, 2 MB Chip RAM, IDE integrata, PCMCIA e connettore d’espansione inferiore.	Non aveva di serie 512 KB aggiuntivi di Slow RAM; acceleratore e Fast RAM erano espansioni.
Amiga 4000	Versioni 68040 e 68EC030, 2 MB Chip RAM, espansione Fast RAM e slot Zorro III.	La CPU era su modulo; la dotazione di memoria dipendeva dalla configurazione, non dalla sola sigla AGA.
Amiga 4000T	Declinazione tower professionale, prima Commodore e poi Amiga Technologies, sempre con AGA.	Il tower non introdusse un chipset grafico successivo; le varianti e le schede CPU vanno distinte.
Amiga CD32	68EC020, 2 MB Chip RAM, lettore CD e chip Akiko.	La musica da CD non aggiungeva nuovi canali PCM a Paula; Akiko non era un secondo blitter.

La configurazione dell’A1200 è documentata dal manuale di servizio; quella dell’A4000 dalla brochure Commodore. Il CD32 ha una propria documentazione di sistema. Per il tower, occorre distinguere la macchina Commodore dalle successive produzioni Amiga Technologies. Riferimento aggiuntivo: Amiga Hardware Database, A4000T e varianti.

CD32 e Akiko: la C2P esisteva, il secondo blitter no

Akiko era una logica d’integrazione specifica del CD32. Gestiva collegamenti e controlli del sistema, l’interfaccia con il lettore CD e una memoria di conversione per aiutare il passaggio chunky-to-planar. La documentazione Commodore la descrive come una funzione di corner turn.

Il suo scopo non era disegnare autonomamente poligoni, aggiungere un blitter 3D o rendere AGA nativamente chunky. La CPU doveva alimentare la conversione e recuperare i dati riorganizzati. Il vantaggio effettivo dipendeva quindi dall’implementazione e dagli altri costi della pipeline.

Anche il suono richiede una distinzione. Il CD32 poteva riprodurre audio stereo a 16 bit da CD, ma Paula conservava i quattro canali campionati a 8 bit. Sono percorsi differenti, non una trasformazione del chip audio. E la console non era letteralmente un A1200 al quale era stata soltanto tolta la tastiera: condivideva il nucleo di quella generazione, ma aveva una propria integrazione hardware. Fonte primaria: documentazione Commodore CD32, System Specifications e Akiko Specification.

Giochi: quali mostrano davvero la differenza AGA?

Per descrivere l’impatto di AGA bisogna distinguere fra un gioco che funziona su A1200, una versione migliorata e un titolo che richiede quel chipset. La compatibilità con una macchina nuova non dimostra l’uso dei suoi otto bitplane. Neppure una confezione CD32 garantisce automaticamente una grafica ridisegnata: il CD poteva servire anche a musica, sequenze e distribuzione.

Alien Breed II: The Horror Continues è un esempio utile perché esiste in versioni ECS e AGA. Permette di parlare di adattamento alla nuova generazione senza confondere l’intera serie con un solo requisito hardware. La stessa Team17 continua a distinguere queste versioni nella propria ricostruzione del catalogo. Fonte: catalogo ufficiale Team17 della serie Alien Breed.

Super Stardust è un altro riferimento della fase AGA. Le immagini distribuite all’epoca e conservate su Aminet sono esplicitamente presentate come materiale della versione AGA. Il suo interesse per questa storia è nel lavoro combinato di grafica, animazione e presentazione, non nella dimostrazione di una generica accelerazione 3D del chipset. Fonte archivistica: voce SuperStardstPx, immagini del gioco diffuse nel settembre 1994.

Alien Breed 3D, nel 1995, mette invece in evidenza le difficoltà di costruire un gioco in prima persona sull’A1200. Andy Clitheroe ha raccontato il lavoro necessario per adattare la rappresentazione dei pixel e ridurre il costo del rendering. AGA consentiva il risultato, ma non eseguiva da solo il renderer. La piccola finestra di gioco e i compromessi visivi raccontano proprio questa distanza fra capacità di visualizzazione e potenza di calcolo. Fonte: testimonianza di Clitheroe nella retrospettiva Team17 sul 1995.

Alien Breed 3D II: The Killing Grounds spinge ulteriormente la richiesta di risorse. Team17 lo ricorda come un progetto pensato anche per Amiga AGA espansi, con versioni differenti per la memoria disponibile. È un caso esemplare: dire «richiede AGA» non basta a descrivere l’esperienza su una macchina base e su una fortemente accelerata. Fonte: retrospettiva ufficiale Team17 sul 1996.

Grafica, Workbench e demoscene: la qualità non era solo nei giochi

Una tavolozza più ampia era utile anche quando non c’erano nemici da animare. Disegno, immagini digitalizzate, interfacce e presentazioni potevano usare scelte cromatiche meno drastiche. Un artista continuava a ragionare su palette e codifica, ma con margini diversi rispetto a un comune schermo a 32 colori.

Il Workbench poteva utilizzare più colori e nuovi modi video. Questo non rendeva automaticamente conveniente aprire ogni schermo alla massima profondità: aumentavano memoria necessaria, dati da elaborare e costi di ridisegno. Anche nell’uso quotidiano il miglior compromesso dipendeva dalla macchina.

La demoscene mostrò quanto lavoro si potesse compiere fra CPU, Copper, palette, sprite e bitmap. Non tutti gli effetti di una demo AGA derivano però da una nuova funzione hardware; possono dipendere da precalcolo, algoritmi, conversioni e acceleratori. Per leggere correttamente una produzione servono i requisiti, la risoluzione effettiva e il tipo di Amiga sul quale gira.

Lo stesso rigore vale per i comportamenti non documentati. Un effetto ottenuto con un preciso ordine di scritture non prova una capacità generale, e una particolarità osservata in emulazione richiede confronto con l’hardware. La ricerca della comunità è preziosa quando conserva queste condizioni, invece di trasformare ogni anomalia in una leggenda tecnica.

Picasso96 e FPGA non aggiungono retroattivamente funzioni ad AGA

RTG, retargetable graphics, consente al software di usare dispositivi grafici differenti attraverso un’interfaccia comune. Picasso96, oggi P96, è parte di questa storia: supporta schede e modalità che non coincidono con il percorso grafico nativo Amiga.

Non è corretto dire che Picasso96 abbia trasformato Alice e Lisa in un chipset con framebuffer chunky o true color indipendente. Un driver può spostare, convertire e presentare dati usando hardware diverso; non può aggiungere da solo transistor o un nuovo formato fisico al display controller originale. La documentazione P96 distingue infatti bitmap native, bitmap RTG, conversioni e schede supportate. Fonte: documentazione e note tecniche ufficiali P96.

Un’implementazione FPGA può riprodurre AGA e, se progettata per farlo, aggiungere estensioni. Le due operazioni vanno dichiarate separatamente. Una modalità introdotta da un core moderno non dimostra che fosse già presente nell’A1200 del 1992. Lo studio dei progetti aperti e degli emulatori aiuta a documentare il comportamento, ma richiede sempre di identificare ciò che si sta riproducendo.

AGA rispetto ai PC e alle console: meglio evitare una classifica unica

Nel confronto con VGA, Super VGA e console dei primi anni Novanta il numero dei colori racconta soltanto una parte. Contano disponibilità di memoria, processore, formato del framebuffer, accelerazione, costo e software. Anche OCS ed ECS non sono una sola configurazione: cambiano capacità e modi video secondo chip e macchina.

Un PC con uno schermo indicizzato chunky può essere più comodo per un renderer che scrive pixel individuali. Un Amiga offre invece una combinazione caratteristica di bitplane, scrolling, sprite e Copper. Una console specializzata in sprite e tile risolve ancora problemi differenti. Non c’è una sola cifra che renda intercambiabili questi sistemi.

AGA fu un aggiornamento concreto per il 2D e l’uso multimediale della piattaforma. La crescita del 3D in tempo reale rese però più evidente ciò che non era stato riprogettato: costo del rendering software, struttura planare, prestazioni del blitter e memoria condivisa. Non è una contraddizione riconoscere contemporaneamente il miglioramento e il ritardo.

Che cosa AGA lasciò aperto

AA+, AAA e Hombre non vanno fusi in una sola lista di caratteristiche mancanti. Erano progetti differenti, con obiettivi, tempi e rapporti diversi con l’eredità Amiga. Una funzione prevista in una loro specifica non appartiene automaticamente ad AGA, né dimostra che fosse pronta per essere commercializzata.

Il punto storico è che Alice e Lisa arrivarono davvero nelle case. Resero possibile una nuova generazione di opere senza chiedere di abbandonare immediatamente tutto il software precedente. La compatibilità rimase un obiettivo importante, non una garanzia assoluta per ogni programma scritto accedendo direttamente all’hardware o contando su un preciso timing.

La fine della Commodore originaria lasciò ad AGA un compito più lungo di quello che avrebbe dovuto avere un aggiornamento intermedio. Sviluppatori e utenti continuarono a cercarne margini mentre acceleratori e schede grafiche cambiavano il significato stesso di «Amiga espanso».

Oggi il modo più interessante di ricordarlo non è né celebrarlo come una GPU nascosta né liquidarlo come un errore inutile. AGA fu l’ultima evoluzione del chipset Amiga arrivata sul mercato sotto Commodore: abbastanza vicina alle origini da mantenerne il linguaggio, abbastanza diversa da produrre immagini nuove, non abbastanza radicale da risolvere da sola i problemi della generazione successiva.

Fonti e note sulle immagini

• Comunicato stampa Commodore A4000, 11 settembre 1992, conservato su Usenet: riferimento per la presentazione, distinta dalle successive disponibilità commerciali.
• Brochure originale Commodore «The Amiga 4000 Series»: configurazione, memoria, porte, espansioni e modi video.
• Documentazione di servizio Commodore A1200: specifiche, organizzazione hardware e schemi.
• Documentazione AA/Pandora in formato AmigaGuide, trascrizione storica conservata nel repository Minimig-MiST: registri, fetch, playfield e formati. La trascrizione contiene refusi e va confrontata con altre fonti.
• HowToCode, documentazione AGA: dettagli pratici su HAM8, allineamenti e programmazione. Documento comunitario, non un’approvazione ufficiale Commodore.
• Manuale AmigaOS, Monitors: gestione delle modalità, palette, HAM8 e requisiti del monitor.
• Spencer Shanson, «AGA questions», febbraio 1993: chiarimenti di uno sviluppatore Commodore sugli sprite e sull’uso delle API.
• Commodore CD32, Engineering Change Release e documentazione di sistema: funzioni di Akiko, conversione C2P e specifiche audio.
• Team17, catalogo Alien Breed; retrospettive ufficiali sul 1995 e sul 1996: versioni dei giochi e testimonianze degli sviluppatori.
• Individual Computers, P96: distinzione fra grafica nativa e RTG.
• Fotografie originali: A1200 di MOS6502, pubblico dominio; Alice di MOS6502, CC BY-SA 3.0. Autore, fonte e licenza sono indicati anche nelle didascalie