Amiga: basta la parola. Non credo di sbagliare se, parafrasando un celeberrimo spot televisivo, affermo che queste cinque lettere rievocano nell’immaginario collettivo una macchina che, come preannunciato nel titolo dell’articolo, è saldamente ancorata alla storia dell’informatica.
Alessio ci ha già deliziato con un paio di articoli sui modelli 1000 e 500, descrivendoli a 360° fra storia, strategie sbagliate, software e hardware. Io mi soffermerò su quest’ultimo aspetto, che ne ha rappresentato la punta di diamante grazie al connubio fra grafica e sonoro che ancora oggi è rimasto impresso nella mente di chi ha potuto goderseli fra la miriade di giochi, demo, e musiche (realizzate coi famosi mod player).
L’Amiga nasce in un momento di forte fermento sulle nuove tecnologie da portare “a casa”, alla massa, con gli home computer che hanno fatto da apripista. Di questo ne è pienamente cosciente la Hi-Toro (azienda che iniziò il progetto, all’epoca nota come produttrice di joystick e cartucce), che però voleva qualcosa di più: un computer con una elevata potenza di calcolo, ma con spiccate capacità videoludiche.
A concretizzare questa visione sarà poi il padre del chipset dell’Amiga, quel genio di Jay Miner che precedentemente aveva realizzato il chip grafico di una delle più gettonate console di tutti i tempi: l’Atari 2600. Ed è sicuramente dal suo precedente lavoro che Jay ha tratto ispirazione per la realizzazione dei tre chip (chiamati Agnus, Paula e Denise) che costituiscono il primo chipset dell’Amiga, l’OCS (Original Chip-Set; in seguito chiamato anche Old Chip-Set con l’avvento dell’ECS prima e dell’AGA o AA poi).
Nell’OCS ritroviamo parecchi elementi già presenti nelle console dell’epoca (sprite, multischermo, scrolling, coprocessore per le display list, DMA) come pure nelle workstation (blitter, audio PCM multicanale), ma Jay Miner, forte della sua esperienza, ha saputo sapientemente ripensare e implementare tutto ciò in questa favolosa architettura, che per parecchio tempo ha rappresentato il punto di riferimento tecnologico per gli altri sistemi (che offrivano poco o nulla; ogni riferimento ai PC non è casuale).
Il cuore dell’OCS era Agnus, il chip che si occupa di gestire l’accesso alla memoria sia per i componenti del chipset, che per la CPU (regolandone opportunamente gli accessi), e al cui interno integra due coprocessori che hanno rappresentato la “bandiera” dell’Amiga: il Copper e il Blitter.
Il primo è un processore dedicato al solo scopo di coordinare l’impostazione dei registri dei chip custom col movimento del pennello elettronico, ed eventualmente tenendo conto anche dello stato del Blitter.
L’idea di base era quella di poter manipolare a proprio piacimento (entro i limiti di tempo e risorse disponibili) i registri in base alla posizione dello schermo correntemente disegnata dalla circuiteria video in modo da poter, ad esempio, cambiare i colori utilizzati (aumentandone il numero).
Inutile dire che quando un programmatore si trova di fronte a un ulteriore elemento programmabile, fantasia e immaginazione prendono il sopravvento su come poterlo sfruttare, e vi posso assicurare che il Copper è stato impiegato per gli usi più disparati.
Il concetto di unità dedicata al veloce spostamento di blocchi di memoria (forma rettangolare), applicando magari delle funzioni logiche, sta invece alla base del Blitter. Già all’epoca esistevano dispositivi similari, ma andando a leggere qualche buon libro sulla computer grafica che tratta della grafica raster è possibile notare in maniera lampante come in questo componente siano stati concretizzati gli studi in materia.
Il Blitter permetteva, infatti, non soltanto di copiare dati da una zona di memoria a un’altra, ma applicare anche delle funzioni logiche e di mascheramento dei dati, mediante appositi registri. Durante la copia era anche possibile “riempire” delle zone di memoria (avete presente il classico strumento “secchiello” presente in programmi come il Paint? Il principio è quello).
In più era dotato anche di un algoritmo di tracciamento delle linee (a cui era possibile applicare anche un pattern) in hardware, che venne poi utilizzato per generare i contorni dei poligoni della grafica 3D.
Denise si occupava, invece, della generazione della grafica, integrando anche la logica per la gestione degli sprite. Alla base troviamo il concetto di bitplane, cioè di un’area rettangolare di bit (lo stesso tipo di dato su cui lavorava il Blitter) che ovviamente possono essere soltanto a 1 o 0. Denise poteva gestire fino a 6 bitplane in totale, combinandoli opportunamente ma con delle particolari restrizioni, per ottenere poi lo schermo o gli schermi da visualizzare.
Tralasciando al momento la trattazione dei bitplane (che affronterò in futuro), mi limito a dire che l’impiego dei bitplane era molto diffuso all’epoca perché permettevano di far risparmiare memoria per gli schermi, in quanto consentiva di definire in maniera precisa lo spazio da utilizzare per visualizzare immagini con un certo numero di colori (sempre per potenze di due): 2, 4, 8, 16, 32 o 64 colori richiedevano, infatti, 1, 2, 3, 4, 5 o 6 bitplane.
In realtà Denise aveva soltanto 32 registri per i colori (selezionati da una palette di 4096: 16 colori per ogni componente cromatica dello spazio RGB), e i 6 bitplane venivano utilizzati soltanto per delle speciali modalità di visualizzazione, il più famoso dei quali era l’HAM (Hold-And-Modify), che consentiva di visualizzare tutti e 4096 colori, sebbene con delle precise limitazioni.
Meno noto dell’HAM era l’EHB (Extra Half-Brite), col quale si arrivava a visualizzare 64 colori, anche se con la limitazione che gli ultimi 32 fossero uguali ai primi, ma con luminosità dimezzata. Sfortunatamente non era presente nei primissimi modelli di Amiga commercializzati, ma comunque fu utilizzata in alcuni giochi (ne parlerò più approfonditamente quando racconterò la storia di Perpetual Craze, poi commercializzato col nome di Fightin’ Spirits, gioco alla cui realizzazione ho partecipato in qualità di additional coder, e che fa proprio uso di questa modalità).
Chi ha avuto modo di conoscere l’Amiga avrà invece apprezzato l’uso che i programmatori hanno fatto della modalità a 6 bitplane (ma era possibile utilizzarne anche meno) denominata dual-playfield, che permetteva di visualizzare ben due schermi indipendenti, sebbene con la limitazione di soli 8 colori (7 per lo schermo frontale, perché il primo “colore” veniva utilizzato per “forare” lo schermo e visualizzare la grafica di quello sottostante). Anche qui, ogni riferimento a Shadow of the Beast non è affatto casuale…
La risoluzione normalmente utilizzata era la 320×200 (per gli Amiga NTSC) e 320×256 (per quelli PAL), ma era possibile sfruttare anche quella che veniva definita come alta risoluzione, cioé la modalità che permetteva di raddoppiare il numero di pixel orizzontali (arrivando a 640), purtroppo con la pesante limitazione del numero massimo di colori che si riduceva a 16 massimo.
Anche verticalmente era possibile raddoppiare la risoluzione (a 400 o 512 linee rispettivamente), facendo ricorso all’interlacciamento, ma col non trascurabile effetto “sfarfallio” dell’immagine che alla lunga poteva diventare stancante. A tutto ciò si aggiungeva il fatto di utilizzare anche i bordi dello schermo (overscan) permettendo quindi di visualizzare immagini con risoluzioni più elevate (ad esempio 704×480 e 704×576, impiegate per le trasmissioni televisive), come pure il supporto ai cosiddetti genlock per miscelare la grafica dell’Amiga con quella di una sorgente video esterna.
Infine, per quanto riguarda gli sprite, ne poteva visualizzare fino a 8 contemporaneamente, ma con soli 4 colori ciascuno (in realtà 3: il primo veniva sempre utilizzato per “forare” lo sprite e visualizzare la grafica sottostante), che divenivano 16 (15 per quanto detto prima) “accoppiandone” due (quindi al massimo 4 sprite a 16 colori), fornendo anche la possibilità di decidere dove visualizzarli nella modalità dual playfield (davanti al primo schermo, in mezzo fra primo e secondo schermo, dopo il secondo) e le eventuali collisioni fra gli sprite, o fra questi e la grafica dei playfield.
La cosa molto strana ma interessante degli sprite dell’Amiga era la loro risoluzione verticale: praticamente illimitata. Quindi mentre orizzontalmente erano larghi 16 pixel, verticalmente potevano arrivare a coprire anche l’intera area visiva, e ciò è risultato molto utile e comodo, specialmente in giochi come Robocod (capolavoro assoluto che spero di vedere presto su Appunti Digitali) che ne ha fatto il suo punto di forza.
Sebbene per la sola grafica abbia speso parecchio spazio e parole, non meno importante è stato il comparto audio dell’Amiga, a cui faceva capo Paula. Questo chip permetteva di generare fino a 4 segnali sonori, sfruttando la già menzionata tecnologia PCM, che consisteva nella riproduzione a una certa frequenza (poco meno di 29Khz massimo) di campioni audio digitali a 8 bit, che venivano poi convertiti in segnale analogico tramite appositi DAC.
Ogni canale era completamente indipendente dall’altro, ed era possibile applicare quindi un volume diverso (fino a 64 livelli), come pure effetti come il loop (la ripetizione di porzioni dello stesso campione) o la concatenazione (di più campioni diversi). Inoltre era possibile che un canale ne modulasse in frequenza o ampiezza un altro, in modo realizzare ulteriori effetti sonori.
Per superare il limite dei 29Khz (imposti dal DMA) Paula permetteva di caricare direttamente i campioni audio negli appositi registri, consentendo quindi di raggiungere frequenze molto più elevate e limitate esclusivamente dalla velocità della CPU. Oltre ai campioni audio era possibile impostare direttamente anche il volume, permettendo quindi di riprodurre campioni a 14 bit. Queste tecniche vennero impiegate in programmi come AudioMaster, molto famoso all’epoca per l’editing audio.
A Paula faceva capo anche la gestione degli interrupt, che venivano estesi dai 7 del 68000 a 14 tramite l’utilizzo di appositi registri (in pratica ad alcuni dei 7 livelli venivano associati più interrupt; ad esempio all’interrupt 4 erano collegati tutti e 4 gli interrupt generabili dai 4 canali audio).
Oltre a ciò, si occupava anche del movimento del mouse, delle leve dei joystick (mentre i rispettivi pulsanti erano collegati ad altri chip periferici della Commodore, chiamati CIA) e delle paddle, ma soprattutto della lettura e scrittura dei dati dal disco.
Un’altra caratteristica particolarmente interessante dell’Amiga era il fatto che sostanzialmente non era dotato di alcun controller dedicato alla gestione dei dischi, a parte una logica minimale per agganciare il segnale di sincronismo (la cosiddetta syncword, o magicword: $4489 in esadecimale) utilizzato per allineare la lettura dei dati.
In pratica l’intera gestione era a carico del programmatore, che si doveva occupare di pilotare i segnali (direttamente mappati in alcuni chip periferici) per accendere il motore, aspettare che fosse pronto per lavorare, inviare i giusti impulsi per far spostare la testina, aspettare che fosse correttamente posizionata, programmare Paula chiedendole di intercettare la syncword, e infine far partire il DMA del disco non appena questa fosse rilevata.
Se ciò era un male (sui PC, ad esempio, il controller si occupa di tutte queste operazioni, sgravando quindi il programmatore), era anche uno strumento flessibilissimo, visto che dava la possibilità di gestire il disco curandone ogni aspetto, codifica dei dati inclusa (che era sempre a carico del programmatore), ed era anche possibile scegliere fra il formato MFM (utilizzato nei dischi più recenti) o il GCR (nei vecchi floppy, come quelli di Commodore 64 & compagnia) con cui erano memorizzati fisicamente i dati.
Questo significa che l’Amiga era potenzialmente in grado di leggere e scrivere qualunque tipo di formato utilizzato per i dischi. Infatti oltre a un suo formato da 880KB, era perfettamente in grado di leggere e scrivere il formato da 720KB di PC e Atari ST, quello da 800KB degli Archimedes, e buona parte degli 800KB di quelli dei Mac (siccome alla Apple si dovevano sempre “differenziare”, adottavano un controller tutto particolare che variava la velocità di rotazione in base alle zone del disco). Ovviamente i programmatori di giochi si sono sbizzarriti (io sono arrivato a stoccare 1029KB su singolo disco; anche di questo ne parlerò in futuro).
Per quanto riguarda l’hardware dell’Amiga ci sarebbe ancora da parlare dei famigerati CIA, chip dedicati all’I/O (tastiera, pulsanti del joystick, linee di controllo dei floppy, porta seriale e parallela) e ai timer programmabili, che erano derivati dagli omonimi utilizzati nel Commodore 64 , quindi non frutto del lavoro di Jay Miner e in generale delle innovazioni che sono state portate dall’Amiga, per cui al momento mi fermo qui, per riprendere più avanti le evoluzioni che sono state fatte e quelle che, purtroppo, non ci sono mai arrivate.
bellissimo articolo…
Cosa dire, ho posseduto una serie di Amiga, passando dal 500, 2000 e infine 1200. E’ stato un computer che ha fatto la storia e che ha saputo fare sviluppare la creatività di chi lo usava.
Non a caso mi dedicavo al ray tracing e alla musica, sia con mod player che MIDI. E’ un peccato che la Commodore non abbia saputo andare avanti nel modo giusto. A quest’ora non avrei un PC a casa, ma un nuovo Amiga…
Articolo fantastico, grazie mille…
Ho ancora una lacrimuccia di nostalgia a pensare ai pomeriggio passati con Street Fighter, Ghost ‘n Goblins e compagnia bella…!!!
Speriamo di leggere presto il “seguit”!
Grazie ancora
Herger
Grazie per l’ottimo articolo.
Complimenti per l’articolo e per aver lavorato a Fightin’ Spirits peccato che quei giochi su Amiga fossero decisamente limitati dai controlli, concordo su Robocod era splendido(sia come gioco che visivamente) non so perchè fosse così snobbato e venissero idolatrate altre ciofeche di team più rinomati..
L’algoritmo di tracciamento delle linee sarà quello che hanno usato i spaceballs in state of art per disegnare quella specie di griglia 3d vista dall’interno ?
Ho un’idea. Partendo da questo video proprio della demo degli spaceballs http://www.youtube.com/watch?v=fPSst20JEcE non si potrebbe cercare di descrivere quali parti del chipset stanno operando in modo magari da facilitare la comprensione delle funzioni delle parti in gioco ?
Per noi utenti pc moderni, abituati a schedone video con tantissima vram suona difficile capire cosa si può fare 4 sprite o questa storia dei bitplane che in qualche modo risultano essere diversi dai livelli di parallasse come vengono intesi adesso.
Credo che l’articolo ne guadagnerebbe parecchio in comprensione.
splendido articolo, sono andato a ripescare dalla mia libreria il manuale dell’hardware dell’amiga…
programmare in assembler era splendito nel 1990…
programmare l’amiga era splendido…
altro che gli OS di oggi…
su un’altro articolo si parlare di os real time…
l’hardware e il kickstart dell’amiga era realtime…
il copper è stata una trovata stupenda…..un piccolo coprocessore risc nascono nel chipset…
splendido….
moltisistemi di oggi dovrebbero imparare da questa architettura…
Ebbastaaa con questi articoli!!! Non se ne può più!!! MI FATE PIANGERE!!!! ;D
Seriamente: grazie per tenere vivo il ricordo dell’Amiga, ottima “sorvolata” sull’OCS! :)
Però credo che il floppy fosse gestito direttamente da Paula, se non ricordo male…
@D
In quella parte di SOTA credo sia usato il blitter per riempire le aree, non per tracciare le linee. L’intera struttura 3D è precalcolata (sempre se non ricordo male…)
Comunque SOTA è una delle demo più sopravvalutate della storia (molto “rumore”, poco codice!), non c’è molto da spiegare… molto meglio Desert Dreams dei Kefrens sotto questo punto di vista! :)
Sti articoli mi piacciono sempre! commodore e amiga mi sn rimasti proprio nel cuore…….che peccato nn esistano più!!! Certo che alcuni giochi anche se vecchissimi sn sempre divertenti e nn smetterei mai di giocarci!!!!
“L’intera struttura 3D è precalcolata”
E non solo. In quella demo ci sono diversi punti interessanti da comprendere.
1- Le donnine e l’acrobata hanno come delle scie: sono stati utilizzati dei bitplane ?
2- I cerchi che coprono lo schermo sono proprio dei bitplane con un colore “che buca lo schermo” ?
3- La struttura 3D di prima…
Al giorno d’oggi sarebbe facile: tanti sprite per le donnine, poligoni a manetta, gif… OMG al semplice costo di avere minimo un PIII per non scattare. Non parliamo poi di certe demo moderne che realizzerebbero tutto con i shader.
@Fabio: la cosa che mi dà più fastidio è che dopo tutto il lavoro che ho fatto e i risultati che ho reso possibili, non mi hanno citato nemmeno nei credit di Fightin’ Spirits.
Comunque è vero che col classico joystick con un solo pulsante realizzare qualcosa di interessante come controllo in giochi come i beat’em up era molto difficile, ma qualcosa di più si poteva fare. Ne parlerò meglio quando tratterò l’argomento joystick.
@D: non so quali tecniche abbiano usato per SotA, ma nell’ambito dell’Amiga circolava un detto molto famoso. “Il precalcolo è alla base del realtime”. Per cui credo che molte delle animazioni fossero prerenderizzate, facendo uso anche del classico dual playfield per sovrapporre gli effetti.
Ovviamente utilizzavano i bitplane, anche perché nell’Amiga non c’era altro. Le modalità “chunky pixel” arrivarono soltanto dopo, ma “emulate” col Copper e con delle limitazioni.
In ogni caso non ti preoccupare: ho intenzione di trattare approfonditamente come funzionavano i singoli componenti dell’Amiga, e in che modo si realizzavano i giochi. In particolare parlerò estesamente di Fightin’ Spirits, e soprattutto dell’altro gioco a cui stavo lavorando come unico coder e che non è mai uscito, USA Racing (gioco di macchine visto dell’alto ispirato fortemente a Trash Rally per Neo Geo). E ci sarà spazio anche per parlare del parallasse “alla Street Fighter II”, che avevo realizzato per il primo gioco e che non è stato mai implementato (come pure un altro effetto spettacolare che avevo ideato e non fu mai implementato).
@jpx: il floppy, come dicevo nell’articolo, non era gestito direttamente da Paula. Questo chip integrava alcune funzionalità utili al suo controllo, come ad esempio la logica per leggere e scrivere dati serialmente da e verso il disco, e agganciare la syncword. Ma questo lavoro lo si poteva fare anche “a mano”, come avrò modo di esporre quando tratterò il tema del funzionamento dei dischi su questa meravigliosa macchina.
Per quanto riguarda SotA, per riempire le aree bisogna prima tracciare le linee. Non credo che per i contorni della figure abbiano memorizzato l’immagine, per poi far usare il Blitter soltanto per il riempimento, perché a questo punto avrebbero potuto benissimo memorizzare l’intera immagine finale, e amen (sempre per il discorso del precalcolo). A mio avviso avranno memorizzato esclusivamente le coordinate dei punti che formano le linee delle figure, per poi tracciare le linee, e infine riempire col Blitter le aree createsi.
Ne approfitto per ringraziare tutti per i complimenti.
““Il precalcolo è alla base del realtime””
Beh, l’Amiga ed il 68000 saranno anche stati dei mostri a quei tempi ma è ovvio che molte cose non avrebbero mai potuto crearle dal vivo senza una tabella precalcolata alle spalle. C’è fior di roba che ancora oggi non si riesce a creare diversamente.
Se non sbaglio uno degli esempi più classici è proprio quello di creare prima una tabella per seni e coseni. In uno sparatutto 2D le navicelle nemiche si muovono sempre in formazioni che non sono altro che funzioni matematiche, ma vorrei vederlo un sistema stare ad impiegare orde di cicli di clock per calcolare le coordinate quando è molto più facile fissare in anticipo i punti da raggiungere.
/bow and /respect
ps: che nostalgia … cesare ma con che nick bazzicavi nella scena?
Comunque Amiga è ancora viva, fate una ricerca con google “Amiga OS4”.
Ma vi ricordate che nelle demo c’era la competizione a chi faceva girare più palle?? la demo classiche arrivavano a 5 palle… ma c’era qualche demo che ha raggiunto l’apice con 6 o addirittura 7! :D
“Amiga è ancora viva”
Anche un moribondo collegato al polmone d’acciaio è tecnicamente “vivo”
Di sicuro le attuali incarnazioni di amiga non hanno ereditato niente della vecchia (tranne i difetti s’intende)
“A mio avviso avranno memorizzato esclusivamente le coordinate dei punti che formano le linee delle figure, per poi tracciare le linee, e infine riempire col Blitter le aree createsi.”
Esattamente! Ho fatto un po’ un riassunto in malo modo: intendevo dire che tutte le sequenze del ballo sono animazioni tracciate in vettoriale e suppongo riempite col blitter (che è usato anche per l’effetto scia delle stesse), mentre la sequenza 3D ha le coordinate dei punti precalcolate (e il solito blitter per linee/aree e scia – gli Spaceballs usarono tecniche simili anche in altre demo come “9 Fingers” e “Mobile Destination Unknown”).
Comunque solo supposizioni le mie, non sono un guru dell’assembly Amiga… posso chiedere conferme all’unico coder superstite degli Spaceballs in caso. Sto andando off-topic e la chiudo qui! :)
@D: sì, è esattamente così che si faceva.
@Giullo: non ho mai scritto demo, per cui non avevo un nick.
A onor del vero non avevo una buona opinione di chi “perdeva tempo” in questo modo. Ho sempre sostenuto che Amiga avesse bisogno di software (applicazioni in primis, e IDE modello Borland in particolare), e non demo. :D
@jpx: sono delle stessa opinione. Ma non ho rovistato nel codice degli altri, per cui non ti saprei dire.
Bellissimo articolo, non uso più l’Amiga da anni ma sempre un piacere leggere di queste cose.
Ci darai il colpo di grazia parlando anche del AAA ?
Verso la fine degli anni 90 ebbi per la prima volta l’opportunità di leggere il documento di presentazione per gli sviluppatori e nonostante fosse ormai vecchio di quasi 10 anni rimasi sbalordito, nonche rattristato da quello che avrebbe potuto fare se fosse uscito allora.
a dire il vero eravamo i reietti della scena, la scena cracking non era ben vista (a parte i primi anni iniziali), tanto che c’erano diversi gruppi che rivendicavano orgogliosamente (e legittimamente) la scelta di essere “legal only” … col senno di poi si può dire che la scena cracking sancì , assieme alle politiche disastrose di mamma commodore, la morte dell’amiga, ma questo potrebbe essere il tema di una puntata di AD :)
saluti, g
Non credo che ne parlerò io (forse Alessio), perché non ero addentrato in queste tematiche.
@Carlo: si, ho intenzione di parlare anche dell’AAA, descrivendone le caratteristiche tecniche e qualche mia riflessione.
Di sicuro le attuali incarnazioni di amiga non hanno ereditato niente della vecchia (tranne i difetti s’intende)
Ma parli per sentito dire?Hai un Amiga NG?Mi sa di no..
“Inutile dire che quando un programmatore si trova di fronte a un ulteriore elemento programmabile, fantasia e immaginazione prendono il sopravvento su come poterlo sfruttare, e vi posso assicurare che il Copper è stato impiegato per gli usi più disparati.”
eh, eh :)
come non citare l’effetto 3D, creato col copper in giochi come Lotus e demo come Arte, oppure il blitter usato per fare addizioni di interi pezzi di memoria…
piuttosto, l’amiga mi ha fatto venire in mente un collegamento su una recente polemica sulla memoria delle schede video ed i problemi di context switching.
ricordo che l’amiga aveva una chip ram in cui tutti potevano accedere con uno scheduler che gestiva gli accessi secondo determinate priorita’: prima il blitter, poi il copper, ed infine il povero processore, relegato in fondo alla lista delle cose importanti e che nei momenti di “traffico intenso” non poteva operare.
per questo l’amiga aveva (o meglio, poteva avere, dato che era opzionale), a fianco della chip ram, una fast ram, esclusivamente dedicata al processore. in pratica, la struttura era rovesciata: nella memoria principale operavano tutti e quello che aveva la memoria dedicata era il processore :)
@D #11
per il resto ti hanno gia’ risposto.
l’effetto scia e’ molto semplice: basta disegnare il frame successivo in un bitplane diverso e fare visualizzare tutti i bitplane insieme, cambiando naturalmente l’ordine di visualizzazione
Lo “scheduler” in oggetto era Agnus, che si occupava di fornire la giusta priorità a tutti gli accessi alla memoria. La CPU era l’ultima perché i dispositivi di cui era dotato l’Amiga erano chiaramente più efficaci di lei nell’eseguire i compiti.
Comunque c’erano 3 tipi di memoria: la chipram, la slowmem e la fastram. I vecchia Amiga 1000, 500 e 2000 avevano i primi due tipi, che sostanzialmente erano la stessa cosa, in quanto era sempre Agnus a regolare l’accesso.
In pratica quella memoria aveva gli svantaggi sia della chipram che della fastram: i chip custom non potevano accedervi, e la CPU doveva sottostare agli stessi livelli di priorità quando vi accedeva (questo significa che, ad esempio, con uno schermo 640×200 a 16 colori, durante la visualizzazione dello schermo era completamente tagliata fuori dall’accesso alla memoria).
Sulla fastram vera e propria, invece, aveva accesso esclusivo e poteva lavorare in maniera completamente distaccata dai chip custom (quindi effettivamente in parallelo).
Tutto ciò perché alla Commodore decisero di risparmiare sui costi, lasciando che fosse Agnus a eseguire il refresh della DRAM, e di conseguenza a regolarne anche l’accesso. Geniali…
Una meravigliosa annata quella dei 16 bit e sopratutto del mitico amiga … Quante nottate a giocare a titoli come BRIAN THE LION, LIONHEART, ZOOL e via dicendo …. che ricordi
Comunque ci sono e c’erano anche espansioni per la grafica … Sarebbe bello parlare anche di questo e sopratutto cosa avrebbe potuto fare con esse…. Comunque per il resto AMIGA FOREVER…
Storia…storia assoluta! Ricordi di gioventù che smuovono il cuore quasi quanto una storia d’amore! Che spettacolo… :°-)
Io ho una domanda un po’ bizzarra per Cesare o gli altri.
Amiga aveva prestazioni molto superiori ai pc e mac dell’epoca ma secondo voi in percentuale quanto di questo vantaggio era dovuto alla qualità dell’AmigaOS e quanto ai 3 chipset aggiuntivi (pc e mac invece avevano solo la cpu)?
Cioè se AmigaOS fosse stato portato su pc o mac (perdendo quindi tutti i 3 custom chip) quanto si sarebbe perso?
Dare una risposta è praticamente impossibile, perché dipende tutto dalla tipologia di applicazioni / codice.
Posso dirti che AmigaOS, anche senza i chipcustom, gira comunque molto bene su PC o Mac, tramite il progetto di “riscrittura” che si chiama AROS e che trovi su http://www.aros.org.
Puoi provare la versione live-CD, ma ti consiglio quella disponibile tramite macchine virtuali VMWare.
AmigaOS, per sua stessa natura (croce e delizia: perché i difetti non mancano di certo), è un s.o. estremamente leggero, parco di risorse, reattivo e molto semplice da usare.
“Ma parli per sentito dire?Hai un Amiga NG?Mi sa di no..”
Amiga NG ?
Ti riferisci ad uno di quei tanti prototipi vaporware inaugurati con il Walker e finiti con il fantomatico Amiga made by Gateway in una bolla di fumo ? O forse a quel affari a cavallo tra un clone mac super buggato (AmigaOne) ad una cosa attualmente ne carne ne pesce come la Sam440 ?
Sarebbe quella la New Generation di Amiga ?
Che pena…
Io sapevo che doveva uscire un amiga os5 e una nuova “macchina” cn processore sempre powerpc! se nn sbaglio la scheda madre doveva esser prodotta da un’azienda italiana (mi sa che è anche in commercio ma si trova a fatica). Cmq ormai amiga è morta nn può sperare di tornare a fare computer! l’unica sarebbe stata cercare di infilarsi in qualche mercato di nikkia, magari in smartbook oppure fare una bella versione per smartphone…..forse forse avrebbe potuto attirare l’attenzione di qualcuno ma in ambito pc purtroppo è tutto esercizio di stile! trovo a sto punto più interessante e utile il progetto AROS e se quelli di amiga (attuale) avessero capito qualcosa avrebbero collaborato cn il progetto!
Nessun amiga os 5 e l’azienda italiana alla quale ti riferisci è quella che produce proprio la SAM440.
Se la cerchi su internet capirai perchè c’è da essere poco positivi in merito al futuro di amiga.
Veramente AmigaOS continua a essere sviluppato, infatti Hyperion che ne detiene i diritti ha rilasciato da poco un update di os4.1 per la SAM prodotta da Acube e fra qualche mese ci sarà una nuova macchina.
AmigaOne X1000
ATX Formfactor
Dual-core PowerISA™ v2.04+ CPU
“Xena” XMOS XS1-L1 128 SDS
7.1 channel HD audio
4x DDR2 RAM slots
10x USB 2.0
1x Gigabit Ethernet
2x PCIe x16 slots (1×16 or 2×8)
2x PCIe x1 slots
1x Xorro slot
2x PCI legacy slots
2x RS232
4x SATA 2 connectors
1x IDE connector
JTAG connector
1x Compact Flash
http://www.a-eon.com/6.html
Anche la comunità amiga esiste ancora, provate a vedere.
http://www.amiganews.it
Bravo Jack, mi hai risparmiato la fatica. Ragazzi, questo è un hardware che potrebbe riservarci qualche sorpresa. Il chip XENA è _programmabile_, lo slot Xorro è esclusivo…
“AmigaOne X1000”
Per adesso è solo un bel progetto, anzi a conti fatti una pagina internet senza neppure uno straccio di foto figurante una dev board come almeno possiamo dire del progetto Natami.
Per carità, niente esclude che tra un po’ di tempo uscirà ma allora ci troveremo di fronte allo stesso problema che fu ai tempi dell’ AmigaOne.
Ricordo di aver letto le prime news su punto informatico e per i tempi sembrava un hardware accettabile (non eccezionale ma non da buttare), poi l’ho letteralmente persa di vista per un anno o due dalla lettura di quell’annuncio (nel frattempo, com’è logico, il resto del mondo è andato avanti) e quando uscì era lo stesso sistema annunciato due anni prima (quindi nettamente sotto la soglia di accettabilità) ad un prezzo spaventoso.
Posso solo dire questo: la si deve smettere di fare annunci trionfanti, volgarmente detto, di far ammazzare di pippe i nostalgici, dietro progetti che non hanno nemmeno uno straccio d’idea di come proporsi sul mercato. Quando va bene escono dei sistemi che riescono a malappena a stuzzicare l’interesse della gente, che non possono assolutamente fare breccia nel cuore delle persone comuni, che non hanno uno straccio di un ecosistema per poter anche incoraggiare il mercato ad interessarsi ad una soluzione alternativa al mondo wintel.
Tanto per fare un esempio: che senso ha vendere la SAM440 senza porte di connessione rimandando il tutto ad una scheda addon che alla mia ultima visita sul sito di acube non era ancora disponibile (e che adesso non riesco neppure a rintracciare, probabilmente si tratta di un progetto annullato menomando di fatto la versione flex della 440). Anzi che senso ha cercare di proporre come soluzione desktop una cosa che a conti fatti è almeno 5 generazioni (a voler essere buoni) indietro rispetto a quello che offre attualmente il mercato. Non sarebbe più logico cercare di proporre dei notebook, dei netbook con amiga incorporato ?
Alla fine qual’è il mercato di riferimento di tutto ciò ? Poche migliaia di utenti ?
AROS gira molto bene anche sui PC, e non ha bisogno di hardware particolare, quanto di driver per supportare le periferiche e di gente che riesca finalmente a completare almeno le librerie standard.
Per quanto mi riguarda trovo che sia completamente sbagliato ostinarsi a progettare soluzioni “custom” che, tra l’altro, costano un occhio rispetto a un PC, e non fornendo prestazioni e flessibilità comparabili.
Io la penso così. Comunque questo è un altro discorso, che magari verrà affrontato in un futuro articolo. Al momento è meglio tornare a parlare di OCS.
Complimenti per l’articolo.
Amiga è stato sempre sinonimo di bella grafica, di bei giochi con trama e di giornate passate con gli amici a giocarci.
Devo essere onesto, sarei felice se l’Amiga tornasse sul mercato di nicchia, come è accaduto prima per Apple.
Ora un discorso da ignorante, il supernintendo e il megadrive sono usciti dopo l’amiga, erano tutti a 16 bit con limitazioni grafiche.
Pero’ ricordo che l’amiga in molti giochi superiore in grafica alla controparte snes e megadrive.
Ricordo male io o era proprio cosi’? :)
Dipende dai giochi. Considera comunque SNES (a 16 bit) e MegaDrive (a 32 bit, come l’Amiga) avevano hardware appositamente pensato per i giochi, ed erano spesso avvantaggiati da questo punto di vista (più il SNES che il MegaDrive, comunque).
Che ricordi ragazzi! Ne ho avute diverse di “Amighe” fino all’abbandono in favore del pc quando l’azienda perse i colpi finali, che tristezza….
Quante ne ho modificate poi, preparavo i cavi ide per il cdrom esterno che non si trovavano normalmente in circolazione e inserivo gli hd da 3,5″ internamente al posto dei 2,5″ sui 1200. Mi ricordo che da un amico per tagliare il lamierino per far posto all’hd non aveva una tronchesina in casa e gliel’ho fatto con il trinciapollo che aveva la madre in cucina :-) lui sudava freddo vedendomi….. ma la scienza deve andare avanti!!!! :-)
Prima o poi l’umanità si libererà della obsoleta, nata male, vecchia architettura x86, che esiste solo in virtù di un monopolio della retrocompatibilità.
Quando ciò avverrà chissà se non si affermerà qualcosa di nuovo, ma che strizzi l’occhio alla filosofia Amiga. Almeno io spero.
Ringrazio Cesare della risposta.
Sarebbe quindi giusto dire che Amiga era un computer quad-processor con una processore generico (68000) e tre specializzati? All’epoca le schede video e audio di pc e mac si occupavano di calcoli?
Chiedo perché non sono nato in tempo per vivere quel periodo ma ho spesso sentito parlare dell’Amiga in maniera quasi mitologica. Sono del ’91 e roba come 386, 68000 etc. li ho visti solo in foto!
No, l’Amiga aveva una sola CPU con un solo core. Gli altri due (Copper e Blitter) erano soltanto coprocessori dedicati, e non erano in grado di eseguire programmi veri e propri.
Il resto è corretto: all’epoca PC e Mac dovevano fare gestire sia il video che l’audio alla loro CPU.
In effetti sei molto giovane, e all’epoca non eri ancora nato, per cui non puoi conoscere queste macchine. Potresti utilizzare degli emulatori, ma questo ti permetterebbe di provare le applicazioni e/o i giochi che giravano, ma non apprezzarli nel loro contesto, perché ai tempi la tecnologia aveva dei limiti precisi e roba come l’Amiga era veramente un gioiello tecnologico.
Immagino anche che programmare una macchina come l’Amiga fosse una sfida più interessante potendo manipolare non solo la cpu centrale come su mac/pc ma anche i 3 chipset, o sbaglio?
Ho anche sentito che Amiga aveva un ottimo multitasking, anche qui il fatto di avere i 3 chipset aiutava?
Un’ultima domanda. Le tecniche attuali di 3D calcolato dalla GPU (come nel desktop Aero di windows calcolato dalla GPU) o le schede acceleratrici di fine anni 90 (Voodoo), quanto assomigliano alle idee alla base dei chipset specializzati di Amiga?
“Immagino anche che programmare una macchina come l’Amiga fosse una sfida più interessante potendo manipolare non solo la cpu centrale come su mac/pc ma anche i 3 chipset, o sbaglio?”
A quei tempi era la norma smanettare direttamente col ferro, non ci si poteva permettere l’intercessione del sistema operativo. Adesso è diverso in virtù dell’enorme numero di combinazioni hardware possibili. Di sicuro se si potesse utilizzare adesso lo stesso metodo di lavoro avremo programmi e giochi con prestazioni 10 volte superiori a quanto siamo abituati a vedere.
“Ho anche sentito che Amiga aveva un ottimo multitasking, anche qui il fatto di avere i 3 chipset aiutava?”
Lì era merito del sistema operativo
“Un’ultima domanda. Le tecniche attuali di 3D calcolato dalla GPU (come nel desktop Aero di windows calcolato dalla GPU) o le schede acceleratrici di fine anni 90 (Voodoo), quanto assomigliano alle idee alla base dei chipset specializzati di Amiga?”
Credo poco o nulla, Amiga aveva una certa difficoltà ad elaborare il 3D per mezzo dei chip custom (le demo che elaborano scene tridimensionali in genere si appoggiano sulla cpu, a volte quella su scheda acceleratrice, o “proiettano” scene precalcolate su un fondo 2D)
Un po’ ci somigliano, perché per il 3D si utilizzava comunque il Blitter per tracciare le linee dei poligoni, e poi per riempirli con un certo pattern.
L’idea di scaricare a unità specializzate questo lavoro (anziché lasciarlo soltanto alla CPU come s’era sempre fatto), insomma, c’era, e col tempo sarebbe migliorato.
All’epoca si programmava direttamente l’hardware, e ciò era possibile perché questo era semplice da gestire, ma saperlo sfruttare bene o meno richiedeva, al solito, certe doti nel saperlo fare.
Veramente il vero succeessore dell’Amiga sta nascendo (con un nuovo chipset ‘Super AGA’ compatibile col vecchio)… il problema è che i suoi padri non hanno uno straccio di business plan né soldi. Sembra un progetto nato più per diveritmento che per costruire qualcosa di utile. Quanto rimpiango la Commodore.
Comunque lo trovate qui: http://www.natami.net/concept.htm
Lo conosco, e ne parlerò in futuro.
Tra l’altro anche sul versante CPU c’è qualche scelta che, da Motorol-Amighista, non condivido.
Ma devo ammettere che rimane, comunque, un bel tentativo. Pregevoli alcune scelte.
“il problema è che i suoi padri non hanno uno straccio di business plan né soldi”
Anche avessero i soldi, mancherebbe il resto e poi sinceramente tolti i nostalgici che mercato vorrebbe avere il natami ?
A volte mi chiedo se è così complicato cercare di mettere insieme qualcosa di attuale sfruttando quello che il mercato offre invece di cercare soluzioni strane che al massimo possono meritare un what if
Chi se ne importa del ‘mercato’… non ci dimentichiamo che la scena Amiga non è comunque morta (pur non avendo alcun reale mercato, di fatto di SAM si dice che ne abbiano vendute a centinaia.. poco o nulla) e c’è comunque gente che ci sviluppa sopra, la gran parte per divertimento ed altri invece per business.
Natami è sempre qualcosa di meglio (anzi a me come hardware eccita alquanto) rispetto a quell’accrocchio della SAM che è né più né meno un PC (una CPU, una GPU, un Northbridge, etc.). Almeno qui si ha a che fare con un hardware che rispetta la filosofia Amiga perché per me l’Amiga era l’hardware… l’OS poteva pure essere fantastico ma l’hardware era UNICO (non a caso i giochi, o alcune demo, lo bypassavano pure l’OS ed alcuni erano irreplicabili su hardware dallo stesso costo).
La CPU è una scelta essenziale se si vuole mantenere la retrocompatibilità, inoltre leggo di gente che si ‘diverte’ a programmare con i 680×0 e che detesta le architettura PowerPC o Intel (soprattutto le PowerPC perché dicono che bisogna scrivere più codice per fare le stesse cose). Ci voglio credere. Anche perché alcuni programmatori si ‘eccitano’ pensando a certe ‘eleganze architetturali’ e questo a me piace molto (come mi piace sentire parlare Cesare di alcune vecchie architetture con toni trionfalistici).
Poi una cosa che mi piace molto è che stanno sviluppando una CPU nuova su architettura 680×0, tale 68050. E trovo una cosa eccezionale avere un’architettura superottimizzata che ti permette di fare ‘quello che serve’ ed anche ‘cose turche’ con 5 miseri W (magari con un pò d’impegno si può fare un OpenOffice ad hoc, il trionfo della qualità del coding e del metallo contro la mediocrità e l’astrazione ). Il tutto senza il rumore dei fan, come il mitico Amiga originale.
Insomma nell’informatica, per noi utenti e per alcuni programmatori, ci vuole anche la parte ‘ludica’.. c’è gente che non vuole toccare il C# e si diverte a programmare in assembler. Il PC lo potremmo lasciare anche per un uso esclusivamente ‘business’ se questo Natami rispetta le aspettative… a casa Natami ed a lavoro il PC.
“Chi se ne importa del mercato” un bel cavolo. E’ da quando è morta commodore che amiga non ha fatto altro che passare da uno sciacallo all’altro.
E’ di assoluta importanza creare un ecosistema che riavvicini utenti e produttori anche a costo di sacrificare la scena (che tanto continua felice a sfornare gioielli per gli amiga originali ignorando quello che è seguito) e fanatismi di vario genere.
La scena è l’unica cosa che ha mantenuto in vita lo zoccolo duro, se Amiga segue la strada del PC allora chiamiamola in altro modo che non è più Amiga (vedi SAM ed OS4). Sono d’accordo che l’ecosistema è importante in qualunque situazione ma i soldi non ci sono… e nonostante tutto sono 20 anni che Amiga non muore grazie allo zoccolo duro. Qualcosa di buono ce lo dovrà pur avere se rimangono i superstiti… sviluppatori ed utenti.
Ora se ‘questi’ (gli sviluppatori di Natami) capissero che non è peccato effettuare qualche porting di qualche programma open source (io gliel’ho consigliato ma sono stato bellamente ignorato) pur di rinfoltire le fila del software, ergo un Abiword (che ha come requisiti minimi un Pentium), sarebbe tutto grasso che cola, invece si fissano su programmi anteguerra… non sò quale sia più complicato se ricompilare su 680×0 un Abiword o un aggiungere (TANTE) features a programmi datati, a occhio direi la seconda.
Addirittura vogliono convertire i giochi di Natami per OS4 (con la scusa che comunque girerebbero ad una frazione della velocità di Natami)… a questo punto si fottono anche le poche esclusive che possono creare interesse per la piattaforma anche nelle persone più scettiche.
Io gli ho consigliato di fare qualche gioco esclusiva Natami (come fa Nintendo), anche qui bellamente ignorato. Con questo modo di ‘vendere’ dove vogliono arrivare?
Secondo me il primo passo da fare sarebbe un bel subnotebook basato sulla SAM440, impiantargli sopra OS4 con quelle 4 cose per renderlo un netbook accettabile ed affrontare il mercato.
Le esclusive soprattutto se sono di giochi e programmi validi non restano a lungo in un mondo che ha come mercato poche migliaia di utenti (quantifichiamo un po’ il famoso zoccolo duro: 3000 utenti in tutto il mondo ? ma chi si sbatte a creare qualcosa di serio per 3000 possibili ma non sicuri acquirenti ?)
Ma a te questa SAM ti sembra un’Amiga? Poi anche il futuro X1000 non mi sembra molto diverso (CPU PowerPC dual core + GPU + XMOS). Non so’ cosa si potrà fare con quel XMOS ma non credo sarà qualcosa di interessante lato utente come il Super AGA. Questa è la strada intrapresa da Hyperion… come fare di un’Amiga un PC. Allora tanto vale starmene con il mio Athlon ed il mio Ubuntu. Poi si parla di ‘high end’, una nicchia nella nicchia. Mah…
Secondo me ce ne sono pure parecchio di più di 3000 ma di ‘nuova generazione’ (OS4) ce ne saranno 500. :D
Non dico di sbattersi, a me piace quello che sta facendo il ‘Natami team’… basso costo tanta resa. Peccato che non abbiano un piano serio lato software, qualcosa per aggredire il ‘piccolo’ mercato.
Ma secondo te cosa vuole ancora dimostrare una tecnologia oramai vecchia ?
Qui non stiamo parlando di far rinascere la tecnologia amiga dopo una pausa di una manciata di anni ma di rimetterla in piedi dopo 16 anni di morte dichiarata. Tutto ciò che poteva essere rivoluzionario a quei tempi adesso è ampiamente surclassato dal più scarso degli smartphone e stiamo parlando di un computer che nei sogni di qualcuno dovrebbe giocaserla e vincere contro sistemi i7 e gpu senza precedenti.
Quella finestra è di fatto chiusa e non si riaprirà più, si deve guardare avanti e lo si deve fare con decisione.
La SAM440 non ha molto di amiga, praticamente niente, ma niente per niente, almeno questa è attuale
Comunque tornando un attimo a parlare di OCS, s’è detto che il Blitter disegnava le righe e poi le riempiva con un pattern generando così figure 3D.
Ma il calcolo delle posizioni dei vertici ai quali “agganciare” le linee disegnate dal blitter a chi viene affidato ? Alla cpu ?
Cioè alla fine l’amiga generava vere figure 3D o disegnava solo quanto veniva precalcolato affinchè venisse proiettato sul fondo 2D ?
In un eventuale cubo rotante su 3 assi, quella parte di poligono che risultava nascosta alla vista a causa del parallelismo tra vertici e vista dello spettatore, come veniva gestito dal blitter ?
Questo riempiva dinamicamente quanto si poteva effettivamente vedere tipo tile rendering delle power vr o si sprecava memoria tenendo parti temporaneamente nascoste ? O ancora era tutto delegato al programmatore ?
@D:
Sì.
Dipende. In un gioco 3D come Stunt Car Racer, ad esempio, la scena era 3D e la CPU si occupava di effettuare tutti calcoli senza ricorrere a precalcoli (a parte per le tabelle dei seni e dei coseni, suppongo).
Demo come 9 Fingers etc. avevano i vertici già precalcolati, per cui li passavano direttamente al Blitter.
La rimozione dei poligoni nascosti era a carico della CPU.
Il Blitter non poteva saperlo: riempiva tutto quello che gli veniva passato.
Esattamente.
Ci vuole un Pentium 4 per emulare un’Amiga 4000 e probabilmente sarà impossibile emulare un Natami che è x volte più veloce di quest’ultimo.. (ed ha anche caratteristiche aggiuntive) quindi ‘surclassato’ mi sembra una parola grossa. Ognuna delle due architetture ha pro e contro e se c’è gente che continua ad accendere il suo 1200 non vedo perché non ci debba essere gente interessata ad acquistare qualcosa di ben superiore.
La scena (per quanto limitata) è ancora attiva, i programmi vengono ancora sviluppati come si vede da qui: http://www.amigapage.it/
L’Amiga non è un PC e la comunità non si aspetta una CPU da 10000 MIPS.
Non serve un P4 per emulare un 4000.
In ogni caso l’emulazione è un’altra cosa, rispetto a un hardware che fa girare un sistema Amiga-like.
‘The use of sound, custom chip logic and the type of frame refresh rates used in many games require more powerful machines and in extreme cases can push even a 750 MHz system to its limits.’ Pentium III, ok. Questo era l’emulatore del 2001, non so’ se a quei tempi venisse emulato bene anche l’AGA.
Non è la stessa cosa ma se ci sarà del software esclusivo su Natami allora questo non sarà emulabile dai comuni PC. Di fatto si parla di 1/3 delle prestazioni su OS4 con il gioco compilato apposta per esso, figuriamoci se invece si dovesse emulare l’intero hardware.
Non so’ se un Core 2 può fare le stesse cose dei nuovi Blitter e Copper del Natami, quel che è certo è che non lo può fare con 5W di consumo complessivo, senza ventilatori, etc.
“La rimozione dei poligoni nascosti era a carico della CPU.”
Ma il concetto di poligono è quello di una figura chiusa determinata da almeno 3 linee o 1 curva giusto ?
La cpu concepisce anche quello che sta dentro lo spazio ritagliato dal poligono o no ?
“L’Amiga non è un PC e la comunità non si aspetta una CPU da 10000 MIPS.”
Ed il mercato se ne sbatte di una comunità di 4 gatti sparsi su tutto il globo, al massimo se ne ricorda per riciclare l’ennesima scheda nata male (AmigaOne ? Un clonemac rimasto fuori mercato. SAM440 ? Un SOC per il mercato Embedded che evidentemente non riesce ad inserirsi in un ramo preciso perchè a scelta o troppo potente o troppo costoso)
@Tetsuro: gli emulatori Amiga oggi sono sviluppati in linguaggi come il C, con poche parti in assembly. Il problema è che l’Amiga è una macchina complicata e i programmatori hanno utilizzato i trucchetti più sporchi (si sono basati perfino sulla pipeline interna del Blitter), per cui per far funzionare tutto alla perfezione la sola emulazione non serve.
In questi casi si parla di emulazione “cycle-exact”, il che significa sostanzialmente passare dal concetto di emulatore a quello di simulatore, che è tutto un altro paio di maniche ( potenza necessaria per il compito inclusa).
Lo stesso vale per Natami, che comunque sarà una piattaforma emulabile, ma con le stesse considerazioni di cui sopra.
Un Core2 oggi può fare di gran lunga di più di Natami, e le versioni sistemi Ultra low-voltage consumano pochissimo (proprio nell’ordine dei 5W, se non ricordo male), anche se a costi più elevati rispetto alle versioni normali (si tratta di versioni appositamente selezionate).
Capisco che l’idea di un sistema “inemulabile” sia affascinante e, soprattutto, che possa “fortificare” il senso di appartenenza e giustificare l’acquisto di piattaforme come Natami, ma è meglio attenersi alla tecnica mettendo da parte i sogni.
@D: sì, la definizione di poligono è quella. La CPU si occupa soltanto di definire i lati del poligono, e di programmare il Blitter per riempirlo opportunamente.
Il blitter quindi è solo un pittore cieco che all’occorrenza prende la squadretta e tira righe a vuoto finchè qualcuno gli dice stop (cpu) ho reso il concetto ?
Esattamente. Non è autonomo: fa esattamente ciò che gli viene ordinato dalla CPU.
Se il blitter avesse avuto al suo interno un’unità autonoma anche solo per il riempimento delle aree invece del pittore cieco in attesa dei comandi della cpu, si sarebbe concettualmente avvicinato ad una cpu grafica ?
Se avesse anche avuto un’unità programmabile separatamente per disegnare le linee avremo avuto una primitiva gpu ?
Beh, stai dicendo che avrebbe dovuto essere una sorta di CPU o DSP, quindi qualcosa di completamente diverso. :D
Chissà che sarebbe successo se fosse stata così
Solo l’Atom ha un TDP di 4 watt, per non parlare del consumo effettivo. Il Core 2 Duo non scende sotto i 10 (del solo TDP) neanche nelle versioni ultracostose e ‘lente’.
Inoltre i 5 watt di Natami sono complessivi, per il PC devi considerare almeno la CPU + la GPU (giusto considerando le soluzioni più compatte).
Un sistema con Atom e relativo chipset (+ 1 HD) ciuccia 40 watt reali.
Non sono convinto dell’effettiva semplicità dell’emulazione Natami, inoltre considera che i ‘trucchi’ li si possono fare anche su Natami.
Non ho parlato di ‘inemulabile’ in senso assoluto, penso che con l’attuale hardware potrebbe essere un compito ostico se non impossibile.
Questa sarebbe una domanda da fare sul loro forum.
http://www.hwupgrade.it/articoli/portatili/2347/nuova-piattaforma-intel-atom-pinetrail-al-debutto_3.html
Quanto all’emulazione di Natami, non vedo difficoltà, specialmente con l’hardware attuale.
Non è ancora uscito comunque si parla del 20% in meno quindi siamo sempre sui >30W. Contro 5.
Qui la pensano diversamente: http://www.natami.net/knowledge.php?b=6¬e=15619&z=a6hcGh
Che lo facciamo uscire intanto, che ci mettano sopra un os funzionale come si deve, che ci scrivano sopra dei programmi che ne sfruttino concretamente le capacità e poi vedremo nei fatti quanto sarà inemulabile il tutto. A meno che i programmi non verranno realizzati con una cura paragonabile a certe demo (interessante la storia della pipeline del blitter, sarebbe interessante approfondire di più ma temo che ne uscirebbere un articolo al cui confronto quelli su arm e gpu sono robetta elementare) mi sa che un atom sarà d’avanzo
@Tetsuro (o Alessandro :D): intanto l’emulazione è possibile, come puoi leggere, ed è quello che affermavo io.
Per quanto riguarda la piena velocità, per la CPU non ci saranno problemi. Per il resto, bisogna vedere come funziona il chipset (sezioni 2D & 3D).
Infine sui consumi, CPU, GPU e memory controller sono gli elementi più importanti e consumano circa 5W. Poi dipende da quello che ci monti sopra.
Beh ma Cesare puoi emulare qualsiasi cosa, anche una PS3… il punto è di farla andare in tempo reale, se poi mi fa 5 FPS è assolutamente inutile (come qualche emulatore Saturn ad esempio).
Si la CPU è più o meno il solito 68060 ma è il chipset quello che non si potrà emulare (in tempo reale).
5 watt è il TDP (il calore dissipato) non il consumo elettrico reale. Gli sviluppatori di Natami parlando di power consumption, non di TDP.
Ma anche volendo (e non vogliamo) un Atom non potrà mai emulare un’architettura come quella Natami quindi il problema neanche si pone.
Per D, il software c’è… sicuramente non è paragonabile a quello PC e non lo sarà mai ma consideriamo anche che non tutti hanno bisogno di tutto il software presente su Linux o Windows e a pochi può interessare anche una piattaforma alternativa.
Non sarà mai una cosa simile al PC. Sarà una cosa diversa per chi sarà interessato, magari qualche amighista di vecchia guardia che vuole giocherellare con un hardware/software Amiga esclusivo. Per chi vorrà un hardware silenzioso e parco di consumi capace di soddisfare le esigenze base degli utenti casalinghi (navigare in Internet, scrivere qualche documento, giocare, fare musica, e qualche altra cosa).
L’Atom non è stato tirato in ballo per l’emulazione di Natami, ma per indicare una piattaforma hardware più o meno equivalente quanto a consumi, ma con hardware più performante.
Comunque di Natami ne parlerò in futuro, dopo che avrò trattato il 68060. E’ già in programma da un pezzo, ma ci vorrà ancora un bel po’ di tempo (la scaletta è lunga). Per cui per il momento evitiamo di parlarne, che sia già andati parecchio OT, visto che il discorso verrà sicuramente ripreso (parola di ex boy scout).
Indubbiamente l’Atom sarà più performante lato CPU però Natami avrà i suoi pregi, altrimenti non avrebbe neanche senso svilupparla.
Aspetto con trepidazione l’articolo su Natami, non dubito che sarà molto interessante come tutti i tuoi articoli sull’hardware.
Suggerisco di tenere in considerazione questo quote degli sviluppatori prima di stendere l’articolo:
‘We do not aim to compete with mainstream machines. Our goal is to build the fastest and most powerful Amiga compatible hardware. This goal was reached. NatAmi is more powerful than the fastest Amiga 4000. We also plan on making it better over time.
The target market is anyone who would like the legacy hardware and OS with enhanced performance; it is almost a bridge between the computing of today and yesteryear. The NatAmi brings back the fun of the late 1980s and early 1990s. NatAmi brings back the ease of Amiga development. But the NatAmi can handle today’s requirements for web-surfing, watching movies, or listening to mp3s. NatAmi keeps the friendly Amiga experience while drastically improving overall performance.’
Non ti preoccupare: conosco abbastanza bene il progetto Natami, e non ho certo intenzione di scrivere un articolo per denigrarlo.
Da sviluppatore Amiga veterano conosco i limiti di questa piattaforma, come pure quello di questo nuovo progetto. E, soprattutto, la filosofia che vi sta alla base.
Detto ciò, se ci sono critiche da fare, le farò: un professionista non può ignorarle. Questo non significa distruggere l’oggetto dell’articolo, sia chiaro.
L’importante è fare informazione e dare la possibilità ai lettori di farsi un’idea concreta.
Al massimo rischio io, quando scrivo, di essere preso a randellate, visto che ci metto la faccia. :D
No ci mancherebbe anche le critiche sono importanti… basta tenere da conto l’obbiettivo alla base del progetto, come il Minimig ha un suo perché, ma vedo che su questo siamo sulla stessa linea d’onda.
Tu ci rimetteresti la faccia ma io lo stomaco (ulcere a gogo!)! :lol:
E’ inutile farsi il sangue amaro per dei pezzi di latta (e peggio ancora per il software).
Come sei cinico… io li chiamerei piuttosto ‘prodotti dell’intelletto umano’. :)
Più che altro sono realista. E parlo da Amighista di lunga data.
ciao scusa un iformazione come faccio a rialliniare il lettore floppy del comodore 64.Grazie
Purtroppo non ne ho mai posseduto uno (sognato sì, e pure molto).