Nuovo hw Amiga

[cdimauro]

Non risolverebbe il problema, perché comunque per simulare l'Amiga devi per forza implementare il meccanismo degli slot riservati e di quelli a priorità. Non si scappa. Poi la presenza di SRAM dedicata per la sezione video e/o CPU aumenterebbe i costi (si andrebbero ad aggiungere alla DRAM), oltre a complicare la vita agli sviluppatori, che dovrebbero sbattere la testa su come utilizzare al meglio questi tipi di memorie diverse (francamente mi è già bastato avete a che fare con la slow-RAM).

[bertocar]

Ok avendo tu esperienza nella programmazione seguo il tuo consiglio.
Percio' la piattaforma come la avevo ipotizzata questa mattina potrebbe andare?
Oggi ho studiato l'implementazione su FPGA del controller DRAM e non e' complicato.
Questo conferma che possiamo seguire la strada con 3 FPGA di cui uno che funge da CHIPSET e a sua volta MC (memory controller). Comunque in fase di progetto anche se poi non vengono montate prevedo la possibilita' di aggiungere DRAM e non SRAM di supporto alla CPU e al chip VIDEO. Costano veramente poco ed e' un peccato non lasciarsi la strada aperta. Tanto comunque per avere compatibilita' Amiga inizialmente non sono utilizzabili.

Nella piattaforma originale Amiga, chi gestiva il refresh della memoria?
E' uguale dall'A500 al A4000?

[sabbate]

Siete dei grandi!!

L'anno prox nuove belle cose.

[cdimauro]

Ok avendo tu esperienza nella programmazione seguo il tuo consiglio.
Percio' la piattaforma come la avevo ipotizzata questa mattina potrebbe andare?
Oggi ho studiato l'implementazione su FPGA del controller DRAM e non e' complicato.
Questo conferma che possiamo seguire la strada con 3 FPGA di cui uno che funge da CHIPSET e a sua volta MC (memory controller). Comunque in fase di progetto anche se poi non vengono montate prevedo la possibilita' di aggiungere DRAM e non SRAM di supporto alla CPU e al chip VIDEO. Costano veramente poco ed e' un peccato non lasciarsi la strada aperta. Tanto comunque per avere compatibilita' Amiga inizialmente non sono utilizzabili.

Nella piattaforma originale Amiga, chi gestiva il refresh della memoria?
E' uguale dall'A500 al A4000?

Per quanto riguarda la chip-RAM, il refresh è lo stesso per il 500 e il 4000. Per la fast-RAM di quest'ultimo non sono informato, ma credo abbia una circuiteria dedicata.
Per rispondere alla tua prima domanda, non sono molto d'accordo sulla possibilità di inserire sram o dram dedicata a CPU o chp video per quanto detto prima.
Preferisco un design molto più semplice, con un solo controller per la RAM, che raccolga tutta banda di memoria e la distribuisca secondo gli schemi discussi. Va bene avere 3 FPGA, non è questo il problema.
Se hai ancora dubbi ne possiamo parlare più appronditamente. Ho parecchia esperienza nella programmazione dell'hardware dell'Amiga, e posso cercare di farti capire il perché di certe scelte ed errori che è meglio non ripetere.

[bertocar]

Ok chiaro... semplicita' innanzi tutto e questo va bene.
Non sara' facile mantenere la compatibilita' di come era stato architettato e allo stesso modo ampliarne le funzionalita'.
Conto sul tuo supporto visto la tua esperienza di programmazione HW.
Faro' un prototipo in piu'

[cdimauro]

Sì, l'arbitraggio degli accessi alla memoria è sicuramente la funzionalità più complicata e delicata da implementare, però si può guardare al Minimig, che le ha già implementate (e migliorate: consente di accelerare l'accesso al disco e il funzionamento del Blitter, ad esempio).

Quanto alle nuove funzionalità, ho alcune idee su come implementarle sfruttando il funzionamento esistente dell'hardware. È importante vagliare bene queste cose, per non ritrovarsi con un frankenstein difficile da gestire e da programmare rispetto al passato, ma fortunatamente esperienza e visione non mancano.

[legacy]

come hanno risolto l'accesso al disco e il funzionamento del Blitter in modo + accelerato sul Minimig v1 ?

[cdimauro]

Non ho letto i VHDL (mi pare utilizzino questo e non i Verilog), ma conoscendo il funzionamento dell'hardware dell'Amiga credo che abbiano raddoppiato o quadruplicato il numero di slot a disposizione per disco e Blitter, se la rispettiva funzionalità risulta abilitata.

Mi spiego meglio. Nell'Amiga funziona tutto a livello di raster line, e al suo interno di color clock, che possiamo chiamare per semplicità "slot". Quando una riga video dev'essere visualizzata, ci sono 227 slot da "assegnare" alle varie periferiche: refresh DRAM (4), disco (3), audio (4), sprite (1 + 7), e poi un certo numero che si spartiscono il display (numero fisso: dipende dalla risoluzione scelta e dal numero di bitplane), il Copper, il Blitter, la CPU. Questi ultimi tre prendono ciò che rimane degli slot a disposizione, esattamente con questa priorità (il Copper ha la precedenza, la CPU è l'ultima ruota del carro).

Il clock dell'Amiga che regola l'accesso alla chip-ram funziona a 7,09Mhz (PAL; 7,16 per NTSC), mentre il color clock è esattamente la metà (3,54M color clock o slot), perché un accesso alla RAM richiede esattamente 2 cicli di clock.

Nel Minimig l'accesso alla RAM mette avviene con un clock di 28Mhz anziché di 7Mhz (per semplificare ho tolto di mezzo le frazioni), quindi esattamente il quadruplo. Quindi immaginiamo che con uno slot assegnato dal vecchio Amiga si possano in realtà eseguire 4 accessi alla memoria anziché soltanto uno.

Per ottenere una questione di compatibilità coi giochi, per audio, sprite, display e Copper, dei 4 accessi alla memoria per slot ne verrà sicuramente impiegato soltanto uno. Mentre se è abilitata l'accelerazione del disco o del Blitter, è possibile sfruttare tutti e 4 gli accessi, in modo da velocizzare l'operazione di lettura/scrittura del disco o quelle grafiche.

Ovviamente per una perfetta compatibilità anche per disco e/o Blitter si dovrà utilizzare un solo accesso alla memoria per slot, come per gli altri casi, ma ci sono giochi che non sono "sensibili" all'accelerazione di queste due componenti e che, quindi, ne possono beneficiare.

Infatti generalmente per il disco è così: viene avviata l'operazione (di lettera, usualmente), e tramite interrupt o polling dell'apposito flag si aspetta che venga completata, per poi passare alla decodificare dei dati MFM letti. Ci possono essere giochi scritti stupidamente che potrebbero assumere che, invece, dopo un tot di raster line o di cicli di clock della CPU i dati siano stati letti, e quindi potrebbero non funzionerebbero velocizzando l'accesso al disco. Credo, però, che siano molto rari, quindi della velocizzazione dell'accesso al disco dovrebbero beneficiarne praticamente tutti, e quindi è una gran cosa.

Per il Blitter la situazione è MOLTO più delicata, perché la sua lentezza "certificata" (dall'Amiga Hardware Manual) è stata sfruttata per sincronizzare i giochi col pennello elettronico nel caso in cui questi richiedessero più di un fotogramma per preparare e visualizzare i dati.

Tradotto in altri termini, i giochi che funzionano a 50Hz/FPS non trarrebbero alcun vantaggio da un Blitter 4 volte più veloce (continuerebbero a girare a 50Hz), mentre quelli a 25Hz/FPS potrebbero non funzionare perché il gioco potrebbe arrivare a girare a 50Hz, facendo sballare i calcoli, l'aggiornamento dei dati, l'audio, e altro: in pratica il gioco girerebbe "accelerato", a 50Hz oppure con un frame rate variabile fra i 50 e i 25Hz.

I giochi che, invece, sono stati pensati per girare a un frame rate variabile, dovrebbero trovare quasi sicuramente beneficio dal Blitter 4 volte più veloce, perché sarebbero molto più fluidi. Fra questi dovrebbero rientrano tutti quelli 3D, ma anche qualcuno 2D abbastanza famoso (Mortal Kombat e, credo, anche Street Fighter 2).

Aggiungerei ovviamente anche il sistema operativo, che sicuramente beneficerebbe moltissimo dal Blitter velocizzato (ma anche del disco), perché è stato realizzato in modo da essere agnostico riguardo al numero di frame al secondo da visualizzare.

In linea teorica, visto che per ogni slot ci sono 4 accessi alla memoria, e audio, sprite, display e Copper quasi sicuramente ne usano soltanto uno (per una questione di compatibilità / perfetta sincronizzazione), il Blitter potrebbe sfruttare i rimanenti 3 accessi e andare, quindi, anche MOLTO più veloce.
Ma penso che per semplificare la progettazione della logica quelli del Minimig si siano limitati a rispettare soltanto l'assegnazione degli slot (slot tutto libero o tutto occupato), senza distinguere quindi l'occupazione degli accessi alla memoria.

Nei miglioramenti al nuovo progetto si dovrebbe, invece, andare oltre la mera logica slot libero/occupato, slegandosi dagli slot e passando a un sistema di regolazione più fine degli accessi, con un "arbitro" che dovrebbe consentire di eseguire il prefetch dei dati per le periferiche "sensibili" (floppy, audio, sprite, ed eventualmente l'hard disk) con un po' di anticipo rispetto al display.

Non mi preoccupa che le periferiche sensibili possano avere problemi con la logica del display, perché con tutta la banda a disposizione rimarranno sempre parecchi accessi disponibili per tutte le altre periferiche (che peraltro richiedono molta meno banda, quindi le loro richieste saranno sempre facilmente servibili). Soltanto per quelle sensibili (e anche per il Copper, comunque, che dev'essere sincronizzato col display) si deve soltanto predisporne l'accesso con un buon margine di anticipo rispetto al display, in modo tale che quando questo abbia bisogno di prelevare i suoi dati possa tranquillamente fungere da master senza "rompere" niente nel sistema.

[bertocar]

cdimauro, tu possiedi una minimig o simile?
Se non lo conosci gia', ti conviene iniziare a studiarti VHDL

Come chiamano questi slot di cui parli nella documentazione di programmazione hardware di Amiga?

[cdimauro]

cdimauro, tu possiedi una minimig o simile?

No.

Se non lo conosci gia', ti conviene iniziare a studiarti VHDL

Mi ha sempre affascinato, ma pur essendo perito in automatica elettronica, l'elettronica non l'ho mai digerita (tranne la digitale), per cui me ne sono tenuto alla larga.

Anche se il VHDL mi consente di programmare gli FPGA, e quindi potrebbe rientrare nel mio ramo, non è sufficiente per realizzare un dispositivo, perché si deve tenere conto di cose che vanno oltre la mera logica booleana.

Purtroppo ho avuto un pessimo professore di elettronica, che mi ha fatto letteralmente odiare l'analogica & annessi (compreso il saldatore).

Come chiamano questi slot di cui parli nella documentazione di programmazione hardware di Amiga?

Per la precisione si chiamano DMA Time Slot Allocation.

Lo schema completo del loro funzionamento, preso dall'Amiga Hardware Manual di Commodore, l'ho pubblicato qui.

[cdimauro]

A scanso di equivoci, non ho nulla contro VHDL (e Verilog). Semplicemente credo che non basti conoscerlo per poterci lavorare e tirare fuori un progettino come Minimig o questo nuovo, perché servono altre conoscenze che vanno oltre alla mera programmazione (quindi mettere nero su bianco la logica di funzionamento).

Ho, comunque, in programma di studiarmelo e lavorarci perché fra i (tanti) progetti che ho nel cassetto c'è quello di sintetizzare il core di alcune CPU che ho progettato. Ma non so ancora quando, perché ho diverse cose più importanti da fare prima.

[legacy]

OK, thanks.

Da Doc Amiga. Approfondisco.

Agnus

Il chip Agnus coordina il funzionamento dell'intero chipset. Tutte le operazioni sono sincronizzate con il pennello video, compreso l'accesso alla RAM dedicata al chipset, detta per questo chip RAM. Il microprocessore centrale 68000 e gli altri membri del chipset si contendono l'accesso alla RAM tramite Agnus. In termini di architettura degli elaboratori, si parla di accesso diretto in memoria (in inglese: Direct Memory Address, DMA), e Agnus è il DMA Controller (DMAC).
Agnus gestisce 25 canali DMA per il chipset con una complessa politica basata su priorità. Poiché il processore 68000 normalmente accede alla memoria ogni due cicli di clock della RAM, Agnus di preferenza effettua gli accessi per il chipset solo durante i cicli dispari, lasciando quelli pari alla CPU, che in questo modo non viene rallentata. Questa pacifica coesistenza viene però messa in crisi quando si scelgono modalità video con più di 4 bitplane in bassa risoluzione (o 2 bitplane in alta risoluzione): in questi casi Agnus comincia ad accedere alla RAM anche nei cicli pari, rallentando la CPU. Anche il blitter, se attivato, può sottrarre cicli alla CPU, specie se si imposta il bit "Blitter Nasty": in questo caso Agnus può negare alla CPU ogni ciclo pari, se richiesto dal blitter.
Le temporizzazioni di Agnus si misurano in "colour clock" di 280 ns, equivalenti a due pixel in bassa risoluzione (140ns) e a quattro pixel in alta risoluzione (70ns). Come per Denise, queste temporizzazioni erano progettate per gli schermi delle TV domestiche, e possono essere sincronizzate ad una sorgente esterna di clock.

Blitter
Il blitter è un sub-componente di Agnus. "Blit" è l'abbreviazione di "block image transfer" (trasferimento di immagini a blocchi) o bit blit. Il blitter è una unità ad alto parallelismo in grado di effettuare trasferimento di blocchi di memoria e operazioni logiche. Ha tre modi di funzionamento: copia di blocchi di memoria, riempimento di poligoni e tracciamento di linee.
Il blitter consente la copia rapida di memoria video, lasciando libera la CPU per altre operazioni. Il blitter era usato principalmente per disegnare sullo schermo immagini grafiche dette "bob", abbreviazione di "blitter object".
In modalità di copia il blitter prende da zero a tre sorgenti in memoria, dette A, B e C, ed esegue su di esse una funzione booleana programmabile. Il risultato viene (eventualmente) scritto in un'area di destinazione, D. Queste aree possono sovrapporsi, e tutti i blocchi devono essere allineati a 16 bit. Il blitter può operare sui blocchi sia dall'inizio alla fine, in modalità detta "ascendente", sia al contrario, in modalità discendente.
I blocchi sono "rettangolari"; hanno una larghezza in multipli di 16 bit, un'altezza misurata in linee, e un passo, ovvero lo scostamento fra la fine di una linea e la successiva. Questo consente al blitter di operare in qualsivoglia risoluzione video. Durante la copia viene eseguita automaticamente un'operazione logica sui singoli pixel, descritta tramite mintermini. Operazioni tipiche sono la copia (D = A), o l'applicazione di una maschera di pixel attorno agli oggetti blittati (D = A AND C). La copia può anche far scorrere (shiftare) ogni linea di fino a 15 pixel, la qual cosa consente al blitter di disegnare a coordinate orizzontali che non siano necessariamente multiple di 16 pixel.
In modalità di tracciamento linee, il blitter disegna linee spesse un pixel usando l'algoritmo di Bresenham. Può anche applicare alla linea un pattern di 16 bit. Nella modalità di riempimento il blitter opera per linee orizzontali, riempendo intervalli orizzontali compresi fra due pixel accesi. Per ogni linea, legge ogni a turno ogni pixel da sinistra a destra; quando legge un pixel a uno, inizia a riempire tutti i bit che seguono fino al successivo bit a uno o alla fine della linea. Insieme, questi modi consentono al blitter di disegnare poligoni singoli monocolori, anche se molto lentamente al confronto con i moderni chipset grafici 3D o anche con la stessa CPU di un Amiga accelerato.

Copper
Il copper è un altro subcomponente di Agnus. Il nome è un'abbreviazione di "co-processor". Il copper è una macchina a stati finiti programmabile che esegue un flusso di istruzioni sincronizzato con l'hardware video.
Quando è in funzione, il copper ha tre stati: lettura di un'istruzione, esecuzione, o attesa che il pennello video raggiunga una specifica posizione dello schermo. Il copper esegue un programma (detto copper list) in parallelo con la CPU principale, sincronizzato al pennello video e può essere usato per effettuare varie operazioni che richiedono sincronizzazione con il video. Più comunemente viene usato per controllare l'uscita video, ma può scrivere in qualsiasi registro del chipset e pertanto può controllare anche l'audio o mandare un'interruzione alla CPU.
La copper list ha tre tipi di istruzione, ognuna delle quali è composta da una coppia di parole di 16 bit, per un totale di quattro byte.
L'istruzione MOVE scrive una parola di 16-bit in uno dei registri del chipset.
L'istruzione WAIT blocca il copper fino al raggiungimento di una data posizione video, rendendo così possibile la sincronizzazione di altre istruzioni al tracciamento dello schermo. Può anche attendere che il blitter finisca un'operazione.
L'istruzione SKIP farà sì che il copper salti l'istruzione successiva se è già stata raggiunta una data posizione del pennello video. Può essere usata per creare cicli nelle copper list.
La lunghezza di una copper list è limitata dal tempo d'esecuzione. Il copper riavvia l'esecuzione della copper list all'inizio di ogni quadro video. Non esiste una istruzione "end" esplicita, al suo posto viene usata l'istruzione WAIT per attendere una posizione video irraggiungibile.

Usi del copper
Il copper viene comunemente usato per (ri)inizializzare i registri dell'hardware video all'inizio di ogni quadro video. Può essere usato anche per modificare l'hardware video durante il tracciamento di un quadro. Questo consente all'Amiga di cambiare la configurazione video, compresa la risoluzione, da una linea all'altra. L'Amiga può visualizzare diverse risoluzioni orizzontali e diverse profondità di colore nello stesso schermo. L'interfaccia grafica dell'AmigaOS consente a due programmi di funzionare con due risoluzioni video distinte, pur essendo entrambi visibili contemporaneamente sullo schermo. Un programma di disegno può ad esempio usare questa caratteristica per consentire agli utenti di disegnare direttamente su uno schermo Hold And Modify a bassa risoluzione, offrendo contemporaneamente una barra degli strumenti in alta risoluzione in cima o in fondo allo schermo.
Il copper può anche cambiare i registri dei colori ad ogni linea di scansione, creando gli effetti "raster bar" tanto comuni nei giochi dell'Amiga. Il copper può fare anche di più, come cambiare il colore di sfondo abbastanza spesso da visualizzare una grafica a blocchi senza usare del tutto i bitplane.
Il copper consente di riusare gli sprite: dopo che uno sprite è stato visualizzato una prima volta, il copper può muoverlo immediatamente ad una nuova locazione, facendolo disegnare nuovamente anche sulla stessa linea di scansione.
Il copper può anche essere usato per programmare ed attivare il blitter. Ciò è utile per fare più operazioni in sequenza col blitter, in quanto il copper può aspettare che il blitter termini un'operazione e riprogrammarlo subito dopo per l'operazione successiva.
Il copper può essere usato per produrre il modo video "sliced HAM", o S-HAM[1], che consiste nel costruire una copper list che modifichi la tavolozza dei colori ad ogni linea di scansione, migliorando la scelta dei colori di base nel modo grafico Hold And Modify.

In particolare Amiga "OCS" chip design.

[legacy]

porting minimig v1 per Altera Terasic DE1 and DE2 Board
code at https://github.com/rkrajnc/minimig-de1
pack at -> https://github.com/downloads/rkrajnc/minimig-de1/minimig-de1-rel5.zip

[bertocar]

Gia' pronti all'uso
Domani mi consegnano le DE1 e vediamo (speriamo che riesca a salvarmi dalla moglie)

[cdimauro]

@legacy: ti odio quando scrivi degli interessantissimi messaggi, ma poi editi e cancelli tutto.