16Bit DOS-Software unter Windows (10) 64Bit - NTVDMx64 als vDOS Alternative

  • Auf der Suche nach Alternativen um GW-BASIC unter Windows 10 64Bit laufen zu lassen, habe ich nach DosBOX-X, MSDOS Player und vDOS nun eine Variante gefunden, die die Vorteile (fuer mich) von dem MSDOS Player mit mehr Kompatibilitaet verbindet.


    Der MSDOS Player hatte Probleme mit der BASICA v3.40 odet 4.00 Version.
    D.h. man konnte da das FRACTAL laden, aber es blieb haengen bei der Ausfuehrung oder brachte bei der Haelfte der Ausfuehrung auf einmal SYNTAX Error (fuer Zeilen, die vorher schon gelaufen sind).


    Auch DOSEmu2 unter Ubuntu wollte nicht mit BASICA v4.00 spielen (die Emulation bekam eine Art Segmention Fault).


    Aber dann fan ich eine Alternative NTVDM, die fuer Windows 64Bit erstellt wurde: NTVDMx64 von leecher1337

    Da es auf dieser Github-Seite keine compilierte Version verfuegbar ist, musste ich auf diese Seite ausweichen.


    Dort gibt es eine gibt es eine CCPU und eine HAXM (Intel Hardware Accelerated Execution Manager) Version.

    Da die HAXM Version nur fuer Intel CPUs ist nutze ich die CCPU Version.
    Fuer eine Intel CPU muesste man dann auch noch HAXM v7.8.0 runterladen und installieren.


    Fuer beide Versionen der NTVDMx64 aber gilt, dass nach dem auspacken des .7z Archiv man (je nach Sprache) in den DE Ordner (fuer deutsches Windows) geht und dort die install.bat ausfuehrt.

    Danach ist ein Neustart notwendig (fuer HAXM User die Installation von HAXM nicht vergessen).


    ABER ACHTUNG: Die .7z Archive will Google Chrome nicht runterladen, da es gefaehrliche Software sei :(


    Da ich diese Meldungen auch schon bei anderen Softwarepacketen gesehen habe, die Virtualisierungsdienste bereitstellen, war ich "mutig" und habe die Pakete per Firefox runtergeladen, der sich nicht beschwert hat.


    Nach der Installation der CCPU Version und dem Neustart kann ich nun in der Windows-Console oder CMDR GW-BASIC oder BASICA einfach aufrufen :)


    Die VDM scheint bei der Ausfuerhung ein Stueck langsamer zu sein als der MSDOS Player oder vDOS, aber hat den Vorteil der Kompatibilitaet und der vollen Clipboard-Unterstuetzung. Zusaetzlich ist die CPU-Auslastung nicht so hoch wie beim MSDOS Player und auch leicht unterhalb von vDOS.


    Besonders am IDLE-Prompt scheint hier dann auch der Task viel weniger Zeit zu verbrauchen (20% weniger = 8% bei meiner CPU gegenueber vDOS mit 29% im IDLE).

  • Warum bist Du eigentlich so versessen auf das GW-BASIC ???


    Wenn es da um die Optik von dem Bildschirm geht, also die Keywords unten und die Form der Startmeldung, dann kannst Du doch auch mal so jemanden wie den SLenz fragen, ob er sich nicht erbarmt und das als Option in sein Basic reinbastelt. Gibt ja anscheinend durchaus allerlei Varianten, die man dann wahrscheinlich auhc schon unter einem modernen OS (sei es nun W11, OS X oder Unixoid) gut comiled bekommt.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

  • Ich kann mir momentan vorstellen, das DOSBOX mit einer Konfiguration (dosbox.conf) mit "cycles=max" oder "cycles=30000" (oder höheren Wert) schneller oder mindestens genauso schnell ist, wie irgendeine andere Emulations- oder Virtualisierungslösung ist, da DOSBOX eine dynamische Recompilierung des Codes vornimmt. Meine besten Benchmark-Werte habe ich übrigens mit Windows 98SE unter VMWare hinbekommen, aber da muss man spezielle Settings (nein, kann man nicht direkt einstellen, muss auch in der Konfigurationsdatei gemacht werden) vornehmen, damit es überhaupt damit läuft. Die so gestarteten DOS-Programme liefen teilweise so schnell, dass man die Grafik nicht mehr richtig erkennen konnte (bspw. bei Arkanoid II - Revenge of Doh).

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

  • Kann ich bestätigen, und DOSbox irst auch generell sehr schön kompatibel zu fast allem.


    Was mir aber bei dem Stichwort


    irgendeine andere Emulations- oder Virtualisierungslösung


    gerade noch eingefallen ist, wäre WINE. Evtl. gibt es das ja sogar , um es unter Windows betreiben zu können. Würde ja z.B. für alte Games etc. mittlerweile durchaus auch Sinn machen. Wäre zumindest einen Versuch wert, mal danach zu suchen. (Wine für W98 wird es wohl nicht geben, aber Wine für W11 könnte ich mir vorstellen, daß man da was findet).

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

  • Warum bist Du eigentlich so versessen auf das GW-BASIC ???

    Wenn es da um die Optik von dem Bildschirm geht, also die Keywords unten und die Form der Startmeldung, dann kannst Du doch auch mal so jemanden wie den SLenz fragen, ob er sich nicht erbarmt und das als Option in sein Basic reinbastelt.

    Das BASIC vin SLzenz ist klasse, braucht aber ab und zu andere Syntax.

    GW-BASIC ist fuer mich das Original, dass ich Ender der 80er / Anfang der 90er genutzt habe.

    Da kenne ich die Syntax und Bedienung am besten.

    Bei MBASIC z.B. fehlen einige Befehle/Funktionen (selbst ein einfaches CLS).

    Picomite-BASIC nutzt zur Programmeingabe (wie QBASIC) den Full-Screen Editor.


    Das BASIC von slenz nutzt zwar auch die direkte Zeileneingabe, aber hat im Gegensatz zu GW-BASIC (wie auch z.B. beim C64) nicht die Moeglichkeit, dass man im Listing eine Zeile auf dem Bildschirm raufgeht und diese ueberschreibt und per Enter dann diese uebernommen ist.


    Ich moechte einen Interpreter, der mit direkt den Fehler ausgibt (bei der Ausfuehrung) und nicht erst beim compilieren.


    Zusaetzlich arbeite ich in BASIC lieber mit Zeilennummern, GOTOs und GOSUBs anstatt Labels, so dass auch einige andere BASIC-Dialekte rausfallen.


    Bei BBC-BASIC stoert mich, dass man die Befehle in Grossbuchstaben eingeben muss.

    Bei GW-BASIC wird das Befehlswort erkann und dann im Listing GROSS geschrieben :)


    Die FKEY-Leiste ist mir nicht wichtig, aber z.B. so Bildschirmausgabe-Befehle wie LOCATE, was bei einer Terminalausgabe wie bei dem BASIC von SLenz eher ueber "Umwege" geloest ist - da der Bildschirm ausfgrund des seriellen Terminal (bei Pico und ESP32) nicht statisch ist.


    Das selbe "Problem" mit dem LOCATE hatte das RT-11-BASIC bei der pdp1140-Emualtion, da hier auch ein Terminal genutzt wurde und man sich er Escape-Sequencen sich einen LOCATE-Befehl bauen musste.


    Am ehesten - fuer meinen Geschmack - passen in Richtung von GW-BASIC dann MSX-BASIC und das Locomotive BASIC des CPC ;)

  • OK, kann man nachvollziehen. Ich mag das ja auch sehr, mit dem direkten Bildschirmlistung und dem Editieren darin. Man ist dann irgendwie "gefühlt" gewissermaßen "näher dran".


    LOCATE ist tatsächlich auch was sinniges, wenns gut funktioniert.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

  • gerade noch eingefallen ist, wäre WINE. Evtl. gibt es das ja sogar , um es unter Windows betreiben zu können.

    Ja, sowas gibt es - allerdings hatte ich dies gestern mit WineVDM von otya128 erfolglos versucht, da die Installaroutine entweder nicht gegriffen hat/nicht alles installiert hat oder die VDM beim Start zusammenbrach (kannte nicht alle CPU-Befehle o.ae. - denn BASICA v4.00 brauchte auch nur was wie "Illegal Instruction".


    WineVDM, eine 16-Bit-Windows-App-Emulationsschicht

    Otvdm/winevdm: run old Windows software in 64-bit Windows

  • Ich kann mir momentan vorstellen, das DOSBOX mit einer Konfiguration (dosbox.conf) mit "cycles=max" oder "cycles=30000" (oder höheren Wert) schneller

    Speed ist nicht alles ;) (fuer mich) - bei der DosBOX ist wegen dem SDL-Screen fuer mich ds Problem mit dem Clipboard da hoechstens (bei vDOS) PASTE geht, aber keine Moeglichkeit des markierens und COPY machbar ist.


    Die NTVDMx64 scheint wegen der etwas langsameren Verarbeitung auch den Bildschirmausfbau und ein PASTE langsamer zu machen, denn der PASTE sieht dann fast wie bei 9600 Baud aus - also wie wenn man bei Tera Term einige ms pro Char Pause einstellt :)