Come ben sappiamo, l’Amiga è stata una meravigliosa macchina che, alla sua introduzione, ha apportato un’autentica rivoluzione in tutti i campi: dal favoloso chipset che ci ha regalato grafica e sonoro mai visti in ambito consumer, al velocissimo s.o. multitasking dotato di pratica nonché semplice interfaccia grafica che ci ha sollevato dal digitare astrusi comandi.
Purtroppo Commodore non ha saputo capitalizzare l’incredibile vantaggio tecnologico che s’è trovata fra le mani, e ha preferito nicchiare procrastinandone lo sviluppo ed evoluzione per parecchi anni, cullandosi sull’enorme distanza a cui si trovava la concorrenza dell’epoca.
Dal 1985 al 1990: arriva l’ECS
Ma se l’introduzione della versione 2.0. del s.o. ha portato un ben po’ di novità, modernizzandone diversi aspetti e ponendo le basi per i futuri avanzamenti, l’hardware è, invece, sostanzialmente rimasto al palo, perché il chipset ECS (rilasciato in concomitanza col nuovo s.o.) era soltanto una rispolverata di quello originale (OCS), con l’aggiunta di alcune modifiche che non hanno contribuito alle nuove esigenze in ambito visivo, sonoro, e computazionale.
L’ingegnere capo del gruppo che l’ha realizzato, Dave Haynie, ha addossato senza mezzi termini la colpa ai responsabili manageriali aziendali dell’epoca, sostanzialmente lavandosene le mani. Famosa la sua frase “Read my lips – no new chips” a loro attribuita e che si trova anche in alcune interviste. Ad esempio qui:
In realtà con l’ECS sono arrivate delle nuove versioni di Agnus e Denise (due dei tre chip dell’Amiga), le quali hanno introdotto le seguenti innovazioni:
- possibilità di riprogrammare liberamente la risoluzione del segnale video (similmente a quanto vecchissimi chip come il Motorola 6845 integrato nelle schede grafiche MDA e CGA dei PC consentivano già nel 1980);
- introduzione della “super alta risoluzione” (1280×200 per macchine NTSC e 1280×256 per quelle PAL);
- maggior granularità nella possibilità di posizionare gli sprite orizzontalmente. La posizione orizzontale degli sprite può, quindi, essere selezionata a 1/2 pixel (rispetto alla bassa risoluzione), consentendone un movimento più fine;
- possibilità di passare dal segnale NTSC a PAL, o viceversa;
- sprite visualizzabili nei bordi dello schermo;
- varie funzionalità utili ai genlock;
- Blitter in grado di gestire aree fino 32768 x 32768 pixel (anziché i 1024 x 1024 dell’OCS);
- fino a 2MB di memoria Chip (l’unica accessibile per i chip custom), contro i 512kB dell’OCS.
In realtà esistono altre funzionalità piuttosto oscure (il cui funzionamento non è documentato) che sono state introdotte con l’ECS (e che si trovano anche nel successivo AGA), ossia i cosiddetti registri Ultra-Highres (UHRES), i quali sembrerebbero controllare un display e uno sprite facenti parti di una circuiteria video addizionale basata su memoria VRAM.
Com’è possibile vedere, dunque, siamo in presenza di nuovi chip che hanno introdotto diverse nuove funzionalità, checché ne dica l’ingegnere capo di Commodore. Il problema è che buona parte di queste innovazioni sono state ben poco utili per l’utilizzo tipico degli utenti: applicazioni e, soprattutto, giochi.
Sì, la possibilità di avere 1 o 2MB di memoria chip è certamente comoda per poter usare più asset nei giochi o per i programmi di grafica o audio. Di ben più rara utilità sono, invece, gli sprite visualizzabili ai bordi, o la possibilità di gestire aree più grandi di 1024×1024 col Blitter.
Nei fatti i giochi Amiga sono rimasti sostanzialmente gli stessi, perché nulla era cambiato dal punto di vista grafico (sempre 32/64 colori al massimo selezionabili da una tavolozza di 4096. E modalità Dual Playfield limitata a 8 + 7 colori massimo) e sonoro (4 canali audio PCM a 8 bit).
Queste misere migliorie non giustificavano la realizzazione di giochi ad hoc. Certo, con almeno 1MB di Chip ram si potevano realizzare alcune cose più interessati, ma in ogni caso serviva un parco macchine abbastanza grande da pensare a un investimento in questo senso, che all’epoca non è arrivato (per primo è arrivato l’Amiga 3000 con l’ECS e soltanto due anni dopo gli Amiga 500 Plus e Amiga 600: altra scelta fallimentare della dirigenza Commodore!).
Cosa si sarebbe potuto fare: 256 colori!
Se i manager Commodore hanno avuto le loro gravi colpe, non si può dire nemmeno che gli ingegneri ne fossero esenti, considerato che pure loro hanno dimostrato una chiara mancanza di visione riguardo a quali caratteristiche sarebbe stato meglio introdurre con l’ECS nonostante il limite di non produrre chip troppo diversi (più grandi = più costosi da produrre) da quelli originali (è in questo senso che va letta l’affermazione “no new chips“).
Cominciamo con quella sicuramente più agognata: i famigerati 256 colori. Come sappiamo, l’OCS era limitato a visualizzare un massimo di 32 colori selezionabili da una tavolozza di 4096, arrivando a 64 con la speciale modalità EHB (Extra-Half Brite) che ne aggiungeva altri 32 prendendoli dai precedenti 32, ma dimezzandone la luminosità (quindi un colore era presente con due diverse luminosità: piena e dimezzata).
E’ proprio sfruttando il principio dell’EHB che si sarebbero potuti ottenere 128 colori (32 colori in 4 diverse luminosità: normale, 3/4, metà, 1/4) oppure 256 colori (32 colori con 8 luminosità). Non è nulla di nuovo né complicato, come tra l’altro dimostrato nel 1987 (quindi ben tre anni prima dell’ECS) dall’Acorn Archimedes (che aveva solo 16 colori selezionabili da 4096, ma con 16 diverse luminosità) e ancora prima dai Commodore 16 e Plus/4 della stessa casa.
L’implementazione sarebbe stata piuttosto semplice proprio perché l’ECS mostrava già in che modo si sarebbe potuto realizzare il tutto, con l’aggiunta di due nuovi puntatori ai bitplane che si sarebbero andati ad aggiungere ai sei già presenti. Se l’ECS ha aggiunto i due inutili puntatori UHRES (vedi sopra), non vedo perché non sarebbe stato possibile aggiungerne altri due ai bitplane per ottenere gli enormemente più utili 256 colori!
Modalità Dual Playfield “modello AGA”
Similmente, con l’aggiunta dei suddetti due nuovi puntatori ai bitplane si sarebbe potuto migliorare anche la famosa modalità Dual Playfield che è stata utilizzata in tantissimi videogiochi di successo, che consentiva di visualizzare due schemi scrollabili completamente indipendenti.
Il limite dell’OCS, dovuto ai soli sei bitplane a disposizione, era rappresentato dal fatto che i due schermi potevano avere al massimo 8 e 7 colori rispettivamente (7 perché una delle 8 combinazioni era utilizzata per “forare” lo schermo e visualizzare la grafica dell’altro) .
Ma con otto bitplane a disposizione la musica cambia nettamente e si possono avere due schermi da 16 + 7 colori (usando sette bitplane) oppure 16 + 15 (usando tutti e otto i bitplane): esattamente quanto consentito dal successivo chipset AGA!
Inutile dire che si sarebbero potuti realizzare giochi nettamente migliori sfruttandoli sapientemente, pur con tutti i limiti del chipset (che non ha a disposizione la stessa banda di memoria dell’AGA per leggere i dati degli schermi e/o degli sprite).
Il panning su tutti i canali audio
Il chip Paula, deputato all’audio e ad alcune altre funzionalità (disco, mouse, seriale, interrupt, ecc.), non ha mai visto alcun miglioramento in tutto l’arco di vita dell’Amiga. Nessun chipset successivo a quello originale, infatti, l’ha mai modificato. Purtroppo.
Sappiamo che mette a disposizione quattro canali DMA che riproducono campioni sonori di 8 bit (PCM), ognuno con un controllo indipendente del volume (65 livelli: 64 + volume massimo). Il comparto audio è una della caratteristiche che ha reso famoso l’Amiga e che ci ha regalato migliaia di colonne sonore nei giochi, demo, o anche soltanto nei famosi “MOD“.
La caratteristica singolare di questi canali è che risultano appaiati nei due canali stereo i cui suoni arrivano poi alle nostre orecchie: due vengono riprodotti nel canale sinistro e gli altri due nel canale destro (tecnicamente questa distribuzione si chiama panning).
In questo modo è possibile ottenere un certo effetto surround che produce una maggior forma di “immersione” nell’ambiente (immaginate un suono che si “sposti” dall’orecchio destro a quello sinistro, ad esempio).
Sfortunatamente questa disposizione dei canali rende più complicata la simulazione dei suoni all’interno di un ambiente, nel caso in cui un suono si debba ascoltare con volume diverso proveniente dal canale sinistro e da quello destro.
Per simulare un effetto del genere sull’Amiga si debbono giocoforza utilizzare due canali per riprodurre lo stesso suono a destra e sinistra (ma con volume differente, a seconda di come il suono dev’essere percepito). Per cui due suoni impegnano tutti e quattro i canali audio disponibili con Paula, non rimanendone altri per riprodurre altri suoni.
Una banale modifica a Paula avrebbe consentito, invece, di poter specificare il livello del volume separatamente per il canale sinistro e il canale destro, dando la possibilità a ben quattro suoni diversi di poter essere riprodotti col panning e, quindi, potendo riprodurre un suono ambientale più immersivo.
Attualmente ogni canale audio di Paula ha associato un registro a 16 bit in cui è possibile specificare il livello del volume nei 7 bit più bassi. Tutti e gli altri 9 bit sono inutilizzati. Per introdurre il panning nei quattro canali sarebbe bastato, quindi, duplicare gli 8 bit bassi di tale registro negli altri 8 bit alti, in modo da poter impostare separatamente il volume per il canale sinistro e destro. Il tutto in maniera assolutamente retrocompatibile.
Potete facilmente immaginare quanto un semplicissimo cambiamento come questo avrebbe contribuito ad avere un sonoro nettamente migliore nei giochi (dove, tra l’altro, i programmatori erano costretti a impostare canali diversi ogni volta che un suono doveva essere “spostato” dal canale sinistro a quello destro, ad esempio). Ma non sarebbero stati soltanto i giochi a beneficiarne, ovviamente.
Miglior accesso alla memoria Chip per la CPU
Una vera e propria piaga per processori diversi dal 68000 (e 68010) è rappresentata dal fatto che gli accessi alla memoria Chip sono regolati in maniera ferrea dal chip Agnus, il quale impone di aspettare quattro cicli di clock (pari a due “slot” di accesso).
Tutto ciò è stato sapientemente realizzato dal progettista del chipset, Jay Miner, poiché si rese conto che, quando doveva accedere alla memoria, il 68000 lo faceva sempre utilizzando quattro cicli di clock, per l’appunto.
Il che andava meravigliosamente bene per questo microprocessore, ma assolutamente male per tutti gli altri che sono venuti dopo (dal 68020 in poi, per intenderci) nel caso in cui fossero stati in grado di accedere alla memoria in un due cicli di clock.
Questo grosso limite ha comportato un’efficienza nettamente inferiore (dimezzata) nel caso in cui fosse stato il processore a doversi prendersi carico di un po’ di lavoro, anziché delegare tutto al Blitter. Il che ne ha limitato l’utilizzo, non potendo sfruttare in maniera ottimale tutti i possibili accessi alla memoria.
Anche qui, nessun chipset ha mai modificato questo comportamento, che avrebbe consentito di guadagnare prestazioni sui sistemi più avanzati (incluso l’Amiga 1200): l’ECS sarebbe stata una buona occasione per eliminare questo vincolo, considerato che è stato utilizzato per primo dal suddetto Amiga 3000, che faceva uso di un 68030.
Cache della maschera dei BOB
Infine un altro cambiamento che avrebbe apportato un significativo miglioramento nei giochi sarebbe stato quello di introdurre una piccola cache per la maschera utilizzata nei BOB (gli oggetti grafici “disegnati” mediante il Blitter). Riporto di seguito qualche informazione utile a comprendere la problematica senza, però, perderci troppo nei dettagli.
Come sappiamo, l’Amiga utilizza la grafica planare per memorizzare i dati degli oggetti grafici. A seconda della profondità di colore utilizzata (2, 4, 8, …, 64 colori), la grafica è conservata in appositi bitplane (1, 2, 3, …, 6).
Il Blitter è in grado di disegnare oggetti in movimento prelevandone i dati un bitplane alla volta e andando a “incastrarlo” nell’apposito bitplane dello schermo che verrà visualizzato. Quindi se lo schermo ha 32 colori, dovrà ripetere quest’operazione per 5 volte: una per ogni bitplane da aggiornare.
Per “incastrare” la grafica del BOB in quella dello schermo, il Blitter deve far uso di un ulteriore bitplane, i cui valori dei singoli bit decidono quale grafica disegnare in uno specifico pixel: quando il bit sarà 0 la grafica dello schermo rimarrà inalterata per quel pixel, mentre verrà copiata la grafica del BOB se tale bit dove essere 1, invece.
In buona sostanza, il Blitter legge i dati della grafica dello schermo, quelli del BOB, la maschera, e poi li combina assieme sfruttando quest’ultima per decidere in che modo farlo. Il tutto ripetuto, ogni volta, per tutti i bitplane dello schermo.
La maschera è sempre la stessa e viene ricaricata ogni volta che deve partire l’operazione per uno specifico bitplane. Quindi se lo schermo è a 32 colori, i dati della maschera saranno caricati cinque volte, anche se ogni volta sono esattamente gli stessi, con un notevole spreco di risorse (banda verso la memoria).
Una modifica che avrebbe consentito di eliminare questo spreco sarebbe consistita in una modifica al Blitter, integrando una piccola quantità di memoria cache in cui conservare i dati della maschera alla prima operazione, per poi prelevarli dalla cache per tutte quelle successive.
Un meccanismo piuttosto semplice, come si può immaginare, ma che sfortunatamente richiede un certo costo per questa memoria addizionale. Bisogna dire, però, che non ne serve nemmeno una gran quantità. Infatti i BOB erano, in genere, di piccola dimensione. Per cui una cache di soli 64×64 pixel/bit (pari a 512 byte) sarebbe stata più che sufficiente a soddisfare la stragrandissima maggioranza dei casi.
Questa è la modifica più consistente e costosa (in termini di silicio / area sul chip), per cui si potrebbe obiettare che non rientrerebbe nei “no new chips“. Dunque non fattibile, per definizione.
Se non fosse che per l’Amiga 3000 è stato realizzato un chip apposito, chiamato Amber, che si occupa del deinterlacciamento (scan doubling) della grafica in modo che si possa visualizzare su monitor multisync a frequenze più elevate rispetto a quelle del segnale video originale, con una maggior stabilità dell’immagine. Ma non solo: questo chip faceva uso di ben 384kB di memoria per poter realizzare quest’operazione!
Non vedo, dunque, per quale motivo non si sarebbe potuta implementare questa piccola cache, la quale, peraltro, sarebbe stata di gran lunga più utile.
Conclusioni
Credo non ci siano dubbi sul fatto che Commodore, e specificamente il progetto Amiga, sia stata affossata dall’incapacità di un gruppo dirigenziale assolutamente non all’altezza nel comprendere le potenziale e poter gestire al meglio il tesoro che era finito nelle loro mani.
Personalmente reputo, però, che il comportato tecnico abbia avuto parimenti anche lui le sue grosse responsabilità, non essendo stato in grado di far evolvere in maniera adeguata un progetto che aveva davanti a sé ampi spazi di miglioramento.
I manager Commodore si sono crogiolati nell’avere trovato la nuova gallina dalle uova d’oro (dopo il Commodore 64), ma lo stesso hanno fatto gli ingegneri: entrambi hanno vissuto “di rendita”, facendo pochissimo per rinforzare il progetto Amiga e renderlo ancora più solido e competitivo.
In particolare agli ingegneri è mancata la visione di cosa servisse realmente alla piattaforma, dal punto di vista delle caratteristiche più importanti da implementare per venire in contro alle esigenze degli sviluppatori (in particolare per i giochi, che sono stati il principale motivo per cui sono stati venduti così tanti Amiga).
I cambiamenti suggeriti qui sopra sono roba di semplice realizzazione, che sarebbero potuti rientrare nel dictat manageriale del “no new chips“, e che qualunque sviluppatore Amiga che abbia lavorato sul campo sono sicuro potrebbe tranquillamente confermare.
“The Amiga, Born a Champion“
“We made Amiga, They f@cked it up“
