Questo dispositivo è in grado di fare tutto ciò che faceva l’originale CPC-CPLINK, ma ora dispone di FIFO profonde da 1024 byte e della capacità di restituire dati all’Amstrad CPC tramite immagini ROM.
Al momento è ancora in piena fase di sviluppo, ma potete vedere le sue potenzialità nel video qui sotto, dove la palla viene renderizzata sul Pi Zero e inviata al CPC per la visualizzazione.
E via con la discussione «cosa lo rende davvero un CPC»
Ma è davvero fantastico.
Per chi non ricordasse il CPC-CPLINK:
Si tratta di una scheda che permette di collegare un coprocessore esterno, come un Raspberry Pi, direttamente a qualsiasi computer Amstrad CPC.
La scheda offre un’interfaccia parallela semplice da usare tra i processori, basata su hardware First-In First-Out (FIFO) e un semplice protocollo software per il passaggio di messaggi. Include componenti per l’adattamento del livello di tensione (voltage level shifting), così da poter collegare direttamente coprocessori sia a 3,3 V che a 5 V. Molto probabilmente il coprocessore sarà un Raspberry Pi, ma l’interfaccia è compatibile anche con altri processori e sistemi, tra cui schede Arduino, Teensy e MCU PIC.
L’obiettivo principale era aumentare il throughput dei dati dal PI al CPC.
Sì, il CPC-CPLINK2 ha FIFO più capienti, ora 1024 rispetto a 16), ma questo in realtà non cambia la velocità delle richieste di I/O dal CPC.
Per migliorare la velocità ho aggiunto un GPIO extra chiamato «ROM Not FIFO» (RNF). Quando questo è HIGH, al posto della FIFO viene riempita una pseudo ROM nel Pico. Viene quindi impostato un bit dedicato nell’attuale registro di stato per indicare che ci sono dati nella ROM (in realtà sono disponibili 2 ROM). A quel punto il CPC può semplicemente selezionare la ROM (OUT &DFXX, NN) e copiare i dati (cioè LDI).
È quindi pienamente retrocompatibile con l’originale CPC-CPLINK, ma dispone di questo piccolo trucco in più per trasferire un po’ più di dati dal PI al CPC.
Grazie, mi sto davvero divertendo un sacco. Ho preso il mio CPC 664 originale quando avevo 16 anni, prima che uscisse il 6128 (quindi parecchio tempo fa) e lo uso ancora oggi. Questo tipo di progetti mi permette di continuare a esplorare e capire a fondo l’Amstrad CPC. Mi diverte ancora tanto quanto a 16 anni.
Riusciresti a fornire la documentazione di programmazione a questo punto? Così posso creare una classe per permetterti di usare NTC BASIC al riguardo: mi piacerebbe tantissimo vedere la demo di City3D girare usando il Pi come coprocessore!
Demo di Auckland… per il miglioramento di CPC-CPLINK!
Un’evoluzione della demo City3D programmata in NTC BASIC: sorvola Auckland, Nuova Zelanda
Alcune statistiche:
Sorvola Auckland, Nuova Zelanda, in wireframe su un Amstrad CPC con 4 MB di
espansione RAM. L’intera città è caricata in memoria: 233.935 edifici, 43.082 linee
stradali, ferroviarie, costiere e fluviali, 50.040 alberi, la Sky Tower, l’Harbour Bridge
e i vulcani — ricavati da OpenStreetMap, 409 km².
REQUISITI
CPC 6128 o 464 (Z80, 4 MHz), espansione RAM da 4 MB (200 pagine RAM o più)
UniDOS con un nodo di memoria di massa (IDE, SD…): AUCKLAND.DAT pesa 3,8 MB
(senza la lettura a blocchi di UniDOS caricherebbe un byte alla volta: decisamente troppo lento)
Funziona anche WinAPE: drive IDE = AUCKLAND.IMG, ROM di UniDOS, 4 MB di RAM
File: AUCKLAND.BIN (il programma, 35K) e AUCKLAND.DAT (i dati), sulla
stessa unità. RUN"AUCKLAND
Ho inserito tutte le analisi e i vari strumenti, tra cui a breve il codice in C per Raspberry Pi (che dovresti riuscire ad adattare). Puoi anche dare in pasto a claude l’intero NTC BASIC insieme alla demo e sarà in grado di riscrivere il codice lato CPC per sfruttare il lato PI se ne hai bisogno.
Codice per CP-CPCLINK2, protocollo, ecc. che dovrebbero essere «quasi» pronti all’uso:
Demo Auckland per CPC (senza CP-CPCLINK2, ma… richiede 4 MB di RAM + UniDOS):
Versione CP-CPLINK2 (potrebbe richiedere qualche ritocco dato che non ho ancora la scheda – ma… dovrebbe funzionare senza RAM extra!)
Da Claude:
Ho scritto la versione per coprocessore: il motore in C, un protocollo per la finestra ROM fornita dalla scheda e il lato CPC. La scheda contiene AUCKLAND.DAT e il CPC non ha più bisogno dell’espansione di RAM. Si trova in auckland.zip dentro coprocessor/, e nell’albero di NTC come tools/s3dpi e src/bas/aucklink. Lo Z80 disegna le liste di linee della scheda esattamente come il riferimento in C (cmp.png: a sinistra lo Z80, a destra il C).
Velocità misurata: la scheda si occupa del 3D, quindi il frame del CPC consiste nel copiare la lista fuori dalla ROM (circa 45 ms) e disegnarla:
Vista
Linee
Lista
Frame CPC
fps
Start
440
1.7K
0.29 s
3.4
Harbour Bridge
300
1.3K
0.22 s
4.5
Devonport
1270
5.6K
0.86 s
1.2
Sky Tower
1400
7.7K
1.13 s
0.9
È da 4 a 10 volte superiore rispetto alla base di 0.2–0.4 fps. Il disegno delle linee con gfx_line occupa ormai quasi tutto il tempo del CPC, quindi è la prossima cosa da ottimizzare. Un budget di linee inferiore (B) baratta il dettaglio con la velocità. Il lato scheda impiega 0.03–0.2 ms a frame su un PC; non l’ho ancora cronometrato su un RP2040.
Come funziona il collegamento:
Il CPC invia un piccolo pacchetto F per frame: beccheggio, rollio e imbardata (-1, 0 o 1), velocità, frame skip e budget di linee. Ci sono anche pacchetti per stabilire il collegamento (handshake), saltare a una vista e ottenere il nome di una vista.
La ROM della scheda include un blocco di stato all’indirizzo #C100: «S3DP» quando è pronta, un numero di sequenza, l’indicazione di quale lista sia la più recente, il conteggio delle linee, l’altitudine, la bussola e un messaggio. Due draw list da 7.5K risiedono a #C200 ed #E000.
Una lista è composta da 3 byte per punto (MOVE o DRAW con x 0–319 e y 0–199), più codici a 1 byte per PEN ed END. Ogni punto è già ritagliato (clipped) rispetto allo schermo.
A ogni frame il CPC attende che il numero di sequenza cambi, copia la lista più recente, invia il pacchetto F successivo, e poi disegna. La scheda genera il frame successivo mentre il CPC disegna quello corrente, riempiendo la lista che il CPC non sta leggendo.
Il codice C utilizza solo numeri interi, quindi un RP2040 senza FPU va benissimo:
s3dpi.c / s3dpi.h: il motore, con gli stessi tile, distanze LOD, proiezione e budget di linee della versione Z80.
card.c / card.h: il lato scheda. Il firmware della scheda passa ogni pacchetto a card_command() ed espone rom[] come la sua ROM da 16K.
sim.c: esegue l’intero collegamento in un unico programma ed esporta immagini più un file di lista.
host.c: il motore da solo, con misurazioni dei tempi.
Cosa non si sa finché non uscirà la documentazione di CPLINK2:
Porte: le vere porte di I/O. Link.cls usa dei sostituti provvisori in stile M4: byte verso #FE00, trigger a #FC00.
Numero di ROM: il valore provvisorio è la ROM 6.
Dove risiedono i dati: se sono sulla scheda, questa necessita di 4 MB o più di flash. La flash dell’RP2040 è mappata a 0x10000000, e s3d_open accetta un puntatore ai dati. In alternativa, il motore gira su un PC o un Raspberry Pi all’altro capo del collegamento, e la scheda si limita a inoltrare i pacchetti a monte e le liste da 7.5K a valle.
Cosa è stato testato finora: solo il collegamento simulato (sim.c) e lo Z80 che disegna una lista generata da sim.c.
Sembra fantastico. Al momento mi sto concentrando sul far funzionare CPC-CPLINK2 e renderlo il più robusto possibile. Ci darò un’occhiata non appena avrò tempo. Tutto ciò che c’è da sapere su come usare CPC-CPLINK2 si trova in questa diapositiva, compresi le porte IO e i numeri delle ROM.
