Grazie. Non conoscevo il CPC-CPLINK2, ma ora che lo vedo, forse potrebbe beneficiare delle modalità DMA.
Documentazione aggiornata, aggiungendo l’utilizzo della modalità DMA 2D: PROGRAMMING.md · master · doragasu / romba-pi-src · GitLab
Penso che forse dovrei aggiungere i programmi BASIC che utilizzo per i test per integrare le spiegazioni su come usare le modalità DMA.
Sì, probabilmente aiuterebbe con il DMA, ma ho dovuto usare 8 GPIO per il lato dati del PI (GPIO 32..39), con i restanti GPIO 40..47 non tolleranti ai 5V anch’essi dedicati al PI. Quindi probabilmente mi mancano alcuni segnali del bus CPC.
Al momento sto solo usando una scheda di sviluppo.
Documentazione aggiornata con molte più informazioni:
- Informazioni più facili da comprendere (spero) su come utilizzare la modalità DMA 2D.
- Elenco dei registri DMA aggiornato.
- Aggiunti listati BASIC di esempio per leggere il mouse ed eseguire trasferimenti DMA lineari e 2D.
- Aggiunte informazioni su come eseguire i riempimenti DMA e trasferire dati anche dalla memoria interna del CPC.
Come sempre, è possibile leggerla nel repository: PROGRAMMING.md · master · doragasu / romba-pi-src · GitLab
Le recenti discussioni su Another World, relative a come il gioco giri su una semplice macchina a stati che dipende unicamente da una rapida routine di riempimento dei poligoni, mi fanno pensare che sarebbe un ottimo candidato per sperimentare le funzionalità DMA di questa cartuccia.
Allo stato attuale, i riempimenti DMA possono essere utili per disegnare rettangoli (incluse linee orizzontali e verticali). A parte questo, però, potrebbero non essere di grande aiuto.
Sicuramente un poligono può essere costruito a partire da linee orizzontali, no? O l’overhead è troppo elevato perché valga la pena fare qualcosa del genere?
I vecchi motori 3D software disegnavano i triangoli in questo modo: suddividendo i triangoli verticalmente e poi tracciando linee orizzontali.
Non sono sicuro che il DMA sia più utile per trasferimenti di dati in blocco piuttosto che per dati molto specifici e in continuo cambiamento.
Devi eseguire alcuni OUT per modificare le coordinate di riempimento e la lunghezza, e poi avviare il trasferimento. Quindi, per disegnare pochi pixel, potrebbe essere più veloce scriverli direttamente nel buffer.
Potresti fare cose come renderizzare poligoni sull’RP2350 e trasferirli via DMA, ma a quel punto la polizia del CPC verrebbe a bussare alla tua porta ![]()
Potresti persino far girare DOOM sull’RP2350, quantizzato per la tavolozza dei colori e la risoluzione del CPC, e trasferire i frame al CPC. Il trasferimento di un’intera schermata richiede circa 16,4 ms, quindi sarebbero possibili anche applicazioni come un lettore video a 50 FPS (hai anche fino a 16 MiB di ROM per archiviare il video).
Sto limitando le capacità DMA della cartuccia a ciò che un tipico blitter era in grado di fare all’epoca. Ma poter modificare l’intero contenuto dello schermo del CPC in meno di un frame permette di realizzare qualsiasi tipo di acceleratore, a patto che non ti dispiaccia che il rendering non sia eseguito dallo Z80.
Sembra interessante!
Adoro le funzionalità DMA: farebbero un’enorme differenza per ottenere framerate fluidi! ![]()
Se ne fai una serie, ne prenderò sicuramente uno!
Trovo le funzionalità DMA davvero interessanti! Continua così! Una domanda che mi pongo è: il 2350 potrebbe essere una daughterboard (ad esempio un modulo core) da poter saldare sopra? Semplificherebbe un sacco questa build
