RunCPM v4.8 Win32-Shell "Starterpacket"
-
-
Mal eine einfache Frage ... CP/M 3.0 Emulieren ist nie ein Ziel gewesen ?
-
Mal eine einfache Frage ... CP/M 3.0 Emulieren ist nie ein Ziel gewesen ?
Hmmm - Nein
Aktuelle Aussage des Autor Marcelo Dantas auf dem RunCPM-Discord-Channel vom 05.10.2022:
ZitatCP/M 3 would require an almost full rewrite of RunCPM.
So I unfortunately have no plans for it.
@geowar has ported some CP/M3 behavior to the internal CCP v2.6 though.
Made it's usage much more interesting.
WIP:Add support for cpm3 line editing control characters #153
Aber es bleibt beim CP/M v2.2 (evtl. mit ZCPR3 - wenn man das andere CCP nimmt).
-
Hmmm also wenn man sich das Bank Switching sparen will, CP/M 3.0 hat auch einen Modus ohne Bank Switching.
Und die CP/M 3.0-API (= BIOS, BDOS) ist doch nur eine Erweiterung der CP/M 2.2 API ... wieso alles neu schreiben ?
-
Hmmm also wenn man sich das Bank Switching sparen will, CP/M 3.0 hat auch einen Modus ohne Bank Switching.
Und die CP/M 3.0-API (= BIOS, BDOS) ist doch nur eine Erweiterung der CP/M 2.2 API ... wieso alles neu schreiben ?
Musst Du ihn fragen Ich habe da keinen Plan, wie er sein BIOS/BDOS erstellt hat
-
Hab' ich schon, diskutiere gerade mit Ihm das, er meinte er könne ja einen "CP/M 3 specific channel" aufmachen.
Was helfen würde, wäre eine Gegenüberstellung was mit CP/M 3.0 "mehr geht", als mit "CP/M 2.2", und wo genau die Unterschiede sind, damit ein System CP/M 3.0 fähig wird.
-
Hab' ich schon, diskutiere gerade mit Ihm das, er meinte er könne ja einen "CP/M 3 specific channel" aufmachen.
in dem Channel so es in den ersten Messages noch nicht so gt aus, wie in den letzten
Wir haetten ja nichts dagegen die Arduinos aussen vor zu lassen - fuer Linux/Windows waer ein RunCPM fuer CP/M 3.0 schon mal ein Anfang
Ich drueck Dir die Daumen, dass Marcelo auch "Blut geleckt hat"{EDIT] Das wird ja schon "ernst"
Preparation for eventual CP/M 3.0 supportund auf Discord:
ZitatRunCPM v6.0 with CCP v3.0 has been pushed to GitHub. I recommend backing up your 5.x version before pulling that one. Most of the changes are preparation to support the additional BIOS and BDOS functions which would be required to run CP/M 3. This might or might not happen. Will depend on many items, like work, free time, children schedules, etc. At least the Foundation Stone is there.
-
hier ein erster initial 32Bit Compile fuer Windows der v6.0 - also Startpunkt fuer CP/M 3.0
Laeuft mit CCP Z80 60k - mal sehen ob es einen Grund gibt nicht das Internal CCP zu nehmen
-
schon hat Marcelo Dantas es auf das "Internal" CCP umgestellt - und upgedated von v2.6 auf v3.0
(das Farb-"Design" it allerdings von mir ) -
weiter gehts
von den aktuellen Aenderungen eine 32Bit & 64Bit Windows-Version... -
Erstes RunCPM v6.0 Windows-Starterpack (32Bit & 64Bit) vom 11.10.2022
-
Durch ein Compile-Problem eines anderen Users auf dem RunCPM-Discord-Channel wurde mir heute der
WinLibs GCC (12.2.0) + MinGW32/64 bekannt.
32Bit:
winlibs-i686-posix-dwarf-gcc-12.2.0-llvm-14.0.6-mingw-w64msvcrt-10.0.0-r2.7z
64Bit:
winlibs-x86_64-posix-seh-gcc-12.2.0-llvm-14.0.6-mingw-w64msvcrt-10.0.0-r2.7z
Normal nutze ich den TDM-GCC 10.3.0 (32 & 64 Bit) - bis heuteMit dem WinLibs habe ich (wohl auch durch den LLVM-Anteil im Compiler?) habe ich wesenlich kleinere Programmgroessen (KB) nach dem Compile und evtl. wird es durch den LLVM auch ein wenig flotter(?)
Ich habe wie der User im Discord-Channel die Variante mit msvcrt genommen, da die auch unter alten Windows-Version (meist 32Bit) nutzbar ist - im Gegensatz zur ucrt-Version, denn ucrt soll erst als Standard bei Windows 10 dabei sein (koennte aber bei alten Windows-Versionen nachinstalliert werden).
Um den neuen Compiler nutzen zu koennen, muesste ich vom TDM-GCC nur die Batch-Datei mingwvars.bat uebernehmen und konnte dann wie mit dem TDM-GCC compilieren.
-
Dein Starter-Paket von RunCPM hat mich dazu veranlaßt, es auch einmal zu versuchen - unter wine auf meinem Linux System :o)
Als erstes habe ich mich am Starter-Paket 'RunCPM_v6_0_Win_09102022.zip' versucht, weil es das letzte aktuelle ist. Das geht mit eines BDOS Fehlermeldung schief:
Das üblich 'A' zum Abbrechen hilft nicht, aus der Nummer ist so nicht heraus zu kommen. Da half es nur, RunCPM über den Taskmanager direkt zu töten.
Manchmal hilft der Blick zurück, also habe ich das vorletzte Starter-Paket versucht: 'RunCPM_Win_v6_0_Starterpack_GL20221011.zip'. Das war ein Volltreffer - läuft unter wine soweit :
Ein kurzer MBASIC Testlauf mit dem Einzeiler '10 for i%=100 to 500:? I%;:next' wird anstandslos abgearbeitet. Der Compilerwechsel hat anscheinend Auswirkungen auf die Lauffähigkeit unter wine, soweit ich das als Nur-Anwender feststellen kann. Mein Linux-System ist ein schon etwas betagteres Debian-Buster. Ev. läuft das unter Debian-11 besser. Ein Upgrade habe ich aber nicht vor.
-
Als erstes habe ich mich am Starter-Paket 'RunCPM_v6_0_Win_09102022.zip' versucht, weil es das letzte aktuelle ist. Das geht mit eines BDOS Fehlermeldung schief
Das üblich 'A' zum Abbrechen hilft nicht, aus der Nummer ist so nicht heraus zu kommen. Da half es nur, RunCPM über den Taskmanager direkt zu töten.
Ein kurzer MBASIC Testlauf mit dem Einzeiler '10 for i%=100 to 500:? I%;:next' wird anstandslos abgearbeitet. Der Compilerwechsel hat anscheinend Auswirkungen auf die Lauffähigkeit unter wine, soweit ich das als Nur-Anwender feststellen kann. Mein Linux-System ist ein schon etwas betagteres Debian-Buster. Ev. läuft das unter Debian-11 besser. Ein Upgrade habe ich aber nicht vor.
kmg Der BDOS-Error ist mir klar denn vom 09.10.2022 gibt es kein Starterpaket
Am 09.10.2022 war es nur die .EXE - aber im Starterpaket ist auch das Laufwerk A (als Verzeichnis /A/0 ) mit vorhanden.
Denn ohne dies Verzeichnis gibt es kein Laufwerk A: fuer RunCPM und es kommt zum BDOS Error (meist kommt man mit 1-2 mal ENTER da raus - aber wenn schon Laufwerk A: fehlt kann er dahin nicht zurueckspringen)
Das Starterpack vom 11.10.2022 war noch mit dem alten TDM-GCC - diese Version habe ich nun von Github geloescht und ein Starterpack von heute (12.10.2022) eingestellt, die mit dem WinLibs compiliert ist.
Wieviel Bit hat denn Dein debian Buster bzw. wieviel Bit vertraegt Dein Wine? - weil bei Deinem DIR Aufruf werden viel zu wenig Dateien fuer Laufwerk A: angezeigt.
Dies weist meist eine eine Bit-Inkompatibilitaet hin. Hast Du mal versucht die 64Bit Version in Deinem Wine zu starten?
Zeig doch mal das Ergebis eine "uname -a" von Deinem BusterAllerdings wuerde es wohl am meisten Sinn machen, RunCPM unter debian selbst zu kompilieren, dann umgehst Du den Overhead von Wine Ich koennte evtl. eine Art Kurzanleitung (oder mein Shell--Script zur Verfuegung stellen).
Ich kompiliere RunCPM neben Windows auch unter Linux (debian/armbian) oder fuer Mikrocontroller (per Arduino IDE) wie ESP32, STM32 und Arduino DUE.
Die Anzeige des DIR Befehl auf A: sollte folgendes Ergebnis liefern:
-
Denn ohne dies Verzeichnis gibt es kein Laufwerk A: fuer RunCPM und es kommt zum BDOS Error (meist kommt man mit 1-2 mal ENTER da raus - aber wenn schon Laufwerk A: fehlt kann er dahin nicht zurueckspringen)
Du hast recht, da war ich zu schnell oder zu blauäugig. Ich habe ohne weiter darüber nachzudenken angenommen, da alles im .exe drin steckt. Spätestens bei der nachfolgenden Aktion hätte mir auffallen müssen, das da was übersehen wurde 8^) - nämlich, das im älteren Archiv deutlich mehr Dateien enthalten sind (warum wohl).
Wo jetzt aber die ganzen Dateien auf A0: hinverschwunden sind (bis auf die, die über DIR angezeigt werden), verstehe ich trotzdem (z. Zt. nicht). Auf Laufwerk A: wird ja zugegriffen, sonst gäb's die ausgegebenen Dateien nicht. Nach USER 1 und DIR müßte INFO.TXT kommen, tut's aber nicht.
Zeig doch mal das Ergebis eine "uname -a" von Deinem Buster
$ uname -a
Linux refracta9 4.9.0-4-686-pae #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23) i686 GNU/Linux
Wieviel Bit hat denn Dein debian Buster bzw. wieviel Bit vertraegt Dein Wine?
wine ist 32-bit
Allerdings wuerde es wohl am meisten Sinn machen, RunCPM unter debian selbst zu kompilieren, dann umgehst Du den Overhead von Wine
Das wäre eine interessante Option. Am wine-Overhead störe ich mich da weniger, da das CPM eh' in einer Emulation läuft (die dann i.d.R. ohnehin deutlich schneller ist wie das Original).
Ich koennte evtl. eine Art Kurzanleitung (oder mein Shell--Script zur Verfuegung stellen).
Das wäre optimal, als Nicht-Informatiker habe ich da keine guten Erfahrungen gemacht, wenn es um das Zusammenstellen von Entwicklungsumgebungen geht. Da habe ich meistens Schiffbruch erlitten, weil man im Thema nicht so drin steckt.
-
Ich koennte evtl. eine Art Kurzanleitung (oder mein Shell--Script zur Verfuegung stellen).
Das wäre optimal, als Nicht-Informatiker habe ich da keine guten Erfahrungen gemacht, wenn es um das Zusammenstellen von Entwicklungsumgebungen geht. Da habe ich meistens Schiffbruch erlitten, weil man im Thema nicht so drin steckt.
kmg Das Script habe ich Dir in folgendem neuen Thread mal bereit gestellt
Evtl. kannst Du Dir das Script auch etwas anpassen
Pause einfuegen mit
read -p "Press any key..."und z.B. vor dem Compile Dateien anpassen im Verzeichnis $HOME/RuCPM_git/RunCPM/
-
Super, ich danke Dir.
-
hierm mal ein Test-Compile (kein Starterpaket ) der v6.0 vom 12.10.2022
ABER
diesmal eine Version mit UCRT anstatt MSVCRT - d.h. sollte nur sauber angezeigt werden unter Win10/Win11
oder einem aelteren Windows bei dem UCRT Support nachinstalliert wurde
MSVCRT (Microsoft Visual C++ Runtime)
UCRT (Universal C Runtime)
Das kompilierte Programm ist nochmal etwas kleiner als beim GCC 12.2.0 mit MSVCRT
Die 64Bit Version der v6.0 lag vorher - mit dem TDM-GCC - bei ueber 700KB
Allerdings nur ein Test, da die meisten die RunCPM nutzen wollen (vorkompiliert fuer Windows) es eher in einem Windows kleiner v10 nutzen wollen
-
fuer Peter z80.eu extra compiliert
RunCPM v6.1 (mit dem Fix fuer den HEBAS BASIC Interpreter) in 32 & 64BitNur die .exe Files
[EDIT]
Hab gerade meinen MinGW 64Bit auch auf GCC 13.1.0 gehoben und nochmal die 64Bit Version neu compiliert
(gegenueber dem GCC 12.2.0) -
Wegen der BDOS/Case Funktion 248 (Timer) musste ich die Apps nochmal updaten.....
Also nochmal 32&64Bit
-
Und gib' mir mein tägliches Update....
-
guidol - bisher nicht bemerkt... HEBASIC begrenzt Variablennamen auf 4 Buchstaben/Zeichen. Microsoft BASIC-80 kann hingegen Variablennamen bis zur Länge 40 (zumindest bei der Disk- bzw. Extended Version, nur die 8KB-Version ist auf die ersten zwei signifikanten Zeichen begrenzt. Es mag vielleicht nicht so eine große Einschränkung sein, aber man muss es wissen. RUNCPM in der 6.1 läuft bisher fehlerfrei, ein paar Compiler habe ich schon ausprobiert.
-
HEBAS mochte mein Programm zur Pi-Berechnung nicht, weil bei einer Zuweisung von A(I,L)=
I dann -1 war, weil im Gegensatz zu anderen Basic man die Base (0 oder 1) nicht setzen kann.
Dafuer musste ich bei Variablen kein A# fuer Double Precision nutzen, da HEBAS von selbst bei den normalen Varablen mit grossen Zahlen umgehen kann - z.B. bei grossen Fibonacci Zahlen.
-
HEBASIC läuft (ohne Zeitmessung) doch mit dem "CALCPI"-Programm. Siehe Anhang.
-
HEBASIC läuft (ohne Zeitmessung) doch mit dem "CALCPI"-Programm. Siehe Anhang.
Meine Version wollte noch BASE 0 nutzen, da war die Umstellung von A(I-1) auf A(I) noch nicht drin
Ist nun auch angepasst und entspricht nun fast Deiner Version:
Code
Alles anzeigen140 PRINT "Calculating Pi as a BASIC benchmark." 150 PRINT "Enter number of digits (below or equal 1000): "; 160 INPUT S$ 170 IF S$ = "" THEN PRINT "Nothing done.": END 180 N = VAL(S$):IF N > 1000 OR N< 1 THEN PRINT "Not a valid number.": GOTO 150 200 LN = INT(10 * N / 3) + 16 210 ND = 1 230 DIM A(3350) 240 SM=MILLIS(1) 250 N9 = 0 260 PD = 0 280 FOR J = 1 TO LN 290 A(J) = 2 300 NEXT J 320 FOR J = 1 TO N 330 Q = 0 340 FOR I = LN TO 1 STEP -1 350 X = 10 * A(I) + Q * I 360 A(I) = X - (2 * I - 1) * INT(X / (2 * I - 1)) 370 Q = INT(X / (2 * I - 1)) 380 NEXT I 390 A(1) = Q - 10 * INT(Q / 10) 400 Q = INT(Q / 10) 410 IF Q = 9 THEN N9 = N9 + 1: GOTO 610 420 IF Q <> 10 THEN GOTO 540 440 D = PD + 1: GOSUB 670 450 IF N9 <= 0 THEN GOTO 500 460 FOR K = 1 TO N9 470 D = 0: GOSUB 670 480 NEXT K 500 PD = 0 510 N9 = 0 520 GOTO 610 540 D = PD: GOSUB 670 550 PD = Q 560 IF N9 = 0 THEN GOTO 610 570 FOR K = 1 TO N9 580 D = 9: GOSUB 670 590 NEXT K 600 N9 = 0 610 NEXT J 620 PRINT RIGHT$(STR$(PD), 1); 640 END 670 IF ND=0 THEN PRINT RIGHT$(STR$(PD), 1);: RETURN 680 IF D=0 THEN RETURN 690 PRINT RIGHT$(STR$(PD), 1);"."; 700 ND = 0 710 RETURN
-
RunCPM Windows Starterpack 32Bit & 64Bit compiled mit Winlabs MinGW-GCC 13.2.0 MSVCRT
(startet es mit CMDer / ConEmu oderr ansicon) fuer die korrekte ANSI-Farb-Darstellung)
BTW:ansicon scheint nur mit der 32Bit-Version zusammen zu arbeiten 🙁
CMDer/ConEmu arbeitet auch mit dert 64Bit-Version zusammen
-
Info fuer die User, die auch diese gruen/orange/schwarz Einstellung mit CMDer fuer RunCPM in der Windows-Version nutzen wollen - oder somit eine solche Wordstar-Menue-Ansicht:
-
Auch ReactOS v0.4.15-x86-dev arbeitet im LiveUSB Mode (zusammen mit ansicon) sauber bei der Nutzung eines 32Bit Compile (minGW32-GCC-13-2-0) von RunCPM
Hier auf einem neoware m100 Thin Client (Model CA24) mit VIA Eden Esther CPU 800Mhz (1GB RAM)
Allerdings ist ReactOS immer noch sehr zickig bei der Hardware-Auswahl zum booten/unterstuetzen
-
echt cool,
ReactOS auf echter Hardware, da war bisher immer zu faul das mal zu probieren.
Neidvoll nehm ich das zur Kenntnis und zum Anlass es auszuprobieren. -
echt cool,
ReactOS auf echter Hardware, da war bisher immer zu faul das mal zu probieren.
Neidvoll nehm ich das zur Kenntnis und zum Anlass es auszuprobieren.Die v0.4.15 ist eine "nightly" d.h. den Link auf der Download-Seite nehmen um eine Version des LiveUSB zu bekommen der im Moment auf einiger Hardware (laut Bildern auf Ex-TwitterX) bootet.
Bei einem Wyse xn0l bleibt es an der Mouse haengen, obwohl es ein VIA C7 1.2Ghz ist