RunCPM auf dem Raspberry Pi Pico

  • Nachdem ich mal die Hardware-Features des Pico mit dem Arduino DUE und einem ESP32 verglichen hatte, kam ich auf die Idee, dass der Pico das doch auch leisten koennte...


    Der Autor von RunCPM sah darin dann auch kein Problem und mich packte der Ehrgeiz ;)


    Gluecklicherweise hat mein Pico schon eine SDCard "angeflanscht" bekommen per SPI, so war der erste Schritt der Anpassung die SDCard dem RunCPM bekannt zu machen.


    Beim kompilieren wollte aber die Arduino-IDE nicht so recht und meckerte immer ueber die SDFat-Library und dass Funktionen fehlen wuerden bzw. nicht definiert sind.

    Wie das bei der Arduino-IDE leider oefter ist, gibt es "falsche Fehlermeldungen" und Folgefehler.
    Hauptproblem WAR, dass das RP2040 (CPU des RPi Pico) package selbst eine Version der SDFat-Library mitbringt - allerdings eine aeltere v2.0.2 und RunCPM will schon laenger eher was in Richtung v2.0.5 oder hoeher.


    Nachdem ich in den langen Fehlermeldungen endlich sah, dass er die falsche SDFat-Library nimmt, habe ich diese v2.0.2 im Pfad gezippt und dann das Directory der v2.0.2 geloescht unter
    C:\Users\guido\AppData\Local\Arduino15\packages\rp2040\hardware\rp2040\1.9.5\libraries\SdFat


    Dann konnte die Arduino-IDE die normale (bei mir installierte/neue) v2.1.0 der SDFat-Library nehmen, die die Befehlsanforderungen von RunCPM kennt :)

    Das gezippte .UF2-Binary ist echt mini....



    Die Fehlermeldungen, die dann noch kamen, liessen sich relativ leicht beheben/eingrenzen.


    So musste die "HostOS" -Variabe definiert werden, dass wird normal ueber den Hardwaretyp (Arduino DUE, ESP32, Teensy oder STM32) gesteuert.
    Da ein DUE in Bezug aufs BDOS die wenigsten Anforderungen hatte, habe ich dieses (0x01) fuer den Pico hard-coded definiert im Source.


    Somit klappte das compilieren (wobei ich zwar ein paar Warning erhalte) - aber Programme lassen sich starten und ich kann lesend und schreibend auf die SD-Karte zugreifen ;)


    Also kann ich sagen die erste "Alpha-Version" ist geboren! :)


    Ich werde wohl versuchen mit dem RunCPM Autor noch an den Compile-Warnings zu arbeiten - aber fuer RunCPM koennte die Pico-Version einige neue User bringen :)


  • Ein paar Tests spaeter ;)
    Normaler Compile war bei 125Mhz CPU Takt und 12Mhz fuer SPI/SDCard


    Es klappt aber auch (in der Arduino-IDE auswaehlbar) ein CPU-overclock Takt von 250Mhz und 20Mhz SPI/Card-Takt.


    Bei 250Mhz ist RunCPM fast doppelt so schnell :) Das merkt man z.B. gut in Wordstar.

    Die auswaehlbaren CPU-Takt-Stufen 275Mhz und 300Mhz lassen dann RunCPM nicht mehr starten :(

  • Um die "vielen" compile-warning zu umgehen, kann man in der platform.txt den C-Dialekt von Typ 17 auf 11 umstellen.
    Typ 14 wird wohl nicht unterstuetzt :( :

    arm-none-eabi-gcc: error: unrecognized command-line option '-std=gnu14'; did you mean '-std=gnu11'?


  • wenn man RunCPM fuer den Pico compiliert (bei 250Mhz) und in der oben genannten platform.txt die Compiler-Optimierung von -Os (small/standard) auf -O3 (fast) umstellt, dann erhaelt man nochmal 34.78% mehr Rechenleistung ;)


  • Auch mit einem ESPTerm (ESP8266) arbeitet der RunCPM Pico zusammen ;)
    Mit meinem WiFi-Netzwerk hat es aber nur sauber geklappt (einhaengen ins vorhandene WiFi-Netzwerk)
    mit der v2.31 des ESPTerm.


    Die 2 Pre-Release Versionen von v2.40 wollten bei mir nicht mit meinem WiFi-Netzwerk mitspielen
    (bekamen keine DHCP-IP vom Router).



  • RunCPM 5.7 UF2-Binary fuer den RPi Pico -> Rev. GL20220402
    compiled with RP2040 v1.13.1 (updated from v1.9.11)

    and SDFat v2.1.2 (updated from v2.1.0)




  • Vielleicht habe ich es übersehen, aber: wie schnell ist der emulierende Pi Pico im vergleich zu z.B. einem Z80 mit 4 MHz?

    Hier im Forum gibt es schon einen "Speed-Vergleich" fuers FRACTAL.BAS


    Ein Philips P2500 (Z80@4MHz) schafft es in 4 Minuten 50 Sekunden


    Der RPi Pico schafft es je nach Optimierung bei der Kompilierung
    -Os (also Standard) in 1 Minute 9 Sekunden (bei 250Mhz)

    bzw.

    -O3 (starke Optimierung) in 45 Sekunden (auch bei 250Mhz)


    Das Binary (.UF2) hier im Forum und auf github ist jeweils mit -O3 (fast) compiliert :)

    Das ergibt also ca. 25.6Mhz als "Z80"

    (4m:50sec = 290 sec / 45 sec = Faktor 6.4 * 4Mhz = 25.6 Mhz)

    fuer den Pico wenn man es umrechnet (wenn ich mich nicht verrechnet habe)

    bei der -O3 Optimierung.

  • Und wenn ein Z80 mit 250MHz laufen würde, wäre er 62,5x schneller, als ein 4MHz-Z80. Das fractal.bas müsste theoretisch in 4,64sec Fertig sein... ;)

    Ich nehme mal an, einen derartigen Z80 gibt es nicht und ich meine gelesen zu haben, das der schnellste Z80 eine CMOS-Variante mit 20MHz wäre.

    Kommt mein Wissensstand so in etwa hin?

  • Und wenn ein Z80 mit 250MHz laufen würde, wäre er 62,5x schneller, als ein 4MHz-Z80. Das fractal.bas müsste theoretisch in 4,64sec Fertig sein... ;)

    Ich nehme mal an, einen derartigen Z80 gibt es nicht und ich meine gelesen zu haben, das der schnellste Z80 eine CMOS-Variante mit 20MHz wäre.

    Kommt mein Wissensstand so in etwa hin?

    Die heute noch angebotenen (oder zumindest: beworbenen) Varianten (eZ80 Acclaim / Acclaim Plus) gibt es alle bis 50 MHz. Darüber hinaus kann man natürlich noch einen (oder mehrere, s. Zedripper) Z80-Cores in ein geeignetes FPGA zu gießen und höher takten.

    Einmal editiert, zuletzt von MJGraf ()

  • Hallo Guidol,


    mit dem Pico habe ich bisher nichts gebaut. Kennst du dich damit aus, weißt du was für andere Platinen das sind (Shields?) , und sind die käuflich?

    ___________________________________________________________________________________________________

    "Traue niemals einem Computer, den du nicht aus dem Fenster werfen kannst" (Steve Wozniak)

  • Hallo Guidol,


    mit dem Pico habe ich bisher nichts gebaut. Kennst du dich damit aus, weißt du was für andere Platinen das sind (Shields?) , und sind die käuflich?

    Der VGA-Ausgangs-Shield ist kaeuflich bei Pimori

    Bei den anderen "gestackten" rechts gehe ich von "selbst erstellt" aus, da ich dazu noch keine Info finden konnte :(


    Von Pimori gibt es noch viele andere Zusatzteile fuer den Pico :)

  • Danke für die interessanten Links. Ich denke, die Demo-Base wird reichen. :)

    ___________________________________________________________________________________________________

    "Traue niemals einem Computer, den du nicht aus dem Fenster werfen kannst" (Steve Wozniak)

  • P.S.: Tolle Sache, dieses RunCPM!

    ___________________________________________________________________________________________________

    "Traue niemals einem Computer, den du nicht aus dem Fenster werfen kannst" (Steve Wozniak)

  • Die Links leiteten mich im Endeffekt (größtenteils auf asiatisch) nach yahoo weiter. Aber danke trotzdem dafür!

    ___________________________________________________________________________________________________

    "Traue niemals einem Computer, den du nicht aus dem Fenster werfen kannst" (Steve Wozniak)

  • Mit der RP2040-Boardunterstuetzung v2.2.0 klappt der SD-Init nun auch wieder bei 25Mhz (anstatt 19Mhz).

    Wobei mir der Zugriff nicht schneller vorkommt ;)


    Aber bei 250Mhz kommt mir der Pico langsamer vor als der 160Mhz ESP-C3-32S (RiscV-CPU).

    Das merk ich beim Start von Wordstar V4 und beim Bildschirmaufbau/-Scrollen.


  • Hallo Guido,

    einfach mal eine positive Rückmeldung für das schöne Pico-RunCP/M-Projekt von mir. Ich habe es ausprobiert und es läuft schön rund. Mir ist es aber zu klein und „unscheinbar“. Da hat man ja nichts in der Hand ;) Wenn man den Pico ohne Pins nimmt, kann man das CP/M-System als Lesezeichen verwenden.

    Und zu schnell ist es auch noch ;)

    Gruß

    Siegfried

  • Hallo Guido,

    einfach mal eine positive Rückmeldung für das schöne Pico-RunCP/M-Projekt von mir.

    Ich habe es ausprobiert und es läuft schön rund.

    Und zu schnell ist es auch noch ;)

    Danke fuer die Rueckmeldung :) Freut mich immer sehr, wenn jemand Spass daran hat.

    Von mir ist ja nur die "Umsetzung" auf den Pico (bzw. teilweise auch auf dem VGA32)

    Das Original RunCPM Projekt war - vom Autor - nie darauf ausgelegt nur so schnell wie ein original Z80-Rechner zu sein.

    Wobei "damals" als es auf dem Arduino DUE startete, war es ja auch noch nicht besonders schnell.

    Erst jetzt mit Pico und ESP32 (ein neuer Teensy soll noch schneller sein) rennt einem das System davon ;)


    Mir persoenlich macht es mit diesem Speed erst Spass - auf einem Mikrocontroller - das gibt dann DOS-Feeling wie auf einem 486DX4/100 :)


    Langsamer bekommt man es durch viele Moeglichkeiten

    - Pico runtertakten

    - Bildschirmausgabe auf 9600 Baud

    - Mhz fuer die SD-Karte runtertakten

    oder gleich nen Arduino DUE nehmen ;)


    Fuer den Pico habe ich es umgesetzt auf dem Ansporn, dass sich RunCPM evtl. weiter verbreitet, wenn man ein Board unterstuetzt dass sehr bekannt und guenstig ist.

    Die meisten am Anfang unterstuetzen Boards waren "damals" realitiv teuer fuer die Leistung :(


    Aber so ein Pico (oder ein ESP-C3) sind heute NOCH guenstig, selbst mit dem SPI-SDCard-Modul.


    Persoenlich wuerde ich mich ueber ein Bild Deines kleinen Systems freuen :)

  • Dass RunCP/M nicht von Dir ist, hatte ich schon verstanden. Deine Leistung solltest Du aber nicht abqualifizieren. Gerade die von Dir realisierte Implementierung auf einer extrem kostengünstigen und aktuell auch verfügbaren Plattform, macht das System so attraktiv. Also Hut ab, vor dieser Leistung.


    Mein PiPico „System“ ist leider völlig unromantisch entsprechend Deinem im Post #10 aufgebaut. Nur mit noch freierer Verdrahtung. Daher leider kein Bild. Überlege noch, ob ich das permanent etwas ordentlicher gestalte.


    In den letzten zwei Wochen habe ich noch weitere CP/M Systeme aufgebaut, die alle noch recht unfertig sind. Alle laufen allerdings stabil. Da wären Dein PiPico, ein Atmega8515 mit 8080 Emulation, ein Z80 MBC2 sowie ein SC130 Z180 mit 9MHz. Ein SC126 Z180 ist in Vorbereitung (mit einer Platine von LaryL aus dem Marktplatz).


    Auch wenn die Erinnerung schon etwas trübe ist, die Z80 Karte im Apple][ war damals doch um einiges gemächlicher unterwegs. Schon erstaunlich, was die „aktuelle“ Hardware heute für Alternativen für CP/M ermöglicht. Z. B. 512K RAM/Flash auf jeweils einem Chip. In meinem SC/MP nach elektor brauchte ich noch für 4K RAM eine Europa-Karte und eine ordentliche Stromversorgung.

  • Dass RunCP/M nicht von Dir ist, hatte ich schon verstanden. Deine Leistung solltest Du aber nicht abqualifizieren. Gerade die von Dir realisierte Implementierung auf einer extrem kostengünstigen und aktuell auch verfügbaren Plattform, macht das System so attraktiv. Also Hut ab, vor dieser Leistung.


    ein Atmega8515 mit 8080 Emulation,

    Danke fuer die Blumen :)
    Geholfen hat dabei sicherlich, dass ich mir vorher RunCPM auf dem DUE, ESP32/VGA32 angesehen hatte und auch RunCPM mal fuer Linux (armbian) und Win32/64 mit MinGW-TDM-GCC compiliert hatte.

    Durch ausprobieren klappte die Version fuer den Arduino DUE als Grundlage am besten.

    Besonders derzeit ist die Verfuegbareit beim Pico ein Vorteil und auch dass viele aufgrund des echten Raspberry Pi sich auch mal an einen Mikrocontroller "rantrauen" und schauen, was da moeglich ist.


    Und der Pico ist mit ein paar Zusatzbauteilen schon erstaunlich universell einsetzbar.


    DieAtmega8515 mit 8080 Emulation kannte ich noch nicht, aber ich hatte vor "Urzeiten" mal eine AVR-CPM Platine von PeterSieg gekauft, die ich leider gerade etwas verlegt habe :(


    Der Apple II mit CP/M ist sicher noch gemaechlicher als mein Z80-SBC2, der hat aber wenigstens einen echten Z80 gegenueber den Mikrocontroller-Emulationen - wobei mich diesre nicht stoeren.


    Echte Hardware ist auch OK, aber dann haette ich persoenlich leiber einen ez80 ;)

  • Mit der RP2040-Boardunterstuetzung v2.2.0 klappt der SD-Init nun auch wieder bei 25Mhz (anstatt 19Mhz).

    Wobei mir der Zugriff nicht schneller vorkommt ;)

    Das .UF2-Binary dazu liegt nun auf GitHub und hier als Anhang



    Also Rev-GL20220621 mit

    - Internal CCP v2.4

    - compiled with RP2040 v2.2.0

    - SD-Init mit 25Mhz