Aggiungere piccole, ma importanti, funzionalità al chipset per migliorare l’audio e la grafica sono soltanto una parte delle possibili migliorie che avrebbero consentito di far evolvere molto meglio la piattaforma Amiga, rendendo anche la vita molto più semplice ai programmatori e agli artisti.
Finora, però, queste modifiche sono basate esclusivamente sul chipset originale (l’OCS), scavando nel suo funzionamento interno e cercando di sfruttarne al massimo alcuni aspetti abbastanza oscuri e poco noti (trattandosi di dettagli squisitamente tecnici).
Per quanto molto utili (e sicuramente avrebbero fatto la differenza, se messi a disposizione nei tempi giusti!), ciò non sarebbe stato sufficiente per affrontare le ben più impegnative sfide di lungo termine, con la concorrenza che nel frattempo non è stata certo a guardare.
Aumentare le frequenze
La risposta scontata a ciò è quella di aumentare le frequenze. D’altra parte il miglioramento dei processi produttivi ha consentito, col passare degli anni, non soltanto di aumentare il numero di transistor a parità di area, ma ha dato il via libera all’innalzamento del clock dei componenti elettronici (oppure la riduzione dei consumi a parità di frequenze).
L’argomento è stato sviscerato in un recente articolo, che ha trattato parecchi aspetti prettamente tecnici e, soprattutto, inerenti i problemi di compatibilità che sorgono in questi casi, illustrando il modo di affrontarli in modo da preservare integralmente l’esecuzione del codice già esistente.
I vantaggi di un sistema (chipset in primis, ma anche il processore) che lavora a 14Mhz (anziché i canonici 7Mhz) sono quelli che certamente hanno un maggior impatto (basti pensare al Blitter che va da 2,5 a 3 volte più veloce: già solo per questo avrebbe dovuto esser preso assolutamente in considerazione!), seppur tali modifiche siano estremamente conservative (si è trattato “soltanto” di far girare tutto al doppio della frequenza).
Dunque nulla è stato proposto in termini di funzionalità aggiuntive, in modo da andare oltre quello che fosse già offerto dai chipset originali (OCS e ECS). D’altra parte il tema trattato era anche quello di “non avere nuovi chip” (SIGH!), e se quelli dell’ECS, pur con tutte le modifiche apportate rispetto a OCS, non vengono considerati nuovi chip dagli ingegneri Commodore, allo stesso, identico, modo non possono essere considerati tali anche chip che implementino il “solo” funzionamento a 14Mhz. Questione di coerenza.
Quella di avere a disposizione frequenze più elevate rappresenta una grande opportunità per andare oltre ciò, ed espandere ulteriormente i discorsi che sono stati già fatti nei precedenti due articoli di questa serie.
Aumentiamo gli slot per (quasi) tutti i dispositivi
Per prima cosa è, però, doveroso riportare nuovamente il diagramma di allocazione degli slot dei DMA dell’Amiga:
perché rappresenta il cuore del funzionamento dei tre chip custom di questa stupenda piattaforma, ed è anche quello a cui bisogna necessariamente riferirsi quando parliamo di aumentarne la frequenza di funzionamento.
Il già citato articolo sul sistema a 14Mhz ha mostrato come funzionerebbe la logica del controllore video in questa modalità e, quindi, come i vari slot a esso dedicato “cambino di posto” (nonché funzionamento) per poter essere in grado di operare correttamente (sostanzialmente con la stessa logica).
Il posto è cambiato perché, giusto per dare una rispolverata a quell’idea, per visualizzare la stessa grafica in una riga a video, ma col clock a 14Mhz, il numero di cicli di clock a disposizione è stato raddoppiato: mentre col clock a 7Mhz la grafica partiva dallo slot $38 (esadecimale), adesso parte da $70; e così via ($39 diventa $72, $3A è $74, ecc. ecc.) per tutti gli altri slot allocati per la grafica dello schermo.
Gli slot erano rimasti esattamente gli stessi (quindi anche nella stessa posizione) per gli altri dispositivi (circuiteria di rinfresco della memoria, disco, audio e sprite) in quanto, e come già scritto, lo scopo di quell’articolo era di mostrare in che modo sarebbe stato possibile aumentare il clock dell’intero sistema in maniera retrocompatibile, ma senza introdurre alcuna altra funzionalità aggiuntiva (che è, invece, lo scopo di questa serie).
Lo stesso meccanismo, però, si può benissimo applicare a tutti i dispositivi, per l’appunto. Quindi gli slot per il rinfresco della memoria diventerebbero $-2 (il primo, che in precedenza era $-1, parte sempre dalla fine della precedente riga video), $2, $6, $A, mentre per il disco sarebbero $E, $12, $16, a seguire l’audio con $1A, $1E, $22, $26, e infine gli sprite che vanno da $2A, $2E fino a $62, $66: tutti con posizione “raddoppiata” rispetto a quella che avevano operando a 7Mhz.
Questo significa che rimarrebbero liberi i nuovi slot che li seguono immediatamente. Giusto per essere chiari, tutti gli slot originali hanno adesso una posizione raddoppiata in seno a una riga video (e, quindi, per mera definizione matematica tale posizione sarà sempre un numero pari). Per cui tutti quelli che li seguono hanno una posizione dispari, e sono a disposizione per altri usi.
Aggiungiamo altri canali audio…
A questo punto possiamo utilizzare alcuni di questi slot liberi per aggiungere altri canali audio, ad esempio, com’è stato illustrato nel primo articolo di questa serie. Abbiamo visto che l’Amiga ne riserva quattro allo scopo ($D, $F, $11, $13):
che col clock raddoppiato si sono “spostati” negli slot $1A, $1E, $22, $26.
Avere un clock al doppio della frequenza vuol anche dire che sono stati aggiunti degli slot esattamente dopo ognuno di quelli originali. Quindi i nuovi slot che sono stati “creati” sono $1B, $1F, $23, $27, e sono proprio quelli che si possono usare per aggiungere altri quattro canali.
Ovviamente avere la possibilità di accedere alla memoria Chip (l’unica da cui possono leggere o scrivere i chip custom) è soltanto uno dei requisiti necessari per poter ottenere canali, ma poi servono anche i registri dedicati e la logica per implementarli.
Tutto ciò è stato già ampiamente trattato nel primo articolo, per cui è sufficiente far riferimento a esso per tutti i dettagli del caso. Inoltre il meccanismo è assolutamente scalabile e in maniera del tutto trasparente per gli sviluppatori.
L’articolo ha mostrato anche come sfruttare gli slot pari liberi per aggiungere canali, fino a un massimo di 12 + 2 (due per campionare suoni dall’esterno), che in realtà sono 14 (non è obbligatorio dover riservare due canali solo per il campionamento: sulla carta si può decidere di sfruttarli come si vuole).
E’ chiaro che se non ci si limitasse ai soli 4 nuovi slot dedicati all’audio che sono stati creati col raddoppio della frequenza e si applicasse lo stesso principio anche agli slot degli altri 10 nuovi canali audio, a conti fatti potremmo avere a disposizione ben 28 canali audio.
Sfruttando, infine, i tre nuovi slot ($F, $13, $17) creati nella sezione dedicata al DMA del disco e l’ultimo nuovo slot ($B) della sezione del rinfresco della memoria:
si potrebbero aggiungere altri 4 canali audio, per arrivare a un totale di 32 canali (stereo e indipendenti).
Direi che non ci sia altro da aggiungere…
… e altri sprite!
Similmente, anche l’area dedicata agli sprite può contare su un numero doppio di nuovi slot a disposizione:
che consentirebbero, di conseguenza, di raddoppiarne il numero, passando da 8 a 16 a 4 colori, oppure da 4 a 8 a 16 colori (sto semplificando per non allungare troppo il discorso).
Il precedente articolo dedicato alla grafica ha mostrato, però, come sarebbe stato possibile raddoppiarne già il numero col sistema a 7Mhz, facendo uso dei relativi slot liberi (quelli pari) adiacenti a quelli normalmente usati e implementati dal chipset originale.
Di conseguenza, il raddoppio di frequenza potrebbe consentire di avere a disposizione un totale di ben 32 sprite a 4 colori, oppure 16 a 16 colori: un sogno per i programmatori di giochi, ma anche per i videogiocatori che avrebbero potuto contare su giochi di gran lunga più appaganti visivamente (e molte conversioni da sala giochi sarebbero state all’altezza degli originali).
Liberiamo il Copper dalle catene
C’è un altro elemento che trarrebbe immediatamente vantaggio dall’aumento delle frequenze, ed è il Copper: il coprocessore dedicato a controllare e modificare il comportamento dei chip custom sincronizzandosi col segnale video.
Avere a disposizione molti più slot liberi (a parità di risoluzione video orizzontale) gli avrebbe consentito, infatti, di poter impostare più registri nella stessa linea video da visualizzare, consentendo di cambiare più colori, ad esempio, oppure di moltiplicare (multiplex) più sprite.
In realtà il Copper è stato limitato a utilizzare soltanto gli slot dispari, lasciando quelli pari agli altri dispositivi in modo da evitare interferenze (ma, soprattutto, per semplificare all’osso la sua implementazione):
The Copper is a two-cycle processor that requests the bus only during odd-numbered memory cycles. This prevents collision with audio, disk, refresh, sprites, and most low resolution display DMA access, all of which use only the even-numbered memory cycles. The Copper, therefore, needs priority over only the 680×0 and the blitter (the DMA channel that handles animation, line drawing, and polygon filling).
Il problema è che in questo modo se ne limita l’utilizzo anche quando avrebbe potuto essere impiegato negli slot pari che fossero stati liberi. Sarebbe stato meglio lasciare ai programmatori, insomma, come e quando utilizzarlo, consentendo piena flessibilità e possibilità di sfruttarla al massimo.
Per questo motivo e in accordo con quanto scritto nel precedente articolo, abilitare il nuovo funzionamento del Copper per l’istruzione MOVE in grado di impostare più registri alla volta dovrebbe al contempo sbloccarlo per utilizzare tutti gli slot liberi a disposizione (lasciando la priorità agli altri dispositivi quando devono accedere alla memoria. Fatta eccezione per Blitter e CPU che rimarrebbero sempre con una priorità inferiore alla sua).
In questo modo il Copper avrebbe acquisito maggior valore e funzionalità, consentendo di realizzare un maggior numero di operazioni per linea video e, quindi, più effetti speciali. Ciò, unito a un ristrutturazione delle sue tre istruzioni (che verrà proposta in un altro articolo) e a un cambiamento su alcuni suoi meccanismi interni (mostrato nel prossimo articolo), avrebbe portato, infine, al suo massimo potenziale.
Frequenze ancora più elevate (?)
Il trucchetto ormai penso sia chiaro: il raddoppio delle frequenze operative consente di raddoppiare il numero di slot a disposizione nella riga video da visualizzare (e tutti i dispositivi che hanno delle aree allocate), rendendo possibile quindi raddoppiare il numero di canali audio e sprite.
Il tutto potendo contare, inoltre, su un Blitter veloce ben più del doppio (a parità di risoluzione e numero di colori visualizzati), e una grafica che richiede la metà dei cicli di clock per essere visualizzata (oppure i nuovi slot potrebbero essere usati per aumentare il numero di colori da visualizzare).
Sembra tutto molto bello e facile, visto che raddoppiando ancora un’altra volta la frequenza (passando da 14 a 28Mhz) di funzionamento del chipset si arriverebbe ad avere 64 canali audio e 64 sprite (e ulteriori benefici nelle altre aree, come già descritto).
In realtà ci sono un paio di considerazioni molto importanti da fare. La prima è che il chipset originale dell’Amiga non funziona effettivamente a 7Mhz, ma almeno a 14Mhz internamente (forse anche a 28Mhz col chip Denise ECS che supporta la super alta risoluzione da 1280 pixel orizzontali).
Infatti 7Mhz è la frequenza di accesso alla memoria, dove per ogni accesso vengono richiesti due cicli di clock (quindi in realtà la memoria sarebbe a 3,5Mhz, dove ogni accesso richiede un solo ciclo di clock), che è tutt’altra cosa.
Ciò significa che passare il clock del sistema (il quale è usato anche dalla CPU, che normalmente viaggia in maniera sincrona coi chip custom. Anche se non è necessario che sia sempre così) da 7 a 14Mhz in realtà richiederebbe lavorare a 28 o addirittura 56Mhz (per la versione che supporta la super alta definizione) per i tre chip custom, che potrebbe comportare problemi di consumo di corrente e relative temperature più elevate, costringendo magari a ricorre a qualche ventolina per il loro raffreddamento.
Non credo che ci sarebbero potuti essere particolari problemi a supportare tali frequenze, considerati gli enormi avanzamenti dei processi produttivi da quando è stato introdotto il primo Amiga, ma è bene mettere in chiaro tutti gli aspetti (anche quelli negativi) che comportino lavorare a frequenze ben più elevate.
Per questo motivo un ulteriore raddoppio delle frequenze, portandole a 28Mhz, potrebbe essere un grattacapo anche andando avanti nel tempo (ad esempio nel 1992: anno di commercializzazione degli Amiga 1200 e 4000, basati sul nuovo chipset AGA), considerato che il chipset dovrebbe lavorare a 56Mhz (non dovrebbero esserci problemi) o addirittura a 112Mhz per la versione in super alta risoluzione (e qui ce ne potrebbero essere sicuramente, visto che parliamo di frequenze estremamente elevate per l’epoca).
La seconda considerazione riguarda, invece, le memorie: passare da 7 a 14Mhz equivale a dovere utilizzare DRAM da 140ns (contro i 280ns per quelle a 7Mhz del chipset originale), che sono assolutamente alla portata (economiche) anche agli inizi degli anni ’90 (il chipset ECS è stato rilasciato nel 1990, con l’Amiga 3000, che tra l’altro ha usato memorie più veloci).
Mentre passare a 28Mhz avrebbe richiesto DRAM da 70ns. Sicuramente disponibili nel 1992 (anno del chipset AGA), ma non certo economiche.
Ciò significa che in futuro si sarebbe dovuto assistere a una biforcazione del chipset, con una versione “base” (che gira a frequenze più ridotte) per i sistemi più economici, mentre una versione avanzata (con frequenze più elevate) per quelli più costosi. Niente di trascendentale, considerato che l’AAA (il chipset in lavorazione dopo l’AGA) prevedeva già due versioni.
Un’ultima considerazione da fare riguarda i futuri aumenti del clock. Raddoppiare ogni volta le frequenze, infatti, non è assolutamente sostenibile, soprattutto perché le memorie DRAM hanno avuto una grossissima battuta d’arresto in tal senso, che hanno costretto i produttori di CPU a disaccoppiare le loro rispettive frequenze di funzionamento (e, quindi, il bus / interfaccia che le collegava).
Avrebbe avuto più senso, quindi, cercare di sfruttare quanto possibile. Ad esempio, se quadruplicare la frequenza rispetto al chipset originale non fosse stato possibile o non conveniente, si sarebbe potuto optare per la sola triplicazione (quindi da 7 a 21Mhz). E così via per gli altri aumenti (dopo i 28Mhz ci sarebbero potuti essere i 35Mhz, i 42Mhz, ecc.).
L’utilizzo di clock così “strani” non è un tabù, ma certamente complica le cose e pone dei limiti anche abbastanza pesanti perché, per dirne una, non consente di far visualizzare grafica in alta risoluzione o in super alta risoluzione a parità di colori visualizzati da quella a bassa risoluzione.
Per essere più chiari e prendendo un clock triplo (21Mhz), ad esempio, visualizzare schermi a 256 colori è tranquillamente possibile in bassa (320 pixel orizzontali) e alta (640 pixel) risoluzione, ma non in super alta (1280) perché non ci sono abbastanza slot a disposizione per poter leggere grafica con tutti quei colori.
Inoltre la logica di funzionamento della circuiteria video andrebbe leggermente cambiata, in modo da eliminare l’estrema rigidità nonché perfetta sincronizzazione fra la logica che si occupa di leggere i dati dalla memoria e quella che si occupa poi di visualizzarli, passando, quindi, a un sistema “on demand” (la logica di lettura dei dati deve iniziare “poco prima” che la logica di visualizzazione stia per finire di visualizzare quelli già caricati).
Niente di trascendentale, ma anche questo va tenuto in conto, soprattutto in ottica di realizzazione di computer Amiga più economici che devono far uso di memorie meno veloci (meglio un clock triplo che limitarsi soltanto al doppio, perché quello quadruplo sarebbe troppo costoso). Che poi sono anche quelli che hanno fatto la fortuna di questa piattaforma, e che pertanto sarebbero dovuti essere il centro dell’attenzione degli ingegneri della casa.
Conclusioni
Come avevo già esposto all’inizio, la soluzione banale per migliorare le prestazioni di un sistema è quella di aumentarne le frequenze operative. E’ banale perché penso che sia piuttosto ovvio e chiunque può pensare di “aumentare i numeri” per “avere di più”.
Le peculiarità di un sistema complesso come quell’Amiga consentono, però, di poter trarre ben altri vantaggi leggendo fra le pieghe delle specifiche di funzionamento dei suoi chip custom e cogliendo le opportunità ivi celate, come qui dimostrato.
Molto si sarebbe potuto fare, dunque, e molto altro ancora sfruttando opportunamente un altro fattore, di cui parlerà il prossimo articolo.
