Die Ne2000 Emulation setzt immer voraus, dass DosBox sich auf dem Host in den Netzwerkadapter einklinkt. Das erfordert tiefgreifende Rechte. Diesem werden die Pakete aus der Dosumgebung „untergejubelt“. Daher funktioniert das eigentlich nur mit einem Ethernetadapter im Host.
Die besten Chancen (ausser mit einem BaseBox Port) hast du vermutlich mit einem virtuellen Modem-Setup, wie hier im Thread beschrieben.
Posts by t.hass
-
-
Die BaseBox mit der GeosHostintegration übernimmt die Ver-/Entschlüsselung. Wenn du unter RiscOS (vorerst) auf andere DosBoxen ausweichen musst, hilft ein externer Proxyserver z.b. WebOne. Läuft bei mir bequem als Dockeranwendung auf dem Synology NAS.
-
Wenn ich mich richtig erinnere, war der Compilerschalter nicht als Build Flag implementiert nur im Code zu setzen. Der Code, den er aktivierte, hat eine Zeitdifferenz durch kleine Offsets versucht auszugleichen (kontinuierlich). Das hilft nichts nach einem Host-Wakeup… außer man hat viel Geduld. Mehr Code/Rechenaufwand ist es auch.
-
Negative Auswirkungen auf Datenkonsistanz sind nicht zu erwarten, da nur der Direktory-Cache praktisch für mit -s gemountete Drives vor jedem Dir gelöscht wird - Floppy Mounts ist das Default. Auf die Schnelle habe ich keine spürbaren Effekte beim Betrieb von Geos bemerkt - ich habe aber auch kein R-Basic getestet und wüsste jetzt spontan auch keine App, viele Dirs triggert. Vielleicht wirkt sich der fehlende Cache auch nur Host-Lw mit hoher Latenz WebDav-Mounts(?) negativ aus. Das gilt es zu testen…
Generell denke ich, sollten alle Geos-spezifischen Anpassungen ein Opt-In sein, wenn wir sie upstream bringen wollen. Codeblöcke für zusätzliche DOSBox.conf Parameter sind ja zusammenhängend an einer Stelle und eigentlich unproblematisch. Die Anpassung des Mount Befehls war hier bewusst, um z.b. im Splitsetup zwischen System und User-Tree auf getrennten Lw evtl. Performanceprobleme umschiffen zu können.
Einstellungen bzgl. bedingter Compilierung halte für viel problematischer. Meson und Cmake Configs sind IMHO schwieriger zu warten - und solange DB-Staging beides nutzt doppelte Arbeit. Ich würde sogar soweit gehen, BaseBox im (CI/CD-)Code nicht so zu nennen, weil die dadurch entstehenden Brüche einfach nur lästig sind.
-
Dumme Frage aus dem OFF: Wenn F5 die Standard-Taste zum Neuaufbau von Fenstern ist, warum dann nicht im GeoManager F5 benutzen um erst die Dateien neu einzulesen und dann erst das Fenster neu darzustellen? Dann muss ich niemand Strg-F4 als weiter Kombination merken.
Also Konzeptionell: Datei nicht da obwohl ich sie vom Host gerade eingespielt habe? -> F5 -> Ah, da ist sie ja!GPC-Installer v3.0.9D feat: add MOUNT -s flag for lazy hostdrive refresh
Add RefreshMode enum (Manual/Lazy) and MOUNT -s flag to automatically invalidate directory cache on FindFirst, matching the existing floppy refresh behavior. Includes localdrive unit tests validating that Manual mode caches while Lazy mode picks up external host file changes.
Im Grunde ist Ctrl+F4 nur nötig um den Directory-Cache zu löschen. Für -t floppy Mounts wird der jetzt schon nicht genutzt, um Diskettenwechsel zu behandeln. Auf modernen Rechnern scheint das auch keinen Performance-Impact zu haben, wenn man's deaktiviert. Ohne Hostintegration plopt eine neue Datei zwar nicht von selbst im File/GeoManger auf, aber beim Verzeiichniswechsel oder F5 wird sie sichtbar. Vieleicht ist das ja schon Änderung genug. Probierts einfachmal aus...
Gruß Thomas
-
das ist eine Erweiterung die für die Basebox kommen soll:
ganz trivial ist das aber nicht. Ich habe das selbst auch schon probiert und folgende (potentielle) Probleme ausgemacht:
- die unterschiedlichen Plattformen (z.B. Windows, Linux) verwenden recht unterschiedlich Mechanismen Änderungen im zu überwachenden Dateisystmzweigen zu "alerten"
- Polling hatte sehr negative Einflüsse auf die Performance
Die Basebox war immer mit als Teil des Systems zu denken
...muß dann aber auch konsequent gepflegt werden. Aktuell häng sie >3800 Commits hinter DosBox-Staging hinterher, was vmtl. manuelles Rückportieren von Code/Mergen erfordert. Die CI/CD-Skripte sind für veraltete OS gedacht und teilw. (macOS) auch nicht lauffähig, weil die zu Grunde liegenden Runner EoL sind.
das sogenannte split-setup
stammt ursprünglich aus der Netzwerkinstallation, die bewust größere Veränderungen durch den Nutzer unterbunden hat. Geos-Nutzer fummeln jedoch mit Begeisterung an ihrem Systemen herum, um es ihrem ganz persönlichen Geschmack anzupassen: die Struckturierung der Applikationen im GeoManager steht da sicher ganz oben auf der Liste. Das kann man bestimmt durch Ablage der Apps im SYSTEM-Bereich und Verlinkung in (User)WORLD lösen, aber auch dann muß ich saber zwischen Erst- und Update-Installation unterscheiden. In menen Experimenten hat sich auch gezeigt, dass nicht aller Einstellungen in NET.INI und GEOS.INI gleichermßenanwendbar sind - Skepsis....
Gruß Thomas
-
dein unglaubliches Wissen nicht Upstream einbringst
Hallo Konstantin,
das ist weniger böser Wille oder Egoismus als vielmehr darin beründet, dass der Umgang mit Git nicht mein täglich Brot ist. Die coolen Features der Geos-Hostintegration (dynamische BS-Auflösungen und SLiRP) sind leider nicht in BaseBox:main sondern in einem eigenen Branch, an den ich halt die Printer-Redirection (und die Zeitsynchronisation) angestrickt habe, weil ich halt alles zusammen haben wollte. Inzwischen weiß ich, dass eine sch*ß Ausgangsbasis für einen vernüftigen PR ist... Dann kam das Rabithole GH-Actions hinzu, was man auch separat gegen main fixen sollte. Wenn mir einer sagen kann, wie ich aus dem Dilema wieder raus komme?!
Der Verweis auf den GPC-Windows-Installer ist bitte auch nicht als Afront gegen Eure Arbeit zu verstehen, es ist halt nur nicht in 3 Zeilen zu erklähren, wie man die Druckerumleitung in BaseBox, GhostScript & Print-Skript und GEOS.INI konfiguriert... Und keine Bedenken, ich habe keine weitere Zeit in den Installer investiert (außer die History zu pflegen). Er wird vielmehr gescripted erstellt indem die Zutaten: akt. BaseBox-Build aus VS + latest Ensemble(de).zip von GH + ein paar wenige Artefakte (Splash- & Hintergrundbild etc.) vom automatisch InnoSetup-Compiler zusammengebaut.
Gruß Thomas
-
Ich habe es gerade mal auf meinem Linux-Laptop mit Mint 22.3 versucht... funzt nicht, dosbox läßt sich nicht starten, mit der Meldung:
Ungültiger Maschinenbefehl (Speicherabzug geschrieben)
Vermute mal, es ist nur für PiGeos...
Sorry den Linux-Build hatte ich noch nicht getestet. Ist an sich aber für x86-64 gebaut. An dem Pi-Build arbeite ich noch. Soll final auch ein APT für Ubuntu 24.04 und kompatible gebaut werden.
für Devs: ich habe die Gh-Actions von Cmake auf Meson umgestellt, um möglichst lokale Pakete zu nutzen. Nur wenn diese nicht verfügbar sind gibt es ein Fallback auf Meson Warps. Auch Crossbuilds will ich vermeiden, was leider einen lokalen Runner für Pi-Buils erforderlich macht. -
Ich hätte daauch noch ein paar Fragen. 😄
Geht das jetzt mit der regulären Basebox, oder nur mit der in PIGeos?
Wenn ja, was muss ich tun um das nutzen zu können ?
Dank im Voraus.
In dem weiter oben verlinkten GPC-Windows-Installer ist das Drucken bereits konfiguriert. Es ist auch das das zum Zeitpunkt aktuellste Geos in deutscher Sprache enthalten. UI kannst du natürlich ggf. umstellen. Die Drucke landen als PDF-Datei im Windows Dokumente-Ordner.
-
Hallo Bernd,
Danke für‘s Testen. Die dynamischen BS-Auflösungen über die „BaseBox 72 dpi“ etc. Treiber sollten auch gehen. Spannend für Falk ist sicher auch, ob Du via Host-Ip Intergration ins Web kommst. Die Lpt-Umleitung ist auch enthalten. Als Command müßte auf dem Mac eigentlich gehen: lpr %s
Thomas
-
nächster Versuch mit zusätzlichem Code, der alle Abhängigkeiten rekursiv ermittelt: https://github.com/hastho/basebox….82.0-pigeos.75
-
ok, das Problem war, dass das Paket noch externe Abhängigkeiten (von Homebrew) verwendete. Jetzt sollten alle benötigten Libs im Paket sein -> Zeit für einen weiteren Test: https://github.com/hastho/basebox….82.0-pigeos.67
-
Hallo Bernd,
sorry ich hätte erwähnen sollen, daß ich den macOS Build im "Blindflug" erstellen ließ, da ich keinen aktuellen Mac mehr besitze. Ich hab mit Unterstützung des künstlichen Kollegen nochmal and der GH-Action gefeilt. Versuch's also bitte nochmal: https://github.com/hastho/basebox….82.0-pigeos.63
Gruß Thomas
-
Ich habe in die BaseBox die kontinuierliche Zeit+Datum-Synchronisation implantiert:
[dosbox]
hosttime = trueIm GPC-Installer 3.0.8D ist es standardmäßig aktiv in BaseBox macOS u.a. Builds auf GitHub müßt Ihr es selbst aktivieren.
Gruß Thomas
-
In der MB6 ist die kontinuierliche HostTime-Synchronisation ziemlich "mit dem Holzhammer" implementiert indem im BIOS INT8-Handler durch Aufruf von BIOS_HostTimeSync() die entsprechden BIOS ticks zur akt. Host-Zeit berechnet werden. In DOSBox-Staging steckt auch Code zum Ausgleich von Timedrifts, der aber beim Complilieren aktivert werden muß und dann alle 5s eine 1/2s korrigiert, wenn emulierte Zeit und Hostzeit auseinander driften.
EIne Mischung aus beiden Methoden abhängig vom Delta wäre sicher die zu bevorzugende Methode. Vorher sollte man aber gut testen, on wirklich alle GEOS-Apps den harten Ausgleich sicher verkraften.
-
Ich habe jetzt keinen Pi zur Hand, aber wenn alle getesteten Displays nur XGA anzeigen, hast Du möglicherweise den falschen HDMI-Ausgang am Pi 4/400 genommen. Auch kann Pi/GEOS keine 1920x1080@64k nativ ausgeben. Das Display muss 1280x720/768/800 akzeptieren und auf seine native Auflösung skalieren. Das liegt daran, dass DOSBox 0.7x einen S3-Chip mit Max. 4MB VRAM emuliert. In der Praxis ist das auch sinnvoll, da GEOS UI für 72dpi Display konzipiert wurde. Ein Up-Scaling sorgt dafür, daß man sich nicht die Augen verdirbt…
-
Ich muß ehrlich sagen, ich habe inzwischen auch den Überblick verloren, welche GEOS Issue X mit welcher Basbox Y zusammen nutzt werden müssen. Hatte nur festgestellt, dass in der von mir genutzten BaseBox die IP-Hostintegration nicht mit aktuellem GEOS Main/Master funktioniert. Daher sind im Windows-Installer auch nicht die neustesten Versionen enthalten sondern eine Version vom Februar 2026.
-
Nur nochmal zum Verständnis: In GEOS 1280x720@64k Colour/Farben als BS-Auflösung einstellen funktioniert bei Dir nicht? Hast Du in der Raspi-Config.ini gemachte Änderungen wieder zurückgesetzt?
-
Auf dem GEOS-Entwicklertreffen in Syhra gab es einige Neuerungen zu bestaunen, darunter:
- eine stärkere Integration des PC/GEOS-Grafiktreibers, welcher nun automatisch die GEOS-Bildschirmauflösung an die Fenstergröße anpaßt,
- viele Fehlerbehebungen an der TrueType-Engine, welche vor allem die Geschwindigkeit und Stabilität des Systems verbessern,
- Import-/Exportfilter für PNG-Dateien,
- Beta-Version eines neuen Power-Managemnt-Treibers, welcher die CPU-Last auf dem Host-PC oder Notebook deutlich verringert.
- BaseBox verfügt in der enthaltenen Version über eine eingebaute Umleitung der GEOS-Druckausgabe. Mittels Ghostscript werden automatisch PDF-Dokumente erstellt und in Eurem `Dokumente` Ordner unter Windows abgelegt.
Um die neuen Features und den schon länger mit BaseBox deutlich verbesserten Internetzugriff zu testen, habe ich ein aktuelles PC/GEOS samt BaseBox in ein Windows-Installationspaket gepackt. Anläßlich des 25. Geburtstags des GlobalPC habe ich das GEOS-Look-and-Feel dem Vorbild entsprechend angepaßt.
-
Hallo,
Die Art und Weise der Grafikausgabe hat sich in den verschiedenen Versionen von Pi/GEOS geändert - ältere Diskussionen sind daher mit Vorsicht zu behandeln. Aktuell wird ganz normal ein X-Server gestartet und DOSBox im Vollbildmodus ausgeführt. Dabei wird versucht, in einen Videomodus zu schalten, der die von DOSBox/GEOS angeforderte Auflösung und Farbtiefe liefert. Welche da in Frage kommen, hängt vom Bildschirm ab. Bastler-Displays für den Raspi beherrschen meist nur ihre native Auflösung. Computerbildschirme und TVs verfügen über HW-Scaler und können meist 1024x786 (XGA) 1280x720 (720p/HDready). Folglich mußt Du in Deinem Fall einfach letztere in GEOS einstellen. Startet GEOS dann nicht, lädst Du es am besten neu herunter, was Dich zu XGA zurück bringt. Dann könntest Du noch versuchen, in Setting Deines Monitors nach einer Einstellung zu suchen, die eine unverzerte Skalierung erlaubt.
Die 0: Ensemble 6.0 Bundle Edition habe ich getestet. Sie nutzt noch die Nimbus-Font-Engine und bietet eine gute Darstellungsqualität und (wichtiger noch) volle Abwärtkompatibilität mit alten GEOS-Versionen. Die CI-latest DE/EN werden automatisch erstellt, bieten TTF-Support und können inzwischen kaputt sein… Wenn nicht werden trotzdem keine der BaseBox spezifischen Erweiterungen unterstützt. Die alten GEOS/NDO-Versionen sind aus reiner Nostalgie dabei…
HD Images können im HD Menü heruntergeladen, erstellt und bearbeitet werden. Aktiviert/Zugewiesen werden sie im Base-Menü. Für den DOS-Funpak bietet es sich an, diesen als LW D: einzuhängen. Gleiches gilt für den Font-Pack (nur Nimbus).
Stand der Dinge
Ich habe Pi/GEOS noch nicht ganz aufgegeben, aber die Luft ist schon etwas raus. Im letzten Monat habe ich mit KI-Unterstützung zumindest der BaseBox die (für mich) zwingend nötige Druckerunterstützung beigebracht (GitHub.com/hastho/basebox-pigeos). Durch die Hostintegration des GEOS-Grafiktreibers könnte auch das Problem mit der BS-Auflösung behoben sein, da GEOS dann passend konfiguriert wird. Der nächste notwendige Schritt, wäre Ersatz für `usbmount` zu finden und ReSiloSync aus dem Hersteller-Repo zu beziehen.
Gruß Thomas
