Nuovo hw Amiga

[AMIGATV]

@bertocar

la scheda è di acube system di bassano e uno dei fondatori è l'utente heyvid, ti ha scritto qualche post precedente dove ti rispondeva sull'hdmi

[Amiga Blitter]

Il lattice XP ha delle tecnologie interessanti, come l'instant ON(ho detto la cosa sbagliata prima) il FlashBAK ed altre cosucce

http://www.latticesemi.com/products/fpga/xp2/

[legacy]

Questo è il PDF della 460:
http://www.acube-systems.biz/download/S ... l_v1.3.pdf
c'è un connettore di espansione ad 80 pin

Ho dato una rapida occhiata: la fpga e' sul local bus, ma il connettore di espansione e' gestito dalla fpga. bah ... per agganciare fpga esterne bisognerebbe programmare quella lattice come bridge verso il connettore, sui cui verra' innestata schedina con altra fpga (vantaggio + ciccia per LE, in primis).

Le lattice sono FPGA fabric with Flash non-volatile cells, la flash e' sempre + lenta della ram, mi aspetto che ci mettano molto + tempo per caricare il bitstream -> ti risparmi l'SPI fpga bootchip ma secondo me sono lenterrime da sviluppare.

Il connettore e' di 80 pin, direi che detta cosi' sono a pelo per gestirsi una acceleratrice softcore 68k, ma forse il problema non e' tanto emulare il 68k quanto AGA e li .... metterlo su fpga esterna significa nella soluzione + bovina avere due uscite video, una della SAM, quella che hai gia' ora, e una nuova offerta da questo accorcchio che fornisce funzionalita' AGA in hw, sempre che sia realmente utile/fattibile pratico poi la controparte support sw per offrire accelerazione support Amiga classic.

Al limite se il problema e' solo super Agnus che la SAM fa fatica a simulare, si puo' pensare anche di sintetizzare solo quel pezzo nella Lattice (ci sta ? boh, non ho guardato, non ho nemmeno i sorgenti di AGA, ancora li cerco), e cmq avresti 2 uscite video.

Boh, non e' banale. Direi, e' da studiare, a me non interessa, probabilmente questo progetto new Amiga Classic hw su fpga in topic potrebbe fornire materiale a chi e' interessato per sviluppare anche altro.

[BigAmyDream]

Vedo che su questo topic c'è molta discussione costruttiva.

Avendo letto gli ultimi post, mi sembra di aver capito che utilizzerà delle sodimm o delle dimm, questo mi piace perché si potrà risparmiare sulle spese di sostituzione e/o acquisto ram, spero che sia almeno DDR2, possibilmente di tipo per i portatili ovvero sodimm. Non tutti sono in grado di impugnare un saldatore

Però ho visto nei diagrammi la presenza di SRAM e non di RAM, non doveva esserci solo la RAM su un bus condivisa dai vari chip?

Il progetto sembra che stia iniziando ad assumere una certa forma, mi sembra di capire che nel progetto definitivo ci sarà solo la DVI per poter risparmiare linee IO per gli FPGA, penso che andrebbe bene perché esistono cavi DVI-HDMI, oppure convertitori DVI-VGA. Inoltre la DVI è completamente digitale per cui non c'è necessità di un convertitore D/A come accade per il VGA. Almeno è ciò che mi ricordo.

Per tutto il resto mi sembra che vada bene come configurazione, d'altronde è meglio lasciarlo fare a gente molto più esperta come bertocar, cdimauro e legacy. Stanno oltrepassando largamente il mio livello di conoscenza e sto imparando molto

Complimenti comunque a coloro che si stanno adoperando per realizzare tale progetto.

Ho un dubbio: se verrà realizzato e ci sarà una commercializzazione, quale sarà la modalità? Autonoma o mediante accordi con altre ditte?
Forse è troppo presto per pensarci, ma penso che ciò influenzerà la disponibilità di apparecchi in vendita, se mai il progetto arriverà alla realizzazione.

[cdimauro]

Trovi l'uscita VGA sia su JAY che su MITCHY perche' dovendo partire dal progetto minimig si pensava di creare una porta VGA 'temporanea' connessa a JAY che permetesse lo sviluppo (in pratica caricando minimig per DE2 su JAY dovrebbe funzionare subito). Poi con il tempo e con gli sviluppatori si spostera' la gestione della VGA su MITCHY perche' e' lo scopo per cui esiste e la VGA su JAY non verra' nemmeno montata nelle schede definitive.

Adesso chiaro. Certo, in questo modo lo sviluppo dovrebbe essere decisamente più semplice.

L'IDE dovrebbe occupare circa 20 i/o se non ricordo male ma non mi fascerei troppo la testa... da qualche parte lo inseriamo.

OK

Il problema del bus condiviso per la memoria non penso sia facile da risolvere perche' c'e' necessita' di un memory controller (dato che usiamo SDRAM, se usassimo SRAM non ci sarebbero difficolta' in quanto nessuno deve far refresh). JAY fara' da memory controller e servira' le richieste di MITCHY e della CPU con le priorita' che stabiliremo (ho dedicato 4 i/o diretti oltre al BUS a ogniuno di questi sottosistemi proprio per non trovarci nell'impossibilita' di gestirli bene e con una velocita' ottima).

Non vorrei che MITCHY dovesse fare anche da memory controller

La mia idea era diversa. Forse non sono stato abbastanza chiaro, per cui provo a descriverla in un altro modo.

L'idea è che non ci sia nessun memory controller. CPU, Jay e Mitchy si collegano tutti e tre direttamente all'unica memoria a disposizione, avanzando le loro richieste di lettura e scrittura. Tutti e tre sono collegati fra di loro con apposite linee in cui ognuno segnala agli altri due il suo stato ("voglio accaparrarmi il bus"), più qualche altra linea di controllo se dovesse servire, per cui ognuno ha integrato una parte della logica necessaria a decidere chi debba avere la priorità.
In questo modo i 3 componenti si gestiscono, da buoni fratelli, l'unica memoria a disposizione.

Sfruttando lo stesso meccanismo, la CPU accederà ai registri interni di Jay o Mitchy, che si comporteranno, quindi, come memorie.

Soltanto una delle 3 FGPA, quella più scarica, si occuperà di eseguire programmaticamente il refresh della memoria.

In questo modo si frutta all'osso la banda della memoria, e si dovrebbe anche semplificare il meccanismo di arbitraggio, che verrebbe sostanzialmente distribuito fra i 3 FPGA.

Non so se sia fattibile tutto ciò, specialmente con le risorse che sono a bordo.

perche' su MITCHY punto molto per migliorare la grafica (ricordiamoci che 1920x1080 sono un bel po' di pixel).

E servirà anche molta banda. La sola SDRAM è abbastanza limitata allo scopo, ma se riusciamo ad avvicinarci ai 4GB/s (teorici) prospettati, dovrebbe essere sufficiente. Altrimenti si dovrebbero valutare DDR e, soprattutto, DDR2.

Certo si creera' un traffico notevole tra JAY e MITCHY per la memoria video e questo potrebbe andare a discapito della CPU motivo per cui mi piacerebbe che avesse la sua RAM dedicata.

Rimarrebbe comunque il problema dell'accesso a questa memoria da parte di tutti gli altri componenti. Il fatto è che la chip ram su Amiga è accessibile da tutti: sezione video (bitplane + sprite), Copper, Blitter, disco, audio, e infine la CPU.

Anche se montassi della memoria dedicata per il solo chip video, dovresti comunque mettere in piedi un meccanismo che consenta a tutti gli altri di potervi accedere in lettura o scrittura.

Ecco perché ho avanzato la proposta di un bus unico condiviso da tutti: sia per semplificare l'accesso da parte di tutti alla memoria, che per massimizzarne l'utilizzo.

L'accorpamento dei bottoni, led e joystick e' possibile non consideriamo un'ostacolo quelle i/o.

OK

@Amiga Blitter. Come già detto, questo è un progetto completamente diverso, che non ha nulla a che vedere con le Sam. E, ripeto, una volta ultimato, nessuno impedirà di trasportalo tutto o in parte sulle Sam, a chi avrà voglia di farlo.

Di certo non puoi pretendere che si realizzi questo progetto tenendo conto delle esigenze delle Sam, visto che non c'entrano nulla, sprecando le già poche risorse a disposizione.

Se hai voglia di farlo tu questo lavoro, fai pure.

@BigAmyDream: siamo ancora agli inizi, e ci sono diverse cose da definire, come puoi vedere. Ma è importante parlarne bene ora per fissare le fondamenta.

[BigAmyDream]

@cdimauro
Hai ragione, è meglio porre correttamente le basi. Era solo per portare argomentazioni alla conversazione.

Penso che nella discussione del progetto, una volta arrivati, diciamo al layout "ottimale" della scheda, bisognerà anche considerare la "facilità" di produzione della scheda, da cui ne conseguiranno i costi pianificati per la componentistica e la fabbricazione del pcb. Questo perché vista l'appetibilità di siffatto progetto, sia pure limitata agli appassionati amiga, bisognerebbe garantire la disponibilità. Potrebbe non essere necessario includere subito l'eventuale sodimm nella configurazione in vendita, lasciando all'utente il compito di procurarsene una vista la larga disponibilità, se si adotteranno almeno le DDR2.

(Lo so bene che insisto sulle DDR2/3, ma questo andrebbe a vantaggio sia del produttore che del acquirente )

Infatti per me, come sola memoria di massa andrebbe benissimo la sola SD card, visto che i prezzi delle memorie di tipo flash(usb-stick, sdcard, microSD, etc.) stanno diminuendo, sia pure lentamente. In tal modo si risparmierebbero altre linee, privilegiando magari la connessione ethernet. Una scheda amiga classic like con la ethernet già integrata, DVI come uscita video con molta memoria a buon prezzo mi sembra molto invitante.

[bertocar]

@cdimauro

ho capito la configurazione che vorresti, la propongo ai miei tecnici e vediamo cosa ne viene fuori. In pratica chi si occupera' del REFRESH in realta' gestira' la RAM (stabilendo le priorita' e la disponibilita' della stessa: esempio se e' il momento di far refresh ha massima priorita'), gli altri 2 nel bus dovranno sempre 'chiedere' prima di poter utilizzare.
Questa potrebbe essere la configurazione iniziale perche' piu' semplice, poi la si potrebbe potenziare come hai ipotizzato tu senza dover cambiar nulla nell'hw.

A questo punto JAY gestisce refresh e priorita', ok?

[bertocar]

.............
Altra questione annosa e' l'uscita DVI (e HDMI). Per poter avere HDMI sembrerebbe necessaria una licenza di un forum di produttori che difficilmente la concede.
Invece DVI e' libera percio' dovra' essere una scelta obbligata.
La DE2 prevede un modulo opzionale con uscita HDMI, la settimana prossima provero' a vedere se riesco a reperirla con il modulo per poter fare test (e' un vantaggio non da poco poter testare l'hw prima di produrre la scheda). Fra l'altro la scheda prima versione assomigliera' molto alla DE2 in termini di capacita' (ha 64MB SDRAM e l'uscita VGA a 24BIT, e 35KLE ad esempio), fermo restando le 3 FPGA.

ciao, sei di Padova, strano che non ti conosco, eravamo un bel gruppo che ci trovavamo spesso in zona università, ma forse sei + giovane di me.

Per quanto riguarda il discorso HDMI, non è proprio così, esiste un consorzio e per usare l'hdmi sulla tua scheda devi pagare una royalty di molte migliaia di euro, quindi il mio consiglio è appunto di usare il DVI con annessa anche la parte analogica così l'utente con un adattatore dvi-vga ha già entrambi i connettori.

p.s. se servono connettori dvi te li posso fornire ne ho una certa quantità

ciao

Dipende da cosa intendi per giovane !

Allora ricordavo qualcosa ma non corretto per quanto riguarda HDMI, a questo punto ci sara' solo la DVI tanto con un banale connettore la si converte e che si tengano la royalty...

Ti ringrazio per l'offerta di connettori ma devo averne anche io qualche centinaio, in passato li avevo usati per un encoder video per applicazioni satellitari che avevamo fatto ma poi mai venduto mannaggia ai commerciali.

Alberto

[cdimauro]

@cdimauro
Hai ragione, è meglio porre correttamente le basi. Era solo per portare argomentazioni alla conversazione.

Siamo qui apposta, non ti preoccupare. I "desiderata" degli utenti possono diventare input per il progetto.

Penso che nella discussione del progetto, una volta arrivati, diciamo al layout "ottimale" della scheda, bisognerà anche considerare la "facilità" di produzione della scheda, da cui ne conseguiranno i costi pianificati per la componentistica e la fabbricazione del pcb. Questo perché vista l'appetibilità di siffatto progetto, sia pure limitata agli appassionati amiga, bisognerebbe garantire la disponibilità. Potrebbe non essere necessario includere subito l'eventuale sodimm nella configurazione in vendita, lasciando all'utente il compito di procurarsene una vista la larga disponibilità, se si adotteranno almeno le DDR2.

Capisco. Beh, se ci sarà uno slot SODIMM, come sembra, credo si potrebbe vendere la scheda senza memoria e lasciare all'utente decidere il "taglio" da utilizzare (anche se personalmente mi butterei sui 2GB per riempire completamente lo spazio d'indirizzamento).

(Lo so bene che insisto sulle DDR2/3, ma questo andrebbe a vantaggio sia del produttore che del acquirente )

Le DDR3 non sono supportate dai Cyclon III utilizzati. C'è supporto soltanto per SRAM, SDRAM (SDR), DDR, DDR2, e per le QDR (rare, e praticamente inesistenti nel mercato consumer).

Ma bisogna vedere quale decideranno di utilizzare i progettisti.

Infatti per me, come sola memoria di massa andrebbe benissimo la sola SD card, visto che i prezzi delle memorie di tipo flash(usb-stick, sdcard, microSD, etc.) stanno diminuendo, sia pure lentamente.

Il supporto all'SD c'è sicuro: è previsto fin dall'inizio. Vedremo per l'IDE poi.

In tal modo si risparmierebbero altre linee, privilegiando magari la connessione ethernet. Una scheda amiga classic like con la ethernet già integrata, DVI come uscita video con molta memoria a buon prezzo mi sembra molto invitante.

Tutto ciò è previsto. Il mio unico dubbio, al momento, è sul DVI, perché dipende dal tipo di FPGA che si sceglierà. DVI richiede troppe linee, e molto probabilmente costringerebbe all'utilizzo di un FPGA di tipo BGA, che pur essendo più economico è molto rognoso per i progettisti.

Se si facesse a meno del DVI, come nelle configurazioni di più basso profilo che ho elaborato, si potrebbero usare FPGA non BGA, ma dipende tutto dalle scelte che verranno fatte.

Visto che ne parliamo, m'è venuta in mente un'ideuzza a riguardo, che giro ad Alberto.
Considerato che la VGA finirà nella expansion port, sarebbe realizzabile una porta di espansione che includesse un FPGA il quale, partendo dai 29 segnali della VGA, tirasse fuori tutti i segnali del DVI (e magari includesse anche il connettore)? Magari la expansion port potrebbe prevedere connettori di tutti i tipi: VGA, DVI, S-VHS, Composito, Component, e sarebbe acquistabile soltanto da chi ne avesse bisogno.

@cdimauro

ho capito la configurazione che vorresti, la propongo ai miei tecnici e vediamo cosa ne viene fuori. In pratica chi si occupera' del REFRESH in realta' gestira' la RAM (stabilendo le priorita' e la disponibilita' della stessa: esempio se e' il momento di far refresh ha massima priorita'), gli altri 2 nel bus dovranno sempre 'chiedere' prima di poter utilizzare.
Questa potrebbe essere la configurazione iniziale perche' piu' semplice, poi la si potrebbe potenziare come hai ipotizzato tu senza dover cambiar nulla nell'hw.

A questo punto JAY gestisce refresh e priorita', ok?

Esattamente. Ma ricordiamoci che Jay dovrebbe anche tenere conto delle esigenze dei dischi e dell'audio, e in ultima analisi del video. Il motivo per cui nel chipset Amiga originale esistono gli slot di allocazione del DMA, è che in questo modo il sistema distribuisce e garantisce gli accessi alla memoria in modo da non arrivare a situazioni di grave conflitto nei contenziosi fra i dispositivi. Cosa succederebbe se si dovesse eseguire il refresh della memoria proprio mentre il disco, l'audio, o lo stesso video stia chiedendo l'accesso? Un disastro. Sincronizzando opportunamente gli accessi con gli slot allocati, questo non potrebbe succedere in nessun nodo.
Comunque ci penseremo a momento debito. Tanto è roba che va implementata per questioni di retrocompatibilità, e lì vedremo di applicare anche l'idea che ho avuto prima a riguardo. Teniamo soltanto presente che è vero che il refresh dovrà avere la priorità, ma che è meglio che ciò accada in momenti in cui non arrechi disturbo alle altre periferiche.

Nel frattempo, visto che il cervello non riposa mai , m'è venuta un'altra idea malefica per cercare di migliorare e ottimizzare al massimo gli accessi fra gli FPGA.

Posto che se la CPU, Jay, o Mitchy debbano accedere alla memoria, il funzionamento sarà quello descritto in precedenza, ho pensato che non sia necessario complicare le cose quando la CPU deve accedere a Jay o Mitchy, oppure quando questi due devono comunicare fra di loro. In buona sostanza, quando queste componenti non devono attingere dalla memoria, ma comunicare fra di loro, non è necessario che si comportino come memoria, ma è sufficiente che comunichino direttamente e immediatamente, al singolo ciclo di clock (quindi anche massima efficienza, a prescindere dalla velocità della memoria: si può lavorare a 400Mhz con FPGA di classe 8, e a 500Mhz con quelli di classe 6!).

Ti spiego in breve l'idea. Noi non abbiamo a che fare con una vera CPU e un vero chipset, ma con degli FPGA. Ogni FPGA è "cosciente" di far parte di un progetto, di avere un determinato ruolo, e che esistano altri FPGA con ben precisi ruoli. E' cosciente, e sa pure, che un certo FPGA ha un determinato numero di registri che sono mappati a precisi indirizzi.

Per semplificare, faccio un esempio pratico. Supponiamo che la CPU esegua un'istruzione che vada a impostare di rosso il colore dello sfondo dello schermo, scrivendo la word (16 bit) $0F00 all'indirizzo $DFF180. Internamente l'FPGA sa che il range $DFF000-$DFFFFF è riservato al chipset, e tramite una tabella interna (di un solo bit), utilizzerà i bit 11-1 (11 bit, escludendo il bit più basso quindi) per estrarre un bit e identificare a quale FPGA dovrà accedere (Jay o Mitchy). Capisce, quindi, che $180 vuol dire: devo accedere a Mitchy.

A questo punto, anziché inviare una generica richiesta di scrittura in memoria a $DFF180, seguendo fedelmente il protocollo di accesso alla memoria (con tutti i cicli che ciò comporta), attiva una modalità speciale usando le linee di controllo che condivide con gli altri due FPGA. Dice agli altri: "devo accedere a uno di voi due; esattamente a Mitchy". Una precisazione: questo ovviamente lo può fare soltanto se sa che il bus è libero.
Supponendo che sia libero, quindi, dice a Mitchy: "devo passarti un dato, $0F00, e lo trovi già nei 16 bit più bassi delle linee dati; il tuo specifico registro, di 16 bit di dimensione, è il $180 (da notare che manca il $DFF iniziale, perché sappiamo già che stiamo comunicando con uno dei due FPGA, per accedere a un suo specifico registro), e te lo indico nelle A15-A0 utilizzate normalmente con la memoria per il row o column address.

In questo modo in un solo ciclo di clock si può eseguire una scrittura o richiedere una lettura di uno specifico registro degli FPGA, in maniera semplice e velocissima, senza perdersi col protocollo di accesso alla memoria.

Che ne pensi? E' troppo malvagia come idea?

[bertocar]

@bertocar
cosa prevedi di usare per la ethernet ?

Se stiamo su 10MB utilizzo ENC28J60 stupido ma funziona altrimenti DM9000A o alternative, ce ne sono molte ovviamente

[bertocar]

@cdimauro

si l'idea e' molto buona perche' ci si deve sottoporre alle esigenze della ram solo quando realmente si deve accedere a ram invece tutto quel che riguarda i registri possono passare come decidiamo noi...

Non ha senso convertire il segnale VGA in DVI (sarebbe un lavoro enorme).

Allego lo schema aggiornato con riviste anche le questioni di i/o.
Quello che mi infastidisce abbastanza e' la gestione USB che richiede ben 30 i/o!

Nota per la questione RAM: non utilizzeremo SODIMM perche' sarebbe un passo troppo complicato ora. Per ora ci si limita a 64MB (la scheda comunque prevedera' la possibilita' di montarne 128MB) poi vedremo in futuro... penso sia gia' un bel passo rispetto ai vecchi Amiga

Ora che abbiamo abbastanza definito le cose direi che e' il caso di verificare cosa riusciamo a trovare come fpga che coprano le esigenze dei 3 dispositivi.

[cdimauro]

@cdimauro

si l'idea e' molto buona perche' ci si deve sottoporre alle esigenze della ram solo quando realmente si deve accedere a ram invece tutto quel che riguarda i registri possono passare come decidiamo noi...

Perfetto. Almeno qui andremo a velocità massima.

Non ha senso convertire il segnale VGA in DVI (sarebbe un lavoro enorme).

OK

Allego lo schema aggiornato con riviste anche le questioni di i/o.
Quello che mi infastidisce abbastanza e' la gestione USB che richiede ben 30 i/o!

Al limite si potrebbe spostare nella CPU, che dovrebbe avere qualche linea di I/O a disposizione.

Nota per la questione RAM: non utilizzeremo SODIMM perche' sarebbe un passo troppo complicato ora. Per ora ci si limita a 64MB (la scheda comunque prevedera' la possibilita' di montarne 128MB) poi vedremo in futuro... penso sia gia' un bel passo rispetto ai vecchi Amiga

Sì, al momento va bene così. Ho visto che hai usato l'IS45S16400F come chip di memoria, ma ha un bus a 16 bit. Inoltre dal diagramma che hai fornito noto soltanto 61 linee dedicata per l'interfacciamento alla SDRAM. Quindi ipotizzo che il bus dati finale sia soltanto a 32 bit, giusto? Non è uno spreco, visto che CPU, Jay e Mitchy usano comunque 64 linee per i dati?

Comunque al momento con SDRAM a 200Mhz e 32 bit di bus dati abbiamo poco meno di 800MB/s di banda teorica (quindi quella reale sarà meno) a disposizione. Appena sufficiente per visualizzare un'immagine FullHD 1920x1080 a 60Hz e 32 bit di colore (richiede 575MB/s di banda). Questo significa che anche semplicemente spostare una finestra sarà un'operazione "avvertibile" dall'utente, in quanto non fluida.

Ora che abbiamo abbastanza definito le cose direi che e' il caso di verificare cosa riusciamo a trovare come fpga che coprano le esigenze dei 3 dispositivi.

Ho visto che per Jay e Mitchy sono usate all'incirca 200 linee di I/O. Quindi non si potrà usare l'EP3C25Q240C8N, che ne ha soltanto 148, e si dovrà passare all'EP3C16F484C8N, che ne ha 346, o un suo "parente".
Non è troppo complicato avere ben 2 FPGA BGA?

[bertocar]

Sulla questione RAM attendevo qualche tua osservazione per capire cosa fare.
Il primo punto importante e' che la ram lavora a 200Mhz e difficilmente saranno tutti utilizzabili per leggere/scrivere dati. Io non sono esperto di memorie (il mio ing. oggi e' in ferie) ma per essere cauti, ipotizziamo il 50% percio' considerando il fatto che con 148i/o comunque non ce la facciamo (e che se c'e' un BGA ce ne possono essere 3 non cambia nulla) direi di fare un salto di qualita' con un bus verso la memoria a 128BIT con 8 x IS45S16400F (16bit*8) in parallelo che porterebbero ad avere 256MByte di memoria con una banda di 1600MB/s... spero basti

[bertocar]

Esiste una chat che possiamo utilizzare perche' ci sono alcuni dettagli che vorrei discutere al volo

[cdimauro]

Sulla questione RAM attendevo qualche tua osservazione per capire cosa fare.
Il primo punto importante e' che la ram lavora a 200Mhz e difficilmente saranno tutti utilizzabili per leggere/scrivere dati. Io non sono esperto di memorie (il mio ing. oggi e' in ferie) ma per essere cauti, ipotizziamo il 50%

Io ipotizzerei un 75/80%. Il display, che è quello che si "mangia" la fetta maggiore, ha un accesso abbastanza lineare alla RAM.

percio' considerando il fatto che con 148i/o comunque non ce la facciamo (e che se c'e' un BGA ce ne possono essere 3 non cambia nulla) direi di fare un salto di qualita' con un bus verso la memoria a 128BIT con 8 x IS45S16400F (16bit*8) in parallelo che porterebbero ad avere 256MByte di memoria con una banda di 1600MB/s... spero basti

Sono 3,2GB/s teorici. Mettiamo un 75% di efficienza, e siamo a 2,4GB/s "reali. E' un ottimo valore per un SuperAmiga.

Comunque per la CPU potremmo riuscire a farcela con l'EP3C25Q240C8N: 128 linee di I/O per i dati + 9 DRAM control + 4 DRAM CS selection + 4 Bus control, e siamo a 145 linee. Ovviamente dovremmo rinunciare alla SRAM dedicata per la CPU, ma non è una tragedia.

Per Mitchy e Jay, invece, servono FPGA con molte più linee di I/O.

Esiste una chat che possiamo utilizzare perche' ci sono alcuni dettagli che vorrei discutere al volo

Ti mando in privato il mio contatto Skype.