Hardware > Emulatoren
AtariX => MagicOnLinux
AndreasKromke:
Eigentlich müßte man doch mit https://github.com/att/uwin (Beschreibung: https://www.usenix.org/legacy/publications/library/proceedings/usenix-nt97/full_papers/korn/korn.pdf) den Emulator mit überschaubarem Aufwand auf Windows portieren können. Von dem alten Zeugs (1997!) bräuchte man nur einen kleinen Teil. Verdächtig ist natürlich, daß anscheinend niemand das je verwendet hat, und es wird auch nicht daran gearbeitet.
PS: Und man braucht natürlich "SDL2-devel-2.30.12-VC.zip", das scheint die letzte Version 2 zu sein. Und https://visualstudio.microsoft.com/de/vs/features/cplusplus/.
tosbombe:
--- Zitat von: AndreasKromke am Mi 01.04.2026, 15:20:21 ---Eigentlich müßte man doch mit https://github.com/att/uwin (Beschreibung: https://www.usenix.org/legacy/publications/library/proceedings/usenix-nt97/full_papers/korn/korn.pdf) den Emulator mit überschaubarem Aufwand auf Windows portieren können.
--- Ende Zitat ---
Sollte es nicht ausreichend sein, auf das Posix Subsystem für Windows zurückzugreifen? Wurde zwar nach Windows 2000 entfernt, aber dürfte durch bloßes Kopieren der psxss.exe Datei aus einer alten Windows Installation wiederherstellbar sein, vgl. hierzu https://de.wikipedia.org/wiki/POSIX-Subsystem
ragnar76:
Keine Ahnung ob es so viel Sinn macht "veraltete" Tools zu nutzen. Bei uwin gab es, laut GitHub, vor 11 Jahren die letzten Änderungen und Posix für Windows, naja. Ich kann mir auch nicht vorstellen dass sich jemand WSL2 dafür installieren würde. Was wäre denn mit z.b. mit GTK-3? Das gibt's ja für Windows, Gimp z.B. nutzt es oder auch Inkscape. Eine weitere Alternative wäre QT was von VLC, Krita oder Wireshark benutzt wird. Beide gibt es für Linux, MacOS und Windows
AndreasKromke:
Nein, es geht im wesentlichen darum, die Standard-Aufrufe für das Dateisystem, z.B. openat(), auf Win32, oder was man heute verwendet, umzusetzen. Ich möchte den Emulator selber nicht verändern, also nicht alles wegwerfen und auf Qt o.ä. umstellen. Dann hätte ich initial mit einem Qt-Projekt gestartet, ohne SDL.
AndreasKromke:
Der eigentliche VDI-Grafiktreiber für 16M Farben ist OFF16MOV, d.h. hauptsächlich hier wird in den Bildspeicher geschrieben. Wofür auch immer das "OV" steht...
Immer wieder seltsam:
Ich habe zwar von B&B den Quelltext bekommen, der entspricht aber nicht ganz dem binary. Vergleiche mit meinem Disassembler (der übrigens nativ unter Linux läuft) zeigen im wesentlichen zwei Unterschiede. In einer Funktion ist die Binärversion anscheinend neuer, jedenfalls sieht der Code besser optimiert aus. Auf der anderen Seite hat die Binärversion aber anscheinend eine völlig kaputte Relokationstabelle. Die ist eigentlich dafür gedacht, Adreßunterschiede zwischen erwarteter und tatsächlicher LineA-Basisadresse beim Start des Treibers auszugleichen. Nun ist der Treiber aber genau für die LineA-Adresse des Kernels compiliert, so daß keine Relozierung nötig ist und die Routine, die den Treiber unweigerlich zerstören würde, nicht ausgeführt wird. Also ist anscheinend diese Tabelle wiederum bei der Quelltext-Version neuer bzw. einzig korrekt, nämlich leer.
Vermutlich sieht es bei den anderen Modi nicht anders aus. Eigentlich ein Wunder, daß das alles soweit funktioniert.
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln