Unterschiede zw. TOS 2.06 und TOS 1.62 auf einem 1040STE

[dbsys]

Danke für den Hinweis, daß EmuTOS und MROS nicht zusammenpassen.

Ich muss dazu sagen, dass ich nicht weiß, ob wirklich jede MROS-Anwendung betroffen ist.

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: [Auswählen]

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)

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: [Auswählen]

[00fc289e] 4a2d 0df0                 tst.b      3568(a5)
für TOS 1.x, oder

https://github.com/th-otto/tos3x/blob/7758b6334d9dbea8277c73a08b059915a7d1c958/bios/chardev.S#L2752

Code: [Auswählen]

[00e032da] 4a38 108e                 tst.b     (ikbdstate).w ; inside a multi-byte packet?
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?

Und die Instruktionen werden ja vom C-Compiler ausgewählt, es ist also nicht einmal etwas, das man direkt in EmuTOS einbauen könnte.

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: [Auswählen]

[00fc07c4] 4a39 0000 25a4            tst.b      $000025A4

Was sich leider auch nicht einfach ändern lässt, da man nicht vorraussetzen kann, daß sich die Variable in den ersten 32k befindet.

[czietz]

Vlt. könnte man MROS dort "austricksen"? Dazu müsste man allerdings wissen, was es mit der gefundenen Addresse anfängt.

Wenn man MROS austricksen will, dann bitte per TSR o.ä. Solche dreckigen Programmierhacks kann EmuTOS nicht unterstützen. (Es ist ja nicht nur diese eine Stelle; MROS hat etliche davon.)

[dbsys]

Spannend.

MROS steht für MIDI Realtime OS. Es wurde entwickelt, um das Timing und die Weiterleitung von MIDI-Ereignissen zwischen Anwendungen und an Hardware-Schnittstellen sicherzustellen. Zusammen mit den zahlreichen .DRV Treibern erlaubt MROS den Betrieb von vielen MIDI-Schnittstellen gleichzeitig. Bekanntlich hat ein Atari nur je einen MIDI Ein- und Ausgang, was für den professionellen Einsatz nicht ausreicht(e). Es gab und gibt zahlreiche Zusatzgeräte, die nur per MROS und den Treibern einzubinden waren.

Vielleicht mußte man so "unsauber" programmieren, um die Atari-Hardware umgehen zu können?
 

[dbsys]

Übrigens, im "anderen" Atari-Forum gab es zwischen 2013 und 2018 mal eine Diskussion zum Thema "reverse engineering MROS of Cubase":

https://atari-forum.com/viewtopic.php?t=25067

[Thorsten Otto]

So wie ich das sehe, hat Foxie aber lediglich die Driver analysiert, nicht MROS selber.

Das "MROS-SDK" das dort verlinkt ist, ist sehr minimalistisch. Ausser einer Library die lediglich 3 Funktionen beinhaltet, ist dort nicht wirklich viel interessantes zu finden. Gibt es noch mehr Doku dazu?

[dbsys]

Das "MROS-SDK" das dort verlinkt ist, ist sehr minimalistisch. Ausser einer Library die lediglich 3 Funktionen beinhaltet, ist dort nicht wirklich viel interessantes zu finden. Gibt es noch mehr Doku dazu?

Ich kenne leider keine weiteren Dokumente zum MROS SDK. Im Steinberg Forum "läuft" schon seit Jahren eine Anfrage eines Nutzers, die derjenige jährlich erneuert. Ohne Reaktion seitens Steinberg. Na gut, vor Jahren schon hat jemand von Steinberg geantwortet und gesagt, daß er keine relevanten Unterlagen zu MROS finden kann.

Folgendes hat der Steinberg Mitarbeiter im Oktober 2017 geantwortet:
"i have tried to find any documentation here in our archives about MROS (1995), and did not yet find something defining the API in a easy way (only assembler/Pascal code)".

[Thorsten Otto]

@dbsys : versuch doch bitte mal angehängte gepatchte Version (insbesondere mit EmuTOS, aber ruhig auch mit anderen TOS).

Zur Info: die problematische Stelle wurde so gepatcht, daß sie auch mit EmuTOS gefunden werden sollte. Intern wird dort der komplette ACIA handler ersetzt. Hintergrund ist wohl der, daß MROS Midi-Daten selber auswerten will (hätte man wohl auch über midisys machen können), bei Tastatur-Daten wird dann zur ursprünglichen Stelle im TOS gesprungen. Die gefundene Addresse wird dort mit der Addresse des Tastatur-IOREC Pointers in a0 aufgerufen, das sollte eigentlich auch unter EmuTOS funktionieren.

Es gibt noch drei weitere Stellen, in denen ähnliches gemacht wird. Eine Stelle, die den etv_timer Code ersetzt. Diese ist hier ebenfalls gepatcht, und zwar so daß der interrupt nicht modifiziert wird. Hoffe das funktioniert, wird aber in einer für CT60 gepatchten Version ebenfalls so gemacht.

Dann gibt es noch zwei Stellen, die den USER_BUT und USER_MOT handler vom VDI ersetzen. Diese sollten (da sie ebenfalls in Assembler programmiert sind) auch in EmuTOS gefunden werden, und wurden deshalb so gelassen wie sie sind.

Ansonsten wäre es gut, wenn du mal alles was du an Entwickler-Dokumentation hast, rauskramen könntest. Insbesondere wäre es interessant zu wissen, welche Funktionen über Trap #8 und Trap #10 zur Verfügung gestellt werden.

[dbsys]

@Thorsten Otto vielen Dank für das gepatchte MROS. Ich finde es klasse, daß Du mal in den Code geschaut hast!

Wir sollten @cyberish informieren, damit er das gepatchte MROS auf seiner EmuTOS Installation ausprobieren kann, denn ich selbst betreibe (noch) keinen EmuTOS Rechner.

Ich teste aber gerne mal auf einem 1040ST mit TOS 1.04 und einem 1040STE mit TOS 2.06. Am kommenden Wochenende komme ich eventuell schon dazu und berichte dann.

Leider besitze ich keine Entwickler-Dokumentation von Steinberg.

[cyberish]

@Thorsten Otto
Klasse, vielen Dank für den Patch. - I.d.F. hat Tango MROS 345 unter EmuTOS 1.3 geladen, MIDI Daten kommen an und gehen weg! Jedoch stürzt das Programm ab, sobald die Maus bewegt wird. - s.h. Bildschirmfotos: Jeweils nach dem Absturz durch das Bewegen der Maus.

[dbsys]

@Thorsten Otto
Klasse, vielen Dank für den Patch. - I.d.F. hat Tango MROS 345 unter EmuTOS 1.3 geladen, MIDI Daten kommen an und gehen weg! Jedoch stürzt das Programm ab, sobald die Maus bewegt wird. - s.h. Bildschirmfotos: Jeweils nach dem Absturz durch das Bewegen der Maus.

Immerhin startet Tango schon mal....

[Thorsten Otto]

Der Absturz dürfte dann wohl in den Routinen liegen die MROS noch patcht. Hab mal die entsprechenden Stellen extrahiert (vlt. hat @czietz eine Idee was da schief geht?)

Code: [Auswählen]

install_cur_motv:
[00011aa2] 247a 08bc                 movea.l    linevars(pc),a2
[00011aa6] 45ea ffce                 lea.l      -50(a2),a2      /* lea user_mot(a2),a2 */
[00011aaa] 2052                      movea.l    (a2),a0         /* get original user_motv */
[00011aac] 23c8 0001 1b02            move.l     a0,new_user_mot-4    /* save it */
install_cur_motv_2:
[00011ab2] 0ca8 5842 5241 fff4       cmpi.l     #$58425241,-12(a0) /* XBRA chain? */
[00011aba] 6606                      bne.s      install_cur_motv_1 /* no */
[00011abc] 2068 fffc                 movea.l    -4(a0),a0          /* continue searching */
[00011ac0] 60f0                      bra.s      install_cur_motv_2
install_cur_motv_1:
[00011ac2] 43fa 006a                 lea.l      old_motv_code(pc),a1
[00011ac6] 47fa 003e                 lea.l      new_user_mot(pc),a3
[00011aca] 41e8 000c                 lea.l      12(a0),a0        /* skip the lea gstack,a7 in original code */
[00011ace] 323c 007a                 move.w     #123-1,d1
install_any_motv_2:
[00011ad2] 3018                      move.w     (a0)+,d0         /* get opcode */
[00011ad4] b07c 2e79                 cmp.w      #$2E79,d0        /* movea.l abs.l opcode at end of routine? */
[00011ad8] 6708                      beq.s      install_any_motv_1
[00011ada] 32c0                      move.w     d0,(a1)+         /* copy old code */
[00011adc] 51c9 fff4                 dbf        d1,install_any_motv_2
[00011ae0] 4e75                      rts
install_any_motv_1:
[00011ae2] 22fc 4e71 4e71            move.l     #$4E714E71,(a1)+ /* write 3 nops */
[00011ae8] 32fc 4e71                 move.w     #$4E71,(a1)+
[00011aec] 41e8 0004                 lea.l      4(a0),a0         /* skip remaining opcode of orginal routine */
install_any_motv_3:
[00011af0] 32d8                      move.w     (a0)+,(a1)+      /* copy rest of old code if any */
[00011af2] 51c9 fffc                 dbf        d1,install_any_motv_3
[00011af6] 248b                      move.l     a3,(a2)          /* set new vector */
[00011af8] 4e75                      rts

dc.l 'XBRA'
dc.l 'MROS'
dc.l 0
new_user_mot:
[00011b06] 4af9 0001 1c2e            tas.b      $00011C2E
[00011b0c] 661e                      bne.s      new_user_mot_1
[00011b0e] 23df 0001 1c30            move.l     (a7)+,$00011C30
[00011b14] 027c f4ff                 andi.w     #$F4FF,sr
[00011b18] 6100 0014                 bsr.w      old_motv_code
[00011b1c] 007c 0700                 ori.w      #$0700,sr
[00011b20] 4279 0001 1c2e            clr.w      $00011C2E
[00011b26] 2f39 0001 1c30            move.l     $00011C30,-(a7)
new_user_mot_1:
[00011b2c] 4e75                      rts

old_motv_code:  ds.w 123

Der user_mot vector in den linea-variable zeigt ursprünglich auf die far_mchange routine: https://github.com/emutos/emutos/blob/69d289251f119e19031265ea6f9ea41ac394c303/aes/gemdosif.S#L327-L349 (siegt in TOS 2.x praktisch genauso aus). Was der patch macht hat zur Folge daß
- die routine nicht mehr auf einem eigenen Stack ausgeführt wird (der ist aber eh sehr klein, und wenn das in TOS funktioniert, sollte es auch in EmuTOS kein Problem sein)
- Interrupts werden während dieser Zeit zugelassen, und erst hinterher wieder gesperrt. Ich vermute mal daß hier irgendwas schief geht.

Warum das überhaupt gemacht wird, kann ich nur vermuten. Möglicherweise gehen sonst MIDI Daten verloren. Allerdings halt ich das zulassen von Interrupts an dieser Stelle auch für gefährlich (siehe auch https://github.com/emutos/emutos/blob/69d289251f119e19031265ea6f9ea41ac394c303/aes/gemdisp.c#L48, das ist die C-Routine die vom ursprünglichen Code aufgerufen wird). Man könnte aber mal ausprobieren was passiert wenn man diese Routinen auspatcht. Ist in der angehängten Version der Fall.

[cyberish]

Danke Thorsten

selbes Szenario: beim Bewegen der Maus stürzt es ab. MIDI IN, OUT ist ok. (EMUTOS 1.3 in HATARI 2.50)

[Lukas Frank]

Wenn Midi Ein und Ausgaben erfolgen und man gleichzeitig Tastatur oder Maus bedient darf es ja zu keinerlei Störungen bei der Midi Geschichte kommen z.B. vom TOS ...

... vermute ich mal, deshalb MROS

[KarlMüller]

Das "MROS-SDK" das dort verlinkt ist, ist sehr minimalistisch. Ausser einer Library die lediglich 3 Funktionen beinhaltet, ist dort nicht wirklich viel interessantes zu finden. Gibt es noch mehr Doku dazu?

Auf die schnelle hätte ich folgendes. Muss mal schauen ob ich noch was finde.

[Thorsten Otto]

Danke, das hilft schon mal weiter.

Für die Abstürze habe ich leider noch keine Erklärung.