Con la Commodore fuori dai giochi a seguito del fallimento occorso nel 1994, le possibilità di far rivivere l’Amiga nel connubio hardware & software che ha sempre contraddistinto queste macchine sono, di fatto, svanite.
C’è stato il tentativo di aggiornare le macchine esistenti con CPU PowerPC e schede grafiche più potenti, oppure costruendo nuovi computer basati sempre sulle nuove CPU di Motorola (similmente alla strada intrapresa da Apple coi suoi Macintosh), ma da vecchio e affezionato amighista i chiodi fissi rimangono la famiglia 68000 e i chip custom disegnati da Jay Miner.
Il solo sistema operativo, insomma, non mi basta. AmigaOS è sicuramente uno dei pezzi pregiati; una colonna portante. Però da solo, abbinato ad altro hardware anche completamente diverso, non sono riuscito a farmelo digerire (anche se AROS rimane un progetto interessante, di cui parlerò in futuro).
La nascita di progetti realizzati da hobbysti volti a far rivivere le meraviglie del passato ha ridestato in me la curiosità, la voglia anche soltanto di conoscere cosa sono riusciti a combinare e a che livello di “emulazione” sono arrivati in quella che rimane una delle più affascinanti, ma complesse, architetture hardware.
Questo mi ha spinto a interessarmi del progetto Minimig, di cui ha parlato in un recente articolo e di cui, tra l’altro, esistono delle implementazioni vendute da aziende (una è italiana) per quegli utenti, come me, che non vedono differenze fra un saldatore e il bisturi di un chirurgo.
Un altro che esiste e di cui si discute da tempo è NatAmi, abbreviazione di Native Amiga, che con Minimg condivide l’idea di riportare alla ribalta proprio quell’hardware sul quale, poi, far girare AmigaOS e i relativi programmi (e giochi), ma a velocità mai viste prima, e impensabili nemmeno coi più spinti hack su cui stanno sperimentando gli attuali sviluppatori di Minimig.
Non è difficile immaginare che le finalità siano decisamente diverse, pur partendo da una base comune. Minimig nasce, infatti, per riprodurre il più fedelmente possibile quell’esperienza (sebbene, per gran comodità, abbia eliminato l’uso del floppy e dell’hard disk, sostituendoli con delle schedine MMC/SD), e lo fa decisamente bene grazie a un’emulazione cycle-exact del sistema, ossia accurata fino al ciclo di clock.
Questo significa che si cerca di riprodurre il funzionamento della macchina ciclo di clock per ciclo clock, approccio questo che, se ben realizzato, garantisce eccellenti risultati in termini di compatibilità. Quello che rappresenta un notevole vantaggio ne diviene, però, anche il principale limite: la scalabilità (in termini di maggiori prestazioni dell’intero sistema) ne risulta compromessa.
Qui si biforcano le strade di Minimig e Natami, in quanto per quest’ultimo l’obiettivo finale è di fornire, invece, le maggiori e migliori prestazioni, sebbene il prezzo da pagare sia quello di perdere parte della compatibilità, in quanto l’emulazione non avviene in maniera così precisa, e il funzionamento dell’hardware viene riprodotto in maniera fedele per lo più riguardo al Copper (il che è perfettamente naturale, dovendo questo sincronizzare le operazioni col raster video).
Sia chiaro che ciò non significa che tutto il resto non funzioni bene, perché tutti gli altri chip custom, CIA inclusi, sono comunque implementati nel progetto, ma non mi aspetto che, ad esempio, il funzionamento del Blitter sia riprodotto in maniera accurata, e questo può comportare dei problemi coi giochi o le demo meno “puliti” (cioè che trasgrediscono le linee guida di Commodore sulla programmazione dell’hardware).
Credo che la compatibilità rimarrà comunque di discreto livello, penso in ogni caso inferiore a quella di macchine come l’Amiga 4000 che, a causa delle imperizie di diversi programmatori, non hanno permesso di godere dell’intero parco software disponibile, vuoi per la non perfetta compatibilità di AGA con OCS e ECS , vuoi per l’uso di una CPU come il 68040, che era decisamente più performante del 68000 a 7Mhz di Amiga 1000, 500, 2000 e 600 (e qui ci sarebbe da spezzare le mani a chi ha scritto cicli di attesa usando la CPU anziché i timer).
Natami viene, infatti, presentato come un sistema basato su un chipset “SuperAGA”, perché tale vuole essere: un SuperAmiga. AGA è l’ultimo chipset disponibile e per il quale è stato realizzato software, per cui sceglierlo come base di partenza è stata una scelta perfettamente naturale (Minimig rimane, al momento, vincolato a OCS e, parzialmente, ECS).
Ovviamente è stato notevolmente potenziato per superarne le numerose lacune, integrando anche alcune idee del mai nato AAA, come ad esempio l’uso di modalità chunky pixel a 8 bit (con palette) e 16 bit (HiColor, con 32768 colori a disposizione, e un bit per il genlock), ma aggiungendo anche l’agognato TrueColor (32 bit, 8 per ogni componente cromatica e 8 per overlay / genlock), oltre a una modalità YUV.
Le risoluzioni video arrivano a 1280×1024 pixel, e dalle porte di uscita VGA (analogico) e DVI (digitale) il segnale a 15Khz tipico degli Amiga viene “promosso” a 31Khz per essere visualizzato nei monitor più moderni (che difficilmente agganciano la frequenza del vecchio segnale televisivo), facendo uso dello stesso metodo (lo scan doubler) disponibile con l’Amiga 3000 e adottato anche da Minimig.
Da amighista nonché programmatore, non ho trovato menzione dal famoso Dual Playfield, reso famoso da giochi come Shadow of the Beast col suo stupendo scroll parallattico, ma personalmente gradirei la possibilità di utilizzarlo coi nuovi formati chunky pixel a 8, 16 e 32 bit, fornendo magari la possibilità di scegliere quale fra questi per ognuno dei due schermi indipendenti.
Il Copper, come dicevo prima, funziona in maniera molto simile all’originale, rispettando in maniera rigorosa i timing originali (7Mhz, con accesso alla memoria a 16 bit), ma è possibile abilitare una modalità avanzata che lo fa girare a piena velocità (che dovrebbe essere di 266Mhz nella versione definitiva) pur mantenendo intatte le sue caratteristiche (ad esempio per le istruzioni di attesa del pennello elettronico) e consentendo, quindi, di poter manipolare una quantità di dati impressionante.
Il Blitter è il componente che ha subito più modifiche, in quanto è stato ovviamente aggiunto il supporto alle nuove modalità chunky pixel, oltre a effetti di trasparenza, rotazione e scaling delle immagini, ma essendo a 32 bit (anziché a 16 bit) e con un clock molto più elevato (266Mhz anziché 7Mhz), le prestazioni sono di almeno un paio di ordini di grandezza superiori. Eccezionale!
Gli sprite sono rimasti intatti rispetto all’AGA, quindi in numero di 8, ma sempre a 4 colori (combinandoli a coppie si arriva a 16 colori) e di ampiezza massima pari a 64 pixel. Francamente col nuovo Blitter se ne può fare tranquillamente a meno, visto che si possono muovere interi schemi a 16 milioni di colori in scioltezza.
A completare la sezione grafica vi è un nuovo componente che si occupa della grafica 3D, ma considerato che il progetto è, come per Minimig, basato sull’uso di un FPGA, si tratta di un chip grafico abbastanza limitato, che non implementa funzionalità come vertex o pixel shader, ma si occupa di mere funzionalità di rasterizzazione, con l’applicazione di Gouraud shading per le luci, bilinear filtering, e AA fino a 4x.
Nella FAQ parlano di poter realizzare giochi come Quake 3 e il primo Half Life, per cui parliamo di una GPU simile alle vecchie Voodoo 3 e 4 di 3DFX, con pipeline fissa e, almeno da quel che ho letto finora, senza una sezione di T&L in hardware.
Non v’è, quindi, da aspettarsi nulla di esaltante e ben lontano dalla grafica che siamo abituati a vedere oggi, ma di più da un FPGA non si poteva tirar fuori. Personalmente avrei preferito che il 3D fosse relegato a una scheda di espansione esterna, in modo da poter utilizzare una GPU più moderna, e sfruttare i gate a disposizione per migliorare la CPU.
Da qualche tempo si parla comunque di aggiungere un nuovo componente, chiamato Robin, che dovrebbe trattarsi di una CPU RISC dedicata all’elaborazione vettoriale (dovrebbe far girare 4 thread indipendenti, ognuno datato di 1KB di cache), in modo da scaricare su tale nuovo coprocessore questo tipo di calcoli, ma non esistono ancora dettagli precisi in merito.
Francamente sulla questione ho idee un po’ controverse. Da una parte mi piacerebbe vedere l’ISA 680×0 estesa aggiungendo un’unità SIMD simile all’SSE di x86 o Altivec di PowerPC, mentre dall’altra quella di un processore dedicato che lavora in parallelo è particolarmente allettante, specialmente se realizzato in modo da prevederne un’espansione futura (più core che si dividono i lavori da fare).
In ogni caso qualche soluzione per potenziare la CPU sul fronte dei calcoli in virgola mobile si dovrà pur trovare, in quanto al momento la tradizionale FPU che ha accompagnato le configurazioni di fascia alta, o che era integrata nei microprocessori più avanzati (68040 e 68060), non è stata implementata e pertanto l’unica soluzione rimane l’emulazione tramite un’apposita libreria esterna.
Parlo di unità SIMD e FPU non a caso, in quanto per questo progetto è in lavorazione una nuova CPU (al momento, non essendo completata, viene utilizzato un 68060, sfruttando un apposito slot) che sarà integrata anch’essa nell’FPGA e, sulla carta, sembra promettere molto bene.
Nonostante sia a pipeline singola, questo nuovo arrivo dovrebbe avere prestazioni molto più elevate del più performante 68060 prodotto da Motorola, che però, e come sappiamo, era dotato di una superpipeline in grado di eseguire due istruzioni (in ordine) per ciclo di clock.
Questa nuova CPU, che inizialmente era chiamata N070 (e ancora oggi in alcuni documenti si trova questa nomenclatura) che porta alla mente un 68070 per indicare un’ideale continuazione della famiglia, di recente ha cambiato nome in N050 (o 68050), forse per meglio collocarsi sulla scia delle innovazioni apportate (col 68060 si passò dalla pipeline singola in uso fino al 68040, a quella doppia, appunto).
In ogni caso non si tratta di un derivato del 68050, che non è mai stato prodotto da Motorola (e di cui sappiamo che il progetto fu abortito a causa dei risultati non all’altezza delle aspettative per convogliare le energie su quello superscalare), ma di un nuovo design che eredita parte del concept del 68060, in quanto fa uso di un’unità RISC interna per l’elaborazione effettiva delle istruzioni.
Tornando all’FPU, la sua integrazione al momento non è vista come strategica, in quanto effettivamente per l’Amiga si utilizzavano quasi sempre le sole istruzioni intere, ma è possibile che, avanzando un po’ di gate e tempo, lo sviluppatore implementi quanto meno il supporto alla singola precisione.
Nulla da fare per l’MMU, invece, in quanto richiederebbe troppe risorse (dovrebbero essercene due, una per il codice e una per i dati, in quanto l’architettura è di tipo Harvard), e il cui uso su Amiga era estremamente raro (al più veniva sfruttata per intrappolare gli accessi alla prima pagina di memoria, segnalando l’eventuale uso di puntatori nulli).
Sembra esserci spazio, invece, per l’aggiunta di nuove istruzioni che possano essere utili non col solo scopo di arricchire l’ISA, ma di aggiungere istruzioni mancanti, in quanto l’autore del nuovo core ha anche aperto un thread con l’invito a suggerire eventuali idee.
Personalmente, dopo anni passati a lavorare con questi splendidi processori, apporterei le seguenti aggiunte:
- LEA <EA>,Dn ; calcola l’indirizzo effettivo <EA> e lo copia in Dn
- MOVEZW.B <EA>,Dn ; preleva il byte da <EA>, lo estende con zero a word, e lo copia in Dn
- MOVEZL.B <EA>,Dn ; preleva il byte da <EA>, lo estende con zero a longword, e lo copia in Dn
- MOVEZL.W <EA>,Dn ; preleva la word da <EA>, la estende con zero a longword, e la copia in Dn
- MOVESW.B <EA>,Dn ; preleva il byte da <EA>, lo estende con segno a word, e lo copia in Dn
- MOVESL.B <EA>,Dn ; preleva il byte da <EA>, lo estende con segno a longword, e lo copia in Dn
- MOVESL.W <EA>,Dn ; preleva la word da <EA>, la estende con segno a longword, e la copia in Dn
- MOVEcc Dx,Dy ; copia Dx in Dy solo se la condizione cc è soddisfatta
- MOVEcc Ax,Ay ; copia Ax in Ay solo se la condizione cc è soddisfatta
- BSWAP Dn ; inverte l’ordine dei byte (il più alto si scambia di posto col più basso, il secondo si scambia col terzo)
- SHLD #n,Dx,Dy ; esegue uno shift a sinistra di n, considerando Dx e Dy come un unico registro a 64 bit
- SHLD Dn,Dx,Dy ; esegue uno shift a sinistra di Dn, considerando Dx e Dy come un unico registro a 64 bit
- SHRD #n,Dx,Dy ; esegue uno shift a destra di n, considerando Dx e Dy come un unico registro a 64 bit
- SHRD Dn,Dx,Dy ; esegue uno shift a destra di Dn, considerando Dx e Dy come un unico registro a 64 bit
- JMPT.W <EA> ; esegue un salto all’indirizzo calcolato prendendo la word all’indirizzo <EA>, estendendola con segno, moltiplicandola per due, e sommandola al PC
- JSRT.W <EA> ; esegue un salto alla subroutine il cui indirizzo è calcolato prendendo la word all’indirizzo <EA>, estendendola con segno, moltiplicandola per due, e sommandola al PC
A parte la prima e le ultime due, le altre sono mutuate da equivalenti istruzioni degli x86, perché sono oggettivamente utili (specialmente la MOVEcc, che permette di evitare che la pipeline si stalli).
La LEA con copia su registro dati serve a simulare l’esecuzione di un’operazione di somma che può prevedere diversi operandi sorgente e una destinazione, che può coprire agevolmente (e in maniera decisamente compatta) l’assenza di un’istruzione a 3 operandi tipica di molti RISC.
Le JMPT e JSRT servono, invece, a eseguire salti fruttando una tabella di word contenente l’offset rispetto al PC, in modo da realizzare delle jump-table più compatte da impiegare per emulatori o per le istruzioni switch / case di linguaggi di programmazione come C o Pascal.
Modificherei anche il registro dei flag, CCR, aggiungendone due (ai 5 già presenti) per poter decidere in maniera programmatica se utilizzare il little endian per leggere e scrivere i dati (i 68000 sono rigorosamente big endian), e per imporre un controllo sul registro indirizzi nelle modalità d’indirizzamento verso la memoria che lo prevedono (sollevando un’apposita eccezione se risulta zero, in modo da intercettare il dereferenziamento di puntatori nulli).
Sono assolutamente contrario all’introduzione di istruzioni che prevedano operazioni come somme e sottrazione con saturazione et similia, oppure somme e sottrazioni con interi a 8 o 16 bit packed (quindi vettorizzate), perché preferisco che siano introdotte in un’eventuale unità SIMD.
E’ chiaro che simili innovazioni tenderanno a produrre applicazioni che non gireranno sui veri Amiga (o sugli emulatori), ma è anche vero che la famiglia 68000 è praticamente morta (se non come microcontrollori), e lo stesso vale per queste macchine. Dunque se una nuova speranza su cui puntare ci dev’essere, tanto vale provare con le migliori carte.
Pochi sono, invece, i cambiamenti relativi ai floppy, a cui è stato aggiunto soltanto il supporto a quelli ad alta densità a piena velocità di lettura (con l’Amiga 4000 era, invece, dimezzata), ma è presente il controller IDE. Inoltre è possibile usare tastiere e mouse PS/2, è presente uno slot di espansione per la CPU (al momento usato per montare un 68060, come dicevo prima), e fino a 3 slot PCI.
Anche per l’audio c’è poco, in verità. E’ possibile utilizzare campioni da 8 (i soliti) o 16 bit, il volume è a 6 (come prima) o 8 bit, e si parla di frequenze fino a 192Khz (contro i canonici 29Khz massimi), ma i canali rimangono rigorosamente 4. Le motivazioni sono logiche: aggiungerne altri avrebbe consumato troppe risorse dell’FPGA, ma almeno il volume separato per il canale sinistro e destro sarebbe altamente auspicabile.
Non credo ci sia altro da aggiungere, se non che la commercializzazione è prevista per quest’anno, dopo parecchio tempo passato in fase di sviluppo (le prime notizie risalgono al 2003), ed è per questo che ne parlo (seguendone il forum mi sono fatto l’idea che si tratti di gente estremamente competente e non venditori di fumo; tra l’altro molto appassionati di hardware e, manco a dirlo, di Amiga).
La scheda madre è utilizzabile in un normale case per PC, e dovrebbe già contenere 512MB di memoria suddivisa in 256MB per la chip ram e altrettanti per la fast ram, in modo da avere due bus indipendenti e raddoppiare la banda totale a disposizione, come succedeva con gli Amiga dotati di (vera) fastram. Inoltre il consumo totale sarà pari a 2-3 watt.
Di certo la presenza di un FPGA aggiornabile rimane un “bonus” non indifferente di cui tener conto, ma al momento l’unica incognita rimane proprio sui costi per tanto ben di dio, che decreteranno il successo o il fallimento di questo n-esimo tentativo di far resuscitare questa stupenda piattaforma che ancora oggi ci fa sognare (e i commenti agli articoli che ne parlano sono lì a testimoniarlo).
