Nel precedente articolo sul tema ECS mi sono limitato a illustrare alcune funzionalità che sarebbero potute esser implementate in questo chipset e che avrebbero mitigato un po’ la cronica mancanza di aggiornamenti della piattaforma dopo i lunghissimi cinque anni dalla prima versione.
Mi sono astenuto, però, dal riportare un’altra innovazione, molto più significativa ma sempre in linea con col dictat manageriale “no new chips” che ha limitato il budget dei transistor utilizzabili, che avrebbe consentito all’Amiga di riprendere vigore e rendersi estremamente competitiva con la concorrenza, in particolare in ambito videoludico.
Il problema principale di non avere a disposizione vagonate di transistor da poter impiegare per potenziare le funzionalità esistenti e/o aggiungerne di nuove, è che rimangono pochissime strade per migliorare le prestazioni del sistema.
Allargare il bus dati
La prima è quella di aumentare la dimensione del bus dati, in modo da poter leggere più informazioni e, quindi, riuscire scalare in termini di profondità di colore utilizzabili, ad esempio, oppure risoluzioni maggiori, o sprite più larghi, o ancora campioni audio a 16 bit anziché a 8, come pure leggere / scrivere da/sui dischetti ad alta densità, ecc. ecc.
Questa è la strada che è stata imboccata col successivo chipset, l’AGA, sebbene sia stata limitata esclusivamente ad alcuni aspetti del sistema (i primi elencati e che sono legati allo schermo e alla grafica), tralasciandone altri che avrebbero comunque meritato parimenti un aggiornamento (audio e dischetti).
Il più grosso problema di questa soluzione è che richiede l’impiego di parecchi transistor per poter espandere adeguatamente i buffer utilizzati per le svariate funzionalità. Se, ad esempio, prima serviva un registro a 16 bit per memorizzare la grafica di un bitplane, con un bus dati di dimensione doppia ovviamente ne servirà, parimenti, uno ampio il doppio (a 32 bit). E così via per tutti gli altri buffer interni.
Risulta evidente che quest’approccio risulti del tutto incompatibile col dettato dei manager, perché ciò avrebbe aumentato in maniera consistente la spesa riguardo al numero di transistor necessari e, quindi, la dimensione e i relativi costi dei chip.
Altra problematica comunque importante è rappresentata dai costi che sarebbero lievitati anche per la produzione delle schede madri facenti uso di tali chip, perché bus dati di dimensione maggiore ne avrebbe complicato il layout. Se questo poteva andar bene con sistemi professionali come l’Amiga 3000 (che è stato il primo a impiegare l’ECS e aveva, per l’appunto, un bus dati a 32 bit), non lo sarebbe stato per i sistemi più economici.
Aumentare la frequenza
Scartato l’ampliamento del bus dati, non rimane che l’altra soluzione per eccellenza: aumentare le frequenze dei chip. Questa è la soluzione a cui avevo pensato, ma che ho preferito evitare di riportare nel precedente articolo non avendo avuto il tempo di fare ricerche sulle frequenze raggiungibili dai chip di memoria dell’epoca.
Ma avendo, nel frattempo, chiarito questo punto (erano disponibili, infatti), l’ipotesi di poter far girare i chip a frequenza doppia (a 14Mhz anziché 7Mhz) non è, poi, così peregrina, considerato pure gli enormi progressi dei nuovi processi produttivi a cinque anni di distanza della commercializzazione del primo chipset dell’Amiga (l’OCS).
Nello specifico, la frequenza doppia risulta necessaria per evitare di aver bisogno di più clock di sistema, che avrebbero complicato la piattaforma e l’implementazione. Da questo di vista e avendo un solo “master clock” (clock principale) il problema è risolto (anche perché sono già presenti tutti i clock necessari, derivati da quello a 28Mhz: quelli a 14 e 7Mhz).
I problemi del clock raddoppiato
Utilizzare un clock multiplo di quello principale non risolve tutti i problemi, purtroppo. Non si può, infatti, pensare di raddoppiare il clock utilizzato per accedere alla memoria e sperare che magicamente tutto il sistema funzioni.
Nello specifico, la parte più critica è rappresentata dal sottosistema video, quindi dalla circuiteria che effettivamente visualizza la grafica che è stata prelevata dalla memoria Chip (l’unica utilizzabile dai chip custom). Ma anche il controllore del DMA (il quale si occupa di orchestrare gli accessi in memoria di tutti i chip) non funzionerebbe correttamente così com’è, lavorando a frequenza doppia.
Per capire di cosa si parli e di queste problematiche è necessario fare un piccolo escursus su come funzionino tutti i canali DMA e, quindi, gli accessi alla memoria (d’ora in poi si assumerà implicitamente che si tratti di quella Chip) quando viene elaborata una riga video (detta riga di raster, in gergo), mostrandone il relativo diagramma (preso dal famoso Amiga Hardware Manual. A puro scopo didattico):
Una riga di raster è costituita da 227,5 “color clock“ (un color clock è pari a due cicli di clock di sistema) i quali rappresentano anche gli slot disponibili per gli accessi in memoria, a seconda del particolare uso che se ne faccia (circuiteria di rinfresco della memoria, disco, audio, sprite, e grafica dello schermo).
La circuiteria video
La parte problematica riguarda la grafica dello schermo (perché in tutti gli altri gli slot per la particolare funzionalità / canale sono fissi: o li si usa oppure no), in quanto risulta variabile in base alla risoluzione orizzontale (alta o bassa), dimensione (in caso di overscan, ad esempio) e alla profondità dello schermo (numero di colori = numero di bitplane da cui caricare i dati).
Senza impelagarci troppo nei dettagli, è sufficiente dire che il meccanismo col quale viene visualizzata la grafica si basa su due elementi / chip che collaborano: Agnus, che si occupa di arbitrare gli accessi alla memoria e, quindi, di leggere o scrivere i dati per / da i singoli canali DMA, e Denise che prende i dati letti e li processa inviandoli, poi, alla TV o monitor.
E’ dalla precisa collaborazione fra questi due chip che, quindi, possiamo ammirare a video il risultato di questa sincronia. Per essere più precisi, Denise ha bisogno che tutti i dati che gli servono debbano essere stati letti, in modo da poter partire con la visualizzazione dei pixel.
Dallo schema di cui sopra, verso il centro / destra, si può vedere come Agnus inizi a leggere tutti i dati necessari a partire dallo slot $38, finisca allo slot $40 (dove inizia a leggere quelli del successivo blocco), mentre Denise inizia a inviare a video i pixel elaborati soltanto a partire dallo slot $45 (perché ha dovuto aspettare fino a $40 per poter ottenere tutti i suoi dati).
Operando a 14Mhz anziché a 7Mhz, una riga di raster sarà costituita da 227,5 * 2 = 455 color clock / slot. Quindi ci sono il doppio degli slot a disposizione per accedere alla memoria. Mentre non ci sono problemi per rinfresco della memoria, disco, audio e sprite, che possono utilizzare gli slot alle stesse posizioni, ne sorgono, invece, per la grafica dello schermo.
In questo caso, infatti, non si può più partire dallo slot $38 per leggere i dati, ma da $38 * 2 = $70. Per iniziare a processarli si dovrà, invece, attendere lo slot $40 * 2 = $80. Mentre inizieranno a essere visualizzati a partire dallo slot $80 + 5 = $85.
Il problema sorge soltanto con la bassa risoluzione (320 pixel orizzontali. Overscan escluso), in quanto Agnus avrà finito di leggere i dati degli 8 (al massimo) bitplane già allo slot $70 + 8 = $78. Denise, però, non può utilizzarli immediatamente, ma dovrà aspettare per forza lo slot $80 (altrimenti inizierà a visualizzare la grafica 16 pixel più a sinistra).
Per aggiustare le cose, si dovranno aggiungere due blocchi. Un blocco per Agnus, il quale si fermerà per 8 slot dopo aver finito di prelevare i dati degli 8 bitplane, in modo da non leggere subito gli 8 successivi, visto che non servono immediatamente (Denise impiega il doppio del tempo per processare i pixel in bassa risoluzione).
L’altro blocco riguarda Denise, che in bassa risoluzione dovrà aspettare un ciclo di clock subito dopo aver processato un pixel. Ciò si rende necessario in quanto, operando adesso al doppio della frequenza (rispetto all’OCS), impiega la metà del tempo per inviare il pixel al monitor / TV. Dunque è obbligato ad aspettare un ciclo di prima di passare al prossimo pixel.
Le cose si fanno meravigliosamente bene per l’alta risoluzione, invece. Questo perché è possibile riciclare pari pari il funzionamento della bassa risoluzione in OCS, senza l’aggiunta di alcun blocco. In questo caso Agnus inizierà a leggere i dati allo slot $78. Avrà finito al $80, dal quale Denise inizierà l’elaborazione. Infine il primo pixel verrà visualizzato a $80 + 5 = $85.
Oltre a questo, il notevole vantaggio con l’alta risoluzione sarà quello di poter utilizzare 8 bitplane anziché 4, quindi consentendo la visualizzazione di fino a 256 colori a schermo, incluse le modalità EHB (64 colori), HAM (4096 colori), e Dual Playfield.
Altri aggiustamenti necessari
Qualche modifica minore sarà necessaria per gli sprite, invece: la loro posizione in orizzontale dovrà essere internamente raddoppiata quando lo schermo lavora in bassa risoluzione. Ciò per gli stessi motivi per cui Denise ha bisogno di aspettare un ciclo di clock dopo aver processato un pixel.
Senza questa modifica uno sprite verrebbe visualizzato in alta risoluzione, quindi con una larghezza dimezzata, generando un evidente artefatto visivo.
Una modifica simile spetta al Copper, e più precisamente per le due istruzioni WAIT e SKIP, le quali consentono rispettivamente di aspettare una certa posizione a schermo prima di proseguire l’esecuzione con la prossima istruzione, e di saltare la prossima istruzione se si è già raggiunta o superata una certa posizione dello schermo.
Le modifiche sono necessarie perché non c’è spazio per aggiungere un ulteriore bit per rendere più ampia la selezione della posizione orizzontale da controllare o raggiungere, per cui il Copper lavorerà esattamente come per l’OCS (il che significa “muoversi” orizzontalmente sempre di 4 pixel alla volta in bassa risoluzione).
Infine Paula. Anche questo chip (che non è mai stato toccato: è rimasto sempre lo stesso in tutti i chipset dell’Amiga) ha bisogno di una modifica similare e, specificamente, per la gestione del disco. Infatti Paula si occupa di leggere o scrivere i dati da/sul dischetto. Cosa che avviene a una certa velocità nell’OCS, ma che operando con clock doppio richiede, in questo caso, che la frequenza per queste operazioni sia dimezzata, in modo da funzionare esattamente come con l’OCS.
Come si implementa
Per selezionare il clock a 14Mhz anziché 7Mhz è sufficiente sfruttare un solo bit libero in uno dei tanti registri a disposizione. La soluzione che garantisce la miglior compatibilità con OCS è rappresentata dal nuovo registro BPLCON3, che è stato introdotto proprio con l’ECS.
Come si può vedere in questa descrizione, il nuovo registro funziona soltanto se è stato abilitato, quindi impostando il bit 0 del registro BPLCON0. A questo punto si potrebbe usare un qualunque bit di BPLCON3 per abilitare il clock con frequenza doppia: ad esempio il numero 3.
Quindi soltanto quando sia questo bit sia il bit 0 di BPLCON0 saranno a 1 allora tutti i chip custom (esclusi i due chip CIA che gestiscono l’I/O, che continuano a funzionare sempre allo stesso modo) funzioneranno a 14Mhz e i cambiamenti di cui sopra saranno operativi. Altrimenti tutto funzionerà esattamente come per l’OCS, garantendo piena compatibilità con tutto il software esistente.
Il Blitter con gli steroidi!
Operando a 14Mhz si assiste anche a un miglioramento prestazionale, poiché schermi operanti alla stessa profondità di colore richiedono la metà degli slot per prelevare i loro dati, lasciando gli altri liberi per essere utilizzati da altri dispositivi: CPU, Copper e Blitter.
Questo è esattamente quello che capita anche col chipset AGA, quando viene fatto lavorare con FMODE pari a 1 o 2. Meglio ancora con FMODE 3, ovviamente, ma questo funzionamento non è emulabile dalle modifiche che ho suggerito (servirebbe anche un bus a 32 bit).
Non sarebbe un problema in ogni caso, poiché la modalità a 14Mhz si estende anche al Blitter, che nell’AGA è rimasto, invece, sempre a 7Mhz. Questo significa che l’ECS a 14Mhz è in grado di muovere di gran lunga più grafica sullo schermo rispetto all’AGA con FMODE pari a 3. Paragonato all’OCS, è come se il Blitter viaggiasse a 2 volte e mezza o anche tre volte la velocità.
In pratica tutti i giochi OCS che sono stati sviluppati per Amiga potrebbero funzionare sempre a 60/50Hz, e molto spesso con più colori e/o con grafica più dettagliata (in questo caso usando la modalità Dual Playfield in alta risoluzione, ad esempio. Come pure l’EHB).
Potete, quindi, facilmente immaginare cosa si sarebbe potuto realizzare con un Blitter così veloce. Per Amiga avrebbe significato tornare a essere assolutamente competitivo con le piattaforme ludiche dell’epoca, quindi console e PC inclusi (tranne per i giochi 3D con texture, che però sarebbero arrivati dopo).
Nessun problema di compatibilità
Un Blitter che lavora a 14Mhz sembra sia stato ipotizzato anche per il chipset successivo all’AGA, l’AA+, ma questa soluzione sarebbe apparsa impraticabile per problemi di compatibilità col software esistente.
In realtà e come abbiamo visto, il clock a 14Mhz è selezionabile esclusivamente attivando i due bit summenzionati. Questo significa che i giochi o le demo che partono all’avvio del sistema si troverebbero col chipset impostato in modalità OCS, e quindi girerebbero senza alcun problema.
Quelli che, invece, prendono il pieno controllo a s.o. avviato dovrebbero avere l’accortezza di impostare correttamente il sistema prima di prendere il completo controllo. In particolare invocando l’API LoadView e passando un puntatore nullo: in questo modo il s.o. rimette a posto i registri del chipset e successivamente l’applicazione avrebbe anche potuto cambiarli come le pare.
Conclusioni
Penso sia evidente come queste semplici modifiche (unite a quelle suggerite nel precedente articolo) avrebbero consentito all’ECS di rimettersi in sesto e rendersi molto più competitivo, donando alla piattaforma Amiga una nuova giovinezza che nemmeno il successivo AGA avrebbe portato (a meno che non avesse introdotto anche lui un clock a 14Mhz per tutti i chip, come ho esposto. Cosa che, però, non è avvenuta), il tutto rimanendo nei termini del budget imposto dalla dirigenza (“no new chips“).
La nuova piattaforma ECS sarebbe stata leggermente più costosa, a causa dell’impiego di un processore 68000 operante a 14Mhz (prendendone uno a 16Mhz. Oppure uno a 12,5Mhz overclockato a 14) e per le memorie più veloci (a 140ns).
Ma in quest’ultimo caso 1MB di dotazione standard sarebbero stati adeguati alle esigenze dei tempi, con lo slot di espansione (Trapdoor nel gergo amighista) in grado in ogni caso di poterla espandere, esattamente com’è avvenuto per l’Amiga 500 (che è stato venduto con 512kB. A cui molti hanno aggiunto successivamente altri 512kB).
Non so se questo avrebbe contribuito a cambiare le sorti dell’Amiga, perché parliamo pur sempre di scenari ipotetici. Ma, con quella dirigenza che s’è ritrovata, non penso che Commodore sarebbe durata molto, in ogni caso…
