Hardware > Emulatoren

AtariX => MagicOnLinux

<< < (73/77) > >>

AndreasKromke:
Der NVDI-Patch ist jetzt im Repository gelandet, nebst einer umfangreichen Anleitung. Ich habe ein einfaches Patch-Programm geschrieben, das im "assets"-Ordner liegt. Das muß man compilieren und ausführen, dann erzeugt es aus dem NVDI.PRG ein NVDI_PAT.PRG. Das erschien mir sicherer als die bsdiff/bspatch-Variante, jedenfalls testet es Dateilänge und vorherigen Inhalt.

Das ganze NVDI-Konzept ist mir immer noch ein Rätsel. Der NVDI-Kernel kann nur bestimmte Grafikmodi und schreibt zumindest beim VT52 Byte-weise in den Speicher. Die nachladbaren Treiber enthalten dann wohl die optimierten Varianten oder welche, die der NVDI-Kernel nicht kann. Da gibt es vermutlich einen Haufen Redundanz, z.B. in NVDI.PRG und NVDIDRV1.SYS. Vielleicht ist einiges auch nicht genial, sondern nur historisch gewachsen.

AndreasKromke:
Nach dem elenden NVDI-G'lump bin ich jetzt endlich dazu gekommen, Thorstens erweitertes Installation-Script zu übernehmen. Ich habe es teilweise testen können (mit dummy-Aufrufen), hatte aber erstmal Syntax-Fehler, die ich hoffentlich behoben habe.

Jedenfalls wird damit u.a. auch macOS berücksichtigt, weswegen die Anleitung MACOS.txt jetzt möglicherweise nicht mehr korrekt ist, weil teilweise obsolet. Vielleicht kann mal einer von Euch Apple-Jüngern draufschau'n, was da noch paßt.

Und vielleicht entstaube ich auch mal meinen alten Mac und probiere es selber aus. Hat es schon mal jemand mit "Mojave" ausprobiert? Ich weiß nicht mal, ob es eine neuere Xcode-Version gibt als die, die noch drauf ist, und "brew" habe ich auch wenig verwendet. Aber dazu gibt es ja das Internet.

AndreasKromke:
Ich habe jetzt endlich die Zeit gefunden, Thorstens Anti-Phantom-Doppelklick-Patch für Magxdesk einzupflegen. Mir ist immer noch nicht klar, wie es zu dieser Fehlfunktion kommt; vielleicht ist da noch ein Konzeptfehler im AES. Ob das Phänomen auch in anderen Programmen auftritt, weiß ich nicht.

Seltsamerweise hatte ich den Effekt auf meinem eigenen Rechner sehr selten, aber auf einem anderen, wo ich aber wenig testen konnte, ständig; mitunter gingen drei oder mehr Fenster auf. Die Hauptunterschiede zwischen den beiden Rechnern sind, meine ich, daß meiner neuer und damit etwas schneller ist und daß meiner nicht gut mit Wayland läuft, weswegen ich immer noch X11 verwende.

Und ja, es gibt noch andere Unschönigkeiten (Neologismus!) in Magxdesk, z.B. die Anzeige des freien Festspeichers. Wenn wir großzügig einen Speicher mit 20 TB annehmen, brauchen wir 45 Bit für die Anzahl der Bytes. Wenn wir 4k als Blockgröße annehmen, sind das 12 Bit. Damit braucht die Anzahl der Blöcke 33 Bit, wodurch wir in DISKINFO.b_free und DISKINFO.b_total einen Überlauf kriegen. Irgendwie neige ich dazu, eine neue Dcntl()-Funktion einzuführen, die 64-Bit-Werte liefert. Keine Ahnung, wie MiNT das löst, das ist ja neuer.

Thorsten Otto:
b_total und b_free sind Anzahl von Blöcken. Auch auf sehr grossen Festplatten ist es ziemlich unwahrscheinlich, daß das einen 32bit-Wert überschreitet. Allerdings ist dein Fix in xfs_dfree() (https://gitlab.com/AndreasK/magiclinux/-/blame/main/src/HostXFS.cpp?page=3#L2652) falsch, wo die gesamte Festplatten-Grösse auf 31 bit beschränkt wird.

Bei der Multiplikation mit der Blockgrösse kann der Wert natürlich überlaufen, aber dafür sind bereits 64bit-Funktionen vorhanden.

Bei MiNT gibt es Dcntl(FS_USAGE) das 64bit-Werte liefert, allerdings wird das bisher weder vom MagiC-Kernel unterstützt noch von MagXDesk (oder MCMD) verwendet.

AndreasKromke:
Hat jemand eine Idee, ob und wie man den PureDebugger zum Laufen kriegen könnte? Man muß dann natürlich mit der Auflösung runtergehen, also notfalls im Modus ST-High.

Ich habe sowohl den originalen PD von 1993 ausprobiert als auch einen mit Patch von [http://www.dimitri-junker.de/atari.html]. Die verhalten sich beide gleich. Man kann so leidlich mit Esc die Bildschirme umschalten, und einmal konnte ich auch ein CPU-Fenster sehen, das habe ich aber nie wieder hingekriegt. Ich habe auch keine Erinnerung mehr, ob die unter MagicMac oder MagicMacX liefen. Seltsam ist auch, daß der Debugger auf die Register 0xffff8201/3/d schreibt (physische Bildschirmspeicheradresse). Das kann doch auf dem Mac nie funktioniert haben. Der Patch ändert daran nichts, dabei gibt es doch einen Xbios-Aufruf für solche Schweinereien.

Oder gibt es einen Alternativ-Debugger? Einen, der weniger ins System eingreift? Mir fällt da nur der DB von Atari ein, aber der kann nur Assembler, soweit ich weiß. Ansonsten bleibt nur das mühsame printf-Debugging.

Mit Strg-Q kommt man wieder raus. Blind. Seltsam.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete