di  -  mercoledì 30 giugno 2010

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).

22 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    sandro
     scrive: 

    lo sapevo che con qualche piccolo accorgimento,il tutto sarebbe pouto esser ANCOR MIGLIOR:

    – clock a 8 o piu’ MHZ
    – registri interni dei chip a 32bit come il 68000
    – 16k-32k di fast ram per il solo 68000

    ciao
    Sandro

  • # 2
    Cesare Di Mauro (Autore del post)
     scrive: 

    Quello è normale: alzare i numeri è la soluzione più comoda e veloce, ma bisogna sempre contestualizzare (vedere i limiti della tecnologia dell’epoca).

    Ci sono, più che altro, degli accorgimenti interni su cui soffermerò nel prossimo articolo in cui parlerò dell’Amiga (e che è l’ideale continuazione di questo).

  • # 3
    TheKaneB
     scrive: 

    ottimo lavoro, as usual, @Cesare ;)

  • # 4
    sandro
     scrive: 

    ad esempio si poteva inserire della chip-ram dedicata a quei dispositivi che erano un po’ piu’ “statici” nel loro utilizzo…tipo
    il Copper.se gli fossero stati assegnati un 8k-32k solo per “lui”,si sarebbe potuto liberare qualche ciclo di clock per il blitter e compagnia..

  • # 5
    Cesare Di Mauro (Autore del post)
     scrive: 

    Bisogna fare i conti coi transistor utilizzati / utilizzabili, e la convenienza nell’utilizzarli.

    Tanto per rendere l’idea, al posto di integrare anche soli 8KB di cache (che sono una quantità enorme per l’epoca), si sarebbe potuto creare un Blitter in grado di realizzare molte più operazioni o, meglio ancora, in grado di gestire più bitplane contemporaneamente. ;)

  • # 6
    sandro
     scrive: 

    anche in questo caso,avresti aumentato il numero di transistor..
    non dico di usare 8k di cache interna,anche della semplice chip-ram,indirizzabile solo dal Copper e dal 68k per settare i dati,avrebbe funzionato alla grande..

  • # 7
    Cesare Di Mauro (Autore del post)
     scrive: 

    Meglio una piccola cache allora, solo per il Copper. Anche se io avrei preferito usarla per il Blitter (per eseguire il cache delle “maschere”, che sono caricate più volte quando si lavora coi BOB: una per ogni bitplane utilizzato).

  • # 8
    sandro
     scrive: 

    io esagero,una piccola cache per ogni chip..penso che anche solo pochi byte avrebbero fatto la differenza.tipo 32-64 byte.

  • # 9
    Cesare Di Mauro (Autore del post)
     scrive: 

    Per il Blitter sarebbe bastata, ma per oggetti troppo piccoli. Supponiamo di avere 32 byte, che corrispondo a 16 word a 16 bit. Avremmo potuto cachare maschere per oggetti delle seguenti dimensioni: 16×16, 32×8, 64×4. Davvero scarse come possibilità.

    Per la copper list, invece, sarebbe stata praticamente inutilizzabile, visto che sono decisamente più lunghe (le istruzioni sono sempre a 32 bit, quindi 4 byte alla volta).

  • # 10
    Massimo M
     scrive: 

    Sempre molto interessanti.
    MI piacerebbe salvarli tutti questi articoli, ma l’unica cosa che posso fare è … stamparli uno per uno in PDF …
    Puoi fare qualcosa? Alla fine (? spero mai) riunirli tutti?

  • # 11
    Cesare Di Mauro (Autore del post)
     scrive: 

    Vorresti un Appunti Digitali in stile Ars Technica, insomma. :D

    Giro l’interessante proposta ai commerciali. Grazie per il consiglio! :)

  • # 12
    Cesare Di Mauro (Autore del post)
     scrive: 

    Mi hanno suggerito l’uso di questo: http://html-pdf-converter.com/ strumento. Non dovrebbe bastare per le tue esigenze, o magari ho capito male io? :-P

  • # 13
    sandro
     scrive: 

    allora per il Blitter sarebbe stato utili la possibilita’ di usare un canale sorgente anche come maschera,indicando se usare i bit a 0 o 1
    in questo modo per far i BLOB avresti usato solo 3 canali,un bel risparmi e a costo quasi “0”.

  • # 14
    Cesare Di Mauro (Autore del post)
     scrive: 

    Non sarebbe stato possibile, se non con grafica strettamente monocromatica (un solo bitplane).

    La “maschera” generalmente veniva generata a parte, eseguendo l’or di tutti i bitplane che componevano i BOB.

  • # 15
    Nessuno
     scrive: 

    8Mhz, 3 cicli, 16byte alla volta, cicli pari vs quelli dispari… mi viene da ridere a pensare cosa facesse quell’HW con quei numeri in contrapposizione con quelli che abbiamo oggi… 3GHz, 2GB RAM dual channel (128 bit) a 1600Mhz, schede grafiche dedicate con numeri ancora più grandi… e poi quando inserisci un CD nel lettore si blocca tutto fino a quando il rottame non ha capito cosa ci deve fare con il pezzo di plastica traslucido che abbiamo inserito.
    E se non abilitate l’accelerazione della scheda grafica (ormai di default) tramite il driver apposito, neanche il puntatore del mouse si muove in maniera fluida.

    Bah… progresso tecnologico lo chiamano.

  • # 16
    sandro
     scrive: 

    ma si che era possible.invece di far d = a+b,potevi far d = a (and or) b.e per b indicai se bucare con il bit 0 o 1.e poi ripetevi con le altre bittate.

  • # 17
    sandro
     scrive: 

    ciao Nessuno

    ai ragione,Amiga funzionava alla grande,col casso che si bloccava il mouse..prova con Windoz ad accedere al vecchio e vetusto Driver..
    UHAHAHHA

  • # 18
    Cesare Di Mauro (Autore del post)
     scrive: 

    Con soli due canali / bitplane (più quello di output) non potevi applicare il “cookie cut” per incollare i BOB nella grafica dello schermo.

    Prova a pensarci un attimo. ;)

  • # 19
    sandro
     scrive: 

    ma si che puoi..

    se in A fai entrare lo schermo di Destinazione,in B il BOB da usare,e gli dici far passare i Bit di “A” dove “B” e’ a 1 o 0,sei a posto..

  • # 20
    sandro
     scrive: 

    ripensando bene al funzionamento del blitter,si ai bisogno di 3 canali,ho commesso un errore io..infatti con una cache per la mashera,il blitter avrebbe aumentato di non poco la sua velocita’…
    poi con i registri interni a 32bit ancor meglio..

  • # 21
    Cesare Di Mauro (Autore del post)
     scrive: 

    Ero sicuro che ci saresti arrivato. :)

    Delle altre cose ne parliamo nel prossimo articolo sull’argomento. :P

  • # 22
    sandro
     scrive: 

    dopo anni di “pc”,qualcosa si dimentica.sai un gioco davvero INCREDIBILE per Amiga fu’ Elfamania.in alcuni frangenti era come ,se non superiore a Street Fight 2 per coin-op.i programmatori usarano tanti e tali trucchi,che sono stati davvero FURBI E BRAVI!

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.