Beiträge 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



    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)

    (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

    Kurze Frage.... gibt es eine zweite ser. Schnittstelle?

    Der Pico hat zwar selbst noch 1-2 serielle Schnittstellen, aber leider sind die in RunCPM nicht ueber CP/M ansprechbar :(

    Bis jetzt hatte ich mal seriell anstatt USB-seriell ausgegeben oder an 2 serielle den Text gleichzeitig um dass dann extern mit einem LCD abzufangen, dass an einem 2ten Microcontroller per serieller horschte.


    Die CP/M-devices PUN: und LST: sind im Source auf Dateien gelegt - evtl. kann man mal ueberlegen z.B. PUN: als Ausgabe anstatt in eine Datei auf eine serielle Schnittstelle zu geben - wenn sich dafuer ein Programmierer findet....

    Zitat

    Printing

    Printing to the PUN: and LST: devices is allowed and will generate files called "PUN.TXT" and "LST.TXT" under user area 0 of disk A:. These files can then be tranferred over to a host computer via XMODEM for real physical printing. These files are created when the first printing occurs, and will be kept open throughout RunCPM usage. They can be erased inside CP/M to trigger the start of a new printing. As of now RunCPM does not support printing to physical devices.

    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:





    guidol Bitte mal in abstraction_posix.h folgende Änderungen vornehmen und mit dem HX DOS-Extender testen:

    Ich habe mal eingetragen und compiliert, aber es aendert sich nichts.

    Aber ich denke da hast Du Dich fuer mingw in die falsche Datei "vertieft".


    Meines Wissens wird mingw(32) von der main.c als WIN32 erkannt:


    C
    #ifdef _WIN32
    #include "abstraction_vstudio.h"
    #else
    #include "abstraction_posix.h"
    #endif

    Weil auch das INFO-Command gibt aus: "running on Windows) - wohl wegen dem HostOS


    Ich nutze ja:

    mingw32-make mingw clean

    mingw32-make -f Makefile.mingw


    Die gleich Stelle in der abstraction.vstudio konnte ich per "find" nicht finden :(


    Interessant an der Stelle:
    Unter echten Windows geht LUAINFO und unter DPMILD32 kommt nur eine leere Ausgabe.
    Dass LUA drin ist sieht man beim Bootscreen an der LUA scripting Version ;)

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

    Bitte mal die angehängte abstract.h für DJGPP testen: dort werden die Funktionen aus abstraction_posix.h verwendet ...

    VIELEN DANK fuer diese abstract.h, denn ich hatte nicht getestet, dass meine heutige Version auch nur die Dateien mit den vollen 8.3 Dateinamen anzeigt.


    Mit Deiner abstract.h werden jetzt alle Dateien angezeigt und sind nutzbar - nur leider aendert sich nichts (bei mir hier) an der File-Ggeschwindigkeit.

    Anbei die .EXE - die mit Deinem abtract.h compiliert wurde - als .ZIP


    [EDIT] Ich hatte noch beim INFO-Command gesehen, dass in Deiner abstract.h das HostOS aud 0x02 was zur Anzeige POSIX anstatt DOS fuehrt.
    Dies habe ich nun in 0x03 fuer DOS geaendert.
    Zusaetzlich klappt nun wieder LUA, also haben wir eine Version die alle Dateien mit Deiner abstract.h anzeigt und bei der es LUA gibt :)
    Die .EXE ist nun auch ordentlich groesser geworden...

    ob es dadurch unter DOS überhaupt einen spürbaren Geschwindigkeit-Unterschied zu den entsprechenden DJGPP-Funktionen gibt, müsste man gründlich testen ... ;)

    Ich sehe jedenfalls beim Start/Laden von MBASIC und Wordstar, dass diese bei der 32Bit Version per DPMILD32 fast instant geladen sind und es bei der DJGPP-Version doch eine merkbare Verzoegerung spuerbar ist :(


    Nichtsdestotrotz habe ich mir DJGPP und desen RunCPM-Version nochmal angesehen und eine nonLUA-Version GL20240106 compiliert, die beim compilieren keine Fehlermeldungen geschmissen hat :)
    Ich weiss schon garnicht mehr mit welchen Tricks ich LUA in der vorheringen GL20231231 drin hatte.
    Mit einer 32Bit Version unter DOS koennte man auch dieses tricksen umgehen...wobei wer braucht wirklich LUA? ;)

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



    Ist die Win32-Version von RunCPM mit dem HX DOS-Extender wirklich schneller oder "besser": Benchmark mit FRACTAL.BAS? ;)

    Ich glaube an der Rechnenleistung wie beim FRACTAL.BAS wird sich nichts tun.

    Aber beim File-Zugriff sollte es beser werden.


    Die alte abtract.h hat 2KB und die abstraction_vstuido.h hat 12KB


    Interressant - was mir damals bei der DJGPP-Version auch aufgefallen ist als wir zu weige Dateien angezeigt bekommen haben - wenn man DOSLFN laedt, dann bekommt man bei DIR alle Dateien gelistet, die die 8.3er Konvention voll ausnutzen.

    Also z.B. die MBAS529P.COM oder auch eine README12.TXT


    Auch MBASIC zeigt mit FILES - wenn DOSLFN geladen ist - alle File an, wenn die volle 8.3 Zeichen haben.

    Wenn DOSLFN geladen ist, kann Wordstar sogar dann speichern unter dem kurzen Namen (zeigt diesen aber nicht vorher beim Laden in der File-Auflistung).


    Ein PIP README12.TXT=READ.ME geht und die README12.TXT erscheint in der Wordstar-Fileliste.


    Anbei die alte abtract.h (letzte Version die ich fuer RunCPM v6.1 genutzt habe) und dabei auch zum Vergleich die abstraction_vstudio.h


    ich habe auch schon versucht die Ausgabe wie bei der DJGPP Version mit fputc/putchar abzuaendern - wurde zwar compiliert brig aber nicht in der Ausgabe mehr (damals hatten wir es wegen der Interruptausgabe unter DOS und conio gemacht).

    Ab Windows 7 ist der Windows Defender serienmässig dabei. Meiner Meinung nach völlig ausreichend

    Wichtigster Schutz ist sowieso der eingeschaltete Verstand.

    Ich habe bei Windows 10 auch "nur" den Defender am Start.

    Wenn man auf den bei Download hoert (wenn er was verdaechtiges findet) und nicht zu viel auf russichen Seiten Download abholt ist man fast auf der sicheren Seite.

    Laedt man sich doch mal ein .ZIP aus dem Osten, dann kann man dies auch nochmal manuell vom defender untersuchen lassen.


    Als 2te "Firewall" meckert auch schon der Chrome beim Download gefaehliches an.

    Bei richtig bosem speichert er es garnicht (evtl. in Zusammenarbeit mit dem Defender) ansonsten fragt er ob man dies wirlick behalten will.


    So habe ich schon einige ausfiltern koennen udn mein System (auch Dank dem eingeschalteten Verstad) seit mehr als 6 Jahren Virenfrei ;)

    Der HX DOS-Extender hat ebenfalls einen DPMI-Host: HDPMI32.EXE ... durch die Win32-API-Emulation sind auch ein paar .DLL-Dateien (z.B. DKRNL32.DLL) notwendig:

    Ja das mit den .DLLs ist mir bewusst (aus der DPMI32LD-Doku):

    Es waere ja auch ein Weg vom DJGPP wegzukommen, der so aussieht als wuerde er nicht mehr weiterentwickelt.

    Die hier von mir mitgelieferte MSVCRT.DLL (335KB) ist die Version 7.0.2600.5512

    Das ist die letzte (die ich gefunden habe) die als Abhaengigkeit
    nur die KERNEL32.DLL hat (die HX DOS ersetzt).


    Alle spaeteren haben Abhaengigkeiten mit langen Dateinamen :(
    Ausserdem laeuft die 32Bit Version damit ohne Probleme unter WinXP (auch mit ConEmu).


    Könntest du ein ZIP-Archiv (oder Git) mit den erforderlichen Dateien (HX, RunCPM, WS) erstellen, damit man das direkt testen kann?
    Die RunCPM-Version für DOS (DJGPP) funktioniert doch mit NNANSI, oder habe ich etwas übersehen?

    Natuerlich stelle ich gerne ein Archiv bereit ;)

    Im angehaengtem RCPM32.ZIP sind die Verzeichnisse

    - HX (um das zu "installieren" sollte \HX\BIN im PATH von DOS sein)

    - RUNCPM (hier liegt die 32Bit Version als RCPM32.EXE und NNANSI.COM)


    Im Verzeichnis \H\BIN ist zusaetzlich die MSVCRT.DLL von WinXPSP3 enthalten, da die zum Start vom 32Bit RunCPM angefordert wird, da der mingw32 die MSVCRT-Version ist (im Gegensatz zum neueren UCRT).


    Unter dem RUNCPM-Verzeichnis liegt A: (\A\0) und dort ist auch MBASIC und B: (\B\0) beinhaltet
    Wordstar CPM v4.0


    Zu DJGPP/NNANSI:
    Ja - die DJGPP-Version arbeitet mit NNANSI - dies tut aber fuer die ANSI-Funktionen die 32Bit-Version.

    Da ist also mit NNANSI kein Problem.

    ABER :)
    Die DJGPP-Version benutzt eine aeltere/rudimentaerere Version der abstract.h mit weniger ausgefeilten File-Operationen als die ABSTRACTION.POSIX oder die ABTRACTION.VISUAL_STUDIO


    Bei der 32Bi Version fuer Windows wird die ABTRACTION.VISUAL_STUDIO zum kompilieren "angezogen".


    Da es fuer die DJGPP-Version eh eines DPMI-Hostes (CWSDPMI z.B.) braucht, hat es eigentlich nur Nachteile und schoen waere dann gleich die mit besserem Compiler (mingw32) und besseren/schnelleren File-Funktionen auch unter DOS 16Bit nutzen zu koennen (und spart auch verschiedene Compile-Wege).

    JenGun Peter z80.eu  Martin Hepperle
    In dem Thread zum RunCPM-compile unter DOS per DJGPP hattet ihr echt gute Ideen/Vorschlage, so dass wir damals die Version zum laufen brachten - nun koennte ich bei einer anderen Moeglichkeit auch Euer Wissen/Ideen brauchen:


    Ich habe eine Moeglichkeit gefunden die 32Bit-CLI Windows-Version von RunCPM (compiled mit mingw32) auf 16Bit DOS zu starten.

    Das geht ueber einen Loader (DPMILD32) von dem HX DOS Extender (aktuell v2.20)


    So arbeitet dann die 32Bit Version von RunCPM auch mit dem unter DOS notwendigen NNANSI zusammen ;)


    Allerdings gibt es noch einen/einige Haken (waer ja sonst auch zu einfach/schoen) und zwar in den Datei-/File-Funktionen:


    Was geht:

    - laden von Programmen wie MBASIC oder Wordstar

    - speichern und laden in MBASIC

    - laden eines Dokuments in Wordstar

    - PIP GLTEST.COM=FRAROUND.COM und starten der Kopue GLTEST.COM


    Was get (leider) nicht:

    - speichern in Wordstar (Disk-Full)

    - DIR gibt nur "No File" aus (erkennt aber wenn man ein nicht vorhandes Laufwerk ansprechen will per BDOS-Error)



    Info-Seite zur aelteren (non-Fork?) Version v2.17
    dazu auch die passende Sourceforge-Seite

    von dem hatte ich bis heute nichts gehoert/gelesen....


    Interessant sind die verfuegbaren Disk-Images zum booten und die Ausgabe als extra Fenster im Serial-Terminal-Style
    (leider nur schwarz auf weiss) - aber mit TTF-Font-Auswahl :)


    Emulator v1.0.44 von Joe Moore unter: http://www.z80.info/zip/zemu.zip

    zusaetzliche Disk-Images: http://www.z80.info/zip/diskimages.zip

    Mehr Infos ueber ZEMU ist in folgender Seite enthalten: http://www.z80.info/z80emu.htm#EMU_CPU_W32



    Mal eine simple Frage ... für was ist die Skriptsprache hier eigentlich gedacht?

    Unter CP/M kann ich ja SUBMIT nutzen 8-)

    es kann ein "wenig" mehr als SUBMIT - siehe

    GitHub - MockbaTheBorg/RunCPM: RunCPM is a multi-platform, portable, Z80 CP/M 2.2 emulator.
    RunCPM is a multi-platform, portable, Z80 CP/M 2.2 emulator. - GitHub - MockbaTheBorg/RunCPM: RunCPM is a multi-platform, portable, Z80 CP/M 2.2 emulator.
    github.com