Hardware > Hardware (Classic 16-/32-Bit)
Unterschiede zw. TOS 2.06 und TOS 1.62 auf einem 1040STE
dbsys:
--- Zitat von: czietz am Mo 03.02.2025, 07:37:18 ---
--- Zitat von: dbsys am So 02.02.2025, 22:45:57 ---Danke für den Hinweis, daß EmuTOS und MROS nicht zusammenpassen.
--- Ende Zitat ---
Ich muss dazu sagen, dass ich nicht weiß, ob wirklich jede MROS-Anwendung betroffen ist.
--- Ende Zitat ---
Es ist zu vermuten.
Würde es den EmuTOS Entwicklern vielleicht helfen, sich die MROS Erweiterung isoliert von den Steinberg Anwendungen anzusehen? Es gab damals für Entwickler einen Hinweis mit dem man ein beliebiges MROS isoliert laden konnte. Die Informationen dazu kann ich gern heraussuchen.
czietz:
Ich befürchte, MROS ist ein hoffnungsloser Fall. Es versucht, die Adresse einer internen, undokumentierten Atari-TOS-Funktion zu raten. Das ist leider dermaßen unsauber programmiert, dass ich keinen Weg sehe, das in EmuTOS zu unterstützen. Eher müsste jemand MROS patchen.
dbsys:
Alles klar, ich verstehe. Dann muß man das halt so hinnehmen.
czietz:
Hier mal ein Stück des "Grauens" aus MROS:
--- Code: ---003EFB96 2078 0118 movea.l $00000118.w,a0
003EFB9A 23C8 003F 0314 move.l a0,$003F0314
003EFBA0 0CA8 5842 5241 FFF4 cmp.l #$58425241,(a0,-$000C)
003EFBA8 6606 bne.b #$06
003EFBAA 2068 FFFC movea.l (a0,-$0004),a0
003EFBAE 60F0 bra.b #$F0
003EFBB0 3018 move.w (a0)+,d0
003EFBB2 B07C 4A38 cmp.w #$4A38,d0
003EFBB6 6706 beq.b #$06
003EFBB8 B07C 4A2D cmp.w #$4A2D,d0
003EFBBC 66F2 bne.b #$F2
003EFBBE 4A60 tst.w -(a0)
003EFBC0 2B48 0024 move.l a0,(a5,$0024)
--- Ende Code ---
Es schnappt sich den ACIA-Interrupt-Vektor ($118), verfolgt eine eventuelle XBRA-Kette zurück, bis es (mutmaßlich) im TOS-Code landet und sucht dann (CMP.W) nach einer von zwei hartcodierten Instruktionen! Das klappt natürlich nicht in einem anderen OS (z.B. EmuTOS oder jedes beliebige andere OS), das nicht exakt diese Instruktionen verwendet. Und die Instruktionen werden ja vom C-Compiler ausgewählt, es ist also nicht einmal etwas, das man direkt in EmuTOS einbauen könnte.
Extrem unsauber programmiert. Solchen Stellen gibt es mehrfach.
Thorsten Otto:
Die Stelle die dort gefunden wird, ist entweder
https://github.com/th-otto/tos1x/blob/cb2c04ed186404c0a8c0ea78dabf615314d9d0b2/bios/chardev.S#L1565
--- Code: ---[00fc289e] 4a2d 0df0 tst.b 3568(a5)
--- Ende Code ---
für TOS 1.x, oder
https://github.com/th-otto/tos3x/blob/7758b6334d9dbea8277c73a08b059915a7d1c958/bios/chardev.S#L2752
--- Code: ---[00e032da] 4a38 108e tst.b (ikbdstate).w ; inside a multi-byte packet?
--- Ende Code ---
für TOS 2.x/3.x
Ich frag mich nur was er mit dieser Addresse anfängt. Der code dort wird nur erreicht, wenn es sich um ein Byte von der Tastatur handelt. Ich würde ja verstehen wenn er irgendwie die MIDI Daten abfängt, aber warum solch ein Hack für Tastatur-Events?
--- Zitat ---Und die Instruktionen werden ja vom C-Compiler ausgewählt, es ist also nicht einmal etwas, das man direkt in EmuTOS einbauen könnte.
--- Ende Zitat ---
Naja, nicht ganz. Der entsprechende Code ist auch in EmuTOS in Assembler programmiert. Und wenn ich das richtig sehe, müsste er dort eine ähnliche Stelle bei
https://github.com/emutos/emutos/blob/69d289251f119e19031265ea6f9ea41ac394c303/bios/aciavecs.S#L408
finden
Vlt. könnte man MROS dort "austricksen"? Dazu müsste man allerdings wissen, was es mit der gefundenen Addresse anfängt.
Edit: ne, der Code wird wohl in EmuTOS gar nicht gefunden, weil dort eine andere Addressierung benutzt wird:
--- Code: ---[00fc07c4] 4a39 0000 25a4 tst.b $000025A4
--- Ende Code ---
Was sich leider auch nicht einfach ändern lässt, da man nicht vorraussetzen kann, daß sich die Variable in den ersten 32k befindet.
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln