So noch ein exotischer Test
CP/M-68k V 1.3 mit Enhanced 68k BASIC Version 3.52
nicht emuliert, sondern auf einer realen 68k Hardware:
(MC68000 / 8 MHz)
A>ehbasic.rel
203931 Bytes free
Enhanced 68k BASIC Version 3.52
Ready
LOAD
LOAD file (*.bas) : FRACTAL
Ready
Laufzeit 117 Sekunden.
Dasselbe Programm in C (compiliert mit Alcyon C Compiler)
Laufzeit: 23 Sekunden !!
Saubär 
Nochmal hier - weil doch arg schnell fuer die kleine Platine:
Raspberry Pi PICO mit BBC-Basic (serial-Output) und kein RunCPM
schafft das FRACTAL in unter 6 Sekunden 
Nochmal hier - weil doch arg schnell fuer die kleine Platine:
Raspberry Pi PICO mit BBC-Basic (serial-Output) und kein RunCPMschafft das FRACTAL in unter 6 Sekunden
von den 5.17 Sekunden (Pico mit BBC Basic) zu 3.55 Sekunden (Pico als PicoMite mit MMBASIC)
5 Print Time$
6 W=Timer
...
240 Print Time$
250 Print "Done in ";(Timer-W)/1000; " Seconds."Das ist mal ein Unterschied ! und dabei ist das BBC Basic nicht direkt ein ganz langsames ... eher im Gegenteil.
von den 5.17 Sekunden (Pico mit BBC Basic) zu 3.55 Sekunden (Pico als PicoMite mit MMBASIC)
Mit dem Raspberry Pi Pico unter RunCPM/MBASIC wird es dann wieder etwas gemuetlicher 
Er braucht bei
- 125Mhz CPU-Takt dann 02 Minuten 25 Sekunden
- 250Mhz CPU-Takt dann 01 Minuten 09 Sekunden
Mit dem Raspberry Pi Pico unter RunCPM/MBASIC wird es dann wieder etwas gemuetlicher
Er braucht bei
- 125Mhz CPU-Takt dann 02 Minuten 25 Sekunden
- 250Mhz CPU-Takt dann 01 Minuten 09 Sekunden
Die 01 Minuten 09 Sekunden waren bei der Standard-Compilier-Option -Os (small/standard)
Nutzt man nun statt dessen -O3 (fast) dann gibt es nochmal eine Leistungssteigerung um 34.78%
d.h. dann braucht der Pico bei 250Mhz
nur noch 45 Sekunden
dann braucht der Pico bei 250Mhz
nur noch 45 Sekunden
MFA mit Z180 (36,864 MHz CPU-Clock): 0:28 min
Dann ist der Z180 ja noch im Rennen.
... und der CMM2 mit 0,3 Sekunden auch
der emuliert ja auch kein CPM/MBASIC drunter
Wie geschrieben mit MMBASIC ist der Pico bei 3.5 Sekunden und um Laengen billiger als der CMM2 
... 3,27 EUR
https://de.farnell.com/raspber…bit-arm-cortex/dp/3643332
Nicht schlecht für einen kompletten Homecomputer ( na ja, fast komplett ).
... 3,27 EUR
https://de.farnell.com/raspber…bit-arm-cortex/dp/3643332
Nicht schlecht für einen kompletten Homecomputer ( na ja, fast komplett ).
ungefaehr das gleiche legt man nochmal fuer SPI-SD-Reader/Writer/Kabel hin.
Dann braucht man noch Breadboard und eine kleine SD-Karte:
RE: RunCPM auf dem Raspberry Pi Pico
guidol : Ich habe mal Deine beiden Threads zum Thema Pico hier angepriesen:
https://www.az-delivery.de/blo…y-pi-pico-schnelleinstieg
Hoffe das ist okay
Ich habe mal Deine beiden Threads zum Thema Pico hier angepriesen:
https://www.az-delivery.de/blo…y-pi-pico-schnelleinstieg
Hoffe das ist okay
warum nicht mehr User sind mehr "Mitspieler" - wobei MMBASIC arg flott ist gegen das MBASIC unter CP/M
... 3,27 EUR
Nicht schlecht für einen kompletten Homecomputer ( na ja, fast komplett ).
fuer ca. 2,63EUR (nach dem heutigen Kurs fuer 40TL (TurkishLira)) ist der tuerkische DENEYAP MINI
- ein ESP32-S2 SingleCore mit 240Mhz - auch nicht schlecht dabei
Der schafft das FRACTAL.BAS unter RunCPM/MBASIC in 3 Minuten.
Nicht die Rennmaschine gegen andere aber TOP im Preis-/Leistungsverhaeltnis, denn im Gegensatz zum RPi Pico hat er ja WLAN/BT
Ich finde ja die Sourcecodes auf der Webseite lustig. Da kann man schön sehen, warum man C Kommentare nicht in Landessprache schreiben soll. Dafür kann man noch einfach nachvollziehen, was das Programm so macht ( motor.on(35) oder sowas)
ein ESP32-S2 SingleCore mit 240Mhz - auch nicht schlecht dabei
Ja, irgendwie geht das so langsam in die Richtung, die der Herr Peddle sich mal gedacht haben muß. Allerdings ist es wohl noch weit, bis sowas wirklich vernünftige Sachen tut. Momentan ist da viel "Maker"-Unwesen am Start und noch wenig "Fertigprodukt". Ich warte ja momentan auf die per Handy steuerbare Schrankinnenbeleuchtung - in RGB 16 Mio Farben wählbar (aber wahrscheinlich gibt es da schon was).
( Es, was da so entsteht, ist halt oft nicht so wirklich "sinnvoll" ... was immer das heißen mag 
. )
So mit der RC2014-Emulation - namentlich RC2040 auf dem RPi Pico braucht das FRACTAL doch mal etwas laenger
8 Minuten und 7 Sekunden
So
8 Minuten und 7 Sekunden
Das war die Version, die ohne Overclock (=125Mhz) compiliert war.
Mit Overclock auf 250Mhz (ist safe beim Pico) laeuft er so gut wie doppelt so schnell und schafft das FRACTAL nun in
4 Minuten und 7 Sekunden
Der ESP32-Z80-Emulator-Jr (mein Kleiner Cutdown-compile mit option -O3) bringt es auf den normalen ESP32-Wert von 42 Sekunden (andere Z80 / CP/M Emulationen brauchen auch 46 Sekunden)
Zum "Einstand" von RunCPM auf dem RISC-V ESP-C3-32S
der den FRACTAL.BAS-Test unter MBASIC in 1 Minute und 25 Sekunden geschafft hat,
habe ich - mit meinen NICHT-exitenten Turbo-Pascal-Kenntnissen - mal das Programm umgesetzt
von FRACTAL.BAS ==> FRACTAL.PAS
(ist bestimmt nicht schoen - weil nicht eingerueckt - aber selten )
Das compilierte FRACTAL.PAS als FRACTAL.COM laeuft dann auf dem ESP-C3-32S in 55 Sekunden durch,
also 30 Sekunden schneller als im MBASIC Interpreter
PROGRAM Fractal;
VAR A, B, CA, CB, T : Real;
X, Y, I : Integer;
LABEL ZH, ZHZ;
BEGIN
FOR Y:=-12 TO 12 DO BEGIN
FOR X:=-39 TO 39 DO BEGIN
CA:= X*0.0458;
CB:= Y*0.08333;
A := CA;
B := CB;
FOR I:=0 TO 15 DO BEGIN
T:= A*A - B*B + CA;
B:= 2 * A*B + CB;
A:= T;
IF ( A*A + B*B ) > 4 THEN GOTO ZH;
END; (* Ende FOR I *)
WRITE (' ');
GOTO ZHZ;
ZH:
IF I>9 THEN I:= I+7;
WRITE (Chr(48+I));
ZHZ:
END; (* Ende FOR X *)
WRITELN('');
END; (* Ende FOR Y *)
END.Ich war mal so frei. Man könnte probieren, ob man A*A und B*B noch je einer Hilfvariablen zuweist und diese dann benutzt. Spart potentiell 2 Multiplikationen und kitzelt mit bißchen Glück nochmal 2 Sekunden raus.
Dieses Label-Anspringen ist natürlich, und gerade unter Pascal, absolut daneben. Das geht so nicht und verletzt zutiefst das Ehrempfinden jedes Pascal Fetischisten. Möglicherweise ist es noch nichtmal die schnellste Lösung. Aber solange es tut, ist ja alles erlaubt.
Der Vergleich mit dem Interpreter ist natürlich etwas sinnfrei, da müßte man schon das BASIC auch mal compilen. Wird aber sicher nicht viel besser werden als die 55 Sekunden.
Ansonsten: Wie heißt den der Font im Bild in #153 ?? Der würde mir auch gut gefallen.
Ansonsten: Wie heißt den der Font im Bild in #153 ?? Der würde mir auch gut gefallen.
Ich habe gerade mal fuer dies "Terminal" in kiTTY nachgesehen...
Dies ist Cousine in 14pt (14pt nur fuer den Screenshot damit mehr drauf passt).
Normal nutze ich 16 oder 18pt fuer Linux-Terminals
Alternativ kann ich auch empfehlen (ich wechsle im Moment da noch ein wenig je nach Terminalverbindung):
- IBM Plex Mono (Standard-Dicke 16pt) - eher quadratisch - mag ich fuer Retro und C/M
- JetBrains Mono (Standard-Dicke 16pt) - etwas hoeher als IBM Plex Mono
und
- Vio converted to TTF aus IBM OS/2 - hat aber einen groesseren Zeilenabstand
Vio war eine Empfehlung hier aus dem Forum und kommt normal als - glaub ich - .otf Font
PS: Deinen Source habe ich auch nochmal compiliert, aber der ergab dann keinen Geschwindigkeitsvorteil mehr
Der Vergleich mit dem Interpreter ist natürlich etwas sinnfrei, da müßte man schon das BASIC auch mal compilen. Wird aber sicher nicht viel besser werden als die 55 Sekunden.
Da staunt der Laie und der Experte wundert sich
Deinen Pascal-Source hatte ich als FRAC2 compiliert und der lief auf dem ESP-C3-32S in 56 Sekunden durch
(also vorher wie mein Pascal-Code mit 55 Sekunden - ist nur eine Hand/Augen-Messung)
Um jetzt nicht "sinnfrei" zu sein habe ich mich kurz eingelesen und das FRACTAL.BAS mit BASCOM/L80 von Microsoft in ein FRACTAL.COM verwandelt (welches natuerlich das BRUN.COM als Runtime braucht)
Aber da war ich echt erstaunt!
Auf dem ESP-C3-32S braucht das BASCOM/L80 FRACTAL.COM nur 33 Sekunden!
BASCOM v5.3 ging immer nur auf den Prompt zurueck, aber die alternative Version tat dann ihren Dienst
Im Anhang als .ZIP Source & Binary von FRACTAL (inkl. BRUN.COM-Runtime) und FRAC2
PS: Klar - Spruenge/GOTOs in Pascal sollten ein No-Go sein, aber wie geschrieben habe ich eigentlich keine Pascal-Kenntnisse, so blieb mir nichts anderes als das BASIC-Programm 1:1 umzusetzen
Dank für die Fonts.
Sowas ist ja immer schön, wenn das schick ausssieht. Und es gibt irgendwie nicht wirklich viele, die sich als nicht-proportional Charfont eigenen.
PS: Deinen Source habe ich auch nochmal compiliert, aber der ergab dann keinen Geschwindigkeitsvorteil mehr
Der war auch unverändert. Ich will doch nicht in Deine Schöpfung eingreifen ... . Ich hatte nur eingerückt und zwei remarks ergänzt.
Das mit den vorgeschlagenen gesparten Multiplikationen bringt aber auch nix, habe das mittlerweile mal probiert. Wird anscheindend identisch überkompensiert durch das Belegen und Auslesen der Variablen für A*A und B*B.
Außerdem hatte ich mal getestet, ob man nicht die eine Startvariable, die ja in jeder Bildzeile identisch ist (X), in einem Array unterbringen kann und dann jeweile eine Multiplikation pro Durchlauf spart. Brachte aber auch nichts. Evtl. sieht das aber auf einer kleinen Hardware ohne Floatingpoint doch anders aus.
Dabei habe ich aber festgestellt, daß man bei Pascal auf ein Array von [-39..39] definieren kann, was ja mal eine sehr witzige Sache ist.
Ein sehr schönes Buch dazu gibt es übrigens hier
https://archive.org/details/the-byte-book-of-pascal/mode/2up
taugt natürlich nicht als Bastelbuch am Rechner, wenn man selbst was bauen mag.
Auf dem ESP-C3-32S braucht das BASCOM/L80 FRACTAL.COM nur 33 Sekunden!
Dann nimm mal einen anderen Pascal Compiler. Das MUSS in die gleiche Richtung kommen können.
Ist aber natürlich eine Ansage, die Zeitmessung, das ist ja dann doppelter Speed. Da muß der BASIC Compiler evtl. noch irgendwas anderes machen, vielleicht sowas, wie die richtigen Daten in den Registern halten. Bei C kann man das ja zumindest als Wunsch bei der Variablendefinition ansagen, bei Pascal geht das evtl auch.
PROGRAM Fractal;
VAR A, B, CA, CB, T : Real;
POWA, POWB : Real;
X, Y, I : Integer;
XLIN : ARRAY [-39..39] OF Real;
LABEL ZH, ZHZ;
BEGIN
FOR X:=-39 TO 39 DO BEGIN
XLIN[X]:= X*0.0458;
END;
FOR Y:=-12 TO 12 DO BEGIN
FOR X:=-39 TO 39 DO BEGIN
CA:= XLIN[X];
CB:= Y*0.08333;
A := CA;
B := CB;
FOR I:=0 TO 15 DO BEGIN
POWA:=A*A;
POWB:=B*B;
IF ( POWA + POWB ) > 4 THEN GOTO ZH;
T:= POWA - POWB + CA;
B:= 2 * A*B + CB;
A:= T;
END; (* Ende FOR I *)
WRITE (' ');
GOTO ZHZ;
ZH:
IF I>9 THEN I:= I+7;
WRITE (Chr(48+I));
ZHZ:
END; (* Ende FOR X *)
WRITELN('');
END; (* Ende FOR Y *)
END.hier, zum Probieren
evtl. muß man den Abbruch ( IF ... >4 ) noch anpassen, damit es identisch wird, der kommt ja jetzt potentiell eine Runde zu früh
evtl. muß man den Abbruch ( IF ... >4 ) noch anpassen, damit es identisch wird, der kommt ja jetzt potentiell eine Runde zu früh
Nee, der kommt hier genau richtig!
Der Test muss richtigerweise auch mit dem initialen A und B erfolgen.
Du kannst aber das CB vor dem FOR X berechnen, da sich Y erst wieder bei der naechsten FOR Y aendert.
CB:= Y*0.08333;
FOR X:=-39 TO 39 DO BEGINAber das geht jetzt Richtung Klugscheisser-Modus.
hier, zum Probieren
Deinen neuen Code & den mit den 2 Zeilen abgewandelt von funkenzupfer habe ich compiliert und da sind wir bei Turbo-Pascal von ca. 55 Sekunden nun runter auf 40-41 Sekunden - bei gleicher Hardware.
Interessant - bitte in Zeile 20 die 2 auf 2.0 ausbessern, ebenso in Zeile 22 die 4 auf 4.0
In Turbo3 jedenfalls muß sonst eine Typumwandlung "gerechnet" werden ...
Interessant - bitte in Zeile 20 die 2 auf 2.0 ausbessern, ebenso in Zeile 22 die 4 auf 4.0
In Turbo3 jedenfalls muß sonst eine Typumwandlung "gerechnet" werden ...
bringt leider keinen Geschwindigkeitsvorteil 
ok, weiterer versuch: wieso nicht wie schon zuvor bei xlinx das gleiche auch für Y*0.08333 machen. auch hier kann man ein array vorab ausrechnen ...
ich verstehe die Bemerkung nciht:
Evtl. sieht das aber auf einer kleinen Hardware ohne Floatingpoint doch anders aus.
