di  -  mercoledì 28 luglio 2010

Come promesso, finalmente arriviamo a parlare delle limitazioni presenti nel chipset dell’Amiga (che ricadono nelle singole componenti) con cui hanno avuto a che fare i programmatori, e le idee, o per meglio dire i sogni, che li hanno tormentati nella speranza che Commodore vi ponesse rimedio, o semplicemente chiedendosi perché il buon Jay Miner non avesse osato di più.

Nei precedenti articoli abbiamo avuto modo di vedere in che modo erano foraggiate le varie parti del sistema dotate di appositi canali DMA e, in particolare, quello dei bitplane che facevano parte dello schermo da visualizzare.

La suddivisione in due pezzi non è casuale né serviva soltanto per non appesantire troppo l’argomento (che mi rendo conto non essere dei più “potabili”, ma purtroppo si tratta di dettagli troppo tecnici). I due argomenti andavano trattati in separata sede perché il funzionamento descritto era effettivamente diverso, e ne influenzava di conseguenza i citati limiti.

A prima vista è difficile pensare che le due cose si comportino in maniera dissimile: in fondo si tratta sempre di elementi a cui vengono assegnati degli slot da utilizzare per accedere alla chip ram. In realtà, analizzando bene il pluricitato schema dell’allocazione degli slot, risulta evidente il loro punto di separazione, che sta proprio negli slot utilizzati.

Infatti la circuiteria di refresh della memoria, il disco, l’audio e gli sprite utilizzano soltanto slot dispari, mentre il display predilige sempre gli slot dispari, ma se ne ha bisogno può utilizzare tranquillamente anche quelli pari (anzi, li può anche sfruttare tutti, lasciando a bocca asciutta CPU, Copper, e/o Blitter, come già detto nel precedente articolo).

La motivazione la conosciamo già: lasciare al 68000 i cicli pari, che erano gli unici che utilizzava per accedere alla memoria. Ma “rubare” cicli al processore per svolgere del lavoro più utile non è mai un crimine. Nello specifico, il più grosso limite a cui si sarebbe dovuto (parzialmente) provvedere era sicuramente quello degli sprite, che ricordiamo essere in numero di 8, ma con soli 4 colori, e per averli a 16 colori bisognava “accoppiarne” due di fila (0 con 1, 2 con 3, ecc.).

Da programmatore di videogiochi dell’epoca gli sprite erano uno strumento utilissimo, e averne soltanto 3 disponibili a 16 colori (uno se lo “mangiava” il DMA dello schermo se veniva abilitato lo scroll orizzontale) era un grosso limite. Jay Miner aveva già progettato il chipset dell’Atari 2600, per cui sapeva bene quanto fossero importanti gli sprite, specialmente per una macchina che doveva fungere anche da “console”.

Eliminare il famigerato trucchetto dell’accoppiamento era sicuramente fattibile ma, come per tutte le cose, non possiamo limitarci a sparare dei numeri in alto: serve contestualizzare (ricordiamoci che parliamo del 1985, anno di introduzione dell’Amiga, che il 23 luglio ha compiuto il suo 25-esimo anniversario) e giustificarne tecnicamente la portata, con le relative conseguenze.

A livello di banda verso la memoria non c’erano sicuramente difficoltà, in quanto sarebbe bastato impiegare, oltre ai due slot dispari già assegnati, quelli dispari immediatamente precedenti (ad esempio gli slot da $0C a $0F per lo sprite 0, anziché soltanto $0D e $0F). Sarebbero stati sottratti al più 16 accessi al microprocessore, ma ubi maior minor cessat, come dicevano gli antichi latini.

A livello di logica per gestire il tutto non penso che sarebbe cambiato di molto (tra l’altro l’hack di accoppiare due sprite richiedeva logica apposita per distinguere e gestire i due casi, mentre qui sarebbe venuto meno), mentre alcuni problemi ci sarebbero stati col banco dei registri dedicati agli sprite, che sarebbe dovuti raddoppiare o quasi.

Ogni sprite, infatti, ha associati 4 registri (a 16 bit) che iniziano dalla locazione $DFF140 e che contengono rispettivamente la posizione, alcuni flag di controllo, il primo bitplane e il secondo bitplane (ricordiamo che per avere immagini a 4 colori servono 2 bitplane). Questi registri finiscono a $DFF17F, e subito dopo ($DFF180 ovviamente) iniziano i 32 registri della palette dello schermo, che quindi si sarebbero dovuti spostare in avanti (ad esempio a $DFF1C0).

Quindi incontriamo già alcuni problemi “logistici”, ma facilmente risolvibili, mentre l’aumento dei registri rappresenta un certo costo, perché stiamo parlando di memoria (statica). Tutto sommato penso fosse sostenibile, perché si sarebbe trattato di aggiungere 64 byte, e avrebbe avuto il vantaggio di organizzare anche meglio i due registri di posizione e controllo (vedremo in futuro come sono fatti); un piccolo svantaggio sarebbe stato quello che i dati di controllo letti dal DMA sarebbero raddoppiati (vedremo pure cosa significa questo), ma da coder vi assicuro che non sarebbe stato un problema.

Tirando le somme per gli sprite, credo che con qualche piccolo sforzo la situazione sarebbe stata di gran lunga migliore, vuoi per il numero degli stessi disponibili a 16 colori (4 colori erano veramente troppo pochi, e tra l’altro con precisi limiti sulla porzione di palette da utilizzare), vuoi per non avere a che fare col fastidioso meccanismo dell’accoppiamento, e ancora per l’organizzazione interna dei già citati registri di posizione e controllo.

Lo stesso giochetto di sfruttare gli slot pari si sarebbe potuto attuare anche per gli altri due componenti che utilizzavano esclusivamente quelli dispari: disco e audio. Ma non avrebbe avuto senso apportare dei cambiamenti, sempre per una questione di contestualizzazione.

Parliamo, infatti, del 1985: non esistevano floppy ad alta densità (da 1,44MB), e i 4 canali PCM a 8 bit completamente indipendenti rappresentarono già di per sé una rivoluzione. Di più non si poteva e, soprattutto, non aveva senso fare.

Non v’è dubbio, però, che col passare del tempo le esigenze sono cambiate, e sarebbe stato necessario farvi fronte. Commodore, però, non l’ha mai fatto, lasciando Paula (il chip che si occupa della gestione di disco, audio, seriale, e parte dell’I/O) intatto: lo stesso chip lo ritroviamo sia negli Amiga 1000 che negli ultimi modelli sfornati.

Francamente lo trovo del tutto incomprensibile, perché i floppy ad alta densità sono poi diventati una realtà tangibile, e per poterci lavorare gli ingegneri hanno dovuto dimezzare la velocità di rotazione del floppy per leggere i dati a una velocità compatibile con la banda messa a disposizione per Paula (che ricordo avere 3 slot dispari, per riga di raster, allo scopo).

Tra l’altro Paula utilizzerà sicuramente una coda all’interno per disaccoppiare la lettura o scrittura dei dati da e verso il floppy, come spiegato nell’apposito articolo, e sarebbe bastata raddoppiarla (da 3 a 6 word) con poco sforzo.

Per l’audio il discorso è sicuramente più complicato e delicato. Innanzitutto pensare di aumentare i canali audio avrebbe comportato troppo sforzo, perché l’architettura era stata pensata per gestirne soltanto 4 (la “maschera” per i canali DMA aveva 4 bit dedicati, come pure quella per gli interrupt associati a ogni canale); 8 o più canali, quindi, avrebbero richiesto modifiche più profonde al sistema (incluso il s.o. che avrebbe dovuto gestire il tutto).

Qualcosa, però, la si poteva anche fare nel 1990 (anno di introduzione dell’ECS), su 3 fronti: frequenza di riproduzione, ampiezza e lunghezza del campionamento. Per i primi due, in particolare, sarebbe servito aumentare la banda di memoria, ma sfruttando gli slot pari, similmente agli sprite, si sarebbe tranquillamente potuta raddoppiare.

Anche i canali audio sono dotati di appositi registri, in numero di 6 per ognuno, che contengono rispettivamente il puntatore (a 32 bit, quindi fa uso 2 registri a 16 bit) al buffer di memoria che contiene il campionamento, la sua lunghezza, il periodo (che determina la frequenza di riproduzione), il volume, e infine la word che contiene i due campioni a 8 bit letti (per riga di raster).

Raddoppiando la banda le word lette sarebbero state due, per cui sarebbe stato necessario un ulteriore registro, ma questo non sarebbero stato un problema perché, per ogni canale, a seguito delle 6 sono presenti 2 word inutilizzate.

Questa modifica non sarebbe stata sufficiente, comunque, perché internamente Paula avrebbe dovuto gestire i 4 sample a 8 bit tramite una coda; soluzione, questa, assolutamente alla portata, e che avrebbe permesso di arrivare teoricamente fino a 58Khz di frequenza (contro i 29 dell’OCS).

Per utilizzare sample a 16 bit anziché a 8 sarebbero serviti dei DAC di adeguata “dimensione”, sicuramente più costosi, ma già alla portata all’epoca (ricordo che il CD-ROM è stato introdotto nel 1985, e i lettori necessitavano di 2 DAC a 16 bit). Per il resto, la gestione sarebbe stata simile ai sample a 8 bit del chipset originale, come pure il limite della frequenza (sempre 29Khz massimi).

L’ultimo limite riguardo ai canali audio era rappresentato dalla lunghezza del campionamento riproducibili: al massimo 128KB (pari a 64K word a 16 bit). Questo perché, come già detto, il registro dedicato allo scopo era soltanto a 16 bit. Una soluzione semplice sarebbe stata quella di affiancargli un altro registro (ce n’era ancora uno inutilizzato) in cui specificare la parte alta della lunghezza, similmente a quanto fatto proprio col Blitter ECS e il suo registro per la dimensione dell’area rettangolare (di cui parleremo in futuro).

Infine il display offre diversi spunti di riflessione sulle mancanze o i miglioramenti possibili e fattibili nel contesto in cui nasceva questa meravigliosa macchina. Partendo sempre dal mio punto di vista di programmatore di videogiochi, ricordo che una modalità molto utilizzata e importante era quella soprannominata Dual Playfield, che metteva a disposizione due schermi indipendenti (scrollabili) e che ci ha regalato perle quali Shadow of the Beast.

Il limite, però, era abbastanza pesante: i due schemi potevano avere a disposizione al più 3 bitplane, e quindi visualizzare al massimo 8 colori (7 per quello frontale, a causa del “colore” 0 che serviva a “forare” lo schermo e visualizzare la grafica di quello sottostante).

Con l’AGA sappiamo che questo limite è stato portato a 4 bitplane per singolo schermo, quindi con 16 colori (15 per il primo schermo) visualizzabili contemporaneamente, che rappresentano un notevole salto qualitativo (se pensiamo pure che ogni schermo avrebbe potuto attingere a una sua palette di 16 colori).

4 bitplane per due schermi avrebbero significato 8 bitplane in totale, mentre il chipset ne metteva a disposizione soltanto 6. Aggiungerne altri 2 non sarebbe stato un problema, perché nella mappa dei registri lo spazio a disposizione c’era, e infatti è stato poi sfruttato proprio dall’AGA.

Al solito bisogna tenere conto anche della banda di memoria necessaria per alimentare questi ulteriori bitplane, ma andando a controllare nel diagramma di allocazione degli slot notiamo che il display a bassa risoluzione sfrutta al più 6 degli 8 slot a disposizione, e tutti gli slot usando l’alta risoluzione con 4 bitplane.

C’è sicuramente da tenere conto del fatto che con 8 bitplane il display non avrebbe lasciato alcuno slot a CPU, Copper e/o Blitter, per cui gli unici a disposizione sarebbero stati quelli dell’horizontal retrace e del vertical retrace (oltre a quelli inutilizzati dalle altre componenti), ma avendo a disposizione anche 8 sprite a 16 colori sono sicuro che i programmatori avrebbero trovato il modo di sfruttare sapientemente il Dual Playfield con 8 bitplane.

Con 8 bitplane, però, si sarebbero potute migliorare altre cose. Uno schermo a 256 colori è certamente allettante, ma il limite più grosso è rappresentato dal numero di colori della palette: soltanto 32 (che “coprono”, quindi, 5 bitplane), tant’è che per avere 64 colori si doveva utilizzare la modalità Extra-Half Brite (EHB), che a ognuno dei 32 colori ne associava un altro a luminosità dimezzata.

Aumentare la dimensione della palette avrebbe comportato alcuni grossi problemi. Allargando l’area da $DFF180 a $DFF1FF non ci sarebbe stato spazio per i registri aggiuntivi necessari per avere tutti gli sprite a 16 colori, e personalmente avrei preferito di gran lunga migliorare questi ultimi.

Pensare di spostare l’area subito dopo, quindi a partire da $DFF200, dedicandola interamente alla LUT (da $DFF200 a $DFF3FF si sarebbe potuta definire una palette di 256 colori diversi) sarebbe stato decisamente troppo costoso per il gran numero di registri aggiuntivi richiesto.

Una soluzione di comodo sarebbe potuta essere quella di sfruttare lo stesso principio dell’EHB, ma anziché mettere a disposizione 2 sole tonalità da un colore base, se ne potevano realizzare 4 con 7 bitplane, e 8 con 8 bitplane (qualcosa di simile, se non ricordo male, la faceva l’Acorn Archimedes, che non aveva una palette di 256 colori diversi).

Anche questa soluzione pone dei problemi in termini di banda a disposizione per CPU, Copper e Blitter, ma sono convinto che le avventure grafiche avrebbero avuto di che guadagnarci dal poter utilizzare schermi a 128 o 256 colori (sebbene non tutti distinti).

Qualche utilità l’avrebbe avuta anche l’estensione dell’Hold-And-Modify (HAM) dai canonici 6 bitplane, a 7 oppure 8. Indubbiamente con una palette base più ricca da cui attingere (16 colori per la classica HAM) le immagini avrebbero risentito meno dei problemi di “cambio colore” tipici di questa modalità video, sebbene fosse utilizzata esclusivamente per visualizzare immagini statiche.

L’ultimo accenno è riservato al numero di colori da cui attingere per la palette: 4096 per l’Amiga nel 1985 erano veramente tanti e una gioia per le pupille. I registri che li contenevano erano, però, a 16 bit anziché a 12 (12 bit -> 4096 colori), per cui Jay Miner avrebbe potuto impiegare 5 bit anziché 4 per colore primario, arrivando a 15 bit (15 bit -> 32mila colori).

Ma un SuperNintendo nel 1985 sarebbe stato davvero troppo (costoso ed esagerato)…

42 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
    Marco
     scrive: 

    Grazie Cesare, complimenti per l’articolo!

    Qualche pensiero sparso:

    “sfruttare lo stesso principio dell’EHB”

    Lo stesso TED (C=16 ad esempio) lo faceva con 8 livelli di luminosità per ogni colore. Probabilmente avrebbe complicato troppo la circuiteria (e richiesto un DAC più evoluto, al posto della rudimentale rete resistiva impiegata).

    Per quanto riguarda la sezione audio, Amiga (anche con un 68020) è ben in grado di riprodurre segnali a 14 bit (usando anche i 6 bit per il controllo del volume) con una qualità davvero invidiabile.

  • # 2
    Alex
     scrive: 

    Credo che semplicemente \aggiungere\ altra roba a quello che offriva l’Amiga 500 avrebbe comunque segnato la fine del concetto su cui era stata progettata l’Amiga sopratutto se guardiamo l’evoluzione della grafica in ottica accelerazione 3D. In fondo sull’Amiga era possibile ottenere degli effetti grafici notevoli spremendo attraverso trucchi e stratagemmi l’hardware. Negli anni la potenza di calcolo pura e l’accelerazione della pipeline grafica ha posto (e direi finalmente) l’enfasi non più sul concetto di partire dall’hardware per capire quali SFX puoi realizzare ma spingere direttamente il software per ottenere tutti gli SFX che sei in grado di programmare. Mi sembra una concetto non di poco.

  • # 3
    TheKaneB
     scrive: 

    Bell’articolo :-) forse risulta un po’ difficile da seguire per chi non ha mai programmato su Amiga (io ci giocavo soltanto all’epoca, e facevo qualche cosina in Amos Basic :D ), ma sei comunque riuscito a spiegare le cose in modo da dare un’idea precisa delle problematiche che si riscontravano ;-)

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

    @Marco: hai ragione, avevo l’esempio in casa, e sono andato da tutt’altra parte. Ironia della sorte, il mio primo computer è stato proprio un Plus 4… Si vede che ho bisogno di un po’ di riposo. :D

    Per l’audio è vero quello che dici, ma in questo modo dev’essere la CPU a “pilotare” i canali, caricando in maniera precisa i sample e il volume. Molto più comodo sarebbe ovviamente col DMA che carica sample a 16 bit.

    @Alex: quelle menzionate nell’articolo non sono aggiunte “straordinarie”, come può essere il 3D, appunto, ma modifiche abbastanza semplici e “compatibili” con l’assetto del chipset, di cui ne sfruttano proprio le peculiarità.

    Non ho parlato, infatti, di clock duplicati o quadruplicati, di bus a 32, 64, o più bit, che avrebbero inciso notevolmente sul progetto.

    Si tratta si osservazioni di un programmatore che conosce il funzionamento del sistema e che avrebbe gradito che fosse sfruttato meglio, rimanendo allineati a quella complessità e relativi costi.

    @TheKaneB: magari si capirà meglio con la serie di articoli dedicati alla programmazione delle singole componenti. Purtroppo l’argomento è abbastanza ostico, come avevo scritto nel pezzo, ma “allungando il brodo” forse sarebbe stato peggio; non so.

  • # 5
    TheKaneB
     scrive: 

    @Cesare, no no continua pure su questa linea! Precisi e sintetici, così devono essere gli articoli tecnici ;-) Se parlassimo di filosofia allora ti direi “allunga il brodo, vai _alleggiu_…”, ma qui il problema non sussiste :D

  • # 6
    Alex del viero
     scrive: 

    Io ero innamorato dell’amiga e ne conoscevo ogni particolare tecnico (frequentavo l’iti ai tempi).
    ECS fu un piccolo miglioramento in linea con i tempi, al contrario l’AGA portava miglioramenti piu’ sostanziali ma fu per me una grossa delusione xche non piu al passo con i tempi. La macchina che per anni aveva dettato le regole ormai era (nell’hardware) sorpassata.
    In questo non credo che la colpa sia da imputare a Jay Miner ma a scelte di mercato errate dei dirigenti.

  • # 7
    Alex del viero
     scrive: 

    Dimenticato di fare i miei complimenti per l’articolo!

  • # 8
    Alex
     scrive: 

    @Cesare
    Sono stato un programmatore assembly per Amiga. Ho realizzato qualche demo e qualche piccolo videogioco. Quando la Commodore è fallita ho smesso di affezionarmi ai brand ed alla tecnologie in quanto capì che l’hardware passa ma il software resta. Infatti di quella splendida idea su cui si basava l’Amiga ne esiste qualche traccia forse nelle console portatile di ultima generazione ma anche quelle stanno per passare alla forza bruta su cui far girare software a manetta. Non voglio sminuire il tuo articolo e le tue competenze ma la Commodore non poteva andare avanti per estensione di quello che teneva. Tra i suoi tanti errori c’è stato quello di non aver mai avuto un vero e proprio settore che si dedicasse alla ricerca e fosse in grado di guardare oltre al presente.

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

    In parte l’ha fatto, con ECS, AGA, AAA e Hombre. Il problema è che l’ha fatto tardi e/o male…

  • # 10
    joe4th
     scrive: 

    Scusate l’offtopic, che ne dite di qualche articolo di presentazione sull’imminente (forse) AmigaOne X1000 della A-EON, magari con qualche commento sul chip Xena (la principessa guerriera)?

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

    Ci stiamo pensando.

    Il problema è che agosto è alle porte, e francamente abbiamo bisogno tutti di un po’ di riposo. :-P

  • # 12
    lakar
     scrive: 

    @ Cesare
    Il limite di Paula non si poteva superare con una scheda audio come la Toccata? In questo caso era la cpu che governava il tutto in stile PC/Mac “saltando” Paula?
    Non ho ben capito cosa intendi con “lunghezza del campionamento riproducibili: al massimo 128KB” perché di questo argomento ne so poco. Che cosa intendi?

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

    Certamente, anche per l’Amiga erano disponibili schede per superare i suoi limiti riguardo grafica e audio, ma non erano esattamente alla portata di tutti. Inoltre richiedevano un supporto ad hoc.

    Per quanto riguarda la lunghezza del campionamento, immagina di avere un file WAV che contiene tutti i campioni (a 8 bit) da riprodurre. Ecco, non poteva essere più lungo di 128KB.

    Quindi per riprodurre suoni che occupavano più di 128KB, si doveva gestire manualmente l’operazione anziché lasciare tutto in mano al DMA, come normalmente (e comodamente) avveniva.

  • # 14
    Rosario
     scrive: 

    qualcuno saprebbe dirmi in numeri quali erano le proporzioni di presenza nelle case dei computer ai tempi d’oro dell’amiga? che dire poi del commodore 64? chiedo quasto perchè sembra che la storia dei personal computer l’abbiano fatta solo apple e microsoft, io ricordo tutt’altra cosa: in buco sperduto dell’universo, dove vivo io, una piccola città della sardegna, conoscevo centinaia di possessori di amiga!!!

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

    Francamente non ne ho proprio idea, ma anche dalle mie parti l’Amiga dilagava.

  • # 16
    TheKaneB
     scrive: 

    dalle mie parti (una cittadina in provincia di Palermo) praticamente 1 computer su 4 era Amiga, e di possessori di Apple ne ho conosciuti (ai tempi di Mac con motorola 68K) solo 3 in tutta la cittadina. Quindi proporzioni ben diverse da quelle sbandierate in giro. C’è però da considerare che Amiga era a buon mercato anche perchè tutti, anche dopo l’uscita dell’A3000, continuavano a comprare A500 e al max A600 che ormai erano quasi regalati. I PC (286 e 386) erano la maggioranza (ma non di tantissimo, solo 3 su 4 a occhio e croce).

  • # 17
    joe4th
     scrive: 

    x Rosario: se si parla di cifre assolute…in proporzione alla percentuale di PC incontrati (tipo universita’, strutture, etc.) 99% erano cloni IBM (olivetti, ibm, etc.) con DOS (dal 3 al 6), 0.9% era MAC (quelli in bianco e nero) e 0.1% Amiga. Ma se si parla di percentuale di \appassionati\, allora si saliva a 60% Amiga, 30% PC, 5% Mac e qualche Atari.

    L’effetto C64 al tempo di Amiga era gia’ finito. E per quanto possa sembrare essere stato molto piu’ lungo, non e’ che durato 2 o 3 anni (tipo ’83-’85-’86). In effetti l’ultima rivoluzione si e’ avuta nel 1995 con Linux. Da allora si e’ rimasti agli stessi sistemi seppure aggiornati.

  • # 18
    alex del viero
     scrive: 

    Io ricordo che c’e’ stato un periodo in cui in edicola c’erano piu riviste per amiga che per pc! c’era una rivista mac e le generaliste avevano la propria sezione dedicata all’amiga.

  • # 19
    sandro
     scrive: 

    ciao

    usando il color interlacing,potevano esser messi su schermo circa il doppio dei colori,certo c’era un prezzo da pagare,anzi piu’ di uno,ma vuoi mettere??e tutto cio’ solo programmando,ricordatevi lionheart per Amiga??

    http://www.retrogamer.it/amiga/lionheart.htm

    600 colori su schermo,parallasi come se piovessi..

    ciao
    Sandro

  • # 20
    jpx
     scrive: 

    Oramai i complimenti per questi articoli sono obbligatori e scontati! ;) Ottimo come sempre!

    @Alex
    Mi permetto di dissentire: alla CBM c’era un reparto R&D con i fiocchi (basti pensare che l’AAA – si, l’AAA, non l’AGA) era messo nero su bianco già nel 1991 e che addirittura nel 1988 Jay Miner stesso progettò delle modifiche non da poco per l’OCS (il leggendario chipset “Ranger”). Casomai era la solita dirigenza a segare i progetti sul nascere o ancora più stupidamente (e incredibilmente) ad un passo dalla catena di montaggio, tutto nell’ottica dello “spendiamo poco che altrimenti dobbiamo decurtare gli stipendi ai manager”. (La dirigenza CBM era famosa all’epoca per avere stipendi più alti della media del settore: HP, IBM e SUN incluse, fate voi…)

    Per quel che riguarda il Ranger, leggere qui prego: http://www.amigahistory.co.uk/jayminerinterview.html

  • # 21
    sandro
     scrive: 

    be’ per quel che riguarda gli sprite,si poteva anche leggere i dati in modo differente,senza aumentare i registri.del tipo ogni 2 righe di dati,avevi una riga di sprite,in questo modo avevi 4 bitplane comunque.e ripeto che bei 32k di fast per il 68000 avrebbero fatto la differenze,senza alzar troppo i costi…

    ciao
    Sandro

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

    Ma se ogni due righe prendevi i dati per 4 bitplane, allora gli sprite avrebbero visualizzato per due righe le stesse linee, quindi creando una sorta di zoom 2x in verticale, che personalmente avrei trovato antiestetico.

    Anche 64KB di fast ram non avrebbero fatto molta differenza coi giochi. Il collo di bottiglia è rappresentato dalla chipram, sia per la quantità che per la bandwidth, purtroppo. :(

  • # 23
    sandro
     scrive: 

    gia,a pensare che con un po’ di sforzo in piu’…ho sempre avuto il sentore che Amiga fosse un po’ monca..be 64kb di fast avrebbe fatto la differenza con le applicazioni.

  • # 24
    sandro
     scrive: 

    i dati per gli sprite non li prendevi ogni 2 righe,semplicemente per ogni riga di raster leggevi “2 righe di sprite”.cosi’ non aumentavi il numero dei registri.

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

    Ma non cambiava nulla, perché quei dati dovevano finire negli appositi registri interni, e di questi ce n’erano soltanto due, uno per ogni bitplane; con 4 bitplane ne sarebbero serviti 4, ovviamente.

  • # 26
    sandro
     scrive: 

    be’ se implementavi i registri interni a 32bit tipo 68k,risolvevi gia’ dall’inizio,lo so che anche in questo “modo” aumentavi la memoria richiesta.ma con questa attenta progettazione,ti trovavi “pronto” per il passaggio ai veri 32bit.cosa ne pensi?

    ciao
    Sandro

  • # 27
    Saverio Russo
     scrive: 

    Una modalità video a tile e una modalità chunky avrebbe aiutato parecchio. Specialmente per le conversioni di giochi da console. Raddoppiare la banda della DRAM e magari un DSP Motorola 56001 (tipo quello montato sull’Atari Falcon) avrebbe fatto il resto.

    Io, più che estendere le modalità video preesistenti avrei dato più varietà…

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

    Il contesto era riferito principalmente al 1985, e all’epoca la soluzione dei bitplane la ritengo ottima, tranne per le critiche che ho mosso e motivato nell’articolo.

    Roba come le tile avrebbero sicuramente fatto comodo, ma esclusivamente i giochi. Nell’Amiga la tendenza è sempre stata quella di utilizzare il Blitter, visto che c’era, per disegnare le tile.

    Per il DSP, era stato già previsto dal buon Dave Haynie, ma cassato dagli espertoni manager della Commodore (tanto per cambiare).

    @sandro: l’Amiga era una macchina con bus dati esterno a 16 bit, per cui non avrebbe avuto senso adottare registri (e relativo bus dati) a 32 bit, perché la CPU avrebbe comunque dovuto effettuare due accessi alla memoria.

    Fare diventare quei registri a 32 bit lo si sarebbe potuto fare anche dopo (buona parte lo erano già), realizzando un chipset con quel bus dati in modo da sfruttarne le caratteristiche. Ma ovviamente Commodore se n’è ben guardata…

  • # 29
    Sergio
     scrive: 

    Prima cosa Tanti Auguri Amiga!!!
    Poi tanti complimenti per gli articoli di Cesare Di Mauro, sempre competenti e ben incentrati nel periodo.
    Infatti, e quest’ultima cosa che alcuni non capiscono, che Amiga nel 1985 portava nelle case di tutti a prezzi ragionevoli un Sistema con Monitor a Colori!!!, Audio Stereo a 4 Canali!!! e addirittura Genlock per il segnale video!!!!!!!!!!!!!
    Tutte cose che per un utente PC erano quasi impossibili avere (all’epoca c’era solo il CGA a 16 colori fissi) se non pagando cifre astronomiche, e tutti quei PC installati in ambito Universitario e Aziendale erano con Monitor Ambra o Fosfori Verdi (ancora tengo una parte di retina bruciata per questo :))) ).
    Per gli utenti MAC non era proprio cosa, nonostante il prezzo della macchina.

    Quindi bisogna contestualizzare la cosa quello che faceva Amiga in quel preciso momento era semplicemente incredibile per il mercato Users. Inutile parlare di aumentare la ram e o i GHz all’epoca le espansioni si compravano a 64KB alla volta e costavano quanto un intero PC di oggi, quindi ha ragione Cesare Di Mauro era semplicemente impossibile puntare sull’aumentare queste cose all’Epoca.

    Poi successivamente Amiga si è arenato il progetto AGA e uscito notevolmente in ritardo sulle aspettative e tutto il resto è storia.

    P.S. @Alex nella storia della programmazione dal C64 fino alle console come XBOX360 e PS3 dimostrano cosa possono fare i programmatori quanto possono accedere ad un HW specifico conoscendolo fino in fondo. Per far girare i Giochi su PC come funzionano sulle Console citate bisogna comprare una scheda video enormemente più potente di quelle che stanno sulle Console, questo perché i programmatori le spremono al massimo, mentre l’HW per PC non viene usato neanche per il 60% delle sue potenzialità

  • # 30
    TheKaneB
     scrive: 

    @Sergio: sul discorso dei giochi che sfruttano o meno l’hardware, ti posso assicurare che anche in giochi di altissimo livello le console vengono sfruttate al 50-60% delle loro reali capacità. Ormai vengono programmate come se fossero dei PC, nè più nè meno… (parlo per esperienza :D )
    Ormai tutte le console possiedono un sistema operativo multithreaded, si programmano tranquillamente in C++, hanno quasi tutti eliminato l’hardware 2D, quindi adesso anche la grafica dei giochi 2D viene fatta con poligoni e texture (pratica oscena, IMHO) usando librerie grafiche ad alto livello molto simili ad OpenGL. Queste somiglianze con i PC portano a scrivere strati su strati di wrappers sui quali viene poi scritto il gioco vero e proprio, consumando così enormi quantità di cicli di CPU solo per far girare numerosi layers di astrazione.

    E’ il prezzo da pagare per avere un gioco che i Publishers possano trovare appetibile, e cioè un gioco con costi di sviluppo contenuti e piattaforma di vendita più ampia possibile (scrivi una sola volta il codice e compili per 3 piattaforme, differenziandole al più per la risoluzione delle texture i livelli di LOD della geometria)…. Insomma, ormai è uno schifo anche sulle console…

  • # 31
    Sergio
     scrive: 

    @TheKaneB

    Ovviamente sono daccordissimo con te il mio intervento non voleva essere troppo tecnico.

    Però sulle consoles gli “Engine” come vengono chiamati i tools di sviluppo e di gestione della grafica, converrai con me, sono ovviamente più ottimizzati poiché i programmatori non devono sottostare alla necessità che c’è sui PC di essere compatibile con miriadi di GPU anche molto diverse tra loro. Anche su una XBOX o su una PS3 si può scavalcare il SO accedendo direttamente al HW. Gli stessi programmatori Sony e Microsoft sono avvantaggiati nell’ottimizzazione dei driver OpenGL e simili.

    Con questo volevo solo arrivare a dire che con una ipotetica Amiga che avesse goduto di buona salute e continuato a vivere i programmatori avrebbero sopperito ad alcune mancanze dell’HW con il loro ingegno (stò parlando ovviamente su un Amiga aggiornato nell’HW con il passare del tempo).

    Ne è la testimonianza il GEOS per Commodore64, e altri videogiochi che fecero letteralmente mettere le mani nei capelli ai progettisti della Commodore.

    Comunque W Amiga per quello che ha rappresentato.

  • # 32
    sandro
     scrive: 

    be’ effettivamente parla di piu’ mhz,ram ect con gli oggi di adesso e’ facile.pero’ vedendo L’hw di Amiga,quando usci,alcune parti sembravano tirate li…e qui ci stiamo un po’ divertendo a speculare..
    per quel che riguarda le consolle tipo XBOX360 e ps3,vi posso garantire che sono state abbastanza spemute per bene(programmandole,lo so bene…).guardate gli ultimi giochi usci.fanno paura!

    ciao
    Sandro

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

    In realtà l’articolo non verteva su “speculazioni”, ma nasceva per evidenziare alcuni difetti o mancanze con l’occhio di un (pignolo) programmatore di basso livello.

    Se ci fate caso non ho mai parlato di Mhz, bus esterni a 32, 64 o più bit, memorie VRAM, o caratteristiche aggiuntive (altri blitter, DSP), ma semplicemente del funzionamento interno del chipset e di come si sarebbe potuto sfruttare meglio.

    Un articolo di “speculazioni” onestamente non so che senso avrebbe. Penso che ognuno possa dare libero sfogo alla fantasia e tirare i numeri al rialzo, ma non è un approccio che fa per me.

  • # 34
    Saverio Russo
     scrive: 

    “Il contesto era riferito principalmente al 1985, e all’epoca la soluzione dei bitplane la ritengo ottima, tranne per le critiche che ho mosso e motivato nell’articolo.”

    La soluzione dei bitplane serviva a risparmiare spazio (prezioso per l’epoca) e banda passante. Ma lo stesso Sega MasterSystem utilizzava un sistema a tile i dati delle quali però divisi a bitplane!!!

    Il contesto di cui parli lo conosco bene visto che ho iniziato a sviluppare a livello hardware giusto un paio di anni prima.

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

    Il MasterSystem non aveva un Blitter, mentre l’Amiga sì, come avevo detto prima.

    Tile e Blitter non vanno molto d’accordo. Nel primo caso un sistema affianca un buon numero di sprite.

    Nel secondo ci si affida al Blitter per tutto, quindi per visualizzare sia le tile che i BOB (Blitter OBject: sprite realizzati in software via Blitter). Gli sprite sono un surplus che può essere benvenuto; infatti nell’Amiga ci sono (sebbene limitati, come ho scritto appunto), ma la maggior parte della grafica in movimento era opera del Blitter.

    Quanto ai bitplane, non ho detto che l’Amiga era l’unico a implementarli per risparmiare spazio. Per dire, anche l’Atari ST ne faceva uso.

    Inoltre, e chiudo, il MasterSystem nasceva come console (dove tile e sprite erano diffusi), mentre l’Amiga no (è più simile al Commodore 64).

  • # 36
    Saverio Russo
     scrive: 

    “Il MasterSystem non aveva un Blitter, mentre l’Amiga sì, come avevo detto prima.”

    Il Nintendo DS ha la gestione a tile, il Sega Saturn pure, il PCEngine, il Gameboy/Color… anche il tuo citato Commodore 64 ce l’aveva, l’MSX, l’home computer sul quale ho iniziato a sviluppare in assembler (SEGA SC-3000) ce l’aveva… beh?

    Avere una gestione a tile (uno o più background a costo zero) ed avere ANCHE il blitter sarebbe stata un’idea così malvagia?
    Ovvio che mi sto riferendo alla possibilità di convertire giochi, altrimenti probabilmente inutile.

    “Tile e Blitter non vanno molto d’accordo. Nel primo caso un sistema affianca un buon numero di sprite.”

    Il problema dell’Amiga era fare giochi convertiti da console a “costo zero”. O riuscivano male con pochi colori oppure erano frutto di un gran lavoro ma non erano conversioni.

    “Nel secondo ci si affida al Blitter per tutto, quindi per visualizzare sia le tile che i BOB (Blitter OBject: sprite realizzati in software via Blitter).”

    Conosco già l’hardware di Amiga o comunque di come si usa un Blitter. Grazie per le info cmq.

    “Gli sprite sono un surplus che può essere benvenuto; infatti nell’Amiga ci sono (sebbene limitati, come ho scritto appunto), ma la maggior parte della grafica in movimento era opera del Blitter.”

    Prendendo spunto dalle DRAM ti dico:

    Grazie per avermi ancora una volta “rinfrescato” la memoria… ma praticamente quasi tutto quello che scrivi non mi è nuovo.

    Volevo solo un punto di vista diverso, non un tentativo di lezione di software a livello macchina. :P

    “Inoltre, e chiudo, il MasterSystem nasceva come console (dove tile e sprite erano diffusi), mentre l’Amiga no (è più simile al Commodore 64).”

    Ripeto: il C64 aveva la gestione a tile+sprite eppure veniva venduto come computer per la famiglia esattamente come l’Amiga…

    E finisco:
    il Blitter è sicuramente molto elastico, solo però sostenuto da una banda passante di memoria adeguata. Un “misero” PCEngine gestiva 512 colori su schermo “gratis” senza dover farsi il mazzo a riprogrammare la palette o “giocare” con varie copperlist.

    P.S.: tanta gente che sviluppava nella “scena” (se sai cosa intendo) ti legge, prova ad essere meno “docente” e più “informativo” anche se oggigiorno è più facile trovare programmatori che “coders”…

    Complimenti per il buon dettaglio negli articoli. Mi piace.

    Saluti

    SiRioKD

  • # 37
    Saverio Russo
     scrive: 

    A quando un bell’articolo dei tuoi sulla GUS?

    Ne ho ancora una bella funzionante!!! :)

  • # 38
    Sergio
     scrive: 

    Perchè ogni volta che si scrive in un Forum la si deve prendere sul piano personale?
    I Forum nascono proprio per questo, per uno scambio di Idee e non perché qualcuno vuole insegnare al mondo.

    Facendo scambio di Idee il genere umano si è evoluto.
    Tutto quello che uno scrive e ovviamente il suo parere personale su un argomento, è ovvio che essendo personale non è uguale ai pareri degli altri.

    Altrimenti dovremo iniziare a scrivere dei Post come Massimo Troisi e Roberto Benigni nella famosa lettera a Savonarola nel fim “non ci resta che piangere”;

    Scusa le Volgarità… eventuali.

    Il Blitter serviva ad Amiga per la gestione a finestre del Sistema Operativo. Gli sprite per muovere il cursore del mouse.
    Amiga era principalmente un Computer e non una Console. Quindi le scelte dei progettisti erano state fatte per perseguire questa strada. Tutta bravura dei Programmatori ad usare tali caratteristiche per “clonare” videogiochi da Bar.

    Anche i PC con Windows che sono i computer “professionali” per eccellenza sono sfruttati per fare videogiochi, ma questo non significa che chi li ha costruiti voleva mettersi in concorrenza con le consoles.

    L’errore dei Managers Commodore è stato proprio quello di non far capire alla gente le grandi potenzialità di un Computer con quelle caratteristiche tecniche e costo per l’uso professionale. Infatti, come si legge avvolte nei post ancora oggi, si sottovaluta tale uso da parte di Amiga.

    Per il fatto che le consoles siano spremute a dovere, non avevo dubbio; nella “storia” è sempre avvenuto, infatti, l’esempio delle consoles l’avevo fatto proprio per dimostrare che un programmatore avendo a disposizione un HW fisso lo sfrutta al 120% delle sue specifiche originarie.

    Per quanto riguarda il tono “Didattico” di Cesare Di Mauro, penso sia obbligatorio quando si scrivono degli articoli; non potendo conoscere a priori il Curriculum di chi andrà a leggerli.

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

    @Saverio Russo

    Il Nintendo DS ha la gestione a tile, il Sega Saturn pure, il PCEngine, il Gameboy/Color… anche il tuo citato Commodore 64 ce l’aveva, l’MSX, l’home computer sul quale ho iniziato a sviluppare in assembler (SEGA SC-3000) ce l’aveva… beh?

    Che le console avessero le tile è ovvio: era il sistema migliore all’epoca, specialmente per risparmiare spazio (e per gestire schermi “mobili”).

    Ma l’Amiga non era una console. Il suo accostamento al Commodore 64 riguarda il fatto che non fosse, appunto, una macchina esclusivamente da gioco, ma orientato alla famiglia o al piccolo business.

    Tra l’altro come prezzo era decisamente elevato (1600$ alla sua introduzione), per cui il target era tutt’altro.

    Avere una gestione a tile (uno o più background a costo zero) ed avere ANCHE il blitter sarebbe stata un’idea così malvagia?

    No, ma l’Amiga non era una console. Certamente si portava dietro l’esperienza di Jay Miner in questo campo, ma proprio il Blitter è l’elemento chiave che distanzia questa macchina da tutto il resto.

    Personalmente mi piace definirla “workstation casalinga”. ;)

    Ovvio che mi sto riferendo alla possibilità di convertire giochi, altrimenti probabilmente inutile.

    Chiaro.

    Il problema dell’Amiga era fare giochi convertiti da console a “costo zero”. O riuscivano male con pochi colori oppure erano frutto di un gran lavoro ma non erano conversioni.

    L’Amiga è stata anche una fucina di giochi nuovi. Di capolavori poi esportati in tanti altri formati, console incluse.

    Sulle conversioni ci sono alti e bassi. Penso al programmatore di Lion’s King, che dichiarò pubblicamente di odiare il Blitter, perché troppo abituato alle console (con tile e sprite, appunto), e i risultati si videro, infatti. Ma roba come Silkworm, Super Hang-on, Space Harrier, PacMania, ecc. dimostrano che con un po’ di impegno i risultati potevano essere notevoli e indistinguibili dagli originali.

    Ripeto: il C64 aveva la gestione a tile+sprite eppure veniva venduto come computer per la famiglia esattamente come l’Amiga…

    L’Amiga era qualcosa di più. Mi riferisco sempre al periodo della sua introduzione. E’ il 1000 che identifica questa macchina e il suo target. Roba come il 500, che è stato la versione “home” (quindi per le masse), è arrivata 2 anni dopo.

    E finisco:
    il Blitter è sicuramente molto elastico, solo però sostenuto da una banda passante di memoria adeguata.

    Purtroppo questo era anche il suo grosso limite: non c’era abbastanza banda. Ma i trucchetti per sfruttarla per bene, beh, quelli non mancavano. ;)

    Un “misero” PCEngine gestiva 512 colori su schermo “gratis” senza dover farsi il mazzo a riprogrammare la palette o “giocare” con varie copperlist.

    Mi sembra anche normale: era una console e il suo hardware era stato pensato appositamente per quello scopo.

    Il Blitter dell’Amiga, invece, era pensato a ben altro. Non a caso spostare le finestre era un’operazione che calzava bene.

    Certo, si prestava bene anche per applicazioni videoludiche, grazie alla sua versalità.

    P.S.: tanta gente che sviluppava nella “scena” (se sai cosa intendo) ti legge, prova ad essere meno “docente” e più “informativo” anche se oggigiorno è più facile trovare programmatori che “coders”…

    Complimenti per il buon dettaglio negli articoli. Mi piace.

    Saluti

    SiRioKD

    Grazie per i complimenti. La scena la conosco, ma in tutta onestà ho avuto un rapporto di amore e odio nei suoi confronti.

    Da una parte mi piaceva vedere quello che riuscivano a fare (e da lì sono spuntati anche tanti buoni programmatori).

    Dall’altra ho sempre pensato che fosse uno spreco di risorse e le loro energie avrebbero potuto essere convogliate in qualcosa di più utile. D’altra parte ognuno deve sentirsi libero di fare quello che gli piace. ;)

    Comunque al momento i miei articoli hanno un taglio divulgativo (non poteva essere altrimenti, visto il target di Appunti Digitali).

    Viste le richieste che ho avuto in passato, penso di realizzarne qualcuno che scenda nei dettagli della programmazione dell’hardware dell’Amiga, spiegando anche qualche trucchetto eventualmente.

    A quando un bell’articolo dei tuoi sulla GUS?

    Ne ho ancora una bella funzionante!!! :)

    Era una scheda su cui, passando al PC, ho sbavato non poco, ma purtroppo conosco soltanto le sue caratteristiche di targa.

    Penso che Raffaele Fanizzi, che è più esperto in materia, prima o poi ci regalerà un bell’articolo in proposito. :P

  • # 40
    Saverio Russo
     scrive: 

    @ Sergio
    Nessuno offende o si sente offeso. Era solo un consiglio. Sai, purtroppo noi “coder” abbiamo il brutto vizio di essere convinti di essere sempre i migliori. Fa parte della nostra razza essere così. :P Ma è quando c’è collaborazione che escono fuori buone cose.

    @ Cesare
    Se ti può far comodo, a suo tempo ho sviluppato a basso livello sulla GUS (sia GF1 che Interwave)… il mio “attaccamento” allo sviluppo hardware mi ha portato prima a sviluppare qualche emulatore e ora sono entrato nel mondo degli FPGA… :)

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

    In questo caso se te la senti, qualche articolo lo potresti scrivere anche tu. :)

    Contatta la redazione all’indirizzo che trovi poco sopra il bottone “Commenta!”.

  • # 42
    Sisko212
     scrive: 

    E’ incredibile che ancora a distanza di anni si stia ancora parlando di amiga in termini così tecnici…
    Complimenti per l’articolo ben spiegato e con dettagli per me inediti su quella macchina da me tanto amata.
    … m’è venuta voglia di tirarla fuori… credo che stasera la riaccenderò, piangendo sugli anni passati e sul tempo che gli ho dedicato (invece di studiare e di andare a ragazzine :-) :-) )

    p.s.
    sia gloria al fu Jay Miner…

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.