RunCPM Speed-Vergleich auf verschiedenen Plattformen

Quote from guidol

Die Berechnung der 1000 Stellen - in Windows - geht in ca. 10 Sekunden durch
(der TTGO VGA32 brauchte 281.68301 Sekunden fuer die 1000 Stellen)

Ich hatte das MMBASIC auf einem Picomite immer als schnell im Kopf, deshalb machte ich heute (nachdem die Grippe hier wieder bei mir abebt) den Gegenvergleich - und muss dabei bleiben, dass IoTBASIC/TinyBASIC von slenz ist echt schnell(er)

Wobei MMBASIC hier zu Gute zu halten ist, dass es sich nicht gross mit den REMs bremsen laesst.

Allerdings ist es ca. 4x so langsam, wie das IoTBASIC/TinyBasic auf dem TTGO VGA32
(wobei ich nicht weiss, ob MMBASIC auf dem Pico auch mit 250Mhz compiliert wurde, da es nur ein .UF2 Binary gibt)

Quote from slenz

Freut mich! Ich mache übrigens gerade speziell für Raspberry PI ein paar neue Dinge. Graphik läuft schon, VT52 Terminalemulation auch. Bin grad dabei eine gute GPIO Library einzubinden und MQTT. Damit kann man dan einen Raspberry PI Homecomputer bauen.

slenz Wie siehst Du die Chance eine Version zu definieren, die auf dem RPi Pico laeuft und den USB-Port als serielle Aussgabe nutzt und die SPI-Pins (zusaetzlich zu SS/CS - also auc MISO, MOSI, SCLK) selbst definieren kann?

Bis jetzt sah es fuer mich in Deinem Source so aus, als ob Du Dich auf die Standard-Pindefinition der Boards verlaesst (bis auf SS/CS). Oder welche Pinnummerm waren bei Dir die Standard-Pinnummern dafuer?

Beim Pico gibt es da ja selbst fuer SPI0/SPI1 mehrere Moeglichkeiten.

So nutze ich fuer RunCPM schon solch ein Board mit SPI-SDCard-Adapter:

slenz Danke, leider komme ich wohl erst in ca. 1 Woche wieder an meinen Rechner. Bis dahin nur uebers Smartphone von unterwegs.

Dann werde ich dies sicher testen.

Mein Versuch mit TurboC 2.x und 3.0 brachte leider keinen Erfolg.

Bei 2.x (2.01?) war TurboC das basic.c zu lang und er wollte nach ca. 2700 Zeilen von 7700 das File truncaten (trotz dosify der Sourcefiles)

Wann hattest Du zuletzt den DOS - Compile getestet?

Quote from slenz

Letzte Woche ;-). Du musst unbedingt mit dem Kommandozeilencompiler übersetzen, also

TCC basic.c

dann wichtig, das File hardware-posix.h muss hardware.h heissen im DOS Kontext, weil ja nur 8 Zeichen erlaubt. Ich teste nur mit TCC 2, den 3.0 habe ich nicht.

Ahh - TCC war der Trick - ich wollte es mal selbst kompilieren
Das mit der Datei hatte ich bemerlt und diese einfach hwp.h genannt
Der TCC von v2.x macht mir dann auch ein .EXE - im Gegensatz zum v3.x der mir 8 Fehler schmeisst.

Ist aber nicht wild, wenn der v2.x laeuft.

Eine v3.x findet man ueber folgenden Thread

Quote from slenz

Also, das geht so:

Die Standard SP bus pins sind

#define PIN_SPI_MISO (16u)

#define PIN_SPI_MOSI (19u)

#define PIN_SPI_SCK (18u)

#define PIN_SPI_SS (17u)

Wenn ich das auf Deinem Bild sehe, hast Du das genauso schon angeschlossen.

Dann musst du in die Hardware Definition gehen in hardware-arduino.h und folgendes setzen

#undef USESPICOSERIAL

#define ARDUINOSD

es sind also alle undef außer ARDUINOSD

Es gibt aber noch eine weitere Einstellung. Du musst darauf achten, dass in basic.c das Flag HASEVENTS nicht gesetzt ist. Grund dafür ist, dass attachInterrupt in den core files vom Raspberry Pi Pico anders funktioniert. Ich muss mir das nochmal genauer ansehen.

Display More

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:

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:

#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

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

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

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

Mein PyBoard v1.1 STM32F405RGT6 mit IoTBASIC/TinyBASIC compiliert mit -O3 LTO Optimierung

braucht 326 Sekunden fuer die 1000 Stellen Pi (ohne REMs)

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

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)

Hier noch mal das FRACTAL und 1000 Stell Pi auf einer eher Resourcen-schwachen Plattform

Hier der Interpreter compiliert mit der Option -O3 anstatt -Os

Allerdings bin ich mir nicht sicher, ob dies stabil laeuft - vorhin flippte der ESP8266 auch mal aus in eine

Bootschleife...

Aber immerhin anstatt 1.451 nur 589 Sekunden

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:

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):

Quote from Holger

Das könnte auch mit den Skalierungsfaktoren in den Zeilen 30 und 40 angepasst werden. dann passt es auch auf den Schirm.

aber die Optik leidet dann schon etwas arg drunter:

10 FOR Y=-10 TO 10
20 FOR X=-30 TO 20
30 CA=X*0.07
40 CB=Y*0.13

Quote from Holger

OK, sorry für den nutzlosen Kommentar.

ach was - ein Versuch war es Wert aber bei dem Ergebnis scroll ich lieber ein wenig

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

myBASIC

Quote

Simple BASIC compiler/interpreter originally written by Peter McGavin in ANSI C
as an exercise about 1988.
Compiles a BASIC program to an intermediate form which is then interpreted.
Runs BASIC programs much faster than most Basic interpreters but not as fast
as compiled to native code, while retaining portability.

Supports static multi-dimensional arrays, Microsoft-like strings and a wide range of standard functions, but no modern BASIC features such as subroutines with arguments nor pixel graphics.

Originally developed on an Amiga in SAS/C, later tested on Linux and Cygwin with gcc.
Also works on non-Intel Linux systems such as Raspberry Pis.

Display More

RunCPM laeuft auch sehr flott auf einem G4 Powerbook unter debian v12.0