Hardware > Hardware (Classic 16-/32-Bit)

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

<< < (2/8) > >>

Gaga:
@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:

--- Zitat von: czietz am Do 03.03.2016, 22:32:35 ---@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.

--- Ende Zitat ---

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.

czietz:
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.

dbsys:
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.

KarlMüller:

--- Zitat von: dbsys am Fr 04.03.2016, 21:37:28 ---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.

--- Ende Zitat ---
Schon dem Autor mitgeteilt? Auch wenn die Software schon alt ist wird er sich über ein Rückmeldung wahrscheinlich freuen.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete