Nel precedente articolo abbiamo parlato dei concetti alla base della generazione del segnale video e del fatto che quest’ultimo nell’Amiga regoli tutte le altre componenti (audio, disco, e accesso della CPU alla memoria); abbiamo anche visto che un (semi)quadro è suddiviso in righe di raster, e queste ultime in slot che corrispondo ai color clock (pari a 2 cicli di clock della CPU nei primi modelli).
Ogni riga di raster richiede 227 color clock, che quantificano il numero di accessi alla memoria (o anche ai registri dei chip custom per la CPU). Un accesso alla memoria permette di leggere o scrivere una word a 16 bit, quindi 2 byte, e l’indirizzo di memoria dev’essere necessariamente allineato a tale dimensione (pena risultati imprevisti per i chip custom, mentre viene sollevata un’eccezione dalla CPU).
In totale abbiamo a disposizione una banda verso la memoria pari a poco più di 7MB/s (risultato che salta fuori considerando i circa 3,5M di color clock al secondo), limite strettamente teorico (in quanto non tutta è a disposizione), e in ogni caso viene distribuita fra i vari “pretendenti” con precise logiche di arbitraggio e priorità che andremo a esaminare.
Per comprendere meglio di cosa stiamo parlando è fondamentale prendere visione dell’apposita paginetta dell’Amiga Hardware Manual, in cui è mostrata una riga di raster suddivisa in slot con tanto di commenti che qualificano l’assegnazione e l’uso che se ne fa o se ne potrebbe fare:
Appare evidente, a questo punto, il significato precedentemente attribuito al segnale video in qualità di “regolatore” dell’intera piattaforma, in quanto ogni componente che necessita di accedere alla memoria riservata al chipset (chiamata chip ram) o ai registri del medesimo (principalmente la CPU, ma anche il Copper) trova una precisa collocazione in seno alle righe di raster.
Per alcuni lo slot assegnato è fisso, e addirittura sempre occupato: è il caso della circuiteria dedicata al refresh della memoria (le memorie DRAM, come sappiamo, hanno bisogno di essere “rinfrescate” entro un certo periodo di tempo, pena la perdita delle informazioni memorizzate a causa della scarica dei condensatori di cui fanno uso), che richiede sempre 4 slot all’interno dei quali l’accesso alla memoria non serve a leggere o scrivere una singola word a 16 bit, ma a selezionare interi banchi per effettuarne il refresh.
Il DMA riservato al disco occupa 3 slot seguenti, esclusivamente nel caso in cui sia abilitato per operazioni di lettura o scrittura (altrimenti sarà utilizzabile dal Copper o dal Blitter). In pratica Paula, il chip che si occupa dell’accesso ai dati su floppy, utilizzerà questi slot se avrà riempito la sua coda interna.
Questo perché Paula non può aspettare la disponibilità di questi slot per leggere o scrivere dati, in quanto il chip è sincronizzato con la testina del floppy, pertanto la lettura o la scrittura delle (massimo) 3 word a 16 bit avviene quindi durante tutto il periodo che trascorre per un’intera riga di raster.
Per essere chiari, durante un’operazione di scrittura su floppy Paula preleva immediatamente le 3 word a 16 bit dal buffer che contiene i dati della traccia da scrivere, e le memorizza in una sua coda interna, da dove ne preleverà una alla volta serializzandone la scrittura dei singoli bit e sincronizzando l’operazione di scrittura di ogni bit col movimento della testina.
Per la lettura il procedimento è inverso: man mano che legge i singoli bit provenienti dalla testina li impacchetterà in una word a 16 bit, che verrà poi memorizzata nella sua coda interna; questo per un massimo di 3 word lette. Non appena il color clock sarà “posizionato” (vi prego di farmi passare il termine per una questione di semplificazione divulgativa) negli slot riservati al DMA del disco, li sfrutterà per svuotare la sua coda interna scrivendo in memoria le word lette.
Considerato che abbiamo 625 righe di raster per quadro completo, per 25 quadri completi al secondo, il limite teorico è di 625 * 25 * 3 * 16 = 750 mila bit al secondo trasferibili, quindi superiore ai circa 500 mila bit al secondo standard utilizzati per leggere o scrivere floppy a bassa densità (720KB per il PC, 880KB per Amiga ma il controller permette di arrivare fino a poco più di 1MB di dati).
Anche per l’audio, sempre gestito dallo stesso chip, il discorso è analogo (ma unidirezionale: si legge soltanto dai buffer in memoria), in quanto per ognuno dei 4 canali PCM è a disposizione un solo slot, quindi 1 word a 16 bit equivalente a 2 campioni a 8 bit.
Quando il DMA dell’audio viene attivato per pilotare la riproduzione di un segnale campionato, Paula legge al più una word che memorizza in una sua coda, e che utilizzerà man mano per spedire i due campioni a 8 bit al DAC, in armonia con la frequenza di riproduzione impostata per quel canale.
Anche qui i conti sono presto fatti: 625 righe di raster per 25 quadri completi al secondo per 1 slot fanno 31.250 byte al secondo; quindi in teoria si potrebbero riprodurre segnali a 31,25Khz, ma in pratica Paula ha un limite di design che permette arrivare a circa 29Khz quando fa uso del DMA per leggere i campioni (senza DMA e usando la CPU si va tranquillamente oltre).
Per gli 8 sprite sono disponibili 2 slot ciascuno, in quanto ogni sprite è costituito da 2 bitplane (quindi è possibile visualizzare 4 colori; 3 se consideriamo che il “colore zero” serve per la trasparenza, e quindi per visualizzare lo schermo sottostante). Questo perché gli sprite hanno dimensione orizzontale fissa pari a 16 pixel dove, com’è facilmente intuibile, a ogni pixel corrisponde uno dei 16 bit delle due word. La dimensione verticale è, invece, virtualmente illimitata e si tratta di una caratteristica tipica dell’Amiga (non ricordo di altri sistemi che ne fanno uso).
Denise, il chip dedicato alla visualizzazione della grafica e, quindi, anche della visualizzazione degli sprite, si comporta in maniera diversa rispetto a Paula, in quanto non ha code interne per la gestione dei suoi “folletti”. Quando viene abilitato il DMA per uno sprite, i primi 2 slot assegnatigli vengono usati per leggere i dati relativi alla posizione (coordinate x e y) e dimensione (verticale) dello stesso, dopodiché si metterà in attesa di raggiungere una posizione verticale “utile”.
Quando Denise dovrà visualizzare una riga di raster in cui dev’essere mostrata anche la grafica dello sprite, utilizzerà i due slot per leggere di dati relativi ai due bitplane, che userà successivamente quando comporrà la grafica della linea da visualizzare (ma di questo ne parleremo meglio in futuro).
L’ultimo componente che fa uso degli slot in maniera programmatica è lo schermo, che ovviamente si porta via la maggior parte degli slot, a seconda della risoluzione impiegata (bassa o alta) e del numero di bitplane visualizzati; di come ciò avvenga ne parlerò meglio in un prossimo articolo sui limiti del chipset dell’Amiga (ma guardando l’immagine che ho allegato si capisce già).
Al momento è importante sottolineare il fatto che lo schermo può, in certe condizioni, “rubare” parte degli slot assegnati agli sprite, che pertanto o non possono visualizzare dati, oppure richiedono che sia il Copper o la CPU a “caricarglieli manualmente”(a Denise interessa avere i dati, non che sia il DMA a leggerli).
Questo si verifica quando è abilitato lo scrolling dello schermo, che necessita di una word in più da leggere dai bitplane per poter essere gestito correttamente; pertanto l’ultimo sprite, il 7, non potrà far uso del DMA per recuperare i suoi dati, e normalmente non verrà visualizzato.
Discorso analogo per l’overscan orizzontale, tecnica che permette di sfruttare parte dei bordi laterali per visualizzare più grafica. Ogni 16 pixel orizzontali in più equivalgono ad almeno uno sprite senza DMA, a partire sempre dall’ottavo e a scendere. Abilitando anche lo scrolling si perde un ulteriore sprite. In ogni caso il primo, lo sprite zero, risulta “protetto”: non è possibile utilizzare i suoi slot, quindi almeno la freccetta del mouse sarà sempre visualizzabile.
Tutti i rimanenti slot, quelli che in genere nell’immagine sono bianchi (e graficamente non molto definiti: non esistono quadrati o rettangoli verticali a “inquadrarli”), sono a disposizione di Copper, Blitter e CPU in quest’ordine di priorità, ma con una distinzione: i primi due possono utilizzare qualunque slot, mentre il 68000 soltanto quelli pari.
Questa non è una limitazione del sistema volta a penalizzare il processore ma, al contrario, un vantaggio della piattaforma derivante dalla conoscenza del funzionamento di questo importantissimo componente. Questa CPU (ma non i suoi successori, a partire dal 68020), infatti, utilizza sempre i primi due cicli di clock di sistema (che equivalgono a uno slot) per accedere alla memoria, e i seguenti due per operazioni interne (quindi non accede mai alla memoria).
Il chipset dell’Amiga è stato pensato in modo da sfruttare questo comportamento in maniera intelligente. Infatti per lo più utilizza gli slot dispari per tutte le sue operazioni (basti vedere quali slot sono assegnati a refresh, disco, audio e sprite), lasciando quelli pari quasi sempre liberi. Il risultato è che la CPU “vede” spesso come libero l’accesso alla memoria, operando a piena velocità.
Ovviamente tutto ciò non vale più quando lo schermo ha bisogno di richiedere più dati di quelli normalmente a disposizione con gli slot dispari, oppure se Copper e/o Blitter devono svolgere delle operazioni. Il Copper, in particolare, ha sempre priorità sulla CPU (e sul Blitter) e può rubarle slot quando vuole. Più precisamente, quando ne ha bisogno sfrutta tutti gli slot contigui disponibili in quel momento, siano essi pari o dispari.
Il Blitter è più magnanimo, in quanto normalmente ogni 3 slot pari ne può lasciare uno utilizzabile dalla CPU, se questa ne avesse bisogno. Abilitando, però, un flag chiamato blitter nasty (o DMAF_BLITHOG, il cui nome è tutto un programma), questa politica viene meno, e sarà quindi in grado di consumare qualunque slot, lasciando completamente bloccata la CPU. Questo perché il Blitter è più efficiente per le operazioni per cui è stato concepito, quindi ha senso dargli la possibilità di lavorare sfruttando tutta la banda possibile a disposizione.
Per il momento è tutto. Come accennato prima, nel prossimo articolo dedicato all’Amiga parlerò dei limiti del chipset (e di quello che sarebbe potuto essere con qualche accorgimento).
