	Geschichten rund um den SysMon
	------------------------------

Interlink
---------
Als ich das Programm Interlink getestet habe, mute ich feststellen,
da SysMon im RUN-Modus funktioniert. Als ich es dann nocheinmal
schrittweise versucht habe, gab's fette Bomben. Ein Test mit
TempleMon ergab, da die Register von Interlink zerstrrt worden sind.
Komischerweise traten diese Vernderungen zu unterschiedlichen 
Zeitpunkten ein, so da mir nichts brigblieb als Interlink genauer
zu untersuchen.
Der Fehler war schnell gefunden. Interlink installiert eine VBI-
Routine, vorher sichert es die Register an eine feste Adresse, die
auch zur Registersicherung whrend des VBIs benutzt wird. Wird der
Supexec zur Installation dieser Routine nicht getraced, so kehrt
die Funktion zurck, bevor die Register durch den nchsten VBI ber-
schrieben werden. Beim Steppen mit SysMon wird die Supexec-Funktion
allerdings aufgehalten und es kommt erst ein VBI und dann kehrt der
Supexec zurck. Somit sind die Register durch den VBI berschrieben 
worden...
Das diese Art der Registersicherung -- an eine feste Adresse, die auch 
durch Interrupts benutzt wird -- nicht gerade der Weisheit letzter
Schu ist , brauche ich wohl niemandem zu sagen...

IconDesk
--------
Mit dem IconDesk-Programm von Stefan Becker, kann man fr jede Datei
ein eigenes Icon installieren. Es fngt den 'vro_cpyfm' Aufruf des
Desktop ab und ersetzt die Icon-Daten. Um festzustellen, da der
'vro_cpyfm' Aufruf vom Desktop kam, wird die Rcksprungadresse mit
dem Beginn und Ende des Betriebssystems verglichen. Damit IconDesk
(und andere Programme) auch mit SysMon getraced werden knnen, 
verndert SysMon die Rcksprungadresse so, da sie immernoch in
den aufrufenden Proze zeigt, aber trotzdem zuerst zu SysMon
zurckkehrt.

Die Entdeckung des VDI-Wk-Fehlers
---------------------------------
Als ich das PD-Notepad Accessory bekommen habe, habe ich einwenig
damit rumgespielt. Das Notepad benutzt zur Ausgabe den 8x8 Font,
irgendwann war dann pltzlich auch der Text in meinem Editor in dem
8x8 Font, und zwar berall dort, wo ein Redraw auftrat. Mit der Memory-
Liste in SysMon stellte ich fest, da 3 mal ein VDI-Block mit der
Nummer 3 vergeben wurde, sowohl an den Editor, wie auch an das Notepad
und noch ein weiteres ACC. Den Fehler habe ich dann durch bis zum
v_opnvwk Aufruf zurckverfolgen knnen. Dort ist die Routine zum
Einhngen von VDI-Workstations in die bestehende Liste fehlerhaft,
sobald einmal eine Lcke entsteht, wird immer derselbe Handle
zurckgeliefert. Der Fehler befindet sich in allen TOS-Versionen
bis auf das BlitterTOS. Ich habe daraufhin das VDI-FIX Programm
geschrieben, da die interne VDI-Liste korrigiert, falls ein solcher
Fehler eingetreten ist. Dieser Fehler wurde zeitgleich von den
beiden GEMINI-Autoren entdeckt.

PRGLOAD
-------
Wenn das Programm PrgLoad von  Thomas Tempelmann geladen ist, 
werden alle folgenden Programme erst mit Pexec(Load) geladen und
danach mit Pexec(Start) gestartet. Da der Speicher somit dem
PrgLoad-Programm gehrt, wird er beim Pterm nicht wieder
freigegeben. Das 'resident halten' von Programmen ist ja auch das
Ziel von PrgLoad. Soll das Programm nicht resident gehalten werden,
so gibt PrgLoad den Speicher mit Mfree wieder frei. 
SysMon erscheint fr dem TOS als ganz normales Programm, nach der 
Installation endet es ganz normal mit Pterm, da es seinen Speicher
selber versteckt. PrgLoad versucht nun den SysMon Speicher mit Mfree
freizugeben, was ihm bei den ersten BETA-Versionen auch gelungen ist.
Nun fngt SysMon die Aufrufe, die seinen eigenen Speicher betreffen
ab.

Der Mshrink(0L) Fehler bei TOS 1.4
----------------------------------
Unter TOS 1.4 gibt es einen Fehler bei Mshrink. Wenn man versucht
einen Speicherblock auf die Lnge NULL zu verkleinern, so erzeugt
das TOS eine Endloschleife in der MFL. Dieser Fehler tritt z.B.
auf, wenn man TEMPUS startet und keine Texte geladen hat. Startet
man von TEMPUS ein weiteres Programm, so ruft TEMPUS vorher einam
Mshrink(0) auf. Sobald das Programm zurckkehrt, hngt der Rechner.
Verlt man TEMPUS, so wird die Speicherliste wieder in Ordnung
gebracht, wie das TOS dies hinbekommt, wei ich ehrlich gesagt nicht.
Die Memory-Liste von SysMon erkennt Schleifen in der Speicher-
verwaltung und bricht die Ausgabe ab.

TURBO-ST 1.6
------------
Das TURBO-ST.ACC Version 1.6 installirt sich in mehreren Traps,
beim BIOS-Trap macht es etwas sehr merkwrdiges. Es kopiert 16
Worte vor seinen Traphandler, die es dem vorherigen Einsprung
entnimmt. Sollte das vorherige Programm eine XBRA-Kennung
besessen habe, so hat jetzt TURBO-ST dessen Kennung und Sprungadresse
mitkopiert. TURBO-ST trgt in diesen falschen XBRA noch die eigene
Einsprungadresse ein und schon ist eine prima XBRA-endlos Kette
geschaffen worden. Der rechner funktioniert, weil TURBO-ST nicht
ber diese Sprungadresse weiterspringt. Ein Programm, da XBRA-Ketten
anzeigt, wird in eine Endlosschleife getrieben. Wenn SysMon einen
XBRA-Eintrag findet, der auf sich selbst verweist, so wird die
XBRA-Kennung mit ?BRA berschrieben. Es kann sich bei solch Eintrgen
eh nur um einen Fehler handeln.

Der Cookie-Fehler
-----------------
Um eine Cookie Liste einzubauen, habe ich die Installationsroutine
des STE-TOS disassembliert. Mich hatte interessiert, wie die
Cookie's eingebunden werden und auf welche Art und Weise der
Prozessor (6800-68030) und die Videomodi abgefragt werden. Ganz 
nebenbei habe ich entdeckt, da im STE der _MCH Cookie mit dem
Wert $00010000 belegt wird, was laut ATARI-Dokumentation fr einen
MEGA ST steht. Sofort habe ich im TT-TOS nachgesehen, was dort bei
_MCH eingetragen wird: $0002000. ATARI hat also entweder einen
Fehler in der Doku oder die Programmierer haben sich nicht an die
eigene Doku gehalten. Diesen Fehler habe ich ber Julian Reschke
an ATARI weitergeleitet, aber noch keine Antwort erhalten.

MicroRTX
--------
Das Mirco-RTX ist ein Multi-Tasking Kernel fr den ATARI. Das GEMDOS
und BIOS des ST sind aber nicht multi-tasking-fhig, deshalb gibt es
fr die Systemresourcen GEMDOS/BIOS Semaphoren-Funktionen.
Sollte das GEMDOS/BIOS schon durch einen anderen Prozess belegt sein,
so wartet der Prozess, bis GEMDOS/BIOS wieder frei ist. Diese
Funktionen werden durch die RTX-Bibliothek automatisch dazugebunden.
(Neue Bindings fr _gemdos,_bios und _xbios, die vor dem eigentlichen
Systemaufruf die Semaphore belegen und nach der Rckkehr der Funktion
wieder freigeben...) 
Damit nun ltere Programme (Welche logischerweise nicht die Semaphoren
benutzen) auch in das MultiTasking eingebunden werden knnen (Ohne das
sie das GEMDOS/BIOS zum Absturz bringen), biegt der Mirco-RTX Kernel
(RTX_BOOT) den GEMDOS/BIOS-Trap auf eine eigene Routine um und 
vermerkt sich den vorherigen Vektor. 
Wird nun ein GEMDOS/BIOS-Aufruf ohne vorherigen Aufruf der Semaphore-
Funktion gettigt, so bernimmt dieser GEMDOS/BIOS-Aufruf die 
Semaphoren-Funktion. Ist die Systemresource frei, so wird direkt ber
den alten Vektor gesprungen. Ist die Resource belegt, so schlft
dieser Prozess, bis ein anderer Prozess die Resource wieder freigibt.
Nun wird der Vektor auf die alte Adresse zurckgesetzt und der Aufruf 
nochmal durch das RTX_BOOT abgesetzt. Hinter dem Aufruf wird der
GEMDOS-Trap wieder auf die eigene Routine umgeleitet. 
Das mehrfache Hin- und Herbiegen der Traps ist dem SysMon gar nicht
bekommen, nach einiger Zeit hat er sich immer aufgehngt, da ein
berlauf der Bypass-Tabellen stattfand. Bei den neueren Versionen
werden zwei Bypasse fr jeden Trap angelegt und diese wenn ntig
umgeschaltet...
Bei ganz alten SysMon-Versionen (<1.0.1) wurden noch die Funktionen 
'Bconin'/'Bconstat' benutzt, um Zeichen einzulesen, dadurch fand
mitten in SysMon ein Task-Wechsel statt, wodurch dann pltzlich 
mehrere SysMon-Prozesse liefen, da ja das 'Bconin'/'Bconstat' auch
wieder durch SysMon abgefangen wurden... 

Der MD Block bei TOS 1.2
------------------------
Die Speicherverwaltung unter BlitterTOS scheint auch nicht ganz
in Ordnung zu ein, da des fteren ein MD-Block mit der Lnge
NULL angelegt wird.

MATRIX-LineA-Zeiger
-------------------
Beim MATRIX-Grobildschirm funktioniert die Funktion A_INIT nur
teilweise. Die Register A0 (Zeiger auf LineA-Variablen) und A1
(Zeiger auf LineA-Funktionstabelle) sind korrekt, nur das Register
A2 (Zeiger auf Systemzeichensatz-Liste) ist ungltig und zeigt ins
Nirvana.

Quazar MIDI-Net
---------------
Das QNET.ACC simuliert ein virtuelles Laufwerk ber MIDI und exportiert
das Laufwerk D. Dazu hngt es in einigen Traps, am wichtigstem 
scheint QNET.ACC der GEMDOS-Trap zu sein, da es sich bei jedem
Gemdos-Aufruf wieder davorhngt. Es vermerkt dabei nur beim 1. Mal
den vorherigen Zeiger, so da alle anderen Programme, die sich nach
QNET in den GEMDOS-Trap einklinken wollen, durch QNET ausgehngt und
niemals angesprungen werden. Bei einigen Aufrufen wird der Trap 
kurzzeitig auf die vermerkte Rcksprungadresse umgesetzt, danach aber
wieder die neue Adresse gesetzt.
SysMon mu nun -- wie beim RTX -- zwei Bypasse zur Verfgung stellen,
zwischen denen hin und her gewechselt wird. Die vorherigen Versionen
haben fr jedes Umbiegen einen neuen Bypass angelegt, was zu einem
berlauf der Bypass-Tabelle fhrte.

Mit freundlichen Gren
   Karsten