CP/M auf kleinen Mikrocontroller-Systemen erregen immer meine Neugier – wie damals auch der AVR-„Stick“ den ich von Peter Sieg gekauft hatte:
http://petersieg.bplaced.com/?AVR_CP%2FM

Dieser war wohl mit aus dem Thread bei mikrocontroller.net entstanden:
https://www.mikrocontroller.net/topic/177481
https://www.mikrocontroller.net/articles/AVR_CP/M

Einige Experten haben den auch wohl weiterentwickelt und Platinen gebaut – aber es ging wohl nie in die Masse und selber bauen kann ich es nicht 😦

So fand ich es nun spannend vom CPMduino (RunCPM) zu lesen.

Da reicht ein „einfacher“ Arduino DUE (fuer bis zu 64K Ram unter CP/M 2.2) und ein SD-Reader per SPI und schon kann man CP/M nutzen.
Ein-/Ausgabe per seriellem Port bzw. virtueller serieller Port ueber den USB-Anschluss.

Weiterer Vorteil: keine DiskImages 🙂 Alles per FAT32 auf der SD-Karte. Laufwerke A: – P: sind Verzeichnissse auf der SD-Karte.

Mit ext. MicroSD-Reader Modul am DUE sieht es noch leicht fragil aus….

Leider etwas fragil – aber zum Glueck hat der SD-Card Shield da direkt die richtigen Kontakte

aber ein anderer User hat einfach ein SD-Card Shield genommen und so sieht es fuer mich schon ganz robust aus 🙂

So gefaellt mir das „Gespann“ schon besser 🙂

CPMduino Original-Seite mit dem ext . MicroSDS-Modul:
https://github.com/MockbaTheBorg/CPMduino
https://hackaday.io/project/19560-z80-cpm-computer-using-an-arduino
https://hackaday.io/project/3709-cpmduino

Nachbau mit dem SD-Card Shield:
http://weblambdazero.blogspot.com.tr/2016/07/cpm-on-stick_16.html

Aus dem CPMduino wurde dann auch RunCPM fuer Win, OSX, Linux, Arduino DUE, Teensy 3.5 & 3.6:#
https://github.com/MockbaTheBorg/RunCPM
https://hackaday.io/project/18291-runcpm

So habe ich mir aus England 2 Arduino DUE Clones bestellt und passende SD-Card-Shield wie im Beitrag gab es leider nur direkt aus China.

Die DUE aus England kamen natuerlich flotter an, als die SD-Shields aus China – aber heute war es dann soweit 🙂
Dafuer hatte ich beim Kauf nicht gesehen, dass der SD-Shield nicht nur einen grossen SD-Card-Slot hat, sondern auch einen Mico-SD-Card-Slot mit Federeauswurf.
Hersteller ist hier imall.iteadstudio.com fuer den „Stackable SD Card Shield V3.0“

ZUR INFO: Sollte jemand Probleme mit Init der SDCard und diesem SDCard-HAT haben bei
RunCPM v3.7, dann schaut Euch bitte folgenden Issue-Thread auf GitHub an:
https://github.com/MockbaTheBorg/RunCPM/issues/72

Hardware „zusammengebaut“ bzw. zusammengesteckt – Schalter auf 3.3V neben dem 2ten Reset
Durch die grosse SD-Karte sieht man den Micro-SD-Slot nicht mehr
Hier sieht man einigermassen das Alignment der Pins der 2 Platinen

Nachdem ich meiner Arduino-IDE (unter Linux) den Arduino DUE bekannt gemacht hatte und den .ZIP Mirror des RunCPM-GitHub entpackt hatte, wurde RunCPM auf den DUE – nach dem compilieren- uebertragen ueber den „Programmier“-Port (denn der DUE hat auch noch einen „native“ Micro-USB-Port).

Zum Einsatz kam danach bei mir eine frische 4GB Micro-SD-Karte mit SD-Card-Adapter im FAT32-Format.
Darauf musste die Datei CCP-CCPZ.64K ins Root-Verzeichnis [1]
Die Laufwerke A: – P: werden normal mit Verzeichnissen mit den Namen A – P dargestellt.

Die vorgegebene Version nutzt „User-Space“ [2] , so dass die .COM-Dateien in ein Verzeichnis Namens 0 (=Null) muessen, damit diese ueber den Befehl DIR ausgegeben werden koennen

Nachdem nun Arduino und SD-Karte vorbereitet waren konnte der Rechner gestartet werden – OK erst nach der Installation von minicom bei meinem Linux Mint Mate 18.1….bei Windows koennte man sich mit puTTY zum virtuellen COM-Port verbinden.
Bei Linux startet man die Verbindung mit
minicom -b 9600 -o -D /dev/ttyACM0

Dazu nutzt man auch wieder den „Programmier-Port“ des Arduino DUE und nicht den „native“ Mico-USB-Port.

Und schon kann man loslegen, CP/M zu nutzen 🙂
Ulkigerweise zeigt RunCPM als „Build“ den Zeitpunkt an, zu dem die Arduino-IDE das .INO compiliert hat, so muss man sich – fuer alles andere – auf die RunCPM Version (hier 2.8) verlassen.

PS: Die Consolen-Geschwindigkeit kann man direkt in der RunCMD.ino editieren, in dem man die Baudrate von 9600 Baud:
Serial.begin(9600);
auf 19200 Baud erhoeht:
Serial.begin(19200);

Mehr habe ich noch nicht getestet, da ich mir nicht sicher bin ob es dabei einen Handshake gibt oder ob bei hoeheren Baudraten Zeichen verschluckt werden.

RunCPM nach dem Start

[1] diese Version deshalb, weil diese in dem runtergeladenen Source-Code (Datei globals.h) eingestellt war.
Lieber haette ich die CCP-DR.60K genutzt, eine Version von Digital Research mit „nur“ 60Kb RAM, aber dafuer mit einer kompatibleren Speicher-Map.

[[EDIT]]
Die Anpassung kann man machen, wenn man die RunCPM.ino geladen hat und dann in die include-Datei globals.h geht und dort die entsprechenden Aktivierungs-/Konfigurationszeilen (de-)aktiviert.

Ich habe hier mal beispielhaft die DR-Version und 60Kb Speicher aktiviert und die anderen Konfigurationen durch // auskommentiert:

/* Definition of which CCP to use: INTERNAL, DR or ZCPR (must define only one) */
// #define CCP_INTERNAL // If this is defined, CCP will be internal
#define CCP_DR
// #define CCP_CCPZ
// #define CCP_ZCPR2
// #define CCP_ZCPR3
// #define CCP_Z80

#define SIZEK 60
// #define SIZEK 64
// Can be 60 for CP/M 2.2 compatibility or more, up to 64 for extra memory
// Can be set to less than 60, but this would require rebuilding the CCP
// For SIZEK<60 CCP ORG = (SIZEK * 1024) – 0x0C00

The 64K version provides the maximum amount of memory possible to CP/M application, but its addressing ranges are unrealistic in terms of emulating a real CP/M computer.
The 60K version provides a more realistic addressing space, keeping the CCP on the same loading address it would be on a similar CP/M computer.
Other amounts of memory can be used, but this would require rebuilding the CCP binaries (available on disk A.ZIP). The CCP binaries are named with their extensions being the amount of memory they run on, so for example, DRI’s CCP runnin on 60K memory would be named CCP-DR.60K. RunCPM looks for the file accordingly depending on the amount of memory selected when it is built.

[2] RunCPM can emulate the user areas as well (this is the default), so to create the disk drives use the following procedures:

  • when using user areas – Create subfolders under the executable folder named „A“, „B“, „C“ and so on, for each disk drive you intend to use, each one of these folders will be one disk drive, and under folder „A“ create a subfolder named „0“. This is the user area 0 of disk A:, extract the contents of A.ZIP package into this „0“ subfolder.