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

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

  • 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

    Einmal editiert, zuletzt von guidol ()

  • 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 ;)

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey


    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.

    Einmal editiert, zuletzt von Peter z80.eu ()

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


    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:

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

  • 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 ;)


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



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

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





  • 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


  • 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).

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey


    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.

  • (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

    Einmal editiert, zuletzt 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)