Nuovo hw Amiga

[cdimauro]

@samo: già, ma potrebbe comunque rilasciare a terzi la licenza di AmigaOS3.1, senza infrangere l'accordo con Hyperion, che appunto non è nemmeno interessata.

@sabbate: si potrebbe riciclare quella del Minimig o, ancora meglio, dell'FPGArcade (che ha un parziale supporto al 68020).

Ma servirà comunque del lavoro per completare l'opera (cosa fondamentale), e poi per potenziare il giocattolino.

[samo79]

@samo: già, ma potrebbe comunque rilasciare a terzi la licenza di AmigaOS3.1, senza infrangere l'accordo con Hyperion, che appunto non è nemmeno interessata.

Beh (ammesso che l'accordo lo preveda) non credo che cmq gli farebbe piacere, è vero che non c'è interesse a portarlo avanti ma è anche vero che li dentro ci sono sempre parti di codice "AmigaOS" con tutte le implicazioni del caso .. c'è anche da dire che ad oggi quelle parti di codice non è che abbiamo più sto gran valore d'uso, sopratutto visto lo stato relativamente avanzato di AROS e quello già ampiamente maturo di AmigaOS4/MorphOS

Quindi in realtà a meno che non entrino nuovi "attori in campo" (improbabile a parte progetti amatoriali) praticamente nessuno degli OS Amiga NG attuali se ne farebbe granchè di quei sorgenti ...

[cdimauro]

Su questo siamo perfettamente d'accordo.

Avrebbero dovuto farlo parecchio tempo fa. Ormai non li vuole nessuno quei sorgenti, per lo meno nel mondo Amiga.

[legacy]

siamo senza softcore 68K ottimizzabile, almeno non senza dover pagare per avere i sorgenti di un gioiello come D68000, al lato amatoriale qualcosa c'e', pero' o si fa la bovinaggine di schiaffarlo tal quale su fpga pompate (>>400Mhz) oppure bisogna che qualcuno si metta ad ottimizzarlo: chi ? I tizi di Natami avevano annunciato qualcosa di simile ma ... dove e' il codice ? Nessuno mi ha risposto.

Dall'altro lato c'e' il progetto di FPGA arcade, e li si tratta di un softcore 68020, da finire, da validare, e da ottimizzare.

Che io sappia, e se ce ne sono siam qui apposta, di softcore pronto chiavi in mano c'e' solo roba amatoriale 68000 di cui spesso non si cava fuori 1:1, ma molto molto meno.

Del resto si vede sopra quanto e' poco perfermante un 68EC000 sfornato da freescale: 68EC000@20Mhz ->2.7MIPS, 20Mhz -> 2.7Mhz, sta 10:1, 10Mhz per avere 1MIPS

Su 68000 c'e' vantaggio a fare softcore se su fpga si fa bloated design (a patto di avere risorse su fpga per farlo -> KLE e BRAM) in modo da ottimizzare quel rapporto, pero' anche in questo modo e con strategie ti ottimizzazione per tempo non si va molto lontano, sicuramente abbassa quel 10:1 ma non tantissimo.

I tizi di D68000 invece hanno cambiato nettamente approccio e si sono fatti un core RISC super ottimizzato, e attorno logica che traduce opcode 68K in opcode RISC, il tutto in pipelining (molto difficile da fare), il risultato e' 1:1

I tizi del refactoring 68060/asic pro freescale sono stati ancora + bravi e il risultato di quel mostro super scalare e' addirittura 1:2

Per me ha avuto senso comprare un 68SEC000 (ricordo che e' a 3.3V quindi compatibile a livello elettrico con la mia piccola fpga) perche' ho usato una piccola fpga dal package comodo per lo sbroglio e saldatura; a me va benissimo avere 2.7MIPS e fare pcb semplice, questo e' il design che e' andato bene anche a minimig v1 per simulare A500, pero' su CPU di prestazioni alte come 68060 (amiga1200/3000/4000 con accelleratrice) non c'e' storia: vince per prestazioni/costo un 68060 su silicio.

Quindi in conclusione dipende dagli obbiettivi: cosa si vuole fare.


p.s.
se qualcuno sdoganasse il fantomatico "68050/natami", le cose potrebbero cambiare, ma di fatto il codice di quel coso non c'e', o meglio non l'hanno rilasciato e nessuno ne sa nulla da un po'.

[BigAmyDream]

Sembra interessante tale progetto, mi sembra piuttosto realistico e perciò decisamente fattibile.

Sono un semplice utente e non mi intendo di elettronica a quei livelli, ma solo di informatica. Sono anche un felice possessore di un minimig con controller arm.

Su tale scheda si può cambiare il core sw come sul minimig? Intendo dire se un giorno si vuole emulare un computer diverso dall'Amiga, si mette l'opportuno .bin sulla scheda SD e accendendolo si potrà avere proprio quel computer.
La memoria di massa sarà una scheda SD?

Quanti HDD emulati ci saranno? Immagino 2, ma credo che tutto dipenda dalla disponibilità delle porte logiche sugli FPGA prescelti.

Per la RAM, penso che sia preferibile saturare l'intero spazio di indirizzamento dell'AmigaOS con 2GB, ma se si vuol usare AROS in futuro, credo che sia meglio non porre limiti arrivando eventualmente a 4GB di RAM, possibilmente DDR2 o DDR3 visto il loro relativamente basso costo, magari su un zoccolo per un cambio di ram rapido.

Per quanto riguarda l'uscita video mi parrebbero opportuni due, una VGA e un DVI(I o D) o meglio ancora un HDMI per interfacciarlo alle TV moderne, oltretutto quest'ultima ha un connettore di dimensioni ridotte.

Per la cpu sarebbe preferibile, a mio modesto parere, un softcore perché si avrebbe una maggiore flessibilità, eventualmente una maggior frequenza di lavoro, anche se ciò richiede un grande lavoro nella programmazione e nell'ottimizzazione.

Tutto ciò è solo il mio modesto parere di utente, intanto vedo un'interessante argomento di discussione.

[andres]

Non mi pareva fosse così, ma stando al testo riportato da Samo c'è scritto che Hyperion ha diritti esclusivi su AmigaOS 3.1, quindi dubito che Amiga Inc., anche volendo, potrebbe usarlo (io ricordavo altrimenti nell'accordo però, boh...).
Comunque sono discorsi puramente teorici, l'ultima versione dell'OS su 68k è la 3.9 con varie patch, ed è quella a cui fare riferimento per le macchine classiche.

[cdimauro]

Non è così. Leggi meglio:

"Within the framework of the settlement agreement Hyperion is granted an exclusive, perpetual, worldwide right to AmigaOS 3.1 in order to use, develop, modify, commercialize, distribute and market AmigaOS 4.x (and subsequent versions of AmigaOS including without limitation AmigaOS 5)"

[andres]

Sì, probabilmente hai ragione, anche se per inciso conta il documento legale, mentre questo è un comunicato di Hyperion che di per sé non vale nulla.
Io ricordo infatti che Amiga Inc. è la proprietaria di AmigaOS 1.x/3.9 (sebbene del 3.5 e del 3.9 non abbia i sorgenti di alcune parti, che H&P non ha mai dato), e che può usarli con tutta una serie di vincoli legati all'accordo con Hyperion (non su macchine marchiate Amiga, ad esempio).

[sabbate]

@cdmauro
si effettivamente riguardo la cpu non vedo altre strade visto e considerato che il softcore che vorrebbe utilizzare bertocar e' sotto licenza.
Quello dell'fpga potrebbe andar bene ma si puo' spingere questo 020 cioe' a che frequenze potrebbe arrivare(clock).

@legacy
vediamo cosa dice bertorcar se no dobbiamo stare sul softcore dell'fpga penso per il momento.

cmq soluzione su coldfire non e' possibbile?
mi dicevano qualche pagina indietro che non e' pienamente compatibile con le istruzioni della serie 68000.

ciao

[cdimauro]

I Coldfire sono inutilizzabili.

Rimane solo il softcore. Si può prendere quello di FPGArcade, ma per prestazioni elevate (al momento è fermo sugli 28Mhz) servirà migliorarlo un po' alla volta fino a stravolgerlo.

Si può arrivare anche a competere col 68060, con due istruzioni in-order eseguite per ciclo di clock (in realtà tre, perché può valutare anche un salto), ma prevedo un sacco di lavoro.

[ilbarbax]

mi sembra che di tentativi di questo genere, ce ne siano stati almeno 4 o 5 di cui solo uno andato pienamente in porto. Questo conferma quanto sicuramente non siano semplici, ma penso che il problema più grosso sia che, per un motivo o per l'altro ogni progetto è ripartito da zero reinventando la ruota. Ora dico, visto che c'è il minimig funzionante, non sarebbe meglio estendere quel progetto? Si potrebbe utilizzare lo steso cip del minimig per i soli cip custom, in modo da recuperare il s/w già esistente ed avere al contempo maggior potenzialità di sviluppo pe nuove features.

[legacy]

@cdmauro
secondo me ci sono pocchissime persone al mondo in grado concretamente di fare una cosa del genere, o disposte a farlo, sopratutto per hobby (cioe' non competenze non retribuite). Non a caso D68000 costa 60.000 USD per i sorgenti, e gli ing di freescale sono letteralmente stati pagati a peso d'oro per il refactoring del 68060 e della linea coldfire e 683xxx (AKA 68K/CPU32)

Secondo me il tizio del fantomatico super 68K aka "68050" in Natami se capisce come gira il mercato il suo core lo ritratta in termini di Copyright, proponendolo sotto forma di IP a scatola chiusa, o a diversi zeri per avere anche i sorgenti: e lo penso perche' se ho compreso la natura umana, beh ... con se quel coso davvero esiste e funziona il tizio puo' farci davvero un bel po' di soldi.

In quanto ai salti no, questo no, non penso, i salti sul mio MIPS32-rev2 sono catastrofici e da Mips inc ho visto che sono stati seguiti diversi approcci, sia per CPU asic che per proposte di softcore Mips

Dal piu' pregiato al + bovino, posso tentare di riassumerli cosi':

1) statistico speculativo, dove si usano dati statistici, collezionati dalla storia dell'eseguzione, per istruire la branch prediction nel fare una previsione ogni volta che incontra una conditional branch sul possibile proseguio sul ramo then piuttosto che else

2) a casaccio, diciamo che in fase di progettazione della branch prediction diamo preferenza al ramo true piuttosto che false perche' solitamente assumiamo che i programmatori prediligano il ramo then

in entrambi i casi mentre si fa prefetch e si inizia a macinare, se la logica azzecca il ramo giusto si prosegue, ma se non lo azzecca si blocca la pipeline, la si stalla, la si svuota e si riparte. Farla profonda 5 significa 5 nop, 5 colpi di clock per svuotarla in caso di previsione errata, e qui capisci che serve logica smart, meno failure prediction fa meglio e'. Ma hai abbastanza risorse per mettere in piedi questa cosa ? Sui chip asic il branch prediction e' l'aggeggio che occupa + transistor, sui PIC e sugli AVR8 tagliano molto corto e usano soluzioni bovine proprio perche' hanno maschere a pochi transistor (e il chip deve anche costare $2/$5) per cui ... dubito che sulle fpga piccole si possano fare cose tanto elaborate.

Poi ci sono casini bestia come tradurre le complicatissme EA (effective address) del 68020 in load/store del nucleo RISC, anzi spesso una istruzione che fa EA complessa e' tradotta in un gruppo di micro istruzioni RISC, il che significa che per portare a termine l'istruzione 68k servono diversi e diversi cicli, vero che c'e' pipelining, ma la profondita' e' 4 o 5, oltre bisogna assolutamente stallare con nop per non incorrere in hazard condition fra il dato/registro manipolato da quella istruzione e le istruzioni che seguono che spesso e volentieri vorrebbero consumare quella informazione e devono aspettare che sia pronta e stabile.

Mips Inc per le sue CPU questa rogna la delega al compilatore, con un 68K super scalare dove hai istruzioni 68k tradotte in micro istruzioni RISC, o stalli come ho fatto notare prima e perdi prestazioni, oppure per ottimizzare sarebbe necessaria logica ed intelligenze eseguzione fuori ordine delle micro istruzioni RISC al fine di prevenire le loro hazard -> altro complicatume infinito da fare e validare

[legacy]

da progetto Motorola in refactoring Freescale

68008@8Mhz ->0.9MIPS (approccio micro cablato)
68EC000@20Mhz ->2.7MIPS (approccio micro cablato migliorato)
68EC020@33Mhz -> 9.8MIPS (approccio a microcodice)
68EC030@50Mhz ->14MIPS (approccio a microcodice migliorato)
68EC040@40Mhz ->43.8MIPS (approccio delivering RISC like)
68EC060@50Mhz -> 101MIPS (approccio delivering RISC like migliorato)

fonte Motorola High Performance Embedded System Sources, book 2003
confermato da freescale per il 2011

Cmq, chiariamoci numericamente le idee, e dimentichiamoci per un attimo del 68060 e delle sue prestazioni.

Ipotizzando quindi di restare su un 68000, anche il piu' scassato e poco performante, anzi per ipotesi, prendiamone uno che sia 2 volte + castrato rispetto ad un chip asic reale

un chip reale 68EC000@20Mhz ->2.7MIPS (approccio micro cablato migliorato) -> 10:1
il nostro ipotetico chip sfigato fa 20:1, e' volutamente 2 volte + scarso

OK ? lo prendiamo questo flaccidone ? Si, e state a vedere perche'.

Siamo tanto bravi, e quel coso e' tanto flaccido che senza troppa fatica risuciamo a farlo funzionare su fpga con ottimizzazione per tempo (tanto abbiamo fpga adeguate), e cosi' con 400Mhz otteniamo 20MIPS !!!

20MIPS, ora guardate la tabella! Si vede chiaramente: si ottengono + prestazioni di un 68EC030@50Mhz ->14MIPS

Io dico, se questo va bene, lo si assume come obiettivo e si prosegue del tutto incuranti della precedente: ma consapevoli che migliorando al massimo quel softcore al massimo si avranno a pelo le prestazioni di un 68040, e attenzione, le prestazioni, non le sue istruzioni ! Significa che codice ottimizzato per 68020 o superiore li sopra non puo' girare e va ricompilato espressamente per 68000: cosa cmq fattibile se si usa ArOS.

Vi sentite meglio ora ? Vero ?

Detta cosi' e' + confortante: il bicchiere e' mezzo pieno

[bertocar]

Dopo aver letto tutte le vostre considerazioni che apprezzo, rimango fortemente convito che la strada sia quella del softcore. Solo per il fatto che puo' essere successivamente sostituito con una versione migliore per me merita.
Con questo ci sono 2 strade che cercheremo di seguire:
1. individuare un fpga che in termini di prestazioni sia importante ma non troppo costoso in modo da colmare in parte la 'deficenza' dei softcore open
2. trattare per la license del D68000 che e' vero chiedono 60kUSD MA considerate che e' UN PREZZO ESTREMAMENTE DI LISTINO, soggetto a trattative e sicuramente ridimensionato non di poco. Una volta chiusa la partita io non potro' ovviamente comunicare il costo pero' fare un ragionamento del tipo 'al raggiungimento di n dispositivi venduti potremo tutti godere del softcore D68000... temporaneamente utilizziamo tutti questo open che fa pena (ma forse inizialmente poi nemmeno cosi' tanto)'
Il punto 2 e' importante perche' fin dal principio ho espresso la volonta' di portare le velocita' di elaborazione della cpu notevolmente in avanti rispetto alla piattaforma originale (e non intendo 20MIPS).
Quando mi sono riferito a FPGA molto costosi, intendo dispositivi che arrivano al GHz (non conosco specificamente quali perche' ho ignorato l'info, ma uno dei miei ingegnieri me ne ha parlato ieri) ma siamo completamente fuori dal target.

[schiumacal]

@ bertocar

Come azienda e progettisti in generale immagino avrete le giuste qualita' per realizzare un progetto del genere.

Un plauso al coraggio che dimostrate.

Pero' mi domando anche perché dover fare tutto da zero, quando invece potreste provare... e dico almeno provare a unire le forze con il Team di Natami e continuare lo sviluppo di questo sistema.

Ci sono tante persone sparse per il globo che non vedono l'ora di trovarsi tra le mani un sistema Natami bello e funzionante, ma cio' non avviene mai.

Allora se avete la forza finanziaria e le qualita' giuste per sviluppare una tale idea, perché non provare la strada di chi ha gia' iniziato da tanto e sviluppato tanto ?

In Natami gia' si parla di 68070 :-)
http://www.natami.net/68070.htm