RunCPM Speed-Vergleich auf verschiedenen Plattformen


    slenz Hmmm - ist doch schwieriger als gedacht :(

    Fuer den plain RP2040 habe ich ein "Profil" RP2040PLAIN angelegt, in dem alles wie oben eingestellt war.

    Also alles undef ausser ARDUINOSD - wobei ich fuer eine erste rudimentaere Ausgabe auch

    USEPICOSERIAL auf define setzen musste.


    Ich hatte im .ino (anstatt basic.c) alle HASEVENTS auf undef gesetzt und musste die SD.h hart selektieren, da die "Ersatz" der SdFat.h v2.2.2 nicht ging ohne dass es Fehler beim kompilieren gab :(


    Also nutze ich die (bei mir) C:\Zusatzprogramme\Arduino\libraries\SD\src\SD.h


    Aber als einzige Ausgabe bekomme ich:


    Code
    Stefan's Basic 1.4 Memory 65535 0
                                 >


    und dann ist Ende - keine Ein-/Ausgabe mehr.

    Quote from guidol

    wobei ich fuer eine erste rudimentaere Ausgabe auch

    USEPICOSERIAL auf define setzen musste.

    die gleich Ausgabe kommt doch auch ohne USEPICOSERIAL

    Serial ist beim Pico ja USB - sollte passen....


    [EDIT]

    Eingabe geht jetzt ;) War ein Tastatur-Config-Problem :)
    putty/kitty brauchte diese Haken:


    Jetzt muss ich nur noch schauen, warum er meine SDCard noch nicht mag...


    Im RP2040PLAIN-Profil habe ich folgendes mit drin:


    Code
    #define PIN_SPI_MISO (16u)
#define PIN_SPI_MOSI (19u)
#define PIN_SPI_SCK (18u)
#define PIN_SPI_SS (17u)
#define SDPIN  17

    aber er mag noch nicht mit mir spielen :(


    Edited once, last by guidol ().

    Quote from guidol

    aber er mag noch nicht mit mir spielen :(

    Das habe ich jetzt auch rausbekommen ;)
    Da anstatt der SdFat-Library bei RunCPM die normale SD.h benutzt wird, kann er von der SD-Karte nur ein anderes Filesystem (nur FAT anstatt FAT32?)


    D.h, ich habe eine "neue" SD-Karte genommen und die mit dem Befehl FDISK initialisiert.


    Danach klappt CATALOG/LOAD/SAVE :)
    Allerdings bekomme ich nicht immer die Einschaltmeldung (mgreet), weil der Pico schon sendet bevor der USB-serial Port zuhoert....sowas hatte ich mit einem ESP32-C3 auch bei RunCPM.



    Der RPi Pico braucht trotz Source ohne REMs doch laenger als der ESP32 (TTGO VGA32) fuer die Berechnugn der 1000 Stellen Pi:



    Tera Term brauchte fuer einen Source-Paste nur ein minmales delay pro Zeile von 1ms un d0ms fuer die Zeichen.
    Ulkig, dass es ohne dies nicht in putty/kitty geht:

    TeraTerm_delay.jpg

    slenz Hast Du evtl. eine Idee, warum der PicoW haengen bleibt (COM5 wird angezeigt, aber das System haengt wenn man zugreifen will und der PicoW ist nicht mehr ansprechbar - auch nicht zum flashen) wenn man das IoTBASIC direkt fuer den PicoW compiliert anstatt nur fuer den Pico?


    Ich kann das .UF2 Binary fuer den Pico auf den PicoW flashen oder auch den PicoW als Pico in der Arduino IDE programmieren und das IoTBASIC laeuft, aber wenn ich den PicoW einstelle komme ich nachher nur noch ueber den BootSel/UF2-Mode an den PicoW.


    Von der SDCard-Pinbelegung habe ich beide gleich und der Unterschied in der LED (Pin 25 zu 32) wird ja nicht genutzt.


    So nutze ich fuers erste den Pico-Code fuer den PicoW ;)

    Mit welchem Core compilierst Du denn den PicoW Code? Ich habe den gar nicht.

    Quote from guidol
    Quote from slenz

    Mit welchem Core compilierst Du denn den PicoW Code? Ich habe den gar nicht.

    slenz Wie auch bei RunCPM nutze ich - um Arduino Code auf dem Pico(W) zu kompilieren - den
    arduino-pico von Earle F. Philhower, III


    Aha! Ich benutze das nicht und hab auch keinen Pico W zur Hand. Ich hatte die beiden offiziellen Arduino Cores, also die Mbed OS Cores for den Nano Connect und den Pico verwendet.


    Hast Du ARDUINOMQTT mitcompiliert?


    Generell sieht der Fehler danach aus, dass der USB Code bzw. die Serial Emulation auf USB nicht gestartet wird. Das kann allerlei Gründe haben. Versuche mal das Memory direkt zu setzen, also MEMSIZE zu setzen, z.B. auf 32kB. Es ist zwar eher unwahrscheinlich, dass das der Grund ist weil die Boards ja viel Memory haben. Aber das könnte ein Ansatzpunkt sein. Ich nehme an, dass Du ohne USEPICOSERIAL compilierst, oder? Ich muss mal drüber nachdenken, was da noch schiefgehen kann. Irgendwann hatte sich solche Phänomene auch einmal mit den Mbeb Boards.

    slenz fuers IotBASIC bzw. TinyBASIC habe ich nun einen eigenen Thread eroeffnet, da wir doch hier noch einiges zu besprechen koennen ;)


    Evtl. kann ein Moderator/Admin aus den letzten Messsages dieses Thread zum Thema IoTBASIC/TinyBASIC die Teile netterweise dahin verschieben ? DANKE :)

    Quote from guidol

    (Ich muss nochmal verifizieren, wie/ob damals der VGA32 unter 300 Sekunden kam - ob das noch stimmt)

    Mit dem VGA32 klappt es unter 300 Sekunden, man man mit der Option -O3 compiliert

    (dies muss man aber in der platform.txt der ESP32-Hardwareunterstuetzung der Arduino-IDE tun)


    Ich habe mal den Anzeige-Bereich fuers FRACTAL geaendert, so dass man den ganzen runden Kreis um das Mandelbrot sieht ;)


    Geaendert habe ich dazu die Werte in den Zeilen 10-20:


    Code
    10 FOR Y=-16 TO 16
20 FOR X=-45 TO 23

    dann ergibt sich ein viel netteres Bild (auch wenn es nicht ganz auf die Zeilen eines 80x25 Bildschirm passt):

    Auch nett ;)
    8-BIT BATTLE ROYALE! X16 vs. C64 vs. ZX Spectrum (Round 1: BASIC Fractal)



    myBASIC

    So, mal ein neuer Kandidat für den Benchmark... Allerdings kennt der keine Timer-Funktion für die Zeitmessung, also handgestoppt...


    Der VCF 6502 BASIC BADGE. Der 65C02 läuft mit 2 MHz, mein Badge habe ich mit dem 32 kB SRAM ausgestattet, also Maximalausbau, Neben der Ausführung von FRACTAL.BAS im EhBASIC Interpreter im ROM muss sich der 6502 auch um die serielle Kommunikation (9800, 8n1) mit dem PC auch noch um den durch die 7-Segment-Anzeige laufenden Scrolltext und das Geblinke der LEDs darüber kümmern... Den Scrolltext vernachlässigt er aber ziemlich während der Programmausführung, nicht lesbares Aufblitzen einzelner Zeichen...