Come promesso, finalmente arriviamo a parlare delle limitazioni presenti nel chipset dell’Amiga (che ricadono nelle singole componenti) con cui hanno avuto a che fare i programmatori, e le idee, o per meglio dire i sogni, che li hanno tormentati nella speranza che Commodore vi ponesse rimedio, o semplicemente chiedendosi perché il buon Jay Miner non avesse osato di più.
Nei precedenti articoli abbiamo avuto modo di vedere in che modo erano foraggiate le varie parti del sistema dotate di appositi canali DMA e, in particolare, quello dei bitplane che facevano parte dello schermo da visualizzare.
La suddivisione in due pezzi non è casuale né serviva soltanto per non appesantire troppo l’argomento (che mi rendo conto non essere dei più “potabili”, ma purtroppo si tratta di dettagli troppo tecnici). I due argomenti andavano trattati in separata sede perché il funzionamento descritto era effettivamente diverso, e ne influenzava di conseguenza i citati limiti.
A prima vista è difficile pensare che le due cose si comportino in maniera dissimile: in fondo si tratta sempre di elementi a cui vengono assegnati degli slot da utilizzare per accedere alla chip ram. In realtà, analizzando bene il pluricitato schema dell’allocazione degli slot, risulta evidente il loro punto di separazione, che sta proprio negli slot utilizzati.
Infatti la circuiteria di refresh della memoria, il disco, l’audio e gli sprite utilizzano soltanto slot dispari, mentre il display predilige sempre gli slot dispari, ma se ne ha bisogno può utilizzare tranquillamente anche quelli pari (anzi, li può anche sfruttare tutti, lasciando a bocca asciutta CPU, Copper, e/o Blitter, come già detto nel precedente articolo).
La motivazione la conosciamo già: lasciare al 68000 i cicli pari, che erano gli unici che utilizzava per accedere alla memoria. Ma “rubare” cicli al processore per svolgere del lavoro più utile non è mai un crimine. Nello specifico, il più grosso limite a cui si sarebbe dovuto (parzialmente) provvedere era sicuramente quello degli sprite, che ricordiamo essere in numero di 8, ma con soli 4 colori, e per averli a 16 colori bisognava “accoppiarne” due di fila (0 con 1, 2 con 3, ecc.).
Da programmatore di videogiochi dell’epoca gli sprite erano uno strumento utilissimo, e averne soltanto 3 disponibili a 16 colori (uno se lo “mangiava” il DMA dello schermo se veniva abilitato lo scroll orizzontale) era un grosso limite. Jay Miner aveva già progettato il chipset dell’Atari 2600, per cui sapeva bene quanto fossero importanti gli sprite, specialmente per una macchina che doveva fungere anche da “console”.
Eliminare il famigerato trucchetto dell’accoppiamento era sicuramente fattibile ma, come per tutte le cose, non possiamo limitarci a sparare dei numeri in alto: serve contestualizzare (ricordiamoci che parliamo del 1985, anno di introduzione dell’Amiga, che il 23 luglio ha compiuto il suo 25-esimo anniversario) e giustificarne tecnicamente la portata, con le relative conseguenze.
A livello di banda verso la memoria non c’erano sicuramente difficoltà, in quanto sarebbe bastato impiegare, oltre ai due slot dispari già assegnati, quelli dispari immediatamente precedenti (ad esempio gli slot da $0C a $0F per lo sprite 0, anziché soltanto $0D e $0F). Sarebbero stati sottratti al più 16 accessi al microprocessore, ma ubi maior minor cessat, come dicevano gli antichi latini.
A livello di logica per gestire il tutto non penso che sarebbe cambiato di molto (tra l’altro l’hack di accoppiare due sprite richiedeva logica apposita per distinguere e gestire i due casi, mentre qui sarebbe venuto meno), mentre alcuni problemi ci sarebbero stati col banco dei registri dedicati agli sprite, che sarebbe dovuti raddoppiare o quasi.
Ogni sprite, infatti, ha associati 4 registri (a 16 bit) che iniziano dalla locazione $DFF140 e che contengono rispettivamente la posizione, alcuni flag di controllo, il primo bitplane e il secondo bitplane (ricordiamo che per avere immagini a 4 colori servono 2 bitplane). Questi registri finiscono a $DFF17F, e subito dopo ($DFF180 ovviamente) iniziano i 32 registri della palette dello schermo, che quindi si sarebbero dovuti spostare in avanti (ad esempio a $DFF1C0).
Quindi incontriamo già alcuni problemi “logistici”, ma facilmente risolvibili, mentre l’aumento dei registri rappresenta un certo costo, perché stiamo parlando di memoria (statica). Tutto sommato penso fosse sostenibile, perché si sarebbe trattato di aggiungere 64 byte, e avrebbe avuto il vantaggio di organizzare anche meglio i due registri di posizione e controllo (vedremo in futuro come sono fatti); un piccolo svantaggio sarebbe stato quello che i dati di controllo letti dal DMA sarebbero raddoppiati (vedremo pure cosa significa questo), ma da coder vi assicuro che non sarebbe stato un problema.
Tirando le somme per gli sprite, credo che con qualche piccolo sforzo la situazione sarebbe stata di gran lunga migliore, vuoi per il numero degli stessi disponibili a 16 colori (4 colori erano veramente troppo pochi, e tra l’altro con precisi limiti sulla porzione di palette da utilizzare), vuoi per non avere a che fare col fastidioso meccanismo dell’accoppiamento, e ancora per l’organizzazione interna dei già citati registri di posizione e controllo.
Lo stesso giochetto di sfruttare gli slot pari si sarebbe potuto attuare anche per gli altri due componenti che utilizzavano esclusivamente quelli dispari: disco e audio. Ma non avrebbe avuto senso apportare dei cambiamenti, sempre per una questione di contestualizzazione.
Parliamo, infatti, del 1985: non esistevano floppy ad alta densità (da 1,44MB), e i 4 canali PCM a 8 bit completamente indipendenti rappresentarono già di per sé una rivoluzione. Di più non si poteva e, soprattutto, non aveva senso fare.
Non v’è dubbio, però, che col passare del tempo le esigenze sono cambiate, e sarebbe stato necessario farvi fronte. Commodore, però, non l’ha mai fatto, lasciando Paula (il chip che si occupa della gestione di disco, audio, seriale, e parte dell’I/O) intatto: lo stesso chip lo ritroviamo sia negli Amiga 1000 che negli ultimi modelli sfornati.
Francamente lo trovo del tutto incomprensibile, perché i floppy ad alta densità sono poi diventati una realtà tangibile, e per poterci lavorare gli ingegneri hanno dovuto dimezzare la velocità di rotazione del floppy per leggere i dati a una velocità compatibile con la banda messa a disposizione per Paula (che ricordo avere 3 slot dispari, per riga di raster, allo scopo).
Tra l’altro Paula utilizzerà sicuramente una coda all’interno per disaccoppiare la lettura o scrittura dei dati da e verso il floppy, come spiegato nell’apposito articolo, e sarebbe bastata raddoppiarla (da 3 a 6 word) con poco sforzo.
Per l’audio il discorso è sicuramente più complicato e delicato. Innanzitutto pensare di aumentare i canali audio avrebbe comportato troppo sforzo, perché l’architettura era stata pensata per gestirne soltanto 4 (la “maschera” per i canali DMA aveva 4 bit dedicati, come pure quella per gli interrupt associati a ogni canale); 8 o più canali, quindi, avrebbero richiesto modifiche più profonde al sistema (incluso il s.o. che avrebbe dovuto gestire il tutto).
Qualcosa, però, la si poteva anche fare nel 1990 (anno di introduzione dell’ECS), su 3 fronti: frequenza di riproduzione, ampiezza e lunghezza del campionamento. Per i primi due, in particolare, sarebbe servito aumentare la banda di memoria, ma sfruttando gli slot pari, similmente agli sprite, si sarebbe tranquillamente potuta raddoppiare.
Anche i canali audio sono dotati di appositi registri, in numero di 6 per ognuno, che contengono rispettivamente il puntatore (a 32 bit, quindi fa uso 2 registri a 16 bit) al buffer di memoria che contiene il campionamento, la sua lunghezza, il periodo (che determina la frequenza di riproduzione), il volume, e infine la word che contiene i due campioni a 8 bit letti (per riga di raster).
Raddoppiando la banda le word lette sarebbero state due, per cui sarebbe stato necessario un ulteriore registro, ma questo non sarebbero stato un problema perché, per ogni canale, a seguito delle 6 sono presenti 2 word inutilizzate.
Questa modifica non sarebbe stata sufficiente, comunque, perché internamente Paula avrebbe dovuto gestire i 4 sample a 8 bit tramite una coda; soluzione, questa, assolutamente alla portata, e che avrebbe permesso di arrivare teoricamente fino a 58Khz di frequenza (contro i 29 dell’OCS).
Per utilizzare sample a 16 bit anziché a 8 sarebbero serviti dei DAC di adeguata “dimensione”, sicuramente più costosi, ma già alla portata all’epoca (ricordo che il CD-ROM è stato introdotto nel 1985, e i lettori necessitavano di 2 DAC a 16 bit). Per il resto, la gestione sarebbe stata simile ai sample a 8 bit del chipset originale, come pure il limite della frequenza (sempre 29Khz massimi).
L’ultimo limite riguardo ai canali audio era rappresentato dalla lunghezza del campionamento riproducibili: al massimo 128KB (pari a 64K word a 16 bit). Questo perché, come già detto, il registro dedicato allo scopo era soltanto a 16 bit. Una soluzione semplice sarebbe stata quella di affiancargli un altro registro (ce n’era ancora uno inutilizzato) in cui specificare la parte alta della lunghezza, similmente a quanto fatto proprio col Blitter ECS e il suo registro per la dimensione dell’area rettangolare (di cui parleremo in futuro).
Infine il display offre diversi spunti di riflessione sulle mancanze o i miglioramenti possibili e fattibili nel contesto in cui nasceva questa meravigliosa macchina. Partendo sempre dal mio punto di vista di programmatore di videogiochi, ricordo che una modalità molto utilizzata e importante era quella soprannominata Dual Playfield, che metteva a disposizione due schermi indipendenti (scrollabili) e che ci ha regalato perle quali Shadow of the Beast.
Il limite, però, era abbastanza pesante: i due schemi potevano avere a disposizione al più 3 bitplane, e quindi visualizzare al massimo 8 colori (7 per quello frontale, a causa del “colore” 0 che serviva a “forare” lo schermo e visualizzare la grafica di quello sottostante).
Con l’AGA sappiamo che questo limite è stato portato a 4 bitplane per singolo schermo, quindi con 16 colori (15 per il primo schermo) visualizzabili contemporaneamente, che rappresentano un notevole salto qualitativo (se pensiamo pure che ogni schermo avrebbe potuto attingere a una sua palette di 16 colori).
4 bitplane per due schermi avrebbero significato 8 bitplane in totale, mentre il chipset ne metteva a disposizione soltanto 6. Aggiungerne altri 2 non sarebbe stato un problema, perché nella mappa dei registri lo spazio a disposizione c’era, e infatti è stato poi sfruttato proprio dall’AGA.
Al solito bisogna tenere conto anche della banda di memoria necessaria per alimentare questi ulteriori bitplane, ma andando a controllare nel diagramma di allocazione degli slot notiamo che il display a bassa risoluzione sfrutta al più 6 degli 8 slot a disposizione, e tutti gli slot usando l’alta risoluzione con 4 bitplane.
C’è sicuramente da tenere conto del fatto che con 8 bitplane il display non avrebbe lasciato alcuno slot a CPU, Copper e/o Blitter, per cui gli unici a disposizione sarebbero stati quelli dell’horizontal retrace e del vertical retrace (oltre a quelli inutilizzati dalle altre componenti), ma avendo a disposizione anche 8 sprite a 16 colori sono sicuro che i programmatori avrebbero trovato il modo di sfruttare sapientemente il Dual Playfield con 8 bitplane.
Con 8 bitplane, però, si sarebbero potute migliorare altre cose. Uno schermo a 256 colori è certamente allettante, ma il limite più grosso è rappresentato dal numero di colori della palette: soltanto 32 (che “coprono”, quindi, 5 bitplane), tant’è che per avere 64 colori si doveva utilizzare la modalità Extra-Half Brite (EHB), che a ognuno dei 32 colori ne associava un altro a luminosità dimezzata.
Aumentare la dimensione della palette avrebbe comportato alcuni grossi problemi. Allargando l’area da $DFF180 a $DFF1FF non ci sarebbe stato spazio per i registri aggiuntivi necessari per avere tutti gli sprite a 16 colori, e personalmente avrei preferito di gran lunga migliorare questi ultimi.
Pensare di spostare l’area subito dopo, quindi a partire da $DFF200, dedicandola interamente alla LUT (da $DFF200 a $DFF3FF si sarebbe potuta definire una palette di 256 colori diversi) sarebbe stato decisamente troppo costoso per il gran numero di registri aggiuntivi richiesto.
Una soluzione di comodo sarebbe potuta essere quella di sfruttare lo stesso principio dell’EHB, ma anziché mettere a disposizione 2 sole tonalità da un colore base, se ne potevano realizzare 4 con 7 bitplane, e 8 con 8 bitplane (qualcosa di simile, se non ricordo male, la faceva l’Acorn Archimedes, che non aveva una palette di 256 colori diversi).
Anche questa soluzione pone dei problemi in termini di banda a disposizione per CPU, Copper e Blitter, ma sono convinto che le avventure grafiche avrebbero avuto di che guadagnarci dal poter utilizzare schermi a 128 o 256 colori (sebbene non tutti distinti).
Qualche utilità l’avrebbe avuta anche l’estensione dell’Hold-And-Modify (HAM) dai canonici 6 bitplane, a 7 oppure 8. Indubbiamente con una palette base più ricca da cui attingere (16 colori per la classica HAM) le immagini avrebbero risentito meno dei problemi di “cambio colore” tipici di questa modalità video, sebbene fosse utilizzata esclusivamente per visualizzare immagini statiche.
L’ultimo accenno è riservato al numero di colori da cui attingere per la palette: 4096 per l’Amiga nel 1985 erano veramente tanti e una gioia per le pupille. I registri che li contenevano erano, però, a 16 bit anziché a 12 (12 bit -> 4096 colori), per cui Jay Miner avrebbe potuto impiegare 5 bit anziché 4 per colore primario, arrivando a 15 bit (15 bit -> 32mila colori).
Ma un SuperNintendo nel 1985 sarebbe stato davvero troppo (costoso ed esagerato)…
