RunCPM v4.8 Win32-Shell "Starterpacket"

Update des RunCPM Starterpacks auf v5.8 (mit CCP v2.6) fuer Windows Console 32Bit & 64Bit

Zitat von Peter z80.eu

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:

Zitat

CP/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).

Zitat von Peter z80.eu

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

Zitat von Peter z80.eu

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 support

und auf Discord:

Zitat

RunCPM 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 heute

Mit 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.

Zitat von kmg

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 Buster

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

Zitat von kmg

Zitat von guidol

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/

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 & 64Bit

Nur 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

Peter z80.eu

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.

Zitat von Peter z80.eu

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:

140 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

Zitat von klaly

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