[WIP] RC2040 - der RPi Pico als RC2014 Emulator

Ist noch frueh in der Alpha Phase, aber ich wurde aufmerksam drauf durch diese Seite von Extreme Electronics

Auf Twitter gab es zumindest schon einen der es nachgebaut hat und ich habe mich heute auch mal - aber noch nicht erfolgreich - versucht.

Durch die Hilfe von Brian Welsby (@TheFlyingKipper) auf Twitter habe ich unter armbian das RPI Pico 2040 SDK aufgesetzt und den Source der 0.0.2 Alpha als .UF2 compilieren koennen.

Nur mit der "Kabel-age" fuer die SDCard bin ich mir noch nicht sicher, da im original Circuit PDF nur die SDCard Pin-Namen genutzt werden und nicht die SPI-Namen (wie MISO/MOSI).

Das Bild mit dem Pico ohne BreadBoard ist von Brian Welsby, da habe ich mal versucht die SPI-Belegung rauszufinden und drauf geschrieben.

Im Moment habe ich keinen Output ueber USB, aber auf der seriellen bekomme ich ein "USB-INIT OK" - allerding meckert mein PC wenn ich die serielle verbinde, dass er das USB-device (den Pico auf normal COM10) nicht mehr erkannt hat.

SDCard und deren Inhalt sollte passen (ein .bin und ein .cf-file aus den SD-Card-Contents)

Aber ich bleibe da dran

Das "Problem" war doch etwas kleiner
Der Prompt kommt bei USB so frueh, dass die Konsole es bei mir nicht mit bekam

Brian sagte ich sollte mal "Space" druecken - und tadaa jetzt kommt auch Output per USB

(will man den Output seriell muss man gemaess Schaltplan GPIO21=Pin27 nach GND verbinden)

Zum leichteren Zugriff auf die Laufwerke A:-P: mit den cpmtools gibt es in dem Goolge-Groups-Archiv einen netten/hilfreichen Thread mit dem man durch die dort enthaltene defs-Datei direkten Zugriff auf die Laufwerke A:-P: hat, obwohl diese im .img/.cf Image-File liegen.

rc2014a = Laufwerk A:
rc2014c = Laufwerk C:
Beides mal hier User 0:

Zitat von guidol

Zum leichteren Zugriff auf die Laufwerke A:-P: mit den cpmtools gibt es in dem Goolge-Groups-Archiv einen netten/hilfreichen Thread mit dem man durch die dort enthaltene defs-Datei direkten Zugriff auf die Laufwerke A:-P: hat, obwohl diese im .img/.cf Image-File liegen.

Es braucht aber einen "kleinen Umweg" fuers saubere funktionieren der cpmtools, weil ein .cf (IDE Disk format file) im Gegensatz zu einem .img File einen 1Kb Header (vorne dran) hat (holds meta-data and the virtual identify block)

D.h. bevor man die cpmtools nutzen kann fuer Laufwerk A: - P: muss man entweder den header wegschneiden -
oder wie wir hier - nehmen uns das Standard 128MB .img (15x 8MB + 1x 2MB (P:) -Laufwerk fuer A: - P:) - kopieren unsere Software drauf und erstellen ein neues .cf mit dem 1Kb Header vorne dran.

Die Befehle/Links habe ich mal (eher in Source-Schreibweise) mal zusammengestellt:

 // CPM_RC2040.cf     = https://github.com/ExtremeElectronics/RC2040/raw/main/SD%20Card%20Contents/CPMIncTransient.zip
// CPM128MB_org.img  = https://github.com/RC2014Z80/RC2014/raw/master/CPM/CPM%20128MB%20inc%20transient%20apps.zip

// Google Groups thread about the comtools diskdef for .img files
// search for rc2014cf-cpmtools-diskdefs.txt
// from <irjustman@gmail.com> 18.05.2017, 13:46:14 through RC2014-Z80

// Info from https://github.com/EtchedPixels/RC2014/blob/master/OUTDATED_INSTRUCTIONS.md
// In other words the IDE disk format (.cf) has (additionally to the .img )
// a 1K header that holds meta-data and the virtual identify block.

// Extrating the 1K header from the original 512MB CPM_RC2040.cf
dd if=./CPM_RC2040.cf bs=512 count=2 of=./CF1k_Header.bin

// Creating a working copy of the CPM128MB_org.img
cp ./CPM128MB_org.img ./CPM128MB.img

// copying Worstar to Drive O: on the working copy 
cpmcp -f rc2014o ./CPM128MB.img /toshiba/wordstar/*.* 0:

// copying some software to Drive A: on the working copy 
cpmcp -f rc2014a ./CPM128MB.img ../RUNCPM/*.* 0:

//checking copied files on drive a in the working copy
cpmls -f rc2014a ./CPM128MB.img

// creating NEW CPMIncTransient.cf out of the 1K header and 128MB working copy
// creating with > a NEW CPMIncTransient.cf with the content of the 1K header
dd if=./CF1k_Header.bin > ./CPMIncTransient.cf

// appending the 128MB working copy with >> to the a NEW CPMIncTransient.cf
dd if=./CPM128MB.img >> ./CPMIncTransient.cf

Nach ein wenig lesen fand ich den Befehl um im RP2040-SDK den Pico von seinen Standard 125Mhz auf 250Mhz zu overclocken (wie man es auch in der ARDUINO IDE machen kann):

set_sys_clock_khz(250000, true);

Diesen Beghl habe ich an der richtigen Stelle in der RC2040.c (im Bereich nach dem "main") eingefuegt und RC2040 neu compiliert.... (.UF2 und .c im Anhang)

Nun laeuft er doppelt so schnell

Ich glaube ich habe das/mein Problem geloest beim Zugriff mit cpmtools auf die .cf-Datei, die im Verleich zu einer .img Datei einen 1K-header hat.

Bei diskdefs, die ich bis jetzt gefunden hatte wurde ab Laufwerk B: (fuer Dateien die 8MB Laufwerke A:-O: und 2MB fuer P: enthalten) immer ein offset pro Partition von 512 Tracks angegeben.

Wenn man diese mit einer .cf Datei nutzt bekommt man zwar richtige Directory-Anzeigen aber beim kopieren/loeschen geht es dann "in die Hose".

Um nun den 1K Header mit ins offset zu bekommen, kommt uns zu Hilfe dass ein Sector 512 Bytes hat - also 2 Sectoren der Groesse des Headers entsprechen

Wenn wir das offset in der diskdef nicht mehr in Tracks (trk) sondern in Sectoren (sec) angeben, koennen wir "netterweise" einfach beim offset der Partiton im im Verhaltnis zum Start des Image einfach 2 Sectoren dazuzaehlen.

Pro Partition gibts da einen Abstand von 16384 Sectoren (512 Tracks mal 32 Sectoren)

Gehen wir also davon aus, dass Laufwerk A: einer 0 entspricht und somit Laufwerk P: 15

ergibt gibt sich folgende Formel fuer die offset-Option in der diskdef

offset = 2 (=2x512 bytes fuer den header) + ( Laufwerknummer/-wert * (512 Tracks mal 32 Sectoren))

rc2040a   offset  2sec
rc2040b   offset  16386sec
rc2040c   offset  32770sec
rc2040d   offset  49154sec
rc2040e   offset  65538sec
rc2040f   offset  81922sec
rc2040g   offset  98306sec
rc2040h   offset  114690sec
rc2040i   offset  131074sec
rc2040j   offset  147458sec
rc2040k   offset  163842sec
rc2040l   offset  180226sec
rc2040m   offset  196610sec
rc2040n   offset  212994sec
rc2040o   offset  229378sec
rc2040p   offset  245762sec

Das Ganze habe ich dann mal in eine diskdefs fuers RC2040 gepackt und auch erfolgreich getestet
D.h. ich muss das .cf nicht mehr zum .img auseinander nehmen und kann direkt mit dem .cf arbeiten.

Der Emulator hat schon einige Spruenge - jetzt auf v0.0.7 - gemacht und einige Features dazu bekommen

Nebenbei habe ich mal ein -besseres- Bild zum Anschluss eines SPI SDCard-Modules erstellt...

Heute kam aus London von Extreme Electronics (Derek Woodroffe) mein RC2040-Kit

D.h. Platine und Bauteile (bis auf den Pico).

Bis jetzt habe ich eher wenig geloetet (eher mal Pins an den Pico oder Stecker/Kabel - aber nichts "groesseres).

So war dies heute mein erstes Kit (OK - auch wenn es klein und uebersichtlich ist)

Ich musste nachschauen, welche Widerstande welche Werte hatten, wie rum man die LED einloetet und wie man die Pushbuttons einloetet, dass die dann auch schalten koennen

Nach dem einlesen klappte dies ganz gut. Etwas geweigert hat sich das einloeten des Pico, weil ich den mit den Pins fuers Breadboard auf die Platine gelotet hab.

So stehen die Pins unten etwas weiter raus... deshalb konnte ich die normalen Spacer und Schrauben nicht nutzen um die Acrylplatte anzubringen.
Aber meine Alternative hat auch geklappt

Wichtig war auch um dann alles gestartet zu bekommen:
Die Hardwarejumper over-rulen die Jumper-Config in der rc2040.ini

Sonst laedt er aus der ROM-Datei nicht die richtige "Bank"

Zitat von Toast_r

Für solche Module wie RPi Pico, Arduino usw. lieber Stift- und Buchsenleisten verwenden, statt sie nur mit Stiftleisten fest einzulöten.

Ja - iss klar Aber ich habe garkeine Buchsenleisten da deshalb musste es so gehen. Steckbar waere mir auch lieber gewesen.

Mit meinem Port/Fork unterstuetzt der/das RC2040 nun auch RunCPM