ROM-Patch, der nächste - Reaktionen

Nein, es gibt heute keine neuen Patches, obwohl ich inzwischen schon wieder einige Änderungen an meinem TOS vorgenommen habe. (Boot-Sektor-Überwachung, schnelleres Schreiben auf Diskette, zusätzliche Formatiermodi, Entpacker in ‘PEXEC’).

Diese Änderungen können aber nicht als einfacher Patch durchgeführt werden, weil im ROM nicht genug Platz ist. Ich habe das ROM daher komplett neu assembliert.

Ich möchte heute öffentlich auf die Zuschriften eingehen, die zu dem Artikel ‘ROMPATCH, der nächste’ (Ausgabe 10/ 90) bei mir eingegangen sind.

Zunächst noch eine allgemeine Bemerkung zu Leserbriefen: Da die Briefe, die sich auf einen bestimmten Artikel beziehen, an den jeweiligen Autor weitergeleitet werden, ist es ganz günstig, wenn bei der Anschrift gleich ‘z.Hd. Autorenname’ angegeben werden. Die Post kann so schneller weitergeleitet werden. Sie muß dann nicht mehrmals gelesen werden. Bei Anfragen sollte Ihre Adresse nicht nur auf dem Umschlag stehen, sondern auch auf dem Brief. Bei den meisten Briefen ist dies bereits der Fall, aber es gibt immer wieder ein paar Ausnahmen.

Die meisten Zuschriften bezogen sich auf das PD-Programm von M. Rogge. Die Leser wollten entweder die gepatchte Version vor dem Brennen noch einmal testen oder eigene Änderungen vornehmen. Die aktuelle Adresse von M. Rogge habe ich nicht. Herr Rogge ist nach seinem Studium nach Großbritannien gegangen, um Auslandserfahrungen zu sammeln.

Mir ist nicht bekannt, ob das Programm von einem PD-Vertrieb angeboten wird.

So lange es nicht zu viel wird, bin ich bereit, für eine angemessene Aufwandsentschädigung (10DM inklusive Disk und Porto bei Vorkasse) eine Kopie des Programms zu verschicken. Dazu gibt es noch ein ähnliches Programm, daß ich geschrieben habe. Mein Programm reloziert das TOS direkt beim Laden. Außerdem ist es auch für die Länderversionen für F, NL und GB verwendbar.

Die Unterscheidung erfolgt nach (_sys-base)+28. Hier steht die Kennung für das Land. Mir sind folgende Kennungen bekannt:

3 Deutschland
5 Frankreich
7 Großbritannien
17 Niederlande

Wenn sich Ihr Programm gleich in der richtigen Sprache melden soll, könnt Sie hier das Land überprüfen:

land%=PEEK(LPEEK(&H4F2)+28)

Mit dem bisher Gesagten habe ich bereits angedeutet, daß es verschiedene Versionen vom TOS 1.4 gibt. Der Unterschied zwischen den verschiedenen Versionen beruht auf verschiedenen Routinen für die nationalen Sonderzeichen derTastatur und natürlich in den übersetzten Texten. Während die Texte alle am Ende des Betriebssystems stehen, befindet sich die Tastaturroutine zwischen $FC3E00 und $FC4000. Alle Programmteile hinter der Tastaturroutine verschieben sich daher um einen bestimmten Bereich. Die veröffentlichten Änderungen sind aus diesem Grund nur für das deutsche TOS verwendbar. Nur die Patches 5,6 und 7 können unverändert eingefügt werden. Bei den anderen Patches müssen die absoluten Adressen korrigiert werden. Da die französischen und die niederländischen Versionen länger sind als die deutsche, reicht der Platz am Ende nicht für die zusätzlichen Funktionen (Patch 4 u. 10). Man müßte das TOS komplett neu assemblieren, um Platz zu bekommen.

Ein Leser wollte wissen, ob ich Ihm die Patches nicht in sein TOS 1.2 einbauen könnte. Im Prinzip wäre dies wahrscheinlich möglich, aber Aufwand dafür ist doch recht hoch. Man müßte das TOS erst analysieren, ob die entsprechenden Routinen sich geändert haben, und wo sie überhaupt stehen. Ich habe auch kein Programm, mit dem ich aus dem (gepatchten) TOS 1.2 eine RAM-Version machen kann, damit man das Ergebnis überprüfen kann. Man sollte daher einen Zeitaufwand von einigen Tagen kalkulieren. Wenn man einen halbwegs akzeptablen Stundenlohn ansetzt, ist es erheblich günstiger, sich das neue TOS zu kaufen und - nach dem Patchen neu zu brennen. Wer auf das alte TOS nicht ganz verzichten will (ein paar schlecht programmierte Programme laufen nicht mit dem neuen TOS), kann sich als Alternative ein umschaltbares TOS brennen. Dabei werden zwei TOS-Versionen in sechs 64kByte-EPROMs gebrannt und die höchste Adreßleitung (Pin 1) jeweils übet einen Schalter auf +5V oder auf Masse legt.

Zum Schluß noch ein Punkt, der nicht nur auf meinen Beitrag zutreffen dürfte:

Es gibt immer wieder Zuschriften, bei denen jemand ein Listing abgeschrieben hat. Das Programm funktioniert aber nicht, weil sich beim Abschreiben Fehler eingeschlichen haben. Wir erhalten dann das Listing mit der Bitte, es zu überprüfen, weil der Leser die Fehler nicht finden kann.

Wie bereits in dem Kasten ‘Ein Wort in eigener Sache' (Seite Leserbriefe) steht, können wir dies nicht machen, weil der Zeitaufwand dafür zu groß wird. Da die Listings direkt aus einer Kopie des Quelltextes erzeugt werden, ist es auch sehr unwahrscheinlich, daß in der Zeitung ein fehlerhaftes Listing abgedruckt wird (zumindest wenn der Autor das Programm nach einem eventuellen Zeilenumbruch noch einmal getestet hat).

Man kann also schon davon ausgehen, daß der Fehler beim Abschreiben gemacht wurde. Für alle, die sich wenig mit Programmieren und Fehlersuche befassen, möchte ich ein paar Tips geben.

Bei der Fehlersuche kann man drei Wege gehen:

  1. Man vergleicht das Listing mit der Vorlage. Diese Methode dürfte von den meisten Leuten verwendet werden. Bei dieser Methode besteht die Gefahr, daß man die Fehler übersieht, weil man nicht konzentriert genug bei der Sache ist. Dieses Vorgehen empfiehlt sich vor allem, wenn das Programm mit einer Fehlermeldung abgebrochen wird. Mit etwas Glück ist die Zeile fehlerhaft, in der der Programmabbruch erfolgte. Andernfalls sollte man sich ansehen, ob alle Variablen, die in dieser Zeile verwendet werden, überall richtig geschrieben sind.

  2. Man schreibt das Programm noch einmal ab (ja ich weiß, daß ist mühsam, es kann aber die schnellste Methode sein, wenn man den Text nicht grade nach dem Adlersystem eingibt). Besser ist es meist, wenn die zweite Abschrift von einem anderen gemacht wird (nicht, weil dann der andere die Arbeit hat, sondern weil die Wahrscheinlichkeit kleiner ist, das der andere die gleichen Fehler macht). Nun vergleicht man die beiden Versionen z.B mit dem folgendem kurzen Programm. Man sollte sich nicht daran stören, daß man dabei einige Unterschiede findet, die man nicht unbedingt als Fehler interpretieren muß (z.B. eine andere Schreibweise in Infotexten). Natürlich kann man sich auch auf einen Teil des Programms beschränken, wenn man weiß, daß der Fehler in diesem Bereich liegen muß. Diese Methode wird sehr häufig in der Wirtschaft angewandt, wenn man sicher sein will, daß die eingegebenen Daten fehlerfrei sind.

    OPEN "i",#1,"datei1" OPEN "i",#2,"datei2" PRINT "Fehlerhafte Zeilen:" REPEAT LINE INPUT #1,a$ LINE INPUT #2,b$ INC i% IF a$<>b$ PRINT i%, ENDIF UNTIL EOF(#1) CLOSE #1 CLOSE #2

  3. Man kann das Programm etwas ändern, damit man den fehlerhaften Bereich stark einschränken kann. Die eigentliche Fehlersuche wird dann meist mit Methode 1 durchgeführt. Die erforderlichen Änderungen hängen dabei natürlich von dem jeweiligen Fehler ab. Meist wird man irgendwo eine zusätzliche Ausgabe für eine Variable einfügen.

Nehmen wir ein konkretes Beispiel: Bei meinem Programm hatte jemand die Fehlermeldung ‘DATA nicht numerisch’. Dieser Fehler kann nur bei einem ‘ READ ’ -Befehl auftreten. Da das Programm keine besonderen Bildschirmaufbau verwendet, kann man einfach nach jedem READ’-Befehl die eingelesene Variable mit ‘PRINT’ ausgeben. Beim Auftreten des Fehlers kann man dann die entsprechende Stelle im Listing über das letzte korrekt gelesene ‘DATA’-Statement suchen. In diesem Fall war ein paar Mal das Komma zwischen den ‘DATA’-Statements durch einen Punkt ersetzt worden. Dies ist (bei GFA-BASIC) bei hexadezimalen Zahlen nicht erlaubt.

Ich hoffe, daß ich einigen von Ihnen mit diesen Tips etwas weiterhelfen konnte. Für alle, die die Listings nicht abtippen wollen, gibt es ja noch den Diskettenservice der ST-Computer.


Georg Scheibler
Aus: ST-Computer 07 / 1991, Seite 178

Links

Copyright-Bestimmungen: siehe Über diese Seite