Da un po’ di tempo a questa parte circola insistentemente nei forum dedicati alla piattaforma del cuore (l’Amiga, “ovviamente”. Almeno per me e parecchi altri fortunati che hanno avuto il privilegio di potersela godere) l’idea che nella sua evoluzione si sarebbe potuto (e dovuto!) introdurre un DSP per sopperire a delle croniche mancanze dovute agli scarsi aggiornamenti che sono stati effettuati al suo chipset.
Idea non peregrina, in quanto corroborata da un po’ di lavoro di ricerca & sviluppo che è stato fatto dagli ingegneri di casa Commodore (non il team originale che, purtroppo, era andato via qualche anno dopo l’introduzione del primo Amiga), i quali avevano sperimentato col DSP3210 di AT&T che era stato integrato in alcuni prototipi di Amiga 3000+.
Perché un DSP?
Le motivazioni per l’adozione di un DSP come quello sono sparse in diverse dichiarazioni e/o interviste di alcuni membri dello staff Commodore che si è occupato dello sviluppo dell’hardware.
In particolare da Dave Haynie, alla pagina dedicata all’Amiga 3000+:
There was an audio CODEC here, designed to allow 16-bit, 2-channel recording and playback
[…]
In addition, there was a separate mono CODEC with hardware phase correction, which supported modem protocols up to V32.
[…]
we wanted it for a general purpose signal computing engine […] The DSP3210 could do some floating point operations (single precision only) ten times faster than the 68040
[…]
two audio CODECs. One was for modem projects, a lower bitrate mono CODEC with phase correction, and the other was a 16-bit, CD-quality audio CODEC, for high quality audio I/O
[…]
the DSP would have been able to give us at least eight channels of playback at full CD quality
e da un’altra intervista:
This would have delivered 16-bit audio I/O, software modem, number crunching 5x-10x faster than a 68040, etc.
Ancora un’intervista, ma da parte di Mike Sinz:
the DSP was powerful enough to do a full V.32bis/V.42bis FAX/Data modem *IN SOFTWARE*
[…]
It would also so really good speach and sound and math (talk about fast rendering times!)
E infine un’intervista a Lew Eggebrecht:
The current capability is four channels of 8-bit samples at 27 KHz and we forsee that most systems in the future will have CD capability. Most of the sound and music will come from this so it was not as important to put that technology in. Our long term strategy is to put the DSP in every system, obviously. That will be sound in and sound out and you can do pretty much whatever you like
Qui è bene sottolineare immediatamente che l’intervista è del 1993, quindi dopo la commercializzazione degli Amiga 4000 e 1200, e si riferisce ai futuri modelli di Amiga che dovranno occuparsi di risolvere il gap tecnologico che attanaglia la piattaforma da parecchio tempo.
Altro materiale si trova in un documento introduttivo del DSP e dell’Amiga 3000+:
DSPs are good for performing a large number of repetitive mathematical operations combined with extreme memory bandwidth requirements.
DSPs are capable of real-time signal processing of real-world data (e.g. audio samples).
e in un altro riguardo l’implementazione del sistema:
Audio rate sampling should certainly support the CD frequency, 44.1kHz, directly, and should also consider AAA system 16-bit HiFi sampling rates
[…]
For modem applications […] Telephone interfaces should consider the V22 and V32 standards for modem and the V27 and V29 standards for Fax
In sintesi, il DSP sarebbe servito per:
- acquisizione di audio stereo di qualità CD (16 bit, e almeno 44,1Khz);
- fino a 8 canali audio con la stessa qualità;
- modem per telecomunicazioni;
- elaborazione dei segnali e massiccio calcolo (rispetto al top di gamma dell’epoca: il 68040).
Bisogna anche notare che il DSP sarebbe dovuto esser adottato dalle macchine top di gamma e non da quelle low-end, come affermato da Mike Sinz:
The A3000+ was a AA (oops, AGA) based machine with the same box/formfactor of the A3000 but also included an AT&T DSP32 (very cool)
The A1000+ was a super-low-cost 2-slot AGA-based Amiga. Goal was to have this thing list at $999 including hard drive, 2 or 4 megs of RAM depending on RAM prices, keyboard, etc.
D’altra parte, e come evidenziato da Lew Eggebrecht, l’adozione generale del DSP (quindi per tutti i sistemi) sarebbe dovuta avvenire soltanto con le macchine che avrebbero seguito quelle AGA, e per giunta a lungo termine. Infatti, all’epoca, i CD avevano solo da qualche tempo cominciato a prendere piede nei computer):
The current capability is four channels of 8-bit samples at 27 KHz and we forsee that most systems in the future will have CD capability. Most of the sound and music will come from this so it was not as important to put that technology in. Our long term strategy is to put the DSP in every system, obviously. That will be sound in and sound out and you can do pretty much whatever you like.
Era la strada seguire?
Ci si potrebbe chiedere a questo punto se tutto ciò avesse un senso, quindi se quella sarebbe dovuta essere la strada da seguire.
Avere a disposizione un mostriciattolo per macinare numeri sarebbe potuto anche essere interessante per una macchina high-end, specialmente votata al multimedia com’è stata sempre l’Amiga, ma… perché pensare di supportare un modem? E’ vero che la telecomunicazione fra dispositivi collegati tramite il telefono era in grande espansione, ma era per lo più roba di appassionati.
Discorso diverso per la polifonia. Infatti uno dei più grossi problemi dell’Amiga è stato quello che il comparto audio fosse rimasto assolutamente cristallizzato durante l’intero arco della sua esistenza, nonostante fosse partito con un vantaggio tecnologico spaventoso all’epoca dell’introduzione del primo modello.
La concorrenza non è stata certo a guardare e ha presentato innovazioni che hanno superato (a volte anche di molto!) i quattro canali PCM stereo a 8 bit da 28Khz dell’Amiga 1000 (che, come già detto, sono rimasti esattamente gli stessi per tutti i modelli).
La prima è stata Apple col suo IIGS, il quale con le sue 32 voci (16 in stereo) è stato il primo, fortissimo, segnale in tal senso. La seconda è stata Acorn, che con l’Archimedes ha messo a disposizione 8 canali stereo. Ma anche il PC ha aperto le danze con la famosissima (ma costosissima) Roland MT-32, che arrivava fino a 32 voci. Questo per citare gli esempi più famosi, ma non sono stati gli unici.
Nel ’91, dopo ben sei anni dall’arrivo dell’Amiga 1000, la soluzione che stavano sperimentando gli ingegneri di casa Commodore su un modello tutt’altro che economico era un DSP: componente alieno all’ecosistema, incompatibile col software esistente, e che avrebbe richiesto apposita programmazione (col contorto linguaggio assembly che può avere un DSP).
Decisamente non la strada da seguire. Anche perché s’è continuato a ignorare completamente il mercato di riferimento di queste macchine: quello dei molto più economici e abbordabili home computer, con una particolare predilezione in ambito videoludico.
Ciò che lascia esterrefatti, però, è che si poteva tranquillamente trovare la soluzione “in casa” (anche quella del campionamento di audio da fonti esterne. Altro punto di quelli citati in precedenza quali motivazioni per adottare il DSP) se si fosse mostrata una conoscenza (e competenza) ben più approfondita del funzionamento della macchina.
Il funzionamento dei chip custom
Si potrebbe ben dire, infatti, che si trovasse proprio sotto il naso (letteralmente!), ma soltanto andando a posare lo sguardo su un particolare diagramma: quello dell’allocazione degli slot dei DMA (che mostra in che modo gli accessi in memoria, chiamati usualmente slot, siano riservati e, in generale, funzionino). Il quale si presenta in questo modo:
Giusto per dare una rapida introduzione, quello visualizzato è ciò che succede quando dev’essere visualizzata una singola linea a video, la quale risulta costituita da 227,5 accessi alla memoria (di cui soltanto 226 realmente disponibili), dove un accesso richiede due cicli di clock (un accesso viene chiamato “color clock“, semplificato in CC, in gergo amighista) e consente di leggere o scrivere una word (16 bit = 2 byte) alla volta.
Tutti questi accessi sono suddivisi in gruppi: si parte con la circuiteria di “rinfresco” della memoria (a cui sono assegnati i primi 4 slot), poi il disco (3 slot), l’audio (4 slot), gli sprite (16 slot. Uno sprite ne richiede due) e infine la circuiteria che si occupa effettivamente di visualizzare la grafica dello schermo (160 slot). Copper, Blitter e processore possono utilizzare i rimanenti slot, in quest’ordine di priorità (il primo è il più importante).
Quando uno di questi dispositivi ha bisogno di accedere alla memoria fa uso di uno degli slot che gli sono stati assegnati, e può quindi procedere direttamente alla lettura o alla scrittura (sto volutamente semplificando, evitando di parlare dei conflitti fra sprite e controllore video), senza chieder conto a nessuno (quegli slot sono suoi e non glieli può levare nessuno).
Il funzionamento magistrale dei chip custom nella piattaforma Amiga si deve al suo principale progettista (Jay Miner), il quale ha modellato il sistema degli slot in perfetta simbiosi col funzionamento del processore 68000 di Motorola.
Infatti quest’ultimo non viene influenzato dagli accessi in memoria di questi dispositivi (a parte contenderli con Copper e Blitter, eventualmente), poiché normalmente tali accessi avvengono quando questi è impegnati in calcoli interni e, quindi, non accede mai in memoria. Per cui è come se vedesse la memoria sempre libera. Geniale, no?
Quest’idillio s’interrompe soltanto quando il controllore video deve visualizzare grafica con più colori (anche qui sto semplificando, evitando di parlare della modalità Dual-Playfield). Quindi con schemi a bassa risoluzione (320×200 o 320×256. Qui ignoro la modalità interlacciata, che comunque non incide in questo discorso) con 32 o più colori, oppure ad alta risoluzione (640×200 o 640×256) con 8 o 16 colori.
Dopo queste informazioni, e andando a rivedere per bene il suddetto diagramma, a questo punto risulta facile comprendere in che modo tutto ciò funzioni. Normalmente (schermi senza troppi colori) tutti i dispositivi utilizzano gli slot dispari per accedere alla memoria lasciando, quindi, quelli pari tutti liberi per CPU & co..
La circuiteria di rinfresco della memoria utilizza gli slot $-1 (perché parte dalla fine della precedente riga video), $1, $3, $5, il disco $7, $9, $B (la numerazione è esadecimale), l’audio $D, $F, $11, $13, gli sprite $15, $17 (entrambi per il primo sprite), $19, $1B (per il secondo), …, e così via, fino a $31, $33 (per l’ottavo).
Un po’ più complesso lo schema del controllore video, poiché l’uso degli slot dipende in primis dalla risoluzione orizzontale, e secondariamente dall’uso o meno dello scroll hardware (che per il momento ignoriamo). L’utilizzo degli slot per la grafica ricalca, in ogni caso, quanto già detto: prima vengono impiegati gli slot dispari e poi, se necessario, quelli pari, com’è possibile verificare da una parte del estratta dal diagramma di cui sopra:
Come si può vedere, gli slot allocati per i bitplane in bassa risoluzione sono $4F, $4B, $4D, $49, $4E, $4A: i primi quattro (fino a 16 colori) sono dispari, mentre gli ultimi (32 e 64/4096 colori) sono pari. Discorso simile per l’alta risoluzione, che invece utilizza $4B, $49, $4A, $48: i primi due (fino a 4 colori) sono dispari e gli ultimi due (8 e 16 colori) sono pari. E così via.
Superiamo i quattro canali audio!
A questo punto la soluzione al problema nasce a dir poco spontanea, andando a controllare gli slot rimasti liberi nella sezione audio:
Abbiamo visto che i canali audio hanno gli slot $D, $F, $11, $13 (tutti dispari, per l’appunto) riservati esclusivamente per loro. Basta spostare tutto indietro di uno slot, e sfruttare i quattro slot pari liberi: $C, $E, $10, $12, che si potrebbero benissimo utilizzare per altri quattro canali. Il gioco è fatto!
Da notare che quest’idea non richiede alcuna né memoria aggiuntiva né banda di memoria addizionale: si sfruttano semplicemente (!) le risorse già a disposizione e che altrimenti risulterebbero inutilizzate oppure impiegate da Copper, Blitter o CPU.
Ovviamente questo ricade esclusivamente sul piano della memoria e degli accessi col DMA per prelevare i dati dei campioni, ma serve ancora altro. Ad esempio, i nuovi registri per programmare questi canali.
Se volessimo puntare al risparmio a tutti i costi, potremmo utilizzare similmente l’orribile pezza che è stata introdotta nel chipset AGA, il quale mette a disposizione una palette di 256 colori, ma sfruttando i 32 registri esistenti in OCS e ECS per caricarne i valori, usando un registro in cui si specifica a quale degli 8 banchi da 32 colori vogliamo accedere. Con l’audio si potrebbe fare esattamente la stessa cosa, con un registro in cui sarebbe possibile scegliere il banco dei 4 canali da selezionare.
Questo meccanismo servirebbe a poter selezionare il banco di canali audio anche relativamente ad alcuni registri speciali (usati anche per altri componenti): DMACON/R, INTENA/R, INTREQ/R, e ADKCON/R. Quindi anche questi registri sarebbero duplicati internamente (ma soltanto per i bit usati dall’audio) per ogni banco di 4 canali.
Una soluzione molto più elegante sarebbe quella di avere un banco di registri dedicati e direttamente accessibili senza un meccanismo del genere, ma a questo punto servirebbe estendere un bel po’ l’area per indirizzare i registri dei chip custom (OCS, ECS e AGA hanno soltanto 256 registri mappati a partire dall’indirizzo $DFF000), e riorganizzare meglio i registri (non aggiungo i dettagli perché non voglio allungare troppo l’articolo).
Cosa che, comunque, sarebbe stata fattibile già da tempo grazie ai miglioramenti dei processi produttivi (che hanno consentito di impacchettare più transistor nella stessa area).
Ciò che importa, in ogni caso, è che la soluzione trovata non richiede un DSP completamente alieno alla piattaforma Amiga, ma si integra perfettamente con l’esistente, in quanto sua naturale estensione, e richiede pochissimo sforzo per il suo supporto.
Ma possiamo andare oltre…
Ed è talmente naturale che sarebbe possibile estendere il meccanismo aggiungendo altri quattro canali audio, sfruttando esattamente lo stesso principio, andando a pescare dai 4 slot (pari) liberi che precedono quelli appena selezionati:
Dunque $4, $6, $8, $A saranno gli slot da utilizzare per arrivare fino a ben 12 canali audio in totale. Ovviamente per i loro registri e le loro impostazioni valgono esattamente le stesse considerazioni fatte in precedenza.
Si tratta degli slot che si trovano in mezzo all’area del DMA del disco e, in parte, di quella della circuiteria di rinfresco della memoria, ma ciò è del tutto irrilevante ai fini della questione, perché tali dispositivi utilizzano soltanto gli slot dispari a loro assegnati e non necessitano di alcuna espansione.
Poiché, come si suol dire, l’appetito vien mangiando, sfruttando la stessa logica si può chiudere il cerchio e implementare anche il primo punto che era stato elencato fra le possibilità offerte dall’introduzione del DSP: l’acquisizione di audio (dall’esterno).
In questo caso è sufficiente utilizzare gli ultimi due slot pari rimasti liberi:
Quindi il $0 e il $2, che ricadono anch’essi nell’area della circuiteria di rinfresco della memoria, ma che al momento erano di esclusivo appannaggio dei Copper, Blitter e processore.
Ovviamente in questo caso, essendo votati alla sola acquisizione di campioni (da scrivere in memoria), non serviranno i registri audio per controllare il volume e altre proprietà: sarà sufficiente impostare la locazione di memoria a partire dalla quale scrivere i dati, e quanto è grande tale area (in termini di numero di word = 16 bit = coppie di byte).
Il costo implementativo
Finora sembra tutto molto bello: ben 12 canali audio a disposizione (potete già immaginare la ricchezza polifonica che ne verrebbe fuori) e un altro paio per l’acquisizione di campioni stereo. Un sogno a occhi aperti per molti amighisti che sono stati costretti a ripiegare su software come OctaMED per cercare di poter ascoltare più delle 4 voci standard.
Ovviamente c’è sempre un pezzo da pagare, perché supportare più canali richiede un bel po’ di transistor allo scopo. Il chip che si occupa dell’audio è Denise, ma al suo interno integra anche il supporto ad altri dispositivi, I/O, e roba di sistema (interrupt).
Quindi non è chiaro quanta della sua area sarebbe deputata e alle sole modifiche richieste. Rozzamente si potrebbe pensare di “triplicarlo”, ma tre chip sarebbero decisamente troppi (anche se perfettamente in linea coi progressi tecnologici che i processi produttivi hanno fatto dal 1985).
D’altra parte moltiplicare/duplicare sempre il numero di chip è un processo che, manco a dirlo, non scala affatto se dovessimo prendere in considerazione di aggiungere ulteriori canali (cosa anche questa fattibile, ma che sarà oggetto di un altro articolo).
La soluzione, in questo caso, è quella di implementare due soli DAC a più alta risoluzione (16 bit, ad esempio), utilizzando una circuiteria che si occupi di “raggruppare” (“sommare”) i dati (a 8 + 6 bit: 14 bit. 8 bit per i campione e 6 per il volume) di ogni canale audio. Ovviamente i due DAC si occuperanno rispettivamente del canale di uscita di sinistra e di quello di destra.
Ciò dovrebbe consentire di scalare abbastanza agevolmente con l’eventuale crescita del numero di canali audio a disposizione. Soprattutto, una soluzione del genere dovrebbe essere ben più economica rispetto all’aggiunta di un elemento alieno come il DSP che è stato proposto per colmare queste carenze.
Che può fare anche altro, è vero, ma quanto ciò possa essere utile all’ecosistema Amiga è ampiamente opinabile. Partiamo dal supporto alla qualità CD, ad esempio. Le modifiche suggerite in quest’articolo aumentano la polifonia (anche oltre ciò che sarebbe stato proposto col DSP), ma rimane limitata a 8 bit e non riesce ad arrivare ai 44,1Khz dei CD (il limite dell’Amiga tramite DMA è di circa 28Khz).
Cosa di cui, però, non si sente molto la mancanza, se consideriamo il periodo di tempo in oggetto: 1991-92. D’altra parte lo stesso Lew Eggebrecht l’aveva già ribadito nell’intervista rilasciata nel ’93 (quindi 1-2 anni dopo), che soltanto in futuro i sistemi avrebbero capacità da CD, e questo sarebbe stato aggiunto tramite il DSP in una strategia di lungo termine (quindi non a breve: ci sarebbe stato ancora da aspettare).
Cosa assolutamente condivisibile se consideriamo pure che aumentare la frequenza e, soprattutto, l’ampiezza dei campioni (da 8 a 16 bit) avrebbe comportato un proporzionale consumo di memoria e della relativa banda, che non erano disponibili in grandi quantità.
Anche dal punto di vista economico, infine, la soluzione DSP appare a dir poco sovrabbondante, visto che sempre Eggebrecht afferma che tale chip sarebbe costato poco (ma soltanto secondo lui. Basti vedere più avanti):
We can’t make that decision right now – it’s something we’ll have to look at but in that time frame, even in the low end, every machine is likely to have a DSP. It’s a cost thing – although the AT&T chip itself is only $20 to $30 or so. AT&T has a number of lower cost options, as well, that are designed more specifically to go on the motherboard.
Anzi: molto sovrabbondante, se pensiamo che il costo di produzione dell’intero chipset AGA (come minimo i tre chip principali, ma probabilmente ne erano inclusi altri secondari) costava a Commodore soltanto $12 (infatti l’Amiga 1200 era molto profittevole, come riportato dai top manager dell’epoca).
Per cui aumentare la polifonia a 8 voci (aggiungendo ipoteticamente un chip audio addizionale) oppure a 12 (aggiungendone due) sarebbe venuto a costare, molto rozzamente, sui $4 e $8 in più, rispettivamente.
Quindi di gran lunga inferiore rispetto al costo del DSP (nel ’93!), e con gli enormi vantaggi di essere sviluppato interamente in casa (anziché legarsi mani e piedi a un produttore esterno) nonché perfettamente integrato nella piattaforma (ne sarebbe stata una naturalissima estensione!).
Conclusioni
Penso sia piuttosto evidente di come il sottosistema audio degli Amiga si sarebbe potuto evolvere se vi fosse stata una migliore conoscenza del funzionamento della piattaforma da parte del personale tecnico di casa Commodore, accompagnata a una visione più chiara e, soprattutto, pragmatica (quindi tenendo conto del mercato in cui si operava e delle annesse esigenze di chi ci lavorava) su come far evolvere il tutto in maniera naturale e coerente con l’esistente.
Le soluzioni molto facili ai problemi non richiedono molto sforzi, e sono spesso alla portata di chiunque (non serve il colpo di genio, come si suol dire). Lo dimostra, ad esempio, il modo in cui sia stata introdotta la circuiteria di conversione da packed/chunky a planare che è stata integrata in Akiko (e di cui abbiamo già parlato lo scorso anno in un apposito articolo).
L’Amiga, insomma, avrebbe meritato ben altro trattamento, e non soltanto dai continuamente vituperati vertici aziendali (manageriali). Le colpe, a mio avviso, vanno attribuite a tutti (quindi anche agli ingegneri), perché le mancanze, inefficienze e incompetenze si possono riscontrare in ogni settore.
Poiché se n’è parlato poco in ambito puramente tecnico, questo è il primo di una piccola serie di articoli che tratteranno specificamente alcuni di questi temi. Il prossimo farà luce sul comparto grafico e quello che si sarebbe potuto fare rimanendo sempre indissolubilmente legati alle caratteristiche proprie di questo meraviglioso sistema, migliorandone ed esaltandone le peculiarità che sono state apprezzate dagli utenti e, in particolare, dai programmatori che ne hanno piacevolmente programmato l’hardware.
