La disamina dei chipset che hanno popolato queste gloriose macchine è terminata con l’articolo che ha discusso dell’AGA , ma una menzione merita sicuramente l‘Amiga Advanced Architecture (AAA), prodotto che ancora oggi fa sognare milioni di amighisti e che, purtroppo, non ha mai visto la luce.
Questo non lo classifica come leggenda metropolitana, in quanto il chipset era sostanzialmente pronto per andare in produzione, com’è attestato da questa intervista (di cui ringrazio il lettore jpx per aver fornito il link in un commento al mio articolo sull’AGA) all’ingegnere Ed Hepler che ha partecipato alla progettazione del suo successore (il progetto Hombre).
Purtroppo come siano andate le cose lo sappiamo bene: la scheda madre che lo doveva utilizzare non era ancora stata finalizzata, e presentava dei problemi, ma soprattutto Commodore decise di cancellare il progetto perché ritenuto troppo costoso e non in linea con l’evoluzione della concorrenza (i PC e le console).
Punto di vista, questo, che come utente di lunga data, ma soprattutto come programmatore, di questi meravigliosi sistemi non condivido assolutamente, in quanto per l’Amiga si trattava di un eccellente chipset nonché l’autentica rivoluzione attesa da troppo tempo, che peraltro poneva delle solide basi per il futuro.
Infatti con l’AAA gli ingegneri avevano finalmente messo mano all’intero comparto hardware, migliorandolo. Non c’è stato elemento che non sia stato ripreso e migliorato a differenza dell’AGA, dove soltanto la palette, il numero di bitplane, e la risoluzione degli sprite erano stati aggiornati, lasciando tutto il resto (audio, disco, seriale, Copper e Blitter) assolutamente invariato.
Al solito, i cambiamenti a cui si presta maggiormente attenzione, forse per una psicologica e patologica corsa alla “misura”, è la risoluzione video, che arriva adesso fino a 1280×1024 pixel, passando per numerose risoluzioni intermedie grazie alla programmabilità del segnale video.
Eredità, questa, dell’ECS, col quale risulta per buona parte compatibile, a differenza dell’AGA di cui praticamente non v’è alcuna traccia, se non a livello di caratteristiche tecniche “sovrapponibili”.
Di fatto con questa mossa gli ingegneri (mi scuserete se non amo dar meriti a Commodore, perché a questo nome continuo ad associare il management incapace che ha portato al collasso la società e ucciso i sogni di milioni di persone) hanno deciso di rompere la compatibilità col passato, ma ciò a beneficio dell’evoluzione anche futura.
Quindi con un’eventuale macchina dotata di AAA potevamo dire addio all’intero parco giochi AGA: non ne avrebbe funzionato nemmeno uno, Pinball Fantasies incluso! Mentre i vecchi titoli che sfruttavano l’OCS, e per quei pochi che andavano a toccare eventualmente qualche registro dell’ECS, qualche speranza di vederli girare c’era, ma sempre a patto che i programmatori non avessero dato fondo alle loro perversioni, come purtroppo sanno bene gli utenti di macchine AGA, che hanno sofferto di problemi analoghi.
La compatibilità con OCS ed ECS è, però, rimasta esclusivamente per facilitare la transizione verso il nuovo (evitando un bagno di sangue), perché i successori dell’AAA certamente non l’avrebbero mantenuta, com’è possibile appurare dall’intervista di cui ho parlato prima e dal documento redatto da Dave Haynie per questo chipset.
Col medesimo principio avrebbero, però, potuto fare lo stesso anche con la compatibilità AGA, ma questo avrebbe complicato notevolmente il chipset. Conoscendone il funzionamento, so bene che questo rappresenta una grossolana e arrabattata pezza che è stata messa sull’ECS, per cercare di mantenere un po’ di competitività nei confronti della concorrenza.
Penso sia chiaro dalle mie parole che non ho digerito particolarmente le soluzioni tecniche che hanno portato all’AGA, e credo che chi ha avuto modo di lavorarci condivida quest’opinione, sebbene i risultati siano stati apprezzabili grazie anche al lavoro degli sviluppatori che hanno cercato di sfruttarle come meglio potevano.
D’altra parte AAA ha dalla sua talmente tanta “potenza di fuoco”, che pensare di continuare a programmare direttamente l’hardware, come si è fatto quasi sempre, diventa non soltanto anacronistico, ma anche pericoloso, in considerazione dei rapidi progressi tecnologici e coi sistemi RTG (ReTargetable Graphics, così erano chiamate le schede grafiche avanzate e non compatibili col chipset dell’Amiga) alle porte.
Il futuro è chiaramente rappresentato dall’uso del sistema operativo, l’AmigaOS, quale intermediario con l’hardware, come peraltro avviene con tutti i s.o. moderni. Ciò, oltre a sgravare il programmatore da numerosi compiti, permette di realizzare applicazioni portabili che, quindi, avrebbero potuto girare anche su macchine completamente diverse.
Tornando alle caratteristiche tecniche, oltre alla risoluzione ovviamente è possibile cambiare la frequenza del segnale (o refresh video che dir si voglia), grazie alla succitata programmabilità, ma è bene sottolineare che con questo chipset assistiamo a un altro sostanziale, ma pregevole, elemento di rottura: non siamo più legati intrinsecamente alla frequenza del segnale televisivo, sia esso NTSC, PAL, o SECAM.
L’Amiga è sempre stata una macchina perfettamente sincrona col clock del segnale televisivo (lo capiremo meglio in un prossimo articolo in cui esaminerò il funzionamento del sistema), che ne regolava ogni aspetto (a parte la CPU, unica ad avere la possibilità di svincolarsi da ciò) e ne ha rappresentato anche un gravoso vincolo.
Con AAA adesso sono a disposizione fino a 8 diversi clock che regolano il funzionamento del chipset, e che possono essere utilizzati per generare diversi segnali video. Singolare è la possibilità di poter scegliere un clock diverso per il recupero di ogni riga di raster visualizzata, ma a occuparsi della generazione del segnale video e della sincronizzazione degli accessi in memoria per prelevare la grafica, armonizzando il tutto, è Andrea, il chip che prende il posto del vecchio Agnus (OCS ed ECS) e di Alice (AGA).
Sempre continuando con la grafica, i bitplane utilizzabili sono passati dai 6 dell’OCS/ECS e dagli 8 dell’AGA, a ben 16. Questo ha consentito, oltre che di visualizzare 256 colori da una palette di 16 milioni (più un bit per l’overlay video, da utilizzare eventualmente con un genlock) come l’AGA, di poter disporre di una modalità dual playfield (due schermi indipendenti) da 8 bitplane ciascuno.
Oltre a ciò troviamo una nuova modalità HAM10 (che, come si può intuire, utilizza 10 bitplane, che si affianca all’HAM8 arrivata con l’AGA), in grado di visualizzare immagini cromaticamente più accurate, avendo a disposizione una palette base di 256 colori (contro i 64 dell’HAM8), e la possibilità di cambiare tutti e 8 i bit delle componenti rosso, verde e blu (l’HAM8 poteva cambiare soltanto i 6 bit più alti, “ereditando” il valore corrente per i 2 bit bassi).
La parte del leone la fanno però le nuove modalità, fra le quali le tanto attese “chunky“ che sono adesso disponibili il diverse versioni. Half-Chunky consente di definire pixel da 2, 4 o 8 bit, coi bit ovviamente “impacchettati”, in quanto viene fatto uso di un solo bitplane in cui risiedono tutti i bit dell’immagine.
Tanto per fare un esempio, coi pixel Half-Chunky a 2 bit, il bit 0 e il bit 1 si trovano uno a fianco all’altro, per cui nel primo byte del “bitplane” (non dovremmo nemmeno chiamarlo così ormai) ritroviamo memorizzati 4 pixel da 4 colori ciascuno.
Ovviamente la più comoda e che sarebbe stata sicuramente usata nei giochi 3D rimane l’Half-Chunky a 8 bit, simile alla modalità a 256 colori della VGA che ha fatto la fortuna del PC in ambito videoludico.
La modalità Chunky utilizza, invece, 16 bit fissi, che sono internamente suddivisi in 5 bit per ogni componente cromatica, più un bit di overlay da utilizzare al solito coi genlock. Corrisponde alla modalità HiColor (o, impropriamente, TrueColor a 16 bit) dei PC, e consente di visualizzare 32768 colori contemporaneamente, senza utilizzare la palette (che rimane sfruttabile dagli sprite).
Hybrid è, invece, una particolare modalità che risulta una combinazione (un “ibrido”, appunto, come si evince dal nome) dei concetti di bitplane e chunky. In pratica si fruttano 3 bitplane, ognuno dei quali conserva un valore “chunky” a 8 bit, che serve a definire la corrispondente componente cromatica.
Si tratta senza dubbio di un enorme passo in avanti, perché in questo modo è possibile visualizzare fino a 16 milioni di colori senza i compromessi di HAM8 e HAM10, ma richiede 3 passaggi per manipolare la grafica, al contrario della classica modalità TrueColor disponibile su PC e Mac (che ovviamente manca nell’AAA). E’ anche vero che in questo modo è possibile realizzare qualche effetto grafico particolare, agendo soltanto sulle singole componenti.
Sono presenti altre due strane modalità, chiamate PACKLUT e PACKHY, che suddividono lo schermo in blocchi di 4×4 pixel, e nei quali per ogni pixel viene fatto uso soltanto 2 e 4 bit rispettivamente. Ogni blocco definisce soltanto 2 colori (dalla palette a 8 bit nel primo caso, mentre genera un colore a 24 bit nel secondo caso). Non ci sono altri dettagli sul loro funzionamento, ma credo siano state pensate per visualizzare animazioni compresse, impiegando pochi bit e, quindi, poca banda per essere memorizzate e visualizzate.
Per riuscire a supportare risoluzioni, refresh, e profondità di colore così elevati, che richiedono una notevole banda passante, il sistema prevede l’uso di memorie VRAM, oltre che le classiche DRAM, e una configuazione chiamata “dual”, che fa uso di 6 chip anziché 4, facendo così passare l’accesso alla memoria da 32 a 64 bit. I sistemi “dual” sono pensati per soluzioni high-end, mentre la configurazione “single” per quelle consumer.
Da questa potenza e flessibilità ne trae vantaggio anche la CPU, che adesso può arrivare ad accedere alla chip ram alla stessa velocità della fast ram a 32 bit. Inoltre in presenza di VRAM il sistema consente, se predisposto con un’apposita circuiteria, anche di poter acquisire un segnale video esterno, che viene campionato e memorizzato esclusivamente in una delle modalità Chunky o Hybrid.
Pochi cambiamenti hanno riguardato, invece, gli sprite, che adesso possono essere larghi fino a 128 pixel, mentre con OCS/ECS erano fissi a 16, e con l’AGA sono arrivati a 32 e 64 pixel di larghezza.
Modifiche molto più consistenti ci sono stati per il Copper, che è ora in grado di lavorare con istruzioni a 32 bit, in quanto tutti i nuovi registri dell’AAA sono, appunto, di questa dimensione (mentre rimangono a 16 bit i 256 registri di OCS/ECS), ed è finalmente presente un’istruzione che permette di caricare in un colpo solo più registri.
Decisamente utile è anche la possibilità di poter ricevere interrupt dal Blitter (e dal segnale di vertical blanking), quando quest’ultimo termina un’operazione per cui era stato programmato. In questo modo è possibile schedulare tramite il Copper tutta una serie di operazioni senza l’intervento della CPU, similmente al concetto di display list da processare presente in altri sistemi.
Inutile dire che l’elemento che ha subito più cambiamenti è proprio il Blitter, che si è svincolato dal lavorare esclusivamente con bitplane e per giunta con dati a 16 bit. Adesso è in grado di manipolare dati a 32 bit, e di qualsiasi natura: bitplane o chunky. D’altra parte l’introduzione delle nuove modalità chunky e ibride ha costretto gli ingegneri a ripensarne profondamente il funzionamento.
Questo si riflette anche in una maggior facilità di programmazione. Adesso non è più necessario impostare “maschere” e affini (di cui, anche qui, parleremo in un futuro articolo) per farlo lavorare correttamente con bitplane non perfettamente allineati a 16 bit, ma è sufficiente specificare la dimensione dei pixel (da 1 a 16 bit, per potenze di 2) e la loro posizione, per far sì che provveda automaticamente a farsi carico di tutte le operazioni di allineamento e mascheramento. E i programmatori, vi assicuro, ringraziano!
Ma la carne sul fuoco non era ancora abbastanza per gli ingegneri, che hanno pensato bene di arricchire la tipologia di operazioni da eseguire. Adesso il Blitter è in grado di contare il numero di volte che un pixel di un determinato colore si trova in un’area rettangolare, ed è perfino in grado di eseguire un ordinamento di tipo Bubble sort sui “pixel”.
Operazioni strane per un componente di questo tipo, a cui però ne sono affiancate altre “canoniche”, per così dire, come quella di somma e sottrazione, tenendo conto di eventuali saturazioni, come pure il calcolo della media, e altre che il documento di Haynie liquida, purtroppo, con un “etc.”.
Se a qualcuno vengono in mente le famigerate estensioni SIMD che ormai dominano sia nelle CPU che nelle GPU, beh, non è andato lontano. Tutt’altro.
E’ ancora presente la modalità di disegno delle linee, che è stata chiaramente potenziata tenendo conto di tutti questi cambiamenti, e permette di specificare adesso anche un pattern a 32 bit (prima era soltanto a 16 bit). Inoltre è stata aggiunta la possibilità di definire un rettangolo per il clipping.
Questo vuol dire che si può definire una zona rettangolare entro la quale il tracciamento deve rimanere vincolato, e il Blitter si farà carico di tutti i calcoli e controlli, senza che si debba scomodare la CPU. Ancora una volta, i coder e Intuition ringraziano.
Ovviamente tutto questo ben di dio viene eseguito molto velocemente dal Blitter, vuoi per l’implementazione interna che è stata completamente rivista (ma è presente ancora la completa compatibilità con quella “a 16 bit” di OCS/ECS/AGA), vuoi per la maggior banda a disposizione coi nuovi sistemi.
Arriva, infatti, a essere anche 10 volte più veloce nel solo trasferimento dei dati, senza tener conto dei notevoli incrementi dovuti alle nuove operazioni che è in grado di eseguire. Roba da infarto, insomma, per un programmatore che ha dovuto fare i conti a manina cercando di risparmiare anche un solo ciclo di clock…
La grafica e tutto ciò che è essa legato è e rimarrà sempre l’argomento che occupa più spazio, perché c’è parecchio di cui discutere, ma non meno importanti sono le innovazioni apportate al comporta audio, dove il chip che se ne faceva carico, Paula, era rimasto praticamente inalterato dalla sua prima incarnazione, datata 1985.
Passiamo finalmente dai 4 agli 8 canali indipendenti (con relativi nuovi canali DMA assegnati alle “new entry”), dagli 8 ai 16 bit (ovviamente è possibile utilizzare indifferentemente l’uno o l’altro “taglio” in totale autonomia), e dai 29Khz di frequenza massima ai 64Khz attuali.
Il volume subisce anch’esso un netto miglioramento, considerato che prima erano disponibili 6 soli bit (64 livelli), e adesso ben 12 (4096 livelli), quindi con una granularità decisamente più fine. A ciò aggiungiamo inoltre la possibilità di poter scegliere liberamente quali canali devono essere presenti nell’uscita di sinistra, e quali in quella destra, mentre in precedenza due (0 e 3) erano fissi sul sinistro e gli altri due (1 e 2) su quello destro.
Come per la sezione video, anche per l’audio è possibile campionare un segnale esterno, anche se, purtroppo, soltanto a 8 bit (e stereo); per il supporto a 16 bit è necessario un ADC esterno. Molto più importante è, invece, la possibilità di poter disporre di un’uscita digitale, che soltanto negli ultimi anni è ormai diffusa nei PC.
Anche l’accesso al disco e il relativo controllo hanno rappresentato la classica “croce e delizia” degli Amiga. Se, da una parte, il meccanismo era estremamente versatile nella definizione dei formati, dall’altra la scarsa banda a disposizione di soli 500Kb/s consentiva di leggere soltanto floppy a bassa densità.
Con Mary, il sostituto di Paula, si superano gli 11MB/s e, quindi, si possono leggere e scrivere i floppy ad alta densità (da 1,44MB per i PC, ma fino a 2MB con l’Amiga), ma anche a quadrupla densità (da 2,88MB per PC, ma fino a 4MB con l’Amiga).
Il controller in ogni caso è estremamente evoluto, essendo in grado di leggere anche CD-ROM, ma anche particolari hard disk, e perfino i famigerati floppy del Macintosh che, come da tradizione Apple, avevano un formato e un meccanismo di memorizzazione dei dati tutto loro.
Oltre al supporto alla lettura “raw” (dati grezzi, che poi erano lo standard per l’Amiga; la decodifica MFM, infatti, avveniva in software) e al vecchio GCR, Mary ha supporto in hardware per le codifiche MFM, RLL(2,7) e Biphase-Mark.
Sempre in hardware supporta la lettura e scrittura di singoli settori (soltanto di intere tracce in precedenza), del formato CD, può gestire il CRC e permette di utilizzare un clock esterno per sincronizzare i dati.
Infine, e a testimonianza che proprio ogni aspetto dell’hardware è stato migliorato, alla porta seriale già presente su Paula se ne aggiunge un’altra su Mary, ed entrambe sono bufferizzate con una FIFO da 4 byte, che consente di ridurre notevolmente l’intervento della CPU (che riceve meno interrupt per la ricezione dei dati), ma soprattutto di poter lavorare a frequenze molto più elevate.
Scusandomi per la lunghezza del pezzo, credo non ci sia altro da aggiungere. Le conclusioni le lascio a voi. Le mie, purtroppo, le ho già realizzate parecchi anni fa, ma a questo punto penso possiate immaginarle…
