RunCPM auf einem ESP32 (hier WeMOS D1 R32 ESP-WROOM-32)

    Heute zu meinem 50ten Geburtstag bekam ich einen WeMOS D1 R32 (sollte laut Shop ein ESPDuino-32 sein) von meinem Sohn und meiner Frau zum Geburtstag :)
    https://www.cnx-software.com/2…some-arduino-uno-shields/


    Da ich noch einen SDCard-Shield wie beim Arduino Due "ueber" hatte, wollte ich den auch mit dem ESP32 nutzen:

    https://www.itead.cc/wiki/Stackable_SD_Card_shield_V3.0


    Also der Arduino IDE den ESP32 beigebracht, im .ino von RunCPM auf esp32 umgestellt und kompiliert....


    OK, die Start-Meldung kam - aber er erkannte den SDCard-Shield nicht :(


    Also bin ich auf den Discord-Server zum RunCPM ( https://discord.gg/WTTWVZ6 )
    und habe mir da die Beitraege zu ESP32-"Problemen" durchgelesen.

    Da es wohl verschiedene ESP32-Chips gibt (WROOM und WROVER) ist die Belegung fuer den SPI-Port und somit fuer den Init der SDCard anders -

    also die Pin-Nummern/Belegung.


    Im Source-Verzeichnis hardware von RunCPM gab es dann eine esp32.h zu aendern.

    Angepasst habe ich folgende Zeilen:



    Code
    #define SDINIT 18,19,23,5
#define LED 2
#define LEDinv 0
#define BOARD "WeMOS D1 R32 ESP-WROOM-32"


    Nachdem die Zeilen angepasst waren und der Sourcecode auf den ESP32 kompiliert war, erkannte er dann auch die SDCard und bootete :)

    CP/M-Mandelbrot Benchmark aus dem F64-Thread
    https://www.forum64.de/index.p…ostID=1578935#post1578935

    Ergebnis in Minuten:Sekunden:
    - 00:40 ESP-WROOM-32 ESP32
    - 02:06 Arduino Due


    - 04:25 Schneider/Amstrad CPC
    - 07:35 C= 128D


    - 00:06 nanoPi Neo ;)


    • Offizieller Beitrag

    Das wollte ich mal auf dem MFA ausprobieren, aber das Programm meldete sich mit:

    Code
    Not enough memory
Program aborted

    Warum auch immer ... egal.

    Also kurzerhand aus dem Forum64 das Pascal-Programm heruntergeladen und mit Turbo Pascal 3.01A auf dem MFA neu kompiliert.


    Ausführungszeit mit Z180 CPU bei 33 MHz ca. 21 Sekunden.

    Zitat von Toast_r

    Also kurzerhand aus dem Forum64 das Pascal-Programm heruntergeladen und mit Turbo Pascal 3.01A auf dem MFA neu kompiliert.

    Ausführungszeit mit Z180 CPU bei 33 MHz ca. 21 Sekunden.

    Mit der von Dir kompilierten Version aendert sich die Ausfuehrungszeit auf dem ESP32 hier nicht -

    bleibt bei 40 Sekunden. Ist also gut vergeichbar die Zeit.


    Dein Z180 ist also schon sehr flott unterwegs ;)

    Bei Turbo Pascal kann man unter Options einstellen, welche Speicherbereiche verwendet werden sollen.

    Ich glaube, default ist immer der auf dem Entwicklungssystem vorhandene Speicher.

    Wenn das Zielsystem weniger Speicher als das Kompiliersystem hat und dort die Obergrenze nicht herabgesetzt wird, kann es sein, dass die Speichermangel-Fehlermeldung produziert wird.

    Die COM Dateien sind ja fest im Speicher angeordnet und nicht verschieblich.

    Turbo-Pascal 3.01A

    Options

    compile -> Com-file

    Start address: 20E3 (min 20E3)

    End Address: E942 (max EC06)


    Als Beispiel ein 244 Zeilen MAZE Programm geladen und zu COM kompiliert:

    Code: 2824 bytes (20E3-2BEB)

    Free: 47706 bytes (2BEC-E646)

    Data: 763 bytes (E647-E942)


    Die statischen Daten werden am oberen Ende des Speichers angeordnet und der Code am unteren.

    Der Bereich dazwischen wird für Parameterübergabe und Unterprogrammaufrufe (Stack) sowie für dynamischen Speicher verwendet.

    Die End-Adresse von E942 (hier im Beispiel) legt die obere Grenze fest.

    Wenn das Zielsystem nicht so viel Speicher hat, kann das Programm nicht geladen werden.

    Das ist aber recht unüblich für CP/M Programme!

    Normal: Code ab 0x100, danach Init, danach Daten, dann Heap.

    Beim Laden wird der Stackpointer auf das Ende des tatsächlichen Speicherbereiches gesetzt und geht von dort aus abwärts.

    Treffen Heap und Stack aufeinander und wird dies geprüft, dann ist "Out of Memory". Ohne Prüfung ziemlich sicher ein Crash...



    Vielleicht auch die Linker Anweisungen (falls möglich) anpassen

    Ich erhalte auf meinem CPM-System (CPM3 mit Z3plus) ebenfalls die "out of memory" Meldung. Das liegt eindeuting am Z3plus, da damit die TPA zu klein ist. Mit ZPM3 gehts ohne Fehlermeldung (TPA 60.5k). In beiden Fällen habe ich das mit TP compilerte com benutzt. Ich habe das pas-File dann mal mit pascalz4 übersetzt und die Zeit gestoppt: ~39sek. Ob das nun tatsächlich genau 39sek. sind oder wegen aus dem Augenwinkel handgestopt auch 40sek. ist erst einmal egal. Interessant ist aber die erzeugte com-File größe: TP = 8832 Byte, PASCALZ4 = 7754 Bytes. Das sind beachtliche 1024 Bytes kürzer. Ob das representativ ist, laß ich mal offen, denn die Tastaturabfrage "Start mit Enter" & "Weiter mit Enter" funktioniert nicht (es wird nicht gewartet, s. Bild).

    Zitat von kmg

    Ich erhalte auf meinem CPM-System (CPM3 mit Z3plus) ebenfalls die "out of memory" Meldung. Das liegt eindeuting am Z3plus, da damit die TPA zu klein ist.

    Du kannst Z3PLUS auf SMALL setzen, manchmal ist dann aber doch noch zu wenig Speicher vorhanden.


    Das CP/M+ aus dem Beispiel hat 62kb TPA im Normalzustand.

    Zitat

    kmg das sind aber auch andere Zeichen, die fuers das Mandelbrotmuster, bei Deiner Uebersetzung des Programmes ;)

    Macht dies der Compiler?

    Am Programm-Code habe ich nichts geändert bis auf die markierte Stelle:

    PROGRAM mandelbrot;

         VAR im, re:Real;

                zr, zr2, zi, zi2:Real;

                n,n2:Integer;

                characters:String 18;

    _____________________________^^^^


    Aus Syntax-Gründen mußte ich die "[" & "]" löschen. Der Rest ist unverändert.


    Zitat

    Du kannst Z3PLUS auf SMALL setzen, manchmal ist dann aber doch noch zu wenig Speicher vorhanden.

    Das mit dem small für Z3plus habe ich noch auf dem Todo-Zettel. Wen ich das so wie es ist aufrufe ist das System etwas strange configuriert und nicht gut zu gebrauchen... Insofern hast Du mit Deinem Hinweis recht. Ich sollte das so langsam mal machen.

    Einmal editiert, zuletzt von kmg ()

    Gefällt mir 1
    Zitat von fritzeflink

    Hier mit MYZ80 und Z3PLUS SMALL

    wuste doch, das ich mit dem Zitat etwas falsch mache, jetzt stimmt's ;)


    Der Run im MyZ80 Emulator sieht besser/ok aus. Das dass mit den Zeichen nicht so richtig stimmt, liegt sicherlich an meiner Korrektur, da würde ein genaueres hinsehen eine Besserung bewirken. Die Indizierung der Zeichen funktioniert wohl nicht mehr wie gewünscht. Aber nicht mehr heute abend. Eigentlich sollte ich einen Run auch noch mit dem SBasic-Compiler versuchen, das mandelbr-Programm bietet sich geradezu dafür an. Anschließend kann ich immer noch Ursachenforschung betreiben.

    Warum das Apfelmänchen unter PASCALZ4 bei der Menge der dargestellten Zeichen anders aussieht, liegt am FLOAT. Turbo-Pascal hat 48-bit FLOATs = 10 signifikante Stellen, PASCALZ4 nutzt 32-bit FLOATs mit 6 1/2 signifikante Stellen. Dadurch sinkt die Auflösung und die Iteration bricht früher ab. Um das auszugleichen mußte die Iterationstiefe auf 28 erhöht werden. Darüber hinaus zu gehen bringt nichts mehr, da dann die Auflösung auch mit mehr Iterationen nicht mehr verbessert werden kann. Konkret heißt das: das letzte benutzte Zeichen ist das $-Zeichen, wenn mit dem Blank gestartet wird. Damit in Inneren des Apfelmänchens das '-' Zeichen erscheint muß n2:=2 gesetzt werden. Dann ist das Blank aber außen vor. Damit Mandelbr auf das ENTER wartet, muß statt READLN der Befehl READ(n1) benutzt werden. READLN hat unter PASCALZ4 die Funktion der File-Eingabe, die hier nicht zum Tragen kommt - deswegen auch kein warten auf eine Tastatureingabe. CHARACTERS ist als characters:ARRAY[1..18] of CHAR; zu definieren, der zugewiesene Zeichenstring muß dann allerdings auch 18 Zeichen lang sein. Regionale unterschiedehalt - deswegen verstehen die Bayern ja auch die Ostfriesen nicht und umgekehrt ;)



    mandelbr4.pas.zip

    PascalZ4.zip

    Zitat von DL5UY

    Das ist aber recht unüblich für CP/M Programme!

    Normal: Code ab 0x100, danach Init, danach Daten, dann Heap.

    Beim Laden wird der Stackpointer auf das Ende des tatsächlichen Speicherbereiches gesetzt und geht von dort aus abwärts.

    Treffen Heap und Stack aufeinander und wird dies geprüft, dann ist "Out of Memory". Ohne Prüfung ziemlich sicher ein Crash...

    Was ich aufgelistet habe, gilt für Turbo-Pascal. Das ist ja Compiler und Linker in einem.


    Dort liegt im unteren Speicher ab 100H der Startcode und auch die Runtime-Bibliotheksroutinen müssen irgendwo hin.

    D.h. an 100H wird das Programm geladen und auch von dort gestartet und springt dann nach Initialisierungen in den Benutzercode, der dann eben höher, über den Bibliotheksroutinen, liegt (bin aber jetzt kein TP-Experte, es gibt aber auch die Quellen um da nachzusehen).


    Grundsätzlich kann das ja jeder Compiler/Linker das halten wie er möchte. Nur der Einsprung muss schon bei 100H liegen, damit CP/M das Programm starten kann.


    Das Bildchen aus dem Handbuchhabe ich auf die Schnelle gefunden, zeigt aber den Speicher mit Turbo-Pascal Editor (also nicht das kompilierte Programm), die COM Datei dürfte aber ähnlich aussehen (Adressen von oben nach unten aufsteigend)



    Fuer RunCPM v4.5 mit SDFat-Lib v2.0.2 musste ich die SDMHZ in der esp32.h
    von 25Mhz auf 19Mhz runterschrauben, damit die SD-Karte mit meinem Mhz-sensitiven SDCard-Shield

    initialisiert werden konnte :(


    Aber nun klappt der Zugriff auch bei der neuen Version :)