di  -  mercoledì 14 luglio 2010

Col precedente articolo il funzionamento delle varie componenti dell’Amiga dovrebbe essere sufficientemente chiaro, ma ho volutamente lasciato fuori dalla disquisizione la generazione della grafica dello schermo, che meritava una trattazione a parte.

Fondamentale rimane ancora la pagina dell’Amiga Hardware Manual che ho riportato nell’articolo (e della quale fornisco il link), che mostra la precisa suddivisione di una riga di raster fra le varie parti del sistema, ma in questo caso c’interessa capire cosa avviene quando dev’essere visualizzata una linea dello schermo all’interno della riga di raster corrente.

Dei 227 color clock, fino a 160 slot sono riservati per la grafica dello schermo, che a questo punto è evidente che faccia la parte del leone (o dell’ingordo, a seconda dei punti di vista; quest’ultimo è quello dei programmatori, ovviamente), fatta eccezione per i bordi dove non viene visualizzata grafica e, quindi, non vengono caricati dati dalla memoria.

I 160 slot sono soltanto teorici, in quanto bisogna sempre fare i conti con due importantissimi parametri: la risoluzione (alta o bassa) e il numero di bitplane. Il caso peggiore, per OCS ed ECS , è rappresentato da uno schermo in alta risoluzione a 16 colori.

In questa modalità il numero di pixel per riga è pari a 640, che equivalgono a 640 / 16 = 40 word (ricordo che una word equivale a 16 bit, e quindi 16 pixel di un bitplane). Poiché 16 colori richiedono 4 bitplane, arriviamo subito al sodo: servono 160 slot per caricare tutte le 40 word per ogni singolo bitplane dello schermo, che equivalgono alla totalità di quelli a disposizione.

Normalmente i dati dello schermo cominciano a essere letti a partire dallo slot 56 ($38 in esadecimale), per proseguire fino ad arrivare allo slot 216 ($D8) escluso. Durante questo periodo il bus dati della chip ram viene impiegato esclusivamente dalla logica di visualizzazione dello schermo per prelevare i dati dei bitplane, tagliando completamente fuori CPU, Copper e Blitter, che potranno contendersi un po’ di accessi esclusivamente durante gli intervalli di horizontal e vertical retrace.

La cosa che salta immediatamente all’occhio è la sequenza con la quale vengono caricati i bitplane: prima il 4, poi il 2, il 3 e infine l’1. Apparentemente questa politica di assegnazione / priorità sembra inutile e confusionaria; dopo tutto i bitplane devono comunque essere caricati tutti e 4, e non ha importanza l’ordine col quale ciò viene fatto.

Se questo è vero per uno schermo (in alta risoluzione) a 4 bitplane, non lo è più con un numero inferiore, e si comincia a comprenderne il motivo. Con 3 bitplane e partendo sempre dallo slot 56 ($38), vediamo che lo slot 56 è libero, il 57 è impiegato per leggere la word del bitplane 2, il 58 per quella del bitplane 3, e infine il 59 per la word del bitplane 1; e così via ripartendo dallo slot 60.

Anche questa, data la disposizione degli accessi dei bitplane, sembra una soluzione bislacca, ma notiamo già che lo slot 56, prima occupato dall’accesso alla word del bitplane 4, adesso risulta libero; inoltre, essendo pari, è utilizzabile dalla CPU (come già detto nell’altro articolo, il 68000 è una CPU che impiega sempre gli slot pari per accedere eventualmente alla memoria, e quelli dispari per le elaborazioni interne).

Quindi con 3 bitplane il processore ha la possibilità di sfruttare ben 40 accessi alla memoria, e dunque non risulta più tagliato del tutto fuori. Lo sarà se e solo se il Copper sfrutterà sistematicamente tutti questi slot liberi per leggere le sue istruzioni, oppure se il Blitter funzionerà in modalità “nasty / hog“, riservandoli per sé e non cedendone nessuno al microprocessore.

Con 2 bitplane avremo gli slot 56 e 58 liberi, ed essendo entrambi pari sarebbero potenzialmente sfruttabili tutti e due dalla CPU. Con un solo 1 bitplane anche lo slot 57 sarà libero, ma in quanto dispari non utilizzabile dalla CPU per quanto già detto, mentre sarà a completa disposizione di Copper o Blitter.

Adesso è chiaro che quella che sembrava inizialmente una stramberia, in realtà è un intelligente sistema nato per ottimizzare al massimo lo sfruttamento degli accessi alla memoria da parte delle periferiche. Per rendercene conto basta riflettere sullo scenario che verrebbe fuori dando accesso in sequenza dei bitplane a partire dal primo: anche con un solo bitplane lo slot 56 risulterebbe sempre impegnato per leggere la word del bitplane 1, e alla CPU verrebbe a mancare la possibilità di sfruttare questo prezioso slot.

Con la bassa risoluzione lo scenario è analogo a quello dell’alta, ma questa volta il fetch dei bitplane è spalmato su 8 slot consecutivi, opportunamente schedulati in base al numero di bitplane da visualizzare, che varia da 1 a 6 (quest’ultimo solo con le modalità EHB a 64 colori, HAM a 4096, oppure il Dual Playfield con 2 schemi a 8 colori ciascuno, di cui ho parlato nell’articolo sull’OCS).

Nel caso peggiore, con 6 bitplane avremo gli slot 56 e 60 liberi (ed essendo pari, sfruttabili dal processore), mentre 57, 58, 59, 61, 62 e 63 assegnati rispettivamente ai bitplane 4, 6, 2, 3, 5 e 1. Rispetto all’alta risoluzione con 4 bitplane, dove non c’era nessuno slot a disposizione, qui ogni 8 ce ne sono 2, per cui il 25% degli accessi (2 su 8) è disponibile per CPU, Copper o Blitter. Risultato identico a uno schermo in alta risoluzione a 3 bitplane (1 slot libero ogni 4).

Scendendo a 5 bitplane (32 colori), gli slot 56, 58 e 60 saranno liberi (e tutti pari, quindi utilizzabili dalla CPU), e tutti gli altri assegnati ai bitplane 4, 2, 3, 5 e 1. Pertanto il 37,5% sarà sfruttabile dalla triade precedentemente menzionata. Rispetto allo schermo con 6 bitplane siamo passati da 2 a 3 slot liberi, quindi con un bell’aumento pari al 50%.

Questi numeri fanno capire perché generalmente i giochi per Amiga erano a 32 colori (al netto degli effetti del Copper) anziché a 64: la banda a disposizione era notevolmente superiore, e quindi si poteva muovere più grafica. Questo senza considerare altri vantaggi: con un bitplane in meno si risparmia sia sullo spazio in memoria (preziosissima all’epoca, specialmente la chip ram, dove stava generalmente la grafica), sia sulla banda per trasferire i dati (si copiano / manipolano 5 bitplane anziché 6).

Nel prossimo articolo dedicato all’Amiga parleremo finalmente dei limiti del chipset (purtroppo la trattazione delle righe di raster e dei color clock ha richiesto più del dovuto, ma era necessario approfondire per capire meglio l’argomento).

29 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
    Gurzo2007
     scrive: 

    ottimo articolo come sempre ;)

  • # 2
    TheKaneB
     scrive: 

    O_O” dopo aver letto questo, non mi lamenterò mai più dell’architettura del Nintendo DS, giuro…
    Qui siamo su livelli di customizzazione estrema dell’hardware, che vanno ad impattare in modo pesantissimo sulle possibilità della CPU. Perlomeno sulle CPU ARM del Nintendo DS c’è la TCM che ti consente di non risentire “troppo” degli stalli del bus durante le operazioni di DMA…

    Comunque bell’articolo, anche se un po’ troppo sintetico forse rispetto al precedente… ma forse è meglio sdoppiare l’argomento in due, e trattarlo bene, che “allungare il sugo” e fare un unico articolo confuso…

    ;-)

  • # 3
    sandro
     scrive: 

    bell’articolo come al solito..

    ripeto che gia’ con un po’ di fast-ram tipo 16k per il 68k,avrebbe liberato ancora un po’ di slot per blitter e copper..

    ciao
    SANDRO

  • # 4
    Darkman^RJ
     scrive: 

    Bei tempi quando facevo glenz vectors 48 faces a 50fps :D

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

    @sandro: 16KB sono troppo pochi per contenere tutto il codice e i dati (compreso lo stack) necessari.

    Inoltre mettere vera fast ram (anziché la classica slom mem) non sarebbe stato economico e pratico da aggiungere.

    @TheKaneB: quest’articolo è più sintetico perché è la continuazione del precedente, dove avevo esposto già tutti i concetti. Se ci fai caso, dopo una breve introduzione sono partito in quarta senza perdere tempo a spiegare roba come color clock, slot, righe di raster, ecc.

    Però se consideri lo spazio che ho dedicato ai bitplane dello schermo, è di gran lunga di più degli altri argomenti, perché l’argomento era complesso e necessitava di essere approfondito (sarà pure molto utile per il prossimo articolo sul tema Amiga).

    E, tanto per cambiare, mi ha richiesto non poco tempo. Se avessi dovuto includerlo nel precedente, sicuramente non sarei arrivato all’appuntamento. :|

    Tornando al topic, è vero che l’hardware dell’Amiga era customizzato, ma è anche vero che molti lo programmavano senza nemmeno conoscere informazioni come queste. Si mettevano a scrivere qualche pezzo di codice, magari copiato da altri o da qualche rivista, e al più utilizzavano le “copper bar” per “misurare” il tempo di blitting. -_-

  • # 6
    sandro
     scrive: 

    lo so che 16k sembrano pochi,ma pensa a quanto avrebbe aiutato..ok 32 era meglio..poi pensa anche a soli 4k di chip mem indirizzati solo dal copper,ci mettevi circa 1024 istruzioni,e avresti ulteriormente liberato la banda per il blitter.be’ non sarebbe stato male..:)

    pensate a quello che hanno fatto con Elfmania,era da paura graficamente….anche se si poteva ancor far di’ piu’..mi ricordo che una volta mi misi a rifare MK2 per Amiga500.pur non essendo un grafico,rielaborai la grafica,e utilizzai sia copper-list dinamiche,che il cross color tra 2 immagini,ed ottenni il doppio dei colori,al costo di un po’ di flicckering,ma ragazzi che definizione!!
    per i giochi che andavano a 50hz era un’ottima tecnica per aumentare il numero dei colori su schermo,e se usata bene,lo sfarfallio era minimo

  • # 7
    Z80Fan
     scrive: 

    Wow, questa sì che è progettazione seria! Altro che IBM x86…
    Ora capisco perchè i programmatori la amano e si arrabbiano così tanto contro i manager che la hanno fatta fallire >:(

    Due domande per Cesare:
    – l’Amiga Hardware Manual è ancora sotto copyright, o si può scaricare regolarmente da Internet? Proverò anche a vedere su e-bay.
    – Nelle prossime puntate prevedi di mostrare anche qualche pezzetto di codice per la programmazione di vari dispositivi?

  • # 8
    TheKaneB
     scrive: 

    @Cesare: si, avevo inteso il senso dell’articolo, e in effetti va bene così, anche perchè gli argomenti sono molto astrusi e vanno trattati con calma :-)

    @Z80Fan: ho visto il tuo progetto di OS sul forum di hwupgrade. Mi consola sapere di non essere l’unico folle ad aver tentato una cosa del genere :-D Purtroppo il mio progetto l’ho abbandonato 2-3 anni fa per questioni di lavoro, ma non mi dispiacerebbe riprenderlo. Però il mio non è un clone di Unix, si basa su un concetto diverso, di OS distribuito per sistemi cluster. Comunque chiudo qui, l’OT… magari ne riparliamo in pvt qualche volta :-)

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

    @sandro: piuttosto che la fast ram, avrei preferito più chipram.

    Per il Copper, 4KB dedicati equivalgono a una cache integrata, che all’epoca era molto costosa. Considera che soltanto col 68040, commercializzato nel 1990, abbiamo visto cache così grandi, e questo mostro aveva qualcosa come 1 milione di transistor (ovviamente non tutti dedicati agli 8KB di cache integrata).

    Inoltre una cache avrebbe presentato problemi di coerenza con la memoria (e, quindi, sarebbe stato necessario integrare logica di bus snooping, intercettando le operazioni di scrittura).

    Se invece di una cache pensavi a una memoria normale, avrebbe dovuto essere mappata da qualche parte, ma avrebbe presentato dei limiti dovuti al fatto che questa memoria sarebbe dovuta essere caricata ogni volta che si cambiava il contenuto (ad esempio usando più copperlist per generare effetti complessi).

    Elfmania me lo ricordo, ma se presti attenzione ai movimenti dei personaggi, ti accorgi che non sono il massimo. Avranno usato qualche trucchetto con gli sprite o le BLOB mask, ma non mi pare granché il risultato.

    @Z80Fan: l’hardware manual è ancora sotto copyright e viene regolarmente venduto (su Amazon lo trovi, anche usato). Poi si trova anche in giro, ma io alla fine degli anni ’80 mi feci spedire dai mie parenti americani tutta la serie “ROM Kernel”, e ne sono soddisfattissimo.

    Finito l’argomento hardware, passerò agli scenari d’uso presentando qualche esempio, eventualmente con del codice allegato (ma non molto).

    Ma questo raccontando in che modo ho realizzato i due giochi a cui ho lavorato, le difficoltà che ho incontrato, e in che modo sono riuscito a risolvere certi problemi.

  • # 10
    sandro
     scrive: 

    qui fo’ un po’ lo sborone:io ho L’hardware Manul in Italiano!!mado’ me lo conservo come un cimelio!!
    me lo ricordo Elfmania,le anim non erano un gran che,ma che tecnica!!
    allora i primi 16 colori erano usati per il fondale,se non ricordo male copperizzato,e gli ultimi 16 per i Bob.inoltre ricordiamo che aveva delle blittate sincronizzate.se ti ricordi bene,il fondale era animato,ma quando le anim degli sprite occupavano troppi blocchi,bloccavano le anim.e non dimentichiamo gli sprite HW usati per fare i vari parallasi su schermo!!!un tributo di effetti video!

  • # 11
    Z80Fan
     scrive: 

    @Cesare
    Ok, grazie dell’info :)

    [OT]
    @TheKaneB
    Wow un’altro avventuriero :D Quando hai voglia di fare una chiacchierata, contattami pure!
    [/OT]

  • # 12
    D
     scrive: 

    @Cesare

    Quando lo scrivi un libro sulla programmazione di amiga ? E non mi dire che la documentazione in giro basta e avanza. Spesso la differenza la fanno gli esempi che vengono proposti insieme.

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

    E se invece scrivessi una serie di articoli qui su Appunti Digitali, su come si programmava l’Amiga (con qualche esempio)? O:-)

  • # 14
    sandro
     scrive: 

    ciao Mauro

    bella idea la tua!!se serve una mano io ci sto’!oddio e’ un bel po’ che nn programmo l’Amiga,mi ci rimetteri volentirei!purtroppo non ho il nostro amato comp fisicamente,ho il WinUaE,qualcuno ci programma con questo emulatore?potreste aiutarmi??

    e-mail s dot sabene at gmail dot com
    skype pestilenziale

    ciao
    Sandro

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

    WinUAE lo uso per giocare ogni tanto, ma quando mi serve posso anche svilupparci, visto che utilizzo l’immagine dell’HD che utilizzavo col mio fido 1200. :P

    Comunque configurarlo è molto semplice. Alla fine, è pur sempre un’Amiga. :D Se hai difficoltà fammi sapere.

    P.S. Mi chiamo Cesare, non Mauro!

    P.P.S. Mi sono permesso di editare la tua mail in modo da renderla più resistente agli spider degli spammer.

  • # 16
    Nicola
     scrive: 

    se fai articoli su programmazione Amiga lascio il browser fisso su AD XDD. Sono troppo giovane per aver avuto l’opportunità di metterci mani, ma seguo la tua rubrica da sempre e sarebbe grandiosa, oltre che utilissima, una cosa del genere ^_^

  • # 17
    sandro
     scrive: 

    Ciao Cesare

    grazie per il ragguaglio,e non ti preoccupare per la mail.
    senti io non ho’ piu’ un programma per Amiga,non e’ che potresti
    passarmi il devpac,deluxe paint,e qualche esempio per rinfrescarmi la memoria??

    ciao
    Sandro

  • # 18
    TheKaneB
     scrive: 

    @sandro: iscriviti su amiganews.it e ti aiuteremo volentieri. Magari evitiamo di andare troppo off-topic qui :-)

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

    Sì, è meglio. Poi la comunità Amiga è ancora viva e vegeta. ;)

    @Nicola: sì, ho intenzione di mostrare come si programmava l’Amiga, ma non ti aspettare di vedere listatoni di assembly 68000.

    Qualche pezzo di codice, se lo riterrò opportuno, lo mostrerò, ma l’argomento verterà sulla spiegazione di come funzionavano i chip custom, e come andavano programmati per ottenere l’effetto desiderato.

  • # 20
    D
     scrive: 

    “E se invece scrivessi una serie di articoli qui su Appunti Digitali, su come si programmava l’Amiga (con qualche esempio)? O:-)”

    Puoi fare molto di più :)

    Se non ricordo male avevi fatto un gioco di corse per Amiga. Non puoi pubblicare e commentare i sorgenti ? Spesso e volentieri gli esempi pratici sono i migliori.

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

    Sì, ho realizzato un gioco di corse (USA Racing, ma non l’ho completato) e partecipato alla realizzazione di un picchiaduro (Fightin’ Spirit, commercializzato un anno dopo che uscii dalla software house), ma hai idea di quanto siano lunghi quei sorgenti? :D

    Comunque no, pubblicare interamente i sorgenti non se ne parla. Degli spezzoni sì, se è il caso e sono corti.

    Ciò non toglie che parlerò di quei due giochi, dei problemi che abbiamo avuto nel realizzarli, e dei trucchetti che ho tirato fuori dal cappello per muovere tutta quella roba. ;)

  • # 22
    sandro
     scrive: 

    ciao Cesare

    mi piacerebbe parlare della tecnica del color crossing per aumentare i colori su schermo con L’Amiga,potrebbe esser un articolo interessante?magari potrei scriver l’articolo.

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

    Per me va bene. Scrivi il pezzo quando vuoi e mandalo all’indirizzo che trovi qui sotto (poco sopra il pulsante Commenta!). Verrà valutata dallo staff e ti faremo sapere (in tempi brevissimi, non ti preoccupare). :)

  • # 24
    TheKaneB
     scrive: 

    @Cesare: nel caso di Amiga, possiamo leggere molti articoli tecnici che sono ben documentati in vecchi manuali, che tutti possono (potevano) comprare e leggere. Nel caso di moderne console, dove il kit di sviluppo viene ceduto soltanto dietro sottoscrizione di NDA, sarebbe perseguibile per legge la pubblicazione di articoli tecnici (come i tuoi) per lo sviluppo a basso livello?

    Faccio questo esempio perchè spesso mi è venuta la voglia di divulgare delle tecniche che ho sperimentato in alcuni giochi per Nintendo DS, ma temo possibili conseguenze… ci sarebbe anche la strada della comunità homebrew, ma anche se la community ha pubblicato le specifiche tecniche del DS (in modo estremamente fedele e dettagliato, quasi al livello dei docs ufficiali che ho avuto modo di studiare), la posizione di Nintendo nei confronti della community è sempre stata poco chiara se non decisamente avversa…

    Sarebbe saggio secondo te scrivere qualche articoletto in merito (ho un blog tecnico piccolino ma affine al vostro), o meglio lasciar perdere e tenere per me “i trucchetti del mestiere”?

    Ovviamente non ti sto chiedendo una consulenza legale :D solo un’opinione, così giusto per chiacchierare…

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

    A mio avviso se hai utilizzato esclusivamente informazioni che si trovano in giro, non dovresti avere alcun problema a scrivere codice, articoli, e quant’altro basati su di esse.

    Ma non sono un legale, e mi fermo anch’io qui. :P

  • # 26
    TheKaneB
     scrive: 

    sono 2 le cose: o mi informo meglio, tramite un legale o qualcuno molto esperto in materia, oppure lascio perdere e chi s’è visto s’è visto!
    D’altronde non me l’ha ordinato il dottore di scrivere per forza di questi argomenti… :D

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

    M’informo anch’io e ti faccio sapere.

  • # 28
    TheKaneB
     scrive: 

    @Cesare: ok grazie, se trovo qualche info prima di te la posterò qui se vuoi (ma prometto di chiudere l’OT subito dopo :D )
    ciao!

  • # 29
    sandro
     scrive: 

    ok Cesare

    mi serve solo un po’ di tempo per preparare l’articolo e passarvelo

    ciao
    Sandro

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.