Hardware > Emulatoren
AtariX => MagicOnLinux
Thorsten Otto:
--- Zitat von: AndreasKromke am Mo 15.12.2025, 10:26:20 ---Einfach pasm -v -b MFM4IP.SYS.
--- Ende Zitat ---
Huks, tatsächlich.:
--- Code: ------ ok 2025-12-15 13:10:28.479910052 +0100
+++ wrong 2025-12-15 13:10:32.613225013 +0100
@@ -80,7 +80,7 @@
[000000ec] 4258 clr.w (a0)+
[000000ee] 20f9 0000 04ea move.l $000004EA,(a0)+
[000000f4] 7027 moveq.l #39,d0
-[000000f6] 247a 03e6 movea.l $000004DE(pc),a2
+[000000f6] 247a 0000 movea.l $000000F8(pc),a2
[000000fa] 246a 002c movea.l 44(a2),a2
[000000fe] 45ea 000a lea.l 10(a2),a2
[00000102] 30da move.w (a2)+,(a0)+
--- Ende Code ---
"wrong" wurde mit -b übersetzt, und die Instruktionen kommen von sowas wie "move nvdi_struct(pc),a2", wobei nvdi_struct im BSS-Segment iegt. Frage mich nur, ob hier nicht der Linker der ist der den Murks baut. Aber einer von beiden sollte auf jeden Fall meckern.
Da ich bei mir beim übersetzen aber DRI nicht benutze, sind die binaries dort nicht betroffen.
Einfach Abhilfe wäre auch, dort entweder nicht pc-relative zu benutzen, oder die Variablen nicht ins BSS zu legen.
--- Zitat ---Übrigens hatte ich noch offiziell eine Version (so etwas habe ich immer freundlicherweise von ASH bekommen) etwa vom Januar 1993 (?), und aus ominöser Quelle habe ich jüngst ein Archiv gefunden mit einem pasm vom Juni desselben Jahres. Das ist hoffentlich das neueste.
--- Ende Zitat ---
Da wäre ich sehr daran intereressiert.
AndreasKromke:
--- Zitat von: Thorsten Otto am Mo 15.12.2025, 13:28:39 ---
"wrong" wurde mit -b übersetzt, und die Instruktionen kommen von sowas wie "move nvdi_struct(pc),a2", wobei nvdi_struct im BSS-Segment iegt. Frage mich nur, ob hier nicht der Linker der ist der den Murks baut. Aber einer von beiden sollte auf jeden Fall meckern.
--- Ende Zitat ---
Sach ich ja. Und es liegt natürlich nicht am Linker, sondern das Format gibt das nicht her.
Mein Debugger übersetzt auch .o-Dateien, inklusive aller Symbole. Du mußt, glaube ich, "-n" spezifizieren, weil der faule Assembler den Code nicht markiert, wie er es tun müßte. Dann kannst Du genau sehen, wer schuld ist.
Bei atari-forum.com gibt es einen Faden "A couple abandonware apps", dort findet man zwar nicht alles Mögliche, aber alles mögliche. Schau dort mal nach!
Thorsten Otto:
--- Zitat von: AndreasKromke am Mo 15.12.2025, 13:57:47 ---das Format gibt das nicht her.
--- Ende Zitat ---
Eigentlich schon. Der linker sieht ja, wo die Referenz erfolgt, und wo das Symbol liegt das referenziert wird. Der Assembler sieht das nur, wenn das Symbol bekannt ist, was aber nicht unbedingt der Fall sein muss.
--- Zitat ---Bei atari-forum.com gibt es einen Faden "A couple abandonware apps", dort findet man zwar nicht alles Mögliche, aber alles mögliche. Schau dort mal nach!
--- Ende Zitat ---
Dann scheine ich die wohl zu haben ;) Die Version von der ich ausgegangen bin, meldet sich mit Jun 21 1993
AndreasKromke:
Oliver Buchmann himself war so nett, auch die ASH-Website entsprechend zu aktualisieren: https://www.application-systems.de/magicmacx/.
Vielen Dank dafür!
AndreasKromke:
--- Zitat von: Thorsten Otto am Fr 12.12.2025, 16:51:59 ---Fliesskomma korrekt zu emulieren ist sowieso so eine Sache. Problem ist daß bei den meisten Compilern double nur 64bit ist, womit sich die 68k-Fließkomma-Werte nicht korrekt darstellen lassen. Und long-double ist nicht überall verfügbar. Selbst wenn, gibt es da kleine aber feine Unterschiede in der externen Darstellung (nicht nur endian-Probleme, 68k speichert die ohne implizites integer-Bit und hat dadurch 1 bit mehr für die Mantisse als z.B. x86).
Edit: oh, sehe gerade, unter https://github.com/kstenerud/Musashi gibt es eine deutlich neuere Version.
--- Ende Zitat ---
Die FPU-Unterstützung in Musashi läuft offenbar ohne "long double", daher signifikant langsamer als möglich, aber ist vermutlich nicht ganz zu Ende gedacht. Zitat:
--- Code: ---extern void m68040_fpu_op0(void);
extern void m68040_fpu_op1(void);
extern void m68881_mmu_ops(void);
--- Ende Code ---
Das wirkt etwas seltsam. Die PMMU ist bekanntlich 68851 und nicht 68881, außerdem fehlen dem 68040 ein paar FPU-Befehle, die man softwaretechnisch nachrüsten müßte -- oder man tut so, als ob die FPU vollständig wäre. Eigentlich schwebte mir die Konfiguration 68020+68882 vor, das macht am wenigsten Umstand, und eine PMMU ist "teuer". Wäre das ein 68EC040 (EC für economy class)? Ich habe die Übersicht verloren.
Außerdem ist der Emulator komplizierter geworden; die eigentlichen Funktionen werden erst generiert, möglicherweise im make-Prozeß, d.h. es gibt eine Art template und einen Code-Generator.
Ist vielleicht den Aufwand doch nicht wert. Schneller würde es vermutlich auch nicht.
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln