RunCPM compile via DJGPP auf DOS/Win9x klappt nicht :(

Diddl

Zitat von guidol

damit man den NNANSI nachladen kann, denn der DOXBox-X ANSI ist auch nicht besser als der vom MS-DOS

Interessant, weil ich auch gerade genau dieses Thema habe;

Man kann die CMD.EXE von Win-32 und Win-64 ganz problemlos aufmotzen.

Dann kann die ANSI und sogar VT-100 über ganz normale Console Befehle (getc(), putc(), printf() ...).

Man kann auch die Anzahl Zeichen und Zeilen fixieren und derlei Dinge.

Sehr praktisch wenn man ein Terminal emulieren will für einen emulierten SBC oder MBC.

Unter DOS geht das auch, wenn man den ANSI.SYS Treiber lädt.

guidol

Zitat von Diddl

Interessant, weil ich auch gerade genau dieses Thema habe;

Man kann die CMD.EXE von Win-32 und Win-64 ganz problemlos aufmotzen.
Dann kann die ANSI und sogar VT-100 über ganz normale Console Befehle (getc(), putc(), printf() ...).
Man kann auch die Anzahl Zeichen und Zeilen fixieren und derlei Dinge.
Sehr praktisch wenn man ein Terminal emulieren will für einen emulierten SBC oder MBC.
Unter DOS geht das auch, wenn man den ANSI.SYS Treiber lädt.

Alles anzeigen

Hmm - wie motzt man die CMD.EXE von Win-32/64 "ganz einfach" auf?

Denn bis jetzt nutze ich lieber putty mit SSH anstatt CMDer/ConEmu/ANSIcon um RunCPM for Windows laufen zu lassen

Unter DOS habe ich das Problem, dass die Darstellung mit ANSI.SYS nicht so klappt mit dem DJGPP RunCPM-Kompilat, deshalb nehme ich da den NNANSI direkt als Programm geladen vor der RUNCPM6.EXE

Peter z80.eu

Der CP/M-Emulator MyZ80 ist übrigens unter DOS immer noch der schnellste ...

guidol

Zitat von Peter z80.eu

Der CP/M-Emulator MyZ80 ist übrigens unter DOS immer noch der schnellste ...

nutzt aber "nur" Disk-Images
Ich liebe es das Filesystem zu nutzen

Peter z80.eu

Zitat von guidol

Zitat von Peter z80.eu

Der CP/M-Emulator MyZ80 ist übrigens unter DOS immer noch der schnellste ...

nutzt aber "nur" Disk-Images
Ich liebe es das Filesystem zu nutzen

Das ist auf dem ersten Blick tatsächlich einfacher und praktischer, aber wenn Du CP/M-Programme testen willst, die die Disk-Struktur auslesen wollen, ist der Ansatz des emulierten Block-Device (= Festplatte, Diskettenlaufwerk) kompatibler. So viele Programme werden das nicht sein, aber bereits Programme wie der KC-Commander (Nachtrag: oder der File-Commander hier) brauchen das

Diddl

Zitat von guidol

Denn bis jetzt nutze ich lieber putty mit SSH anstatt CMDer/ConEmu/ANSIcon um RunCPM for Windows laufen zu lassen

Nee, das ist schon klar, putty nutzen wo es geht.

Aber bei einem CPM Emulator oder einem beliebigen anderen SBC Emulator nutzt man ja keinen Putty sondern schreibt direkt in die Console.

Zitat von guidol

Hmm - wie motzt man die CMD.EXE von Win-32/64 "ganz einfach" auf?

Ach so ja, der Link ...

Es sind einfach zwei Win32 API Aufrufe, dann macht der CMD das, solange er läuft.

Console Virtual Terminal Sequences - Windows Console

Virtual terminal sequences are control character sequences that can control cursor movement, color/font mode, and other operations when written to the output…

learn.microsoft.com

Das ist der Code der das einschaltet:

Code

    // Set output mode to handle virtual terminal sequences
    HANDLE hOut = GetStdHandle(STD_OUTPUT_HANDLE);
    if (hOut == INVALID_HANDLE_VALUE)
    {
        return false;
    }
    HANDLE hIn = GetStdHandle(STD_INPUT_HANDLE);
    if (hIn == INVALID_HANDLE_VALUE)
    {
        return false;
    }

    DWORD dwOriginalOutMode = 0;
    DWORD dwOriginalInMode = 0;
    if (!GetConsoleMode(hOut, &dwOriginalOutMode))
    {
        return false;
    }
    if (!GetConsoleMode(hIn, &dwOriginalInMode))
    {
        return false;
    }

    DWORD dwRequestedOutModes = ENABLE_VIRTUAL_TERMINAL_PROCESSING | DISABLE_NEWLINE_AUTO_RETURN;
    DWORD dwRequestedInModes = ENABLE_VIRTUAL_TERMINAL_INPUT;

    DWORD dwOutMode = dwOriginalOutMode | dwRequestedOutModes;
    if (!SetConsoleMode(hOut, dwOutMode))
    {
        // we failed to set both modes, try to step down mode gracefully.
        dwRequestedOutModes = ENABLE_VIRTUAL_TERMINAL_PROCESSING;
        dwOutMode = dwOriginalOutMode | dwRequestedOutModes;
        if (!SetConsoleMode(hOut, dwOutMode))
        {
            // Failed to set any VT mode, can't do anything here.
            return -1;
        }
    }

    DWORD dwInMode = dwOriginalInMode | dwRequestedInModes;
    if (!SetConsoleMode(hIn, dwInMode))
    {
        // Failed to set VT input mode, can't do anything here.
        return -1;
    }

Alles anzeigen

guidol

RunCPM v6.0 DOS in Action auf dem eeePC 4G (900Mhz Celeron MS-DOS 6.22)

Der Inhalt kann nicht angezeigt werden, da du keine Berechtigung hast, diesen Inhalt zu sehen.

tofro

Der Text im WS ist immer wieder nett:

Zitat

...contains late-breaking news....

PeterSieg

_{guidol : Ich möchte mal Danke sagen für deine RunCPM Versionen für DOS(Box).}

_{So konnte ich gestern schnell mal eine CP/M Umgebung unter DOSBox auf MacOSX zaubern.}

_Danke!

_{VG Peter}

guidol

Zitat von PeterSieg

_{guidol : Ich möchte mal Danke sagen für deine RunCPM Versionen für DOS(Box).}
_{So konnte ich gestern schnell mal eine CP/M Umgebung unter DOSBox auf MacOSX zaubern.}

Gern geschehen

aber waere es nicht schneller gewesen mit dem Makefile.osx RunCPM nativ auf OSX zu conpilieren, anstatt eine DOS-Box aufzusetzen?

PeterSieg

Nö 😏

Weil ich nun das ganze Verzeichnis einfach auch z. B. Auf Ubuntu etc.

nutzen kann. Auch sind da auch noch andere DOS Tools..

Hast du auch die cpmtools für DOS ?

VG Peter

guidol

Zitat von PeterSieg

Hast du auch die cpmtools für DOS ?

Nein - auch nicht, weil RunCPM das normale Filesystem nutzen kann.
Fuer mich der Hauptvorteil.

Die Dateien kann man auch auf anderen Betriebssystemen extrahieren ,)

PeterSieg

ok.

Nur zur Info: RunCPM und auch cpmtools ließen sich ohne jedes Problem unter Mojave und Homebrew (cmdtools) compilieren.

VG Peter

guidol

Weil sich - auch - die Version v6.1 nicht mit GCC-IA16 als 16Bit Application compilieren lassen wollte dann doch wieder eine "Quick&Dirty"-Binary-Version von RunCPM fuer DOS/DPMI/NNANSI - diesmal die v6.1 - erstellt mit DJGPP GCC

Der Inhalt kann nicht angezeigt werden, da du keine Berechtigung hast, diesen Inhalt zu sehen.

guidol

Nur aus Spass und damit auch die DOS-Version komplett ist:
RunCPM v6.1 fuer DOS jetzt mit LUA-v5.4.6-Support

Der Inhalt kann nicht angezeigt werden, da du keine Berechtigung hast, diesen Inhalt zu sehen.

guidol

Zitat von guidol

Nur aus Spass und damit auch die DOS-Version komplett ist:
RunCPM v6.1 fuer DOS jetzt mit LUA-v5.4.6-Support

Nachdem ich (bis jetzt) die 32Bit Version nicht mit dem DPMILD32 von HX DOS sauber zum laufen bekomme, habe ich mir den DJGPP nochmal vorgenommen.

Beim Compile der Version vom 31.12.2023 mit LUA hatte ich einige Meldungen, so dass ich diese Version mit LUA als experimentell betrachten will.

Durch die Arbeit an der 32Bit Version verstand ich jetzt einige Dateien der DJGPP-Version besser und habe durch ein paar Aenderungen an den Compile-Dateien eine nonLUA-Version compiliert bekommen, die ich besseren Gewissens empfehlen kann

Der Inhalt kann nicht angezeigt werden, da du keine Berechtigung hast, diesen Inhalt zu sehen.

guidol

Zitat von guidol

Durch die Arbeit an der 32Bit Version verstand ich jetzt einige Dateien der DJGPP-Version besser und habe durch ein paar Aenderungen an den Compile-Dateien eine nonLUA-Version compiliert bekommen, die ich besseren Gewissens empfehlen kann

Vor lauter "Freude" hatte ich uebersehen, dass diese neu compilierte .EXE auch nur wieder nur Files mit vollen 8.3 anzeigt.

Zu meinem Glueck hat JenGun mir zum Test evtl. schneller File-Funktionen eine neue abstract.h gebaut/bereitgestellt.

Die dann neu compilierte Version zeigt alle Dateien, wen leider nur genauso schnell wie vorher in DOS.

Anbei das gleiche Archive mit der neuen .EXE Version jetzt doch wieder mit LUA

guidol

Nachdem ich ein YT-Video gesehen hatte wie man FreeDOS 1.3 in qemu installiert dachte ich mir, dass waere auch fein fuer die 16Bit DOS-version von RunCPM

Und ich muss sagen bei mir laeuft es in qemu (unter Windows mit der Accelerator-Option --accel whpx) schneller als mit DOSBox-X oder VDOS

Mounten/bearbeiten kann man das HDD-Iage auch komfortabel mit IMDisk-Toolkit

Das von mir erstelle qemu-HDD-Image (22MB - wegen FreeDOS) liegt hier
Laufen hatte ich es unter qemu mit dem qemu-system-i386w-Emulator

Hier ein wenig (Selbst)-Dokumentation fuer die Nutzung unter Windows:

Code

=====================================
= How to install FreeDOS using QEMU =
=====================================
https://www.youtube.com/watch?v=Se69XJWxwAc

Create HDD-Image:
======================
Console:
qemu-img create runcpm.img 100M
Formatting 'runcpm.img', fmt=raw size=104857600

Boot Installer FreeDOS
======================
Console:
qemu-system-i386.exe -hda runcpm.img -cdrom FD13LIVE.iso -m 16 -boot order=d -display sgtk

Console Start mit Window WITH CDROM (wppx may hang):
qemu-system-i386w.exe -hda runcpm.img -cdrom FD13LIVE.iso -m 16 -boot order=d -display gtk --accel whpx

Console Start mit Window WITHOUT CDROM (slow - but can install FreeDOs freom CDROM):
qemu-system-i386w.exe -hda runcpm.img -cdrom FD13LIVE.iso -m 16 -boot order=d -display gtk --accel whpx

Accelerator for Linux
-enable-kvm

Accelerator for Windows (seem to have problems when -cdrom is enabled?)
--accel whpx

For Windows with Menu (because -display sdl hasnt):
-display gtk


Boot HD:
======================
qemu-system-i386.exe -hda runcpm.img -m 16 -display gtk --accel whpx

Boot HD without hanging CD-Driver:
==================================
qemu-system-i386.exe -hda runcpm.img -cdrom FD13LIVE.iso -m 16 -boot order=c -display gtk


OR
After editing to exclude CDROM and CuteMouse-Driver in FDAUTO.BAT:
(Accelerator for Windows = ON)
==================================================================
qemu-system-i386w.exe -hda runcpm.img -m 8 -display gtk --accel whpx

Alles anzeigen

Der Inhalt kann nicht angezeigt werden, da du keine Berechtigung hast, diesen Inhalt zu sehen.

guidol

unter armbian auf einem nanoPi A64 mit dem /usr/bin/qemu-system-i386 geht auch die Emualtion - wenn auch langsam - besonders wenn man nach der i386/DOS-Emualtion noch in die CP/M Emulation geht

Code

/usr/bin/qemu-system-i386 -hda ./runcpm.img -m 8 -display curses -cpu 486 -k de

Der Inhalt kann nicht angezeigt werden, da du keine Berechtigung hast, diesen Inhalt zu sehen.

Peter z80.eu

Wenn Du qemu so liebst, vielleicht gibt es ja auch bereits eine Z80 bzw. CP/M Emulation ? Oder es gibt eine NEC V20/V30 Emulation, dafür gibt es auch CP/M-Emulatoren die direkt den eingebauten 8080 in der NEC CPU nutzt (das glaube ich aber dann doch nicht... wird sich keiner die Mühe machen).

guidol

Zitat von Peter z80.eu

(das glaube ich aber dann doch nicht... wird sich keiner die Mühe machen).

Bei der Installation habe ich einige CPU-Plattformen (wie auch AVR, Alpha, MIPS m68k, PPC, SPARC) abgewaehlt, aber von Z80 und NEC V20 war nicht zu sehen

Der qemu-Z80 scheint vor 15 Jahren eingeschlafen zu sein? Wobei mir der Name des Autor bekannt vorkommt:
https://github.com/davidgiven/qemu-z80

Ahh deshakb : https://github.com/davidgiven/cpmish

guidol

Zitat von guidol

Nachdem ich ein YT-Video gesehen hatte wie man FreeDOS 1.3 in qemu installiert dachte ich mir, dass waere auch fein fuer die 16Bit DOS-version von RunCPM

Ich habe heute mal in QEMU MS-DOS v6.22 und RunCPM 16Bit installiert und muss sagen, dass bei FreeDOS v1.3 die Bildschirmausgabe fuer RunCPM bis zu 4x schneller ist als unter MS-DOS v6.22

Der Inhalt kann nicht angezeigt werden, da du keine Berechtigung hast, diesen Inhalt zu sehen.

Bei der Berechung des FRACTAL Ausgabe kommen bei auf 2-3 Sekunden, aber z.B. bei der Ausgabe eines laengeren Directorys per DIR oder beim Start von Wordstar merkt man (also ich) den Unterschied deutlich.

Ausserdem mag qemu mit Acceletaor Option --accel whpx den MODE Befehl nicht mit dem CODEPAG SELECT
(bleibt daran beim booten haengen - wie FreeDOS beim CDROM Treiber, wenn man kein CDROM definiert)

guidol

Hach ja - ich kanns doch nicht ganz lassen
Gestern auf dem RunCPM Discord-Channel wurde mal wieder nach RunCPM fuer DOS gefragt.
Wohl eher im Gedanken an 8088/8086 Rechner, aber das klappt ja leider nicht.

Helfen (bzw. was "zurueckgeben") will ich dann doch immer und gab dem User erstmal den Link zu der v6.1 Januar 2024 Version.

Heute Morgen hatte ich dann so die Stimung "Jetzt erst recht" bzw. "Hold my Beer" weils Wetter schoen ist und ich gut drauf bin (Ja - mit der passenden Menge Insulin gehts dem Koerper gleich besser) lasset uns RunCPM v6.3 Starterpack fuer DOS/DPMI haben

Erst aergerte mich der DJGPP, wenn ich LUA weglassen wollte . aber zum Glueck hatte ich auf einem USB-Stick noch eine laufende Backup-Version mit der ich die v6.1 von RunCPM Datei fuer Datei auf v6.3 brachte.

Dabei nochmal / again herzlichen Dank an JenGun fuer die damalige Arbeit an der abstract.h
Diese musste ich diesmal nur um eine Funktion erweitern.
Zum Glueck war die Funtion fuer posix schon vorgegegen und konnte per Copy/Paste uebernommen werden.

Weniger Glueck habe ich mit der compilierten GENSUB.C (compiliert mit DJGPP als GENSUB.EXE), die normal eine $$$-SUB fuer den Autostart von RunCPM erstellen soll.

Die GENSUB.EXE will im XP-.Command-Window gar nicht oder bleibt wie unter DOSBOX-X haengen

Nunja - ist ja eher eine kleine Nebenfunktion...

So wuensche ich Euch Spass (und sagt es weiter wenn Ihr ihn damit habt ) und happy CP/Ming!

Der Inhalt kann nicht angezeigt werden, da du keine Berechtigung hast, diesen Inhalt zu sehen.

Peter z80.eu

Mich würde mal interessieren, ob RunCPM mit DOS+DPMI schneller sein kann als MyZ80.

Das ist m.E. der schnellste ab 386 (auch ohne DPMI oder XMS) lauffähige CP/M-fähige Emulator überhaupt.

Hatte damals mit MyZ80 das CP/M 3.0 für den C128 neu assembliert und kompiliert, das ging in wenigen Minuten, mit einem echten Z80-Rechner hatte das Stunden gedauert. Siehe http://www.z80.eu/myz80cpm.html , dort ist auch die letzte Vollversion downloadbar (und für das Erzeugen von CP/M 3.0 siehe hier http://www.z80.eu/c128.html).

guidol

Zitat von Peter z80.eu

Mich würde mal interessieren, ob RunCPM mit DOS+DPMI schneller sein kann als MyZ80.
Das ist m.E. der schnellste ab 386 (auch ohne DPMI oder XMS) lauffähige CP/M-fähige Emulator überhaupt.

Ich denke mal nicht, dass er schneller ist damit (DPMI) als der leichtfuessige MyZ80.

Das DPMI genutzt werden muss durch DJGPP blaeht ihn natuerlich auf

ABER dafuer kommt - fuer mich - der Komfort der nativen Filesystemutzung gegenueber den -DSK files des MyZ80

Ich finde es bei RunCPM (wie auch unter Linux) cool da einfach was vom Jostrechner aus "reinschmeissen" zu koennen ins Verzeichnis (gefuehlt in de Mege auch unbegrenzt - wobei es das nicht wirklich ist.

Richtig flott - mit der FRAROUND.COM - ist RunCPM gefuehlt als 32/64Bit Windows-Cosnsole-App oder auf einem kleinen ARM-SBC (Pi oder sogar meine gute alte SheevaPlug), wo das FRAROUND in weniger als 4 Sekunden auf dem Schirm ist.

Die DOS-Version ist leider nicht so flot mit dem Filesystem, wie die Windows/Linux-Version, aber trotzdem kein Vergleich zu echten Floppy Drives - wobei es lustig waer per Link eine USB-Floppy als A: einzuhangen und mal zu sehen, wie die dann "saegt"

RunCPM ist mein Favorit, weil es sich auch auf so vielen Platformen relativ einfach kompiliern laesst... MyZ80 is pre DOS(?)

guidol

Kaum macht man es richtig - klappt es auch mit dem Autostart Tool GENSUBfuer RunCPM DOS
Im Gegensatz zu dem einen Command des mingw32-Compiler fuer Windows brauchte es beim DJGPP/GCC dann doch zwei Commands zum compilieren/linken des GENSUB.EXE

Code

gcc.exe -Os -Wno-pointer-sign -g -c gensub.c
gcc.exe gensub.o -o GENSUB.EXE -lm

Den/die Autostart-Befehle schreibt man dan z.B. in eine TEST.SUB und GENSUB erstellt in .\A\0\ dannn eine $$$.SUB
die RunCPM beim Start ausfuehrt.

In die TEST.SUB schreibt man z.B. MBASIC (also nicht MBASIC.COM)

Code

MBASIC

und startet GENSUB.EXE mit folgemdem Parameter

Code

GENSUB TEST.SUB .\A\0\$$$.SUB

Ist diese erstell startet man RunCPM (z.B. RCPM63.EXE) - dies laesst sich durch eine Batch-Datei vereinfachen/automatisieren
(z.B. mit einer RUNCPM.BAT:

Code

@ECHO OFF
CLS
rem LOAD NNANSI as TSR
NNANSI D

CLS
rem generate AUTOSTART-File
GENSUB TEST.SUB .\A\0\$$$.SUB

rem Start RunCPM
RCPM63.EXE

rem UNLOAD NNANSI
NNANSI U

Alles anzeigen

Ich haaenge das GENSUB-Archiv hier mal einzeln an, aber das Gesamt-Archiv fuer RunCPM v6.3 fuer DOS ist auf github
komplett aktualisiert

guidol

Tipp (auch wenn einige sicher das schon nutzen):

Vor dem Start von RunCPM fuer DOS (oder in der AUTOEXEC.BAT)

SMARTDRV /X

bis auf das /X ohne Parameter (da greifen eh einige Standard-Parameter) ausfuehren.

Das hilft den File-IO zu beschleunigen (der leider in der DOS-Version etwas arg lahm ist).
Das /X schaltet den Write-Cache aus (den will man meist nicht haben wegen Daten-Verlust)

Am meisten merke ich den "Boost" wenn man ein DIR aufruft

Aber auch Wordstar laedt schnelller und laesst sich schneller beenden

Bei Linux/Windows cachen da wohl andere Apps, deshalb geht es da auch flotter.

guidol

Zitat von guidol

Tipp (auch wenn einige sicher das schon nutzen):

Vor dem Start von RunCPM fuer DOS (oder in der AUTOEXEC.BAT)
SMARTDRV /X
bis auf das /X ohne Parameter (da greifen eh einige Standard-Parameter) ausfuehren.

Als "einfachere" (bessere?) Alternative habe ich eben auch
BUFFERS=20,2
in der CONFIG.SYS getestet.

Evtl. braucht dies weniger Speicher als SMARTDRV?

guidol

Zitat von guidol

Vor lauter "Freude" hatte ich uebersehen, dass diese neu compilierte .EXE auch nur wieder nur Files mit vollen 8.3 anzeigt.
Zu meinem Glueck hat JenGun mir zum Test evtl. schneller File-Funktionen eine neue abstract.h gebaut/bereitgestellt.

So - finally habe ich mich auch mal fuer DOS an die v6.6 von RumCPM gemacht

Seit der v6.3 hatte sich ja einiges getan, so war ich nicht sicher ob der DJGPP GCC mitspielt.

Erst hatte ich versucht die Features FILEBASE und STREAM der neuen abstraction* Files mitzunehmen mt der abstraction_dos66_try.h

Compilieren liess es sich zwar (auch selbst ohne Warnings) aber es wurden keine Dateien gefunden bei DIR und ERA-Befehlen (auch wenn sie bei direktem Programmaufruf gefunden werden -> MBASIC)

Zusaetzlich gab es Probleme beim hochscrollen in Wordstart v4.0 (ConEmu unter WinXP) und teilweise Abbrueche beim Start auch von Wordstar v4.0 (MS-DOS 6.22 auf einem Netbook oder DOSBox-X auf dem PC)

Also bin ich zurueck zur abtract.h, die mir mal @JenGun erstelt hatte.

In dieser musste ich nur die abstract-Anpassungen fuer den Sprung v6.5 auf v6.6 machen.

D.h. an 2 Stelllen

_mockupDirEntry(); in _mockupDirEntry(1); aendern.

Zusaetzlich musste in der disk.h die FILEBASE-Abfrage fuer "shortName" angepasst werden
(die Datein disk_FILEBASE.h im Archiv ist das Original).

Soweit laeuft die v6.6 nun unter DOS - eben ohne die Features. Ist aber nicht so schlimm denke ich.

Wenn JenGun zu viel Zeit und List hat oder er eine kleine Challenge will - da habe ich im Archiv die aktuelle abstraction_posix.h der v6.6 mit reingepackt.

D.h. wenn die angepasst waere und alle File-Operationen laufen (nach dem rueckkopieren oder originalen disk.h) dann haette evtl. auch die DOS version die Features?

Ansonsten lassen wir es dabei und "geniessen" RunCPM v6.6 so unter DOS mit NNANSI & DPMI-Extender

Der Inhalt kann nicht angezeigt werden, da du keine Berechtigung hast, diesen Inhalt zu sehen.

JenGun

Zitat von guidol

D.h. wenn die angepasst waere und alle File-Operationen laufen (nach dem rueckkopieren oder originalen disk.h) dann haette evtl. auch die DOS version die Features?

Ein erster Versuch: in main.c fehlte _host_init(argc, &argv[0]); ... die neuen Features scheinen zu funktionieren:

Code

echo DIR > input.lst
RUNCPM.EXE -i input.lst
RUNCPM.EXE -s < input.lst > output.lst
type output.lst

RUNCPM.EXE -o output.lst natürlich auch ... evtl. kann jetzt "klappt nicht" aus dem Titel dieses Threads entfernt werden ...