PD-Patch

Achtung (für MagicPC Nutzer): Patch 19) funktioniert erst teilweise ab MagiC PC 6.10 vom 7.10.99, und richtig ab der folgenden Version (irgendwann in 2000+x).

Dieses Patchprogramm dient dazu, den Pure Debugger an moderne Zeiten anzupassen. Das Problem ist, daß (AFAIK) ASH aus lizenzrechtlichen Gründen nicht in der Lage ist, ein Update zu erstellen. Somit war Eigeninitiative gefragt, da mir PD ansonsten gefällt.

Mir bekannte Probleme, Voraussetzung für ihr Auftreten und ihr augenblicklicher Status (G= gelöst, U= Ungelöst, V= Ursache verstanden, aber keine befriedigende Lösung gefunden):

Nr.	GUV	Auftreten bei	Beschreibung
1	V	Multitasking	Beim Verlassen von PD ist manchmal die Maus im 'linke Maustaste gedrückt' Status
2	G	MagiC	PD kann von PC nicht im Singletask gestartet werden
3	G	MagiC...	PD schließt bei 'Program reset' noch offene Dateien nicht -> bei einem Neustart führt Fopen zu einem Fehler
4	G	immer	PD benutzt zum Verbiegen nicht den XBRA Standard
5	G	immer	PD verbiegt Vektoren, prüft aber nicht, ob das Programm, das über sie springt, auch das eigene ist -> z.B. wird ein parallel zu PD laufendes Programm beendet (Pterm), so geht PD davon aus, daß dies das zu debuggende Programm war.
6	V	Grafikkarte	Bildschirmumschalten per Setscreen funktioniert nicht.
7	G	immer	Beim ersten RUN gibt PD ein ESC H aus, ist z.B. ein Console Fenster (Gemini,...) offen, so springt der Cursor dort nach oben links.
8	G	Multitasking	Teilweise ist der falsche Menütitel sichtbar
9	G	MiNT	hier soll (ich habe keines installiert) PD gar nicht laufen.
10	G	2 Monitore	keine Fehlerbehebung sondern eine Erweiterung: wenn 2 Monitore angeschlossen sind, können sie jetzt benutzt werden.
11	G	?	Manchmal verschwindet der Mauszeiger.
12	G	Multitasking	PD versucht teilweise Speicher am oberen Rand zu reservieren. Dies schlägt unter Multitasking teilweise fehl, unter MagiC immer. Da PD dann beliebigen Speicher reserviert, fällt es meist nicht auf.
13	G	?	Bei mir stürzte die 1 Monitorversion, auch das Original PD vor einiger Zeit ab, und zwar beim Setzen des Monitors mit Setscreen. Auch ein Umsetzen der Umschaltmethode in den Optionen half nicht.
14	G	>Gemdos 0.19	PD protokolliert alle Malloc mit, um bei 'Program Reset' den Speicher wieder freigeben zu können. Dies wird bei Mxalloc allerdings unterlassen.
15	G	immer	'View File' öffnet ein File, liest es, aber schließt es nicht mehr. Folge: Handles gehen verloren und bei OS, die prüfen ob ein File bereits geöffnet ist, kann es nicht mehr zurück geschrieben werden.
16	G	PCI-MAC	PD testet das Vorhandensein einer MegaST(E) FPU. Dieser Test führt bei PCI-MACs zum Absturz.
17	?	CPU>68030	Das Löschen des Cache wird immer nach 68020/30 Methode gemacht.
18	G	ab TT	Im Menüpunkt 'Programm Info' werden Startadressen und Längen ausgegeben, als 6 stellige HEX-Zahlen, bei TT und anderen Rechnern mit 32 Bit Adressbus reicht das aber nicht.
19	G	ab MagicPC6.1	Ist der Compilermodus von MPC>=6.1 eingeschaltet gibt es Probleme mit der Tastatureingabe ( und evtl. andere?), deshalb wird der Compiler abgeschaltet.
20	G	MiNT/N.AES	Tastatureingabe funktioniert nicht. Kann deshalb auf Gemdosfunktionen umgestellt werden.
21	V	immer	PD benutzt für die Eingabe eines 'Watch' eine Eingabebox, die 63 Zeichen annimmt, verarbeitet aber nur 49.
22	G	Laufw.>P	PD prüft ob ein Pfad gültig ist -> es erlaubt keine Laufwerke >P

 

Um neue Routinen einzubinden, müssen natürlich einige Adressen im Original-PD bekannt sein. Diese Adressen stehen in der Datei PD_ADDR.DAT. Beim ersten RUN versucht PATCH, diese Adressen zu ermitteln und speichert sie dann. Dabei gibt es mehrere Fehlerquellen:
 

• Die gesuchten Routinen haben sich geändert (andere als meine Version) -> Adresse wird nicht oder falsch ermittelt

• Irgendwo anders hat sich etwas geändert, so daß die gesuchte Routine scheinbar zweimal gefunden wird.

Im Falle, daß sie keinmal oder mehrmals gefunden wird, wird eine Fehlermeldung ausgegeben. Da nicht für jeden Patch alle Adressen benötigt werden, kann man trotzdem versuchen, den Patch auszuführen. Der Patch wird abgebrochen, wenn eine nötige Adresse fehlt. Zu Kontrollzwecken wird von der binären Datei PD_ADDR.DAT auch eine Text Version geschrieben: PD_ADDR.TXT

1. Falls kein fertiges PATCH.PRG beiliegt, PC starten, PATCH.PRJ als Projektfile auswählen und ausführen. Ebenso Start_PD.PRJ ausführen. PD_LIB.PRJ braucht nicht separat ausgeführt zu werden, es wird intern von PATCH.PRJ aufgerufen.
2. PATCH.PRG ausführen und das Formular ausfüllen.

3. Falls die neuen PDs aus PC aufgerufen werden sollen, noch PD.PRG aus diesem Ordner in das PC Verzeichnis kopieren, vorher das Original PD ggf. umbenennen.
4. Testen

Compiler: -C, -P
Assembler: -S
Linker -G, -L, -F, Stacksize 100000

Compiler: -K

1) linke Maustaste gedrückt

Da Menüs, Fenster u.ä. nicht über AES verwaltet werden, sondern per VDI direkt auf den Monitor gezeichnet werden, sind sie sozusagen für Mausklicks durchsichtig. Nur weil PD im Supervisor läuft kommt es nicht dauernd zu Problemen, aber eben am Programmende. Ich habe versucht mit wind_update(BEG_MOUSCTRL) das Problem zu lösen, hatte dabei aber die seltsamsten Effekte.
 

2) Starten im Singletaskmodus (MagiC...)

Um PD auch aus PC heraus im Singletaskmodus starten zu können, habe ich einen Starter geschrieben (START_PD), der per AV-Message der Shell mitteilt, daß sie PD starten soll. Wird das AV-Protokoll von der Shell unterstützt, sollte sie nachsehen, ob das Programm als Singletask angemeldet ist, und ggf. so starten. Getestet habe ich es mit Ease 5.01 und Jinnee unter MagiC 5 und 6. Hier klappt es, bis auf eine Kleinigkeit. Beim Starten als Singletask werden keine Parameter übergeben (Ease). Dies teile ich ASH mit und hoffe, das es bald behoben ist. Drückt man während des Aufrufs von START_PD (PD.PRG) aus PC heraus (Project/Debug) die Alternate Taste, so stellt der Starter einige Fragen: Es kann zwischen der Ein- und Zweimonitorversion gewählt werden sowie zwischen Singletask und Multitask. Außerdem kann man diese Einstellungen abspeichern. Falls PD also im Singletask gestartet werden soll wird der AV-Server aufgefordert, es zu starten. Dies tut er aber nur dann im Singletaskmodus, wenn PD_1 bzw. PD_2 so angemeldet ist, sonst wird es normal im Multitasking gestartet.

3) Offene Dateien

Falls beim Programmende bzw. -abbruch (des zu debuggenden Programms) noch Dateien offen sind, und das Programm neu gestartet wird, so kann es z.B. unter MagiC zu Problemen kommen, da man eine offene Datei neu öffnen will. Als Lösung werden die Befehle Fcreate, Fopen und Fdelete protokolliert, und bei Program Reset die noch offenen geschlossen. Dabei werden nur Handles zwischen 6 und 63 berücksichtigt. Falls dies nicht reicht, muß im PDX p_flags entsprechend vergrößert werden, und alle Routinen, die es benutzen, angepaßt werden. Im schlimmsten Fall tritt aber der gleiche Fehler wie beim Original PD auf.
 

4) XBRA

Bei allen Vektoren, die per Setexc verbogen werden, habe ich eine XBRA Struktur eingefügt. Die Kennung ist 'PDeb' für die Einmonitorversion und 'PDEB' für die Zweimonitorversion. Die XBRA Implementation ist jetzt komplett, deinstalliert wird also auch nach XBRA Standard. Da man aber bei einem Programm in der Testphase, nein nicht PD sondern das, was man debuggt, nie von Fehlerfreiheit ausgehen soll, wird im Notfall noch wie vorher deinstalliert. D.h. wenn in der XBRA Kette die eigene Routine nicht gefunden wird, so wird der Urzustand wieder hergestellt, ungeachtet anderer Programme, die sich in der Zwischenzeit eingeklinkt haben, sollte aber, wenn sich alle an XBRA halten, nicht vorkommen. Außerdem wird bei Program Reset kontrolliert, ob ein Zeiger in den freizugebenden Speicher weist, und ggf. ausgeklinkt. Grund für die 2 unterschiedlichen Kennungen ist, daß ich so verhindern will, daß es Probleme gibt, wenn man (oder nur ich ;-) ) PD_1 mit PD_2 debuggt.
 

5) Aufrufer Testen

PD überprüft nicht, welches Programm über verbogene Vektoren springt. Im Singletask ist dies OK, sonst nicht. Der 'schönste' Fehler tritt auf, wenn man parallel ein anderes Programm beendet: PD gibt die Meldung aus 'Programm beendet' und ist nicht mehr im RUN-Modus. Das zu debuggende Programm läuft aber weiter, selbst dann noch, wenn PD beendet wird. Was das für Folgen hat (wem gehört der Speicher...), weiß ich nicht; ich habe immer vorsichtshalber Reset gedrückt. Jetzt merkt sich PD am Anfang die Adresse seiner Basepage, und bei jedem Sprung über eine der mit XBRA verbogenen Vektoren wird geprüft, ob es PD war oder nicht. Falls nicht, wird über den Originalvektor gesprungen. Der steht ja im XBRA. Dieser Patch ist, wie gesagt, mit 4) verknüpft, außerdem ist er für 3) nötig, da sonst dort auch Fopen... von anderen Programmen protokolliert würden. Zu jeder Regel eine Ausnahme. Die Hardcopy Routine (<ALT><HELP>) wird von PD benutzt, um während des Programmlaufs unterbrechen zu können. Würde hier auch getestet, müßte man so lange <ALT><HELP> drücken, bis zufällig PD dran ist. Diese Routine setzt allerdings nur ein Flag, wirklich unterbrochen wird erst, wenn PD das nächste Mal bei einem Vertical Blank an der Reihe ist. Ist das zu debuggende Programm gerade im Wartezustand evnt_multi o.ä., kommt es nie dahin. Meist hilft es, eine Taste zu drücken oder irgendwohin zu klicken. Würde der Basepage Test auch bei der Vertical Blank Routine entfernt, würde PD plötzlich unter einer fremden Basepage laufen. Das ist ganz böse ;-)
 

6) Setscreen

PD reserviert ST-RAM für den 2. und ggf. 3. Bildschirmspeicher. Dann versucht PD, ob Setscreen funktioniert. Dies würde bei der NOVA-Grafikkarte funktionieren, wenn die Adresse im NOVA-RAM liegen würde. Allerdings haben meine Versuche fehlgeschlagen. Das Problem scheint darin zu liegen, daß Mxalloc (ein eigenes) negative Adressen zurück geben muß (NOVA-RAM beginnt bei 0xFEC00000) Als Halblösung wird zumindest bei erkannter Grafikkarte kein ST-RAM sondern TT-RAM verwendet. Wer eine andere Grafikkarte hat, muß noch eine Erkennung in v_opn_init1 einfügen, dort steht derzeit:

if (get_cookie('IMNE',(long *)&icb))

X_pd.p_bs_m=3;

7) ESC H

Beim ersten RUN gibt PD ein ESC H aus. Ist z.B. ein ConsoleFenster (Gemini,...) offen, so springt dort der Cursor nach oben links. Ob dies sinnvoll ist oder nicht, soll jeder selber entscheiden. Ich habe die 3 Möglichkeiten eingebaut:

1. nie ESC H ausgeben
2. nur beim ersten RUN (wie im original PD)
3. bei jedem RUN

8) Menütitel

Bei Multitaskingsystemen ist teilweise ein falscher Menütitel zu sehen, dies ist zwar nur unschön, da die richtigen Menüs aufklappen, aber trotzdem nicht OK. Ich habe es nicht geschafft, alle Fälle zu finden, in denen es auftritt (hängt auch vom eingestellten SWAP-Modus ab). Es wird jetzt die Menüzeile noch einmal kurz nach Programmstart (1. Aufruf von vq_mouse) ausgegeben. Außerdem kann man jederzeit ein Neuzeichnen veranlassen, indem man in die Menüzeile (Y<18) klickt. Am besten natürlich in den rechten Teil, wo kein Menü runterklappt. Auch dies ist nur für die 1-Monitorversion.
 

9) MiNT

PD soll unter MiNT nicht laufen. Ich habe es nie installiert. Inzwischen habe ich aber einen Starter von Thomas Künneth und Chris Felsch erhalten, der es ermöglichen soll PD unter MiNT zu betreiben. Dieser kann aus meinem Starter heraus aufgerufen werden. Es sollte also jetzt funktionieren, natürlich nur wenn man PD über den Starter betreibt (s.a. 2) ) Noch unschön ist, daß jetzt PC meinen Starter, dieses den MINT-Starter und jener endlich PD aufruft. Schöner wäre ein Zusammenfassen der beiden Starter. Da es für die Funktion des MiNT-Starters aber wohl nötig ist, das appl_init an einer bestimmten Stelle aufzurufen, mein Starter aber vorher AES Aufrufe macht, kann dies Probleme geben. Da ich kein MiNT habe, kann ich dies nicht vernünftig testen. Wer immer Lust hat, es zu machen, nur zu.
 

10) Zwei Monitore

Der eigentliche Beginn diese Patches. Es ist mit dieser Version möglich 2 Monitore anzusprechen, ähnlich wie das Programm SYSMON (sehr zu empfehlen). AES-Ausgaben umlenken ist sehr schwierig, vor allem auf eine andere Auflösung. Dies ist aber gar nicht nötig, da PD ausschließlich über VDI ausgibt. Es ist also 'nur' nötig OFF-Screen Bitmaps zu öffnen, und PD deren handle zu geben, statt den per v_opnvwk erhaltenen. Außerdem muß das Zeichnen des Mauscursors selber übernommen werden. Aber das läuft alles. Voraussetzungen:

• VDI, dasOFF-Screen Bitmaps unterstützt, entweder per v_opnvwk2 (NOVA-VDI u.a.?) oder per v_opnbm (NVDI, NOVA u.a. wenn EdDI-Cookie mit Version >=1.1 gesetzt ist.)
• ATARI-kompatibler Monitor und ein 2. über Grafikkarte angeschlossener.

11) Mauszeiger verschwindet.

Da ich diesen Fehler nie beobachtet hatte, während ich noch den Atari TT benutzte, was wohl hauptsächlich daran liegt, daß ich PD dort fast ausschließlich im Zweimonitorbetrieb verwendete, habe ich nur eine symptomatische Lösung eingebaut. Inzwischen, auf einem PC mit MagicPC, hatte ich den Fehler zwar, aber PD mit PD debuggen auf einem Monitor ist Wahnsinn, also bleibt es bei besagter symptomatischen Lösung. Verschwindet der Mauszeiger, so drückt man die rechte Maustaste und er sollte wieder da sein.
 

12) Malloc für 'hohen' Speicher

Bei dem Versuch, die XBRA Nutzung zu verbessern (s. 4)), analysierte ich eine Routine und fand 2 Fehler. PD versucht an einigen Stellen, Speicher an möglichst hoher Stelle zu reservieren. Dabei wird in einem ersten Schritt der gesamte Speicher reserviert (Schleife mit Malloc(-1)) diese schlägt fehl, wenn zwischendurch ein anderes Programm Speicher anfordert. War aber durch eine einfache Änderung der Abbruchkriterien zu lösen. Danach sucht PD den höchsten so reservierten Block, verkleinert ihn so, daß ein Rest in Größe des gewünschten Blocks übrigbleibt. Dies funktioniert unter MagiC nicht, da dort immer 32 Byte mehr angefordert werden. Bsp.: hat man einen Block von 3000 Byte und will 1000 haben, muß man unter TOS den Block auf 2000 Byte schrumpfen (Mshrink), unter MagiC aber auf 1968 Byte und dann jeweils 1000 anfordern. Ich schrumpfe jetzt generell auf 64 Byte weniger als unter TOS nötig, damit verschwende ich zwar unter TOS 64, unter MagiC 32 Byte, aber dafür lohnt es sich nicht mehr Aufwand zu treiben, wahrscheinlich würden dabei mehr als 32 Byte Code entstehen.
 

13) Setscreen für 1-Monitorbetrieb

Dieser Patch ist optional, er sollte nur benutzt werden, wenn PD sonst abstürzt. Ich ersetze das Setscreen einfach durch eine Leerfunktion:

{}

14) Mxalloc

Nachdem ich schon eigene Fopen, Fcreate und Fclose Aufrufe eingefügt hatte, habe ich jetzt beschlossen, den ganzen Gemdos-Dispatcher in den Patch zu übernehmen. Dort ist jetzt auch ein Mxalloc drin, das sich wie bei Malloc im original PD alle Speicherreservierungen merkt, um sie bei Bedarf freigeben zu können.
 

15) View File

View File öffnet ein File, liest es, aber schließt es nicht mehr. Folge: Handles gehen verloren und bei OS, die prüfen, ob ein File bereits geöffnet ist, kann es nicht mehr zurück geschrieben werden. Ich habe ein Fclose eingefügt.
 

16) PCI-MAC

Man kann die MegaST(E) Erkennung im Startupcode abschalten (sinnvoll z.B. bei MACs. Von mir ungetestet, sollte aber OK sein, sonst merkt man es direkt ;-)
 

17) Cache löschen

Das Löschen des Cache wird nicht immer nach 68020/30 Methode gemacht wie im Original PD, sondern ggf. nach 68040 Methode oder gar nicht. Die Methode wird nach dem _CPU Cookie ausgewählt. Dieser Patch ist im ß-Stadium, ich kann ihn nicht testen, ich bitte alle, die entsprechende Hardware haben, es zu prüfen, die Routine clear_cpu_0 in PD_LIB_s.s ggf. zu verbessern. Außerdem möchte ich natürlich Rückmeldungen haben. (Auf welcher Hardware funktioniert es oder auch nicht, welche Änderungen sind nötig,...)
 

18) Programm info

Ich habe das Layout des Formulars so angepaßt, daß 8stellige HEX-Zahlen für die Startadressen und Längen der einzelnen Segmente ausgegeben werden. Ist kein Programm geladen, sollte entsprechend $-------- ausgegeben werden, aus Faulheit habe ich dies nicht angepaßt, so steht da jetzt $------__. Falls da einer ernsthaft Probleme mit hat, soll er es ändern, ist aber nicht ganz trivial ;-)
 

19) MagicPC Compilermodus

MagicPC hat ab Version 6.10 einen Compilermodus der sich nicht mit PD verträgt. So gibt es z.B. Probleme mit der Tastatursteuerung von PD. Ab MagicPC 6.1.3 (lt. 'über MagiC PC': Version 6.10 vom 7.10.99) ist er softwaremäßig abschaltbar, dies geschieht jetzt automatisch im gepatchten PD. Bei der Version 6.10 (vor 10/99) muß der Compilermodus ggf. per Hand abgeschaltet werden. Ich empfehle ein Update. Aber auch mit der o.g. 6.1.3 gibt es noch ein Problem: beim Verlassen des gepatchten PD stellt dieser immer den Compilermodus an, unabhängig davon wie der Status beim Programmstart war. Dies wird in der nächsten Version von MagiC PC behoben sein. Für die Übergangszeit kann man notfalls die 2 Vorkommen der folgenden 2 Zeilen aus pd_lib.c auskomentieren.

if(X_pd.p_mpc_comp)

set_mpc_comp_0(1);

Zusammengefaßt:

20) keine Tastatureingabe unter MiNT + N.AES

je nach Einstellung funktioniert unter obiger Kombination die Tastatureingabe über Gemdos oder Bios nicht richtig. Da die meisten Programme (u.a. die zu debuggenden) wohl Gemdos benutzen aber PD Bios führte dies dazu, daß entweder PD oder das zu debuggende Programm keine Tastatureingabe akzeptiert. Grundsätzlich sehe ich das zwar als einen Fehler in MiNT und/oder N.AES an, aber da es wenig Aufwand war... Die Funktionen Bconstat und Bconin können durch die Funktionen Cconis und Cconin ersetzt werden. Da beide nur mit dem Parameter 2 (Console) aufgerufen werden, ist dies OK. Falls irgendwer so seltsame Sachen wie Eingabeumlenkung zur Steuerung von PD betreiben sollte, kann er mir ja sagen ob es da Probleme gibt.
 

21) Watch

22) Laufwerke >P

23) weitere Änderungen

wie schon in 9) erwähnt, werde ich weiteren Problemen, die mir mitgeteilt werden, nachgehen. Der Patch liegt bewust im Source vor, so daß jeder selber Erweiterungen machen kann, dies ist z.B. sinnvoll, wenn ich nicht erreichbar bin, oder wenn es um Probleme geht, die bei mir nicht nachvollziehbar sind. Über jede Änderung/Erweiterung möchte ich aber unterrichtet werden, ich werde sie dann allgemein zugänglich machen. Hierzu zählt auch vor allem, wenn Einsprungadressen ermittelt werden, die das Patchprogramm nicht gefunden hat. Falls ich auf die Benachrichtigung nicht reagiere, bin ich wahrscheinlich ggf. auch länger offline. Ich bitte, diese Adressen dann in ATARI.Programmieren (Mausgruppe) und falls möglich in der PureC Gruppe der ASH-Box bekannt zu geben.
 

Dieses Programm ist Fairware, es darf frei weitergegeben werden. Gegen freiwillige Spenden habe ich natürlich nichts.
 

Auf keinen Fall darf PD selbst oder eine hiermit gepatchte Version von PD weitergegeben werden, ohne die ausdrückliche Genehmigung von ASH. Der vorliegende Quellcode darf ausschließlich zum patchen von offiziell erworbenen Versionen des PureDebuggers eingesetzt werden. Dies gilt vor allem, da einige der Assemblerroutinen (xbra_exc und xbra_Gd_trm) Abwandlungen der Originalroutinen aus PD sind. Diese sind entsprechend gekennzeichnet.
Ausnahme: im PUREC-Updatebrett der ASH-Mailbox liegt eine, mit diesem Programm (oder einem Vorgänger) gepatchte, Version des PD, diese ist für registrierte User zugänglich. Es ist aber nicht immer die aktuelle Version. Diese Lösung ist aber nicht ideal, da man beim Patch ja mehrere Optionen hat und so nur eine Möglichkeit vorhanden ist.
 

Verwendete Markennamen sind eingetragene Warenzeichen.

Zurück zu meiner Homepage