di  -  mercoledì 24 marzo 2010

Conosciuto internamente col nome in codice “Pandora“, doveva chiamarsi AA (Advanced Architecture), ma alla fine Commodore optò per aggiungere il termine “Graphics”, che in effetti denota perfettamente l’area in cui sono stati apportati i cambiamenti: esclusivamente sul fronte della grafica, e più precisamente sulla sua visualizzazione (schermo e sprite).

Al posto di Agnus (uno dei chip custom dell’Amiga) troviamo adesso Alice a gestire i 27 (prima erano 25) canali DMA e a regolare, quindi, l’accesso alla memoria, che non avviene più esclusivamente a 16 bit, ma finalmente è possibile eseguire la lettura (o scrittura) dei dati a 32 bit, e addirittura a 64 bit. In realtà in quest’ultimo caso è possibile leggere due dati a 32 bit durante lo stesso accesso, ma gli indirizzi devono comunque essere allineati a 64 bit (8 byte) per poter sfruttare questa modalità.

Questo cambiamento è a dir poco fondamentale per rilanciare le capacità grafiche degli Amiga, rimaste al palo sostanzialmente dall’introduzione di queste meravigliose macchine, con la casa madre che è stata impegnata più a incassare soldi cullandosi del successo, che a consolidare il vantaggio pensando ad aggiornare adeguatamente il chipset.

Due sono i limiti più grossi evidenziati già nel precedente articolo sull’ECS: la risoluzione e il numero dei colori. Su entrambi, in particolare sul primo, pesa molto la banda verso la memoria a disposizione per prelevare i dati.

Questo perché, se è vero che è stata introdotta la programmabilità del segnale video superando il limite dell’alta risoluzione (640×200 per l’NTSC e 640×256 per il segnale PAL, e valori raddoppiati verticalmente sfruttando l’interlacciamento), con l’ECS ciò ha comportato una notevole riduzione del numero di colori visualizzabili, scesi a soltanto 4 per le nuove modalità (Super-Hires: 1280×256, VGA: 640×480@72Hz, e SVGA: 800×600@60Hz interlacciati).

Il motivo è presto detto: poiché la banda verso la memoria rimaneva sempre la stessa, all’aumentare della risoluzione e/o della velocità di refresh si era resa necessaria una proporzionale riduzione del numero di bitplane. Il limite precedente era rappresentato da 6 bitplane (perché la palette era di soli 32 colori, e 64 massimo con la modalità EHB, l’Extra Half-Brite; senza tener conto dell’HAM) in bassa risoluzione (320×200 NTSC, 320×256 PAL), oppure 4 bitplane in alta.

Per sottolineare l’importanza della banda e dell’enorme collo di bottiglia che rappresentava, aggiungo che mentre uno schermo in bassa risoluzione a 6 bitplane lasciava circa il 25% dei cicli di clock liberi per Copper e Blitter, e il 50% per la CPU (in futuro capiremo il perché di questi numeri, quando analizzeremo il preciso funzionamento interno dell’Amiga), uno in alta risoluzione a 4 bitplane non ne lasciava nessuno e questi dispositivi rimanevano completamente tagliati fuori dall’accesso alla memoria video (in pratica restavano “congelati” in attesa) per tutto il tempo relativo al tracciamento della grafica della riga di raster correntemente visualizzata.

In questo modo potevano lavorare sfruttando la memoria (risorsa indispensabile per i primi due, e molto importante per la terza) esclusivamente durante il breve periodo di horizontal retrace o il più lungo vertical retrace (si tratta degli intervalli di tempo in cui il pennello elettronico si spostava rispettivamente sulla successiva linea orizzontale, oppure tornava in alto per cominciare a disegnare il successivo fotogramma).

Si tratta di poca roba, purtroppo, perché il grosso del tempo a disposizione era quello che riguardava il disegno della grafica degli schermi. Questo era il motivo per cui molti giochi per Amiga sfruttavano la bassa risoluzione a 32 colori (che lasciava il 37% dei cicli di clock liberi per Copper e Blitter, e il 75% per la CPU), una parte consistente la modalità Dual Playfield (DP: due schermi scrollabili indipendenti, ognuno di 3 bitplane), e pochissimi l’EHB a 64 colori, limitando l’uso dell’alta risoluzione all’eventuale presentazione di immagini statiche.

L’introduzione dell’accesso a 32 e “64” bit con l’AGA innalza notevolmente questi limiti, lasciando moltissima banda a disposizione nelle basse risoluzioni, una discreta banda per l’alta risoluzione, ma divenendo il collo di bottiglia della Super-Hires e in generale degli schermi a risoluzioni più elevata introdotti dall’ECS.

Una buona situazione di cui approfitta Lisa, il nuovo chip che va a sostituire Denise (altro chip custom), che consente di estendere a qualunque risoluzione le modalità di visualizzazione prima disponibili esclusivamente per quella bassa. Adesso è, infatti, possibile visualizzare schermi a 32 colori, in EHB, HAM, o DP anche in alta risoluzione, Super-Hires, VGA o SVGA.

Non solo: dopo anni e anni di attesa, la palette viene estesa e arrivano finalmente gli schermi a 256 colori, questa volta non più limitati a una gamma cromatica di 4096 (16 gradazioni per ogni colore fondamentale), ma… di ben 16 milioni (256 gradazioni per colore fondamentale)! Allineando, quindi, l’Amiga a quanto aveva già offerto da tempo la concorrenza rappresentata principalmente da PC e Mac.

Al contempo si aggiunge una nuova modalità HAM, chiamata HAM-8 e dal cui nome si capisce che per lavorare impiega 8 bitplane (in precedenza soltanto 6), ma la cui meccanica è sostanzialmente identica, tranne per il fatto che questa volta la palette di base a disposizione è di 64 colori (prima erano 16), mentre è possibile cambiare i 6 bit alti di rosso, verde, oppure blu (prima erano i 4 bit “alti”, cioè gli unici).

HAM-8 consente, pertanto, di visualizzare immagini a 16 milioni di colori (in realtà molti meno, vuoi per il fatto che 16 milioni di colori diversi necessiterebbero di schermi da 4096×4096 pixel, ad esempio, per essere visualizzati; vuoi perché non c’è piena libertà di scelta dei colori) con un’ottima approssimazione, ma richiedendo soltanto 1/3 dello spazio rispetto a uno schermo a 24 bit.

Anche il DP ottiene una “promozione”, e adesso i due schermi indipendenti possono visualizzare fino a 16 colori ciascuno (4 bitplane), selezionabili da opportune porzioni della palette di 256. Di ciò ne hanno beneficiato molti giochi che facevano uso di questa modalità (fra i quali penso che molti ricorderanno Brian the Lion per il notevole impatto visivo), che permetteva all’Amiga di tornare competitivo con le console dell’epoca, SuperNintendo e Genesis in primis.

Per tutte le risoluzioni e modalità è possibile specificare uno scrolling orizzontale estremamente fine, che arriva a 1/2 o 1/4 di pixel. Tradotto in altri termini, mentre in precedenza uno schermo in bassa risoluzione poteva scrollare soltanto di valori interi di pixel, adesso lo scrolling più avvenire anche di mezzo o un quarto di pixel. Prima in alta risoluzione si poteva scrollare soltanto di due pixel alla volta, mentre adesso è possibile scrollare di un pixel, o di mezzo pixel. Infine con la Super-Hires si poteva scrollare soltanto di 4 pixel alla volta, mentre adesso di 2 oppure di uno singolo.

Ultimo componente a ricevere beneficio dalla raddoppiata e quadruplicata banda passante verso la memoria sono gli sprite, prima limitati a 16 pixel di ampiezza e visualizzati in bassa risoluzione anche se lo schermo sottostante era in alta o in Super-Hires. Adesso arrivano a 32 o 64 pixel di ampiezza a seconda del corrispondente tipo di accesso alla memoria selezionato, e inoltre possono essere visualizzati in alta risoluzione o Super-Hires a prescindere dalla definizione dello schermo visualizzato. Inoltre si può scegliere la parte della palette che dovranno utilizzare.

Si presenta, però, un grosso problema quando è abilitato lo scrolling orizzontale dello schermo e al contempo per questo viene fatto uso dell’accesso a 32 o 64 bit alla memoria. Nel primo caso (32 bit per i dati dello schermo), rimangono a disposizione soltanto 5 sprite a 4 colori (oppure 2 a 16 colori e uno a 4), mentre nel secondo (64 bit per i dati dello schermo) soltanto uno a 4 colori. Questo perché la logica di prefetch dei dati dello schermo ha bisogno di “rubare” la banda di memoria del DMA degli sprite per poter visualizzare poi correttamente i dati quando servono.

Questo è sicuramente un grosso limite, se pensiamo che lo scrolling orizzontale era presente e usato nella stragrande maggioranza dei giochi, come pure i comodissimi sprite a 16 colori da 16 pixel (se ne potevano usare 3, e ne rimaneva uno a 4 colori). Una soluzione poteva essere rappresentata dalla rinuncia agli accessi a 32 e 64 bit soltanto per gli schermi, sfruttandoli soltanto per gli sprite, e potendo a questo punto usarne 3 a 16 colori, ma da ben 64 pixel orizzontali ciascuno (e uno a 4 colori sempre da 64 pixel), oppure 7 a 4 colori da 64 pixel.

Soluzione discreta, ma non eccelsa, in quanto tagliava fuori buona parte dei BLOB (gli “sprite” realizzati, però, usando il Blitter), costringendo a ridurre il numero di colori a schermo per cercare di lasciare un po’ di banda a disposizione per Copper, Blitter e CPU.

Con gli AGA, però, i 256 colori finalmente a disposizione facevano particolarmente gola, per cui tante volte si preferiva rinunciare agli sprite per ottenere un risultato visivo decisamente più appagante alla vista, delegando al Blitter la realizzazione di personaggi e animazioni varie, grazie anche alla maggior banda di memoria disponibile adesso coi nuovi accessi.

Infine, l’arrivo dei monitor multisync a 31 o più Khz rende possibile l’uso di risoluzioni più elevate a quelle dei canonici monitor e televisori CRT ai tempi a disposizione, per cui Commodore aggiunge anche la possibilità di utilizzare, ove la banda di memoria l’avesse permesso, il cosiddetto “scan doubling” sia degli schermi che, eventualmente, degli sprite, e la relativa eliminazione del famigerato interlacciamento che tanto fastidio dava alle retini degli occhi (costringendo a utilizzarlo il meno possibile).

Per concludere veniamo alla note dolenti. Come dicevo all’inizio, le modifiche apportate hanno riguardato esclusivamente gli schermi e gli sprite: tutto il resto dell’hardware dell’Amiga è rimasto esattamente come prima. I floppy sono rimasti da 880KB, e quelli nuovi da 1,76MB richiedevano una velocità di lettura o scrittura dimezzata. I canali audio erano sempre 4 a 8 bit e massimo 28Khz. Copper e Blitter lavoravano a 16 bit.

Estendendo l’uso degli accessi a 32 e 64 bit si potevano facilmente portare benefici analoghi anche a questi componenti, che non erano meno importanti. Avremmo potuto avere floppy da 1,76 e 3,5MB funzionanti a piena velocità, e 4 canali audio a bit 8 bit fino a 112KHz oppure a 16 bit fino a 56Khz.

Il Copper già da prima richiedeva 2 word a 16 bit per le sue istruzioni, e sfruttando per lo meno l’accesso a 32 bit avrebbe dimezzato l’uso della banda di memoria e velocizzato il suo funzionamento. Idem per il Blitter: si sarebbe potuto sfruttare almeno l’accesso a 32 bit per dimezzare accessi e velocizzarne le operazioni.

La pecca più grossa rimaneva la mancanza delle modalità cosidette “chunky pixel, ossia non facenti uso di bitplane per i dati degli schermi, che erano ormai indispensabili per realizzare velocemente grafica 3D. Per lo meno una modalità chunky a 256 colori (8 bit, 1 byte, che conteneva il colore da selezionare nella palette) sarebbe stata utilissima (e quelle a 16, 24 e 32 bit una gradita aggiunta, specialmente per i programmi di fotoritocco, disegno pittorico, e grafica 3D).

Forse non dovrei parlare di pecche, ma di enormi lacune e di una generale miopia della dirigenza Commodore, che non è mai riuscita a captare per tempo i veloci, spesso repentini, cambiamenti del mercato. Il fallimento di questa gloriosa casa che ha fatto la storia dell’informatica è semplicemente la conseguenza prevedibile di una politica che definire avulsa dalla realtà era fargli un complimento, legata poi mani e piedi al mero profitto dei suoi due presidenti, ancora oggi odiati dagli amighisti di lunga data che li considerano soltanto due sanguisughe senz’anima.

L’AGA rimane pertanto un’opera incompiuta, sicuramente non in linea con quanto ci si aspettava, ma che nonostante tutto è stata apprezzata e, soprattutto, sfruttata da quanto di realmente buono c’era in quell’ambiente: i programmatori pieni di idee e di geniali trovate che hanno cercato di spremere come un limone quella che rimaneva comunque un’architettura con una “filosofia” che ancora oggi lascia l’amaro in bocca.

Grazie, Jay Miner, che hai permesso tutto ciò.

35 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
    D
     scrive: 

    Che fine hanno fatto le due sanguisughe dopo commodore ? Come succede in italia sono riusciti a diventare ceo di qualcos’altro (possibilmente facendolo fallire a sua volta), si sono ritirati, sono stati presi a legnate ed abbandonati sotto un ponte… insomma cosa ?

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

    Non ne so niente. Ma immagino che non si facciano vedere in giro. :D

  • # 3
    Davide
     scrive: 

    Ciao Cesare! Ci siamo conosciuti a Catania, tu eri studente universitario e stavi vicino all’Ambasciatori, io non avevo nemmeno diciott’anni, ma sono venuto diverse volte a casa tua e mi hai sbalordito mostrandomi software allo stato dell’arte per l’amato Amiga. Mi ha fatto molto piacere ritrovarti qui per caso e leggerti. Scusate l’OT. Un caro saluto,

    Davide

  • # 4
    Emanuele Rampichini
     scrive: 

    @cesare
    Non mi puoi mettere il video di pinball fantasies… ci giocavo da piccolissimo sul 486, Party land era il mio tavolo preferito ma anche quello a tema horror mi divertiva molto. Bei ricordi! :D

  • # 5
    iva
     scrive: 

    Ma i canali DMA nei sistemi AGA non sono passati da 25 a 27?

    Stavo leggendo qualcosa a riguardo di recente ma adesso non ricordo in dettaglio perche’ ce ne siano due di piu’…

  • # 6
    D
     scrive: 

    Ma alla fine tecnicamente cosa cambia da OCS ad AGA ? Solo un aumento di banda, insomma un aumento del numero di “fili” o ci sono proprio delle scelte tecniche nuove ?
    Poi altra cosa che mi sfugge. Tutta questa storia della cpu occupata e che quindi non si potevano utilizzare particolari combinazioni di bitplane e risoluzioni stava ad implicare che chipset e 020 operavano in maniera sincrona giusto ? Sarebbe stato troppo complicato per i tempi far operare le due cose in maniera separata liberando quindi la cpu ?

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

    @Davide: incredibile. :D Sì, lo ricordo bene. Era il periodo in cui smanettavo con l’hardware dell’Amiga, ma all’epoca (avevo 21 anni, se non erro) non l’avevo ancora spremuto per bene.

    Mi ha fatto molto piacere “rivederti”. :)

    @Emanuele Rampichini: ho messo quello proprio perché era il mio preferito. :D

    @iva: sì, hai ragione: i due canali in più del DMA sono relativi ai due bitplane nuovi (il 7 e l’8) che adesso era possibile usare. Correggo subito il lapsus, grazie.

    @D: il cambiamento principale è dovuto al tipo di memoria e al suo interfacciamento. Con la VRAM era possibile leggere (o scrivere) due dati durante lo stesso accesso, e di dimensione pari a 32 bit (anziché 16).

    Questo si traduceva in un beneficio anche per le CPU 68020+, perché potevano finalmente leggere e scrivere a 32 bit questa memoria (prima esclusivamente a 16 bit).

    Poi è chiaro che internamente Alice e Lisa sono cambiati rispetto ad Agnus e Denise: il primo per implementare quest’interfaccia nuova (aggiungendo i due canali DMA di cui parlava iva), e il secondo per sfruttarne i benefici (maggior numero di colori e dimensioni degli sprite).

    Il chipset e la CPU non erano necessariamente sincroni. Lo erano nell’Amiga 1000, 5000, e 1200, ma per questioni di semplicità e di risparmio. Ma potevano benissimo operare in asicronia, ognuno con un proprio clock e/o memoria dedicata.

    La sincronia era imposta esclusivamente per l’accesso alla chipram, che operava a una precisa frequenza, e la cui gestione era a carico di Agnus/Alice, che ne dettava anche la priorità (la CPU era l’ultima).

    Una CPU dotata di memoria dedicata (vera fast ram; la slowram, pur innaccessibile dai chip custom, era comunque gestita da Agnus per quanto riguarda il refresh e la priorità dell’accesso) poteva funzionare in maniera completamente indipendente dai chip custom.

  • # 8
    Medicina
     scrive: 

    Mehdi Ali:
    http://stoneridgepartners.biz/principals.htm

    Dovrebbe essere aggiornata al 2004.

  • # 9
    D
     scrive: 

    @Cesare

    Quindi fantasticando che Commodore fosse sopravvissuta e che nel frattempo fosse uscito il chipset AAA, avremo avuto di nuovo un salto di quel tipo ma niente di particolarmente rivoluzionario. Prima o dopo la gloriosa famiglia sarebbe finita comunque nel fango per mancanza di una vera ricerca e sviluppo ferma alle idee del primo chipset.

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

    Posso dirti che l’AAA, per quanto non fosse perfettamente allineato con quanto disponibile per Mac e PC, era comunque un ENORME passo in avanti.

    Diciamo che non sfigurava rispetto alla concorrenza, e usato “the Amiga way” avrebbe spaccato le pietre, come si suol dire.

    Ovviamente se fosse uscito nel ’94. Non più tardi.

    Dell’AAA, comunque, ne parlerò in futuro.

  • # 11
    D
     scrive: 

    Guarda che io per “passo in avanti” intendevo qualcosa ad esempio tipo un nuovo blitter in grado di gestire altre e più avanzate primitive quindi immaginando un’evoluzione lato 3D la presenza di un generatore di figure solide e via dicendo. L’impressione che ho avuto fino adesso è stato un aumento di banda e memoria con le ovvie conseguenze del caso sul numero di colori e le risoluzioni disponibili.
    Riguardo alle risoluzioni non capisco però perchè sforzarsi di far uscire roba in grado di posizionare 1200 punti in orizzontale e meno di 300 in verticale.
    La fissa dei 16:9 non era ancora presente quindi a che pro realizzare degli schermi con le proporzioni così compromesse ?

  • # 12
    jpx
     scrive: 

    @D

    L’AAA era un intero universo avanti rispetto all’AGA. Ci sono ancora i PDF delle specifiche in giro da qualche parte, dacci dentro di google e vedrai! ;)

    Dei limiti del chipset erano tutti coscienti da tempo (ma non dimentichiamoci che stiamo parlando di un design dei primissimi anni ’80, quindi già di per sé miracolosamente sopravvissuto fin troppo a lungo). ECS prima e AGA poi sono state più che altro delle “pezze”. Deluxe, ma sempre pezze IMHO.

    Il reparto R&D era già al lavoro sul progetto Hombre che dell’Amiga avrebbe ereditato la filosofia più che la retrocompatibilità…ma tutto ciò (purtroppo) è oramai solo mito e leggenda.

    http://www.amigahistory.co.uk/21helper.txt

  • # 13
    jpx
     scrive: 

    “Riguardo alle risoluzioni non capisco però perchè sforzarsi di far uscire roba in grado di posizionare 1200 punti in orizzontale e meno di 300 in verticale.”

    Lo scrolling a 1/4 di pixel non ti ha suggerito proprio nulla? ;)
    Ricordati poi che l’architettura Amiga si fondava, tra le tante altre cose, anche su di un subdolo sfruttamento di piacevoli “effetti collaterali”… e chi ha “codato” sa a cosa mi riferisco! ;D

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

    Non a caso ne ho parlato. ;)

    Ovviamente concordo con tutto ciò che hai scritto. :P

    Dell’AAA ne parlerò in futuro. Abbiate pazienza.

    @D: il Blitter era già in grado di disegnare figure “solide”. Vedrai come in una serie di articoli che ho intenzione di scrivere per spiegare per filo e per segno come funzionava l’hardware dell’Amiga. ;)

  • # 15
    D
     scrive: 

    “Lo scrolling a 1/4 di pixel non ti ha suggerito proprio nulla? ;)”

    Non parliamo di scrolling ma di immagini statiche.
    Praticamente i pixel venivano disegnati non come quadrati ma come rettangoli.
    Hai idea che macello sarebbe venuto fuori negli anni quando anche gli amiga avrebbero scoperto proporzioni più standard tipo i 4:3 ?

    “Ricordati poi che l’architettura Amiga si fondava, tra le tante altre cose, anche su di un subdolo sfruttamento di piacevoli “effetti collaterali”…”

    Vabbè ma capiamoci: non ti metti a progettare un’architettura pensando alla demoscene ed i pazzoidi che ci stanno dietro (stanotte mi sono visto un filmino in 3D con il Vice 64, tanto per…). Gli effetti collaterali nascono dalla necessità di ottenere di più con il niente o quasi ma ai giorni nostri una simile scelta sarebbe praticamente un suicidio.

    “il Blitter era già in grado di disegnare figure “solide”.”

    Intendevo solide senza virgolette e magari tutta una serie di primitive per le curve.

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

    Secondo te il 3D come lo si faceva con l’Amiga? Col Blitter che tracciava le linee dei poligoni e li riempiva (usando anche un pattern, eventualmente). :D

    Parlare addirittura di curve non ha senso. Inquadriamo anche il periodo storico in cui stiamo focalizzando l’attenzione: stiamo parlando del ’92 per gli AAA. I PC e i Mac cosa avevano? Soltanto le schede video più potenti (NON per la massa) erano dotati coprocessori grafici dedicati.

    Per quanto riguarda l’aspect ratio, beh, non vedo quale sia il problema: era esattamente quello che il segnale televisivo metteva a disposizione. Non è che si potesse decidere di usarne un altro.

    Per la precisione, a partire dall’ECS si poteva programmare il segnale video come si voleva, ma poi non potevi più usare la tradizionale TV (o Monitor CRT), ma un monitor multisync.

  • # 17
    D
     scrive: 

    “Per quanto riguarda l’aspect ratio, beh, non vedo quale sia il problema: era esattamente quello che il segnale televisivo metteva a disposizione. Non è che si potesse decidere di usarne un altro.”

    Sicuro ? Mi sembra che sia pal che ntsc avessero proporzioni sui 4:3

    1280×256 è un 5:1, praticamente nella super hires mode ci facevi solamente i banner col rullo, i pattern della carta igienica.
    Forse nelle intenzioni avresti potuto realizzare i fondali dei videogiochi ma temo che avresti rubato tutte le risorse al resto per farlo.

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

    Infatti è per questo che non si usava: la maggior memoria e banda necessaria.

    Comunque sono arci sicuro: altrimenti non l’avrei scritto. ;)

    Innanzitutto PAL e NTSC avevano proporzioni diverse. Circa 320×288 il primo e 320×240 il secondo.

    Poi queste erano le basse risoluzioni, ma per entrambe era possibile utilizzare le alte e la super-hires: 640 per le prime e 1280 per le seconde. Sempre con lo stesso segnale televisivo.

    Anche se ha poco senso parlare di risoluzione orizzontale per un segnale analogico. Dovremmo parlare più correttamente di quantità d’informazione trasportata.

    Comunque il senso è che in orizzontale la risoluzione poteva variare in base al clock utilizzato, e alla circuiteria video. Infatti molte console usavano 256 o 512 punti, ad esempio, e non è che il segnale cambiava: sempre NTSC o PAL era. ;)

  • # 19
    Warfox
     scrive: 

    Dai dai.. 320×256.. non rubiamo ancora cicli per un po’ di overscan verticale.. che poi la cpu non basta.. ;)

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

    Allora facciamo lo stesso con l’NTSC e fissiamo la risoluzione a 320×200. :P

  • # 21
    Warfox
     scrive: 

    Mi sembra giusto :O

  • # 22
    PATOP69
     scrive: 

    Credo che alcuni commenti, nessuno me ne voglia, siano stati rilasciati piuttosto superficialmente. Occorre sia chiaro degli anni di cui si stà parlando e di cosa offriva il mercato HOME informatico (ma anche professionale con costi impensabili!) di quell’epoca in alternativa alla piattaforma AMIGA. Se non si tiene presente questo i commenti di raffronto con le possibilità grafiche e/o di calcolo inerenti a feature praticamente non ancora \inventate\ nel mondo home computing dell’epoca sono prive di senso. Il progetto AMIGA e relativo chipset fu reso commerciale nel 1985 con l’introduzione del modello AMIGA 1000…una macchina che precorreva i tempi sotto molti aspetti a rifarsi da quello delle peculiarità grafiche. E’ chiaro che far evolvere una piattaforma custom-proprietaria mantenendo per certi versi la compatibilità in quegli anni non era così semplice come magari potrebbe essere dedotto ai nostri giorni. Infatti non possiamo non tralasciare il fatto che tutto ruotava molto intorno all’hardware e meno al software…..oggi abbiamo fior fiore di emulatori/virtualizzatori software che con così tanta potenza grezza della CPU-GPU-RAM ha spostato il perno dall’importanza di un progetto solo HW verso progetti dove il software middleware diventa di assoluto rilievo. Saluti a tutti i viva AMIGA FOREVER!

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

    Sono d’accordo, però considera che c’è gente che quei tempi non li ha vissuti, e non è informata. O non è correttamente informata (le “voci” e le leggende metropolitane purtroppo avvelenano il “segnale” buono).

    Articoli come questo, e i relativi commenti che ne scaturiscono, servono sia a tramandare (nei limiti del mezzo e delle conoscenze) questa parte della storia dell’informatica, sia a offrire correzioni e/o spunti di riflessione. ;)

  • # 24
    marioseven
     scrive: 

    cito:

    Adesso è, infatti, possibile visualizzare schermi a 32 colori, in EHB, HAM, o DP anche in alta risoluzione, Super-Hires, VGA o SVGA

    Correggo:

    omissis….256 colori o HAM8 in TUTTE le risoluzioni quindi anche Hires, Super Hires, vga o SVGA.

    Era un bel passo avanti, a patto di avere della fast ram o, meglio, un’accelleratrice (anche da poco) con della fast ram.

    Il sistema operativo era ed è tuttora qualcosa di magico. Multitasking preemptive. Dal 1985. Senza bisogno di MMU.
    con le rom 3.x da 512kbyte ed un floppy dal 880Kbyte si aveva il pieno controllo della macchina e delle èperiferiche all’epoca disponibili.

    Io fossi in voi andrei a dare un0occhiata al progetto “natami”.
    Ciao

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

    I 256 colori, l’HAM-8, e il DP a 16 colori per schermo li ho aggiunti subito dopo. :P

    Natami era già in programma, e sarà oggetto di un prossimo articolo.

  • # 26
    marco
     scrive: 

    “in realtà molti meno, vuoi per il fatto che 16 milioni di colori diversi necessiterebbero di schermi da 4096×4096 pixel”.
    Scusate, ma questa cosa non l’ho mai capita. Ma che c’entra il numero di pixel a schermo (e quindi la risoluzione) con il numero di colori visualizzabili? Io poi mi ricordo che l’HAM-8 gestiva internamente immagini a true color mentre in visualizzazione ne mostrava 262.144.

  • # 27
    marco
     scrive: 

    ah…..capito :D ….. un pixel per ogni colore in pratica….4096^2=16 milioni e rotti colori….

  • # 28
    D
     scrive: 

    “Innanzitutto PAL e NTSC avevano proporzioni diverse. Circa 320×288 il primo e 320×240 il secondo.”

    Continuo a non capire sta cosa. Capisco, sono il primo a dirlo, che di wikipedia non c’è da fidarsi ma voglio sperare che almeno una moltiplicazione sia corretta.

    Per realizzare un’immagine conforme allo standard PAL con un programma di elaborazione d’immagini, le dimensioni devono essere di 720 pixel in orizzontale e di 576 pixel in verticale, con una risoluzione di 72 pixel/pollice, presupponendo un rapporto d’aspetto di 4:3 e considerando che esistono dei margini oltre i quali l’immagine non viene visualizzata sullo schermo televisivo e dei margini al di fuori dei quali è meglio non posizionare testi. Per una corretta visualizzazione è fondamentale che all’immagine sia applicato un filtro di interlacciamento e che il rapporto d’aspetto del pixel sia di 1,3.

    L’immagine creata è invece di 768×576 pixel se il rapporto d’aspetto del pixel è quadrato.

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

    Finito Rai per una notte, passo velocemente alle risposte prima di andare a nanna. :P

    @D: provo a fare un po’ di chiarezza.

    Per NTSC, segnale visibile: 640×400; overscan: 704×480; segnale totale (compresi intervalli di horizontal e vertical blanking): 720×525.

    Per PAL, segnale visibile: 640×512; overscan: 704×576; segnale totale: 720×625.

    Preciso che per l’overscan si tratta di valori abbastanza comuni, ma possono anche variare.

    Risoluzione orizzontale dimezzata -> bassa risoluzione.
    Risoluzione orizzontale raddoppiata -> Super-Hires.

    @marco: preciso che HAM-8 non gestiva internamente le immagini in TrueColor. I dati venivano prelevati dagli 8 bitplane in formato già “compresso” (come codificato dallo schema usato da HAM-8), per poi essere processati secondo l’algoritmo di “decompressione”.

    L’output era a 24 bit e non a 18, quindi teoricamente 16 milioni di colori e non 262144. Quest’ultimo dato si riferisce alle combinazioni possibili variando i 6 bit alti delle 3 componenti cromatiche, ma i 2 bit bassi di ognuna vanno recuperati dai corrispondenti dei 64 colori di base della palette usati dall’HAM-8.

    Lo so, è un casino. :D Se serve provo a spiegarmi meglio con degli esempi.

  • # 30
    iva
     scrive: 

    @Cesare, ho dimenticato i complimenti per l’articolo ma tanto ormai sono standard e non te li faccio piu’ :)

    Ma tu giri dalle parti di English Amiga Board?
    Da quando mi e’ arrivato il 4000 lo visito regolarmente ma non mi pare che tra i coder ci sia nessun italiano… potresti dare consigli di programmazione (ci sono forum appositi) e magari anche prendere spunto per qualche articolo futuro.

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

    Intanto ti ringrazio per i complimenti.

    EAB lo conosco, ma non lo frequento perché non ho tempo. Parecchi anni fa frequentavo regolarmente la board dell’emulatore (Win)UAE, e facevo qualche intervento, ma poi ho smesso sempre per questioni di tempo.

    Gli spunti al momento non mi mancano, ma magari ogni tanto torno a farci una capatina se ne ho bisogno. Grazie per l’idea. :)

  • # 32
    ClaudioBG
     scrive: 

    C’entra poco con l’articolo, ma vedere il filmato di Pinball Fantasies mi ha fatto scappare un sorriso nel constatare l’imperfezione evidente nella fisica della pallina, che ai tempi non avrei mai notato! :-) Però che ricordi…consumai letteralmente ogni capitolo dei flipper della Digital Illusions, sebbene i flipper “veri” non siano mai stati la mia passione! Spettacolo!!! :°-)

  • # 33
    Kold666
     scrive: 

    Attivando modalità multisync a 31khz, si raddoppiava anche il sampling rate del Paula, facendolo passare da 28khz a 56khz.
    Questa cosa era sfruttata da programmi come Digibooster o il Symphony (non ricordo se fosse esattamente il suo nome)

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

    Questi programmi non li conosco, ma ciò che dici è corretto: visto che il numero di righe in questa modalità era raddoppiato, lo erano anche gli slot a disposizione per l’audio e per il disco.

  • # 35
    hexaae
     scrive: 

    Ho le lacrime agli occhi quando rileggo della magia di quei tempi fra AGA, OCS, scrolling al leggendario 1/4 di pixel….

    Amiga forever

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.