atari-home.de - Foren
Hardware => Hardware (Classic 16-/32-Bit) => Thema gestartet von: dbsys am Do 03.03.2016, 14:28:15
-
Ich habe einen 1040STE mit TOS 2.06.
Eine bestimmte Software löst beim Programmstart immer 3 Bomben aus und beendet sich dann sang und klanglos.
Genau diese Software funktioniert hingegen problemlos, wenn ich TOS 1.62 einbaue.
Meine Fragen dazu sind:
1) Worin liegen die wesentlichen Unterschiede zwischen TOS 2.06 und TOS 1.62 auf einem 1040STE?
2) Welcher der Unterschiede könnte eventuell verantwortlich für den Programmabsturz unter TOS 2.06 sein? Ließe sich das für den Absturz verantwortliche "Feature" vielleicht gezielt abschalten?
-
2) Welcher der Unterschiede könnte eventuell verantwortlich für den Programmabsturz unter TOS 2.06 sein?
Vieles ist denkbar. Das kann soweit gehen, dass die Software eine TOS-Funktion mit ungültigen Parametern aufruft und TOS 1.62 das durchgehen lässt und TOS 2.06 nicht. Oder die Software fummelt an undokumentierten Variablen herum, die so nur in TOS 1.62 existieren.
Näheres wird man sagen können, wenn Du entweder die Software zur Verfügung stellst oder zumindest mit einem Debugger den Ort das Absturzes (und den Kontext dazu) herausfindest.
-
2) Welcher der Unterschiede könnte eventuell verantwortlich für den Programmabsturz unter TOS 2.06 sein?
Vieles ist denkbar. Das kann soweit gehen, dass die Software eine TOS-Funktion mit ungültigen Parametern aufruft und TOS 1.62 das durchgehen lässt und TOS 2.06 nicht. Oder die Software fummelt an undokumentierten Variablen herum, die so nur in TOS 1.62 existieren.
Näheres wird man sagen können, wenn Du entweder die Software zur Verfügung stellst oder zumindest mit einem Debugger den Ort das Absturzes (und den Kontext dazu) herausfindest.
Danke für Deine Antwort.
Mit einem Debugger kann ich zwar nicht umgehen, aber der Link zur fraglichen Software lautet:
http://www.henning-berg.de/files/TangoAtari.zip
-
Die gute Nachricht: Das Programm stürzt auch im Emulator unter TOS 2.06 ab.
Die schlechte Nachricht: Der Absturz ist irgendwo mitten im AES-Code während der Anzeige des Logos/Startbildschirms mittels objc_draw. Ich vermute, dass da irgendwas nicht ganz sauber programmiert ist, z.B. eine Resource. Das könnte am besten der Autor fixen.
-
@dbsys, heute ist Dein glücklicher Tag. ;)
Nach einiger Zeit im Debugger habe ich herausgefunden, dass der Absturz nur durch ein nicht (oder nicht richtig?) eingebundenes Bild im Splash-Screen/Start-Bildschirm zustande kommt. Ich habe den Verweis auf dieses Bild mal herausgepatcht. Leider verstehe ich überhaupt nicht, wie das Programm funktionier, aber es scheint zumindest nicht mehr zu crashen.
-
@czietz : es wäre sicherlich für einige hier interessant zu erfahren, wie und womit du das alles so machst. Welche Programme setzt die wie ein? Bitte erkläre mal, evt in einem eigenen Beitrag.
Ich bin nahe dran zu glauben, dass das alles Hexenwerk ist!
-
@dbsys, heute ist Dein glücklicher Tag. ;)
Nach einiger Zeit im Debugger habe ich herausgefunden, dass der Absturz nur durch ein nicht (oder nicht richtig?) eingebundenes Bild im Splash-Screen/Start-Bildschirm zustande kommt. Ich habe den Verweis auf dieses Bild mal herausgepatcht. Leider verstehe ich überhaupt nicht, wie das Programm funktionier, aber es scheint zumindest nicht mehr zu crashen.
Oh, Wahsinn!!
Ich werde das gepatchte Programm am Wochenende mal intensiv durchprobieren.
Aber schon jetzt ein dickes Lob, @czietz.
Und ich schließe mich Gaga an, das grenzt schon an Zauberei, was Du so alles hinbekommst.
-
Wie gewünscht, möchte ich hier erklären, wie ich vorgegangen bin. Ich mache keinen eigenen Thread dafür auf, weil das Vorgehen von Problem zu Problem sehr unterschiedlich ist und ich es daher nur am Beispiel von TANGO.PRG beschreibe.
Aufgrund von dbsys' Fehlerbeschreibung habe ich das Programm mit TOS 2.06 in Steem gestartet und zwar in der Debug-Version von Steem. Die bietet u.a. die Möglichkeit, Speicherinhalt und Disassembly des ST zu sehen und Schritt für Schritt durch ein Programm durchzu"step"pen. Insbesondere wird der Debugger auch aktiv, wenn ein Programm auf dem ST abstürzt.
So konnte ich sehr schnell herausfinden dass der Absturz an Adresse 0xE0E16A (im TOS-ROM) stattfindet, weil ein 16-bit breiter Zugriff auf die Adresse 0xFF0001 versucht wird. Auf ungerade Adressen darf nur byte-breit zugegriffen werden, sonst gibt es einen Address Error mit 3 Bomben. Aber ohnehin ist diese Adresse unsinnig, da in einem "normalen" ST(E) nichts an dieser Speicheradresse ist. Wenn ein Absturz im TOS passiert, ist die wahrscheinlichste Ursache, dass irgendeine Betriebssystemfunktion mit falschen Daten aufgerufen wird.
Warum aber dieser Speicherzugriff und in welcher Funktion? Dazu bin ich zu Hatari gewechselt, der ebenfalls einen eingebauten Debugger hat. Dieser ist von der Bedienung nicht so komfortabel wie der von Steem, erlaubt es aber dafür, die Funktionsnummern von aufgerufenen BIOS-, XBIOS-, GEMDOS-, VDI- und AES-Funktionen zu protokollieren. Daran konnte ich erkennen, dass die letzte aufgerufene Funktion objc_draw im AES war, die einen Baum an Objekten (also GUI-Elementen, die z.B. aus einer Resource-Datei stammen oder in diesem Fall im Programm eingebunden sind) auf dem Bildschirm darstellt.
Ein Blick ins Atari Profibuch verrät, wie und mit welchen Parametern objc_draw aufgerufen wird. Der Objektbaum ist der komplexeste Parameter, der an objc_draw übergeben wird, also ist es am wahrscheinlichsten, dass der Fehler dort liegt. Anhand der Dokumentation im Profibuch konnte ich mich im Hatari-Debugger durch den Speicher des ST hangeln, bis ich bei besagtem Objektbaum angekommen war. Ich habe den Objektbaum zur einfacheren Analyse in einer Datei ge"dump"t.
Das Profibuch erläutert auch die Struktur des Objektbaums, den ich mir im Hexeditor angesehen habe. Ein Großteil der Objekte im betroffenen Baum sind von Typ einfache GUI-Elemente wie Rahmen, Texte oder Buttons. Aber zwei sind Bilder. Auch hier gilt wieder, dass die Wahrscheinlichkeit größer ist, dass komplizierte Datenstrukturen (wie die Bilder) korrupt sind. Also habe ich mir die Bilder gezielt vorgenommen und bin (wieder in Hatari) deren Speicheradressen nachgegangen. Ein Bildeintrag zeigt auf eine korrekte BITBLK-Struktur, der andere hingegen nicht. Offensichtlich ist beim Eincompilieren der Bilder in TANGO.PRG etwas schief gelaufen.
Da die Bilder nur den Start-Bildschirm verschönern, habe ich den Eintrag des zweiten Bilds im Objektbaum wieder mit dem Hexeditor in TANGO.PRG so verbogen, dass es auf die Daten des ersten Bilds zeigt. Test zeigt: Absturz behoben.
-
Inzwischen kann ich schon zu Protokoll geben, daß die gepatchte Version von Tango völlig klaglos auf einen 1040 STE unter TOS 2.06 gestartet werden kann.
Auch auf einem Falcon mit TOS 4.04 startet die Software nun. Mit der ungepatchten Version der Software gab es beim Start immer einen Absturz mit 2 Bomben.
Nun muß ich mich erstmal in Tango einfinden. Bei der Gelegenheit werde ich hoffentlich feststellen, ob die gepatchte Version grundsätzlich läuft.
Vielen Dank an czietz für die hervorragende und spannende Erläuterung der Vorgehensweise.
-
Inzwischen kann ich schon zu Protokoll geben, daß die gepatchte Version von Tango völlig klaglos auf einen 1040 STE unter TOS 2.06 gestartet werden kann.
Schon dem Autor mitgeteilt? Auch wenn die Software schon alt ist wird er sich über ein Rückmeldung wahrscheinlich freuen.
-
Ich habe mal das Kontaktformular auf seiner Webseite ausgefüllt und ihn auf diesen Thread hingewiesen.
-
Da ich das Programm seit 1999 selbst besitze und ich es gerne über HATARI zum Laufen bringen würde, hier eine Auferstehung dieses Themas: Unter EmuTOS läuft es nicht. Bekomme es hin, das Programm nach einem Absturz zu laden, aber dann geht nichts. Konstantins Hinweis hier hat mich weiter gebracht: Unter TOS 1.62 in HATARI (2.50) scheint alles zu funktionieren.
Inwieweit der HD Treiber von Ppera (vers.0.9) da mitmischt, kann ich noch nicht sagen.
-
Da ich das Programm seit 1999 selbst besitze und ich es gerne über HATARI zum Laufen bringen würde, hier eine Auferstehung dieses Themas: Unter EmuTOS läuft es nicht. Bekomme es hin, das Programm nach einem Absturz zu laden, aber dann geht nichts. Konstantins Hinweis hier hat mich weiter gebracht: Unter TOS 1.62 in HATARI (2.50) scheint alles zu funktionieren.
Inwieweit der HD Treiber von Ppera (vers.0.9) da mitmischt, kann ich noch nicht sagen.
Hast Du schon die von @czietz modifizierte Version ausprobiert? Die ist ja weiter oben zum Download verlinkt. Diese modifizierte Version läuft bei mir unter TOS 2.06 auf dem 1040 STE und sogar auf 4.04 auf dem Falcon.
-
Ja, klasse, die Version von czietz funzt mit den verschiedenen orginial TOS' aber nicht mit EmuTOS 1.3.
-
Ja, klasse, die Version von czietz funzt mit den verschiedenen orginial TOS' aber nicht mit EmuTOS 1.3.
Kannst Du bitte mal näher beschreiben, wie das Verhalten der obigen Tango Software unterEmuTOS 1.3 ist? Passiert überhaupt etwas bei Programmstart?
-
Hi Konstantin
unter EmuTOS 1.3 in HATARI 2.50 (Mac Version) passiert folgendes, s.h. Bildschirmfoto
-
Gleiches Problem wie bei Cubase; was daran liegen dürfte, dass auch Tango MROS (MIDI - Realtime - Operating - System) verwendet. Es wird versucht, interne TOS-Funktionen zu "hacken", was unter EmuTOS halt nicht klappen kann, weil die Funktionen dort anders implementiert sind als unter Atari TOS. => Atari TOS verwenden.
-
Ok, genau. Das ist die Logik. Ja, Tango benötigt MROS. Danke für den Hinweis.
-
Danke für den Hinweis, daß EmuTOS und MROS nicht zusammenpassen.
Das war mir nicht bekannt.
-
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. Cubase und Tango sind es auf alle Fälle, aus dem oben genannten Grund. Für Cubase ist das auch längst dokumentiert: https://github.com/emutos/emutos/blob/69d289251f119e19031265ea6f9ea41ac394c303/doc/incompatible.txt#L244. (Für Tango nun auch.)
-
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.
-
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.
-
Alles klar, ich verstehe. Dann muß man das halt so hinnehmen.
-
Hier mal ein Stück des "Grauens" aus MROS:
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.
-
Die Stelle die dort gefunden wird, ist entweder
https://github.com/th-otto/tos1x/blob/cb2c04ed186404c0a8c0ea78dabf615314d9d0b2/bios/chardev.S#L1565
[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
[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:
[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.
-
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.)
-
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?
-
Ü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
-
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?
-
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)".
-
@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.
-
@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.
-
@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.
-
@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....
-
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?)
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.
-
Danke Thorsten
selbes Szenario: beim Bewegen der Maus stürzt es ab. MIDI IN, OUT ist ok. (EMUTOS 1.3 in HATARI 2.50)
-
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
-
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.
-
Danke, das hilft schon mal weiter.
Für die Abstürze habe ich leider noch keine Erklärung.
-
Ich habe das gepatchte MROS 3.45 sowohl unter TOS 1.04 (1040ST) als auch unter TOS 2.06 (1040STE) mit der dongle-befreiten Tango Version 1.03 ausprobiert. Tango funktionierte jeweils einwandfrei, soweit ich es bisher beurteilen kann. Keinerlei Abstürze oder Hänger.