★ APPLICATIONS ★ DIVERS ★ UNSER SCHNEIDER CPC 464 HAT UNS WAS ERZÄHLT ★ |
| Ascii-Hexpeeker (Computer Schau) | Applications Divers |
In der letzten Ausgabe der ComputerSchau hatten wir bereits ein kleines Programm abgedruckt, das es den CPC-Benutzern etwas leichter machen sollte, mehr über den Schneider CPC 464 zu erfahren. Wir hatten auch versprochen, mitzuteilen, wo die Variablen liegen usw. Wir machen nun unser Versprechen wahr und gehen außerdem weit darüber hinaus. In der letzten Ausgabe hatten wir auch gezeigt, wie Programmüberspielungen von einem Rechnersystem zu einem anderen erfolgen können. Im angesprochenen Falle war der „Sender“ der CPC 464 und der „Empfänger“ der C 64 von Commodore. Bei den Versuchen, auch den umgekehrten Weg zu beschreiten, haben wir diese Möglichkeit leider noch nicht realisieren können, aber sehr, sehr viel über diesen Computer herausgefunden. Diese Dinge stehen nicht im Handbuch, deshalb sollten „Schneider-User“, die mehr über ihren Computer erfahren wollen, diesen und auch die in den nächsten Ausgaben der ComputerSchau erscheinenden Artikel besonders gut durchlesen. Wie gesagt, wir waren auf der Suche, wie man vom C 64 aus Programme zum CPC schicken kann. Aufgrund unserer Untersuchungen wissen wir, daß es geht. Lediglich die Zeit hat bisher noch nicht ausgereicht, um unser Vorhaben in die Tat umzusetzen. Wir wissen, daß sich eine Menge Schneider-Besitzer freuen würden, auf eine derartig große Programmbibliothek zugreifen zu können. Allerdings gilt es nur für normale Basicprogramme, die keine systemspezifischen Befehle enthalten. Bei unseren Analysen sind wir natürlich hinter viele Schneider-„Geheimnisse“ gekommen und diese wollen wir unseren Lesern nicht vorenthalten. Wie in Heft 3/85 schon versprochen, wollen wir Ihnen auch zeigen, wo die Variablen abgelegt werden. Versprochen ist versprochen! Bevor wir aber auf diese Thematik eingehen, bitten wir die Lese:' um Verständnis, die unseren „Hexmonitor“ abgetippt haben, daß wir schon wieder einen „Peeker“ bringen. Ein Maschinensprache-Monitor war aber zum Zeitpunkt der Analysen noch nicht auf dem deutschen Markt erhältlich. Da wir Ihnen aber zeigen wollen, wie die internen Dinge aus-sehen, hat es sich eben ergeben, daß das in unserer letzten Ausgabe erschienene Programm immer wieder geändert und verbessert wurde. Mit diesem kleinen Programm sind wir sehr „fündig“ geworden. Eine Fülle an Informationen wird Ihnen zeigen, was sich im CPC-Inneren tut. Ohne Fleiß kein Preis Wie Sie vielleicht schon bemerkt haben, befleißigen wir uns, bei den abgedruckten Programmen fast alle „Schnörkel“ wegzulassen. Das heißt, wir sind bemüht - sofern es sich um Programme handelt, die in der Redaktion entstanden - überflüssige „Verzierungen“ und Farbgebungen wegzulassen, damit durch den Interessenten nicht zuviel Tipparbeit erledigt werden muß. Andererseits aber versuchen wir doch, die Programme mit den entsprechenden Bemerkungen zu versehen (sog. REMs - kommt von Remark = Bemerkung), damit unsere Leser diese Programme nicht nur verstehen, sondern — wenn sie wollen - auch leicht weiter ausbauen können. Genauso ist es auch beim Programm „ASCII-Hexpeeker“, mit dem wir alle unsere Untersuchungen gemacht haben. Es ist ein - in bezug zur Leistungsfähigkeit - sehr kurzes Programm. Deswegen sollten Sie, wenn Sie interessierter CPC-Besitzer sind und mehr über Ihren Computer wissen wollen, dieses Programm abtippen, damit Sie unter Zuhilfenahme dieses Werkzeuges alles gleich nachvollziehen können, was wir anschließend aufzeigen. Für all diejenigen Leser, die noch nicht wissen, was ein solches Programm soll, wollen wir dies mit wenigen Worten erklären. Mit einem derartigen Programm ist es möglich, in die Speicherzellen der Computer Einblick zu nehmen. Die Darstellung der Speicherinhalte erfolgt in hexadezimaler Form (diese ist übersichtlicher als Dezimalzahlen). Echte Maschinensprache-Monitore können zwar nicht ersetzt werden, wenn man später tiefer in seine „Maschine“ einsteigen will, aber nachdem erst zum Zeitpunkt der Niederschrift dieses Artikels ein derartiges Programm bei uns vorlag, mußten wir alles mit diesem Basicprogramm herausfinden. Bevor wir nun mit unseren gemeinsamen Analysen beginnen, sollten Sie sich mit dem Programm etwas vertraut machen. Nun dürfen Sie also erst einmal fleißig sein. Zur Programmbedienung
Soweit zu den Programmerklärungen. Von großer Wichtigkeit ist nun noch, daß Sie das Programm genauso im Speicher stehen haben wie wir. Das heißt, daß keine Unterschiede zwischen Ihrem und unserem Programm bestehen. Sind nämlich solche vorhanden, dann ist das Programm zwar durchaus lauffähig, aber die Adreßangaben stimmen nicht überein und Sie müssen dann immer erst suchen. Wichtig sind also auch die Abstände zwischen den Befehlsworten usw. Wenn Sie das Programm ganz genauso abgeschrieben haben, wie unser Abdruck zeigt, so werden Sie im Bereich von &06ea bis &06fb bei den ASCII-Zeichen am rechten Rand dieser ,,Dump“-Zeile den Inhalt der Hilfszeile 570 finden. „Lauter Sternchen!“ Wenn dies nicht der Fall ist und das Programm trotzdem korrekt ausgeführt wird, dann ist es zwar bei den ersten Dingen, die wir nun untersuchen, etwas schwieriger für Sie, aber bestimmt nicht sehr tragisch, versuchen Sie dann vor und hinter den Adreßangaben, die wir machen, die entsprechenden Zeichen zu finden. Eines ist aber für die weiteren Dinge dann erforderlich, nämlich, daß Sie die Zeile 570 so anpassen, daß bei einem „Dump“ (Speicherauszug) ab der Adresse &06fa bei den ASCII-Zeichen nur die beiden ersten Zeichen Sternchen sind! Diese Hilfszeile ist vor allem deshalb, und auch um das Programm-Ende besser finden zu können, enthalten. Nun geht's los! Wie versprochen, nun zu den Variablen. Wie Sie wissen, gibt es beim Schneider-Basic verschiedene Variablentypen. Damit der Computer diese finden und auch unterscheiden kann, werden diese — in von Computertyp zu Computertyp verschiedener Weise - codiert. Der CPC kennt Ganzzahlvariable (= Integerzahlen), Gleitkommavariable (= Realzahlen) und Stringvariable. Falls Ihnen diese Begriffe noch nicht geläufig sind, lesen Sie es bitte im Handbuch nach. Die Integenrariablen Das für diese Gattungsvertreter stehende Identifikationszeichen ist das dem eigentlichen Namen folgende Prozentzeichen. Schreiben Sie deshalb zusätzlich zu dem im Programmspeicher stehenden Programm nun folgende Zeile: 10 b% = 3Nun starten Sie bitte das Programm mit „run“, geben auf die Darstellungsfrage die entsprechende Antwort und können nun ab der Adresse &174 folgende Hexfolge finden: 02 05 00 E2 EF 11 00 Brechen Sie nun bitte das Programm durch Betätigung der ESC-Taste ab und ändern Zeile 10 in a%=1. Nun finden Sie ab der gleichen Adresse folgende Serie: 02 05 00 E1 EF 0F 00 Sie können nun zwei Veränderungen feststellen. Nämlich im vierten und sechsten Byte ab der genannten Adresse. Doch nun zu den Erklärungen: Die erste veränderte Zahl (viertes Byte) zeigt den Variablennamen. Die zweite zeigt eine Veränderung der Zahl als solcher. Das erste Byte der Folge (02) sagt, daß es sich um eine Integerzahl handelt. Das zweite Byte (05) ist die Variablennamenlänge +4, dann folgt eine Trennungsnull. So, und nun ändern wir den Variablennamen in abc%. Daraufhin sollte ab der genannten Adresse folgendes stehen: 02 07 00 61 62 E3 EF 0F 00 Daraus ist nun abzuleiten: Ziehen wir vom zweiten Byte vier ab, erhalten wir die Länge des Variablennamens. Wenn Sie sich nun die Bytes vier, fünf und sechs im Vergleich zu den anderen Folgen ansehen, werden auch Sie schnell erkennen können, daß dies die Codes für a, b und c sind, aber wie Sie bemerken konnten, wird zum letzten Zeichen eines Variablennamens immer &80 (dezimal 128) hinzugezählt. Machen wir noch einen abschließenden Test: Zeile 10: Schneider = 464 nun ergibt sich eine Reihe, wie sie Bild 1 zeigt: Nun nur noch Kurzerklärungen. Länge des Namens &0D (13) - 4 Es wird zwischen Groß- und Kleinschrift unterschieden. 464 ist &01D0 Hinter den Rest sollten Sie nun versuchen selbst zu kommen, spielen und analysieren Sie mit dem Programm. Die Gleitkommavariablen Zeile 10 bitte derart abändern, daß aus der Integervariablen eine Gleitkommazahl wird. (Prozentzeichen löschen!) Nun können Sie erkennen, daß das erste Zeichen sich verändert hat, es steht nun anstelle der bisherigen Hexzahl 02 plötzlich 0D und dies sagt dem Computer, daß er es mit einer Realzahl zu tun hat. Die weiteren Untersuchungen sollten Sie nun auch wieder selbst durchführen, denn wir wollen Ihnen ja noch einiges mitteilen über Ihren Computer und uns steht leider nicht der Platz eines Buches zur Verfügung. Die Stringvariablen Löschen Sie bitte im Programm nun die zusätzlich eingefügte Zeile, sodaß das Programm wieder mit der Zeilen-Nummer 100 beginnt. Starten das Programm wieder und geben Sie als „Neue Adresse“ &1a5 ein. Betrachten Sie dann auch Bild 2 und versuchen die Analyse. Setzen Sie auch wieder eigene Zeilen an den Programmanfang und versuchen Sie hinter die Codierung und die kleinen „Geheimnisse“ Ihres Schneider CPC 464 zu kommen. Viel Spaß bei den Untersuchungen. Nun geht's erst richtig los! Bisher haben wir uns nur damit beschäftigt, wie die Variablen im Programm codiert sind, aber noch nicht damit, wo sie wirklich abgelegt werden, wenn das Programm läuft. Daß dies anders sein muß und daß dafür auch Platz im Rechner freigehalten werden muß, leuchtet hoffentlich jedem ein. Stellen Sie sich mal vor, was passieren würde, wenn beispielsweise in einem Programm die Stringvariable a$ mehrmals manipuliert würde. Wie sähe dann Ihr Listing aus, würden diese Dinge im Programm selbst geschehen? Sie könnten Ihr Listing nicht mehr wiedererkennen. Nachdem wir nun wissen, daß es nicht im Programm selbst geschehen kann, sehen wir uns einmal am Programmende um. Als neue Adresse nun bitte &06f9 eingeben, unseren Ausdruck zeigt Bild 3. Da wir ab &06f9 ausgeben ließen, können wir noch die Reste unserer Hilfszeile erkennen. Danach folgt eine Reihe Nullen, die das Programmende repräsentieren. Bei &0701 beginnt dann die erste für uns interessante Information. Die Folge lautet: C1 02 2D 53 AB Diese Bytes bedeuten für den Schneider CPC 464, daß es sich um die Stringvariable a$ mit einer Länge von &2d (45) Zeichen handelt, deren Inhalt ab der Speicherstelle &ab53 abgelegt ist! Kontrolle ist gut... Sie können sich jederzeit davon überzeugen, sehen Sie sich diesen Bereich an, wie es geht, sollten Sie ja nun wissen. Nur die richtige Adresse eingeben! Wenn Sie dies angesehen haben, dann wissen Sie auch bereits, wo Ihre Speicherobergrenze ist, denn sie liegt unmittelbar am Ende des ersten String, der nach oben abgelegt wurde, also bei Adresse &AB7F. Kontrolle durch print himem = 43903, print hex$(43903) = &AB7F. Also nochmals ganz klar gesagt: Strings werden von &ab7f abwärts, in der Reihenfolge ihres Auftretens, abgelegt. Voraussetzung ist allerdings, daß die Speicherobergrenze nicht verändert wurde. Den Beweis dürfen Sie sich wieder selbst erbringen, indem Sie Bild 4 in die Praxis umsetzen. Kommen wir aber nochmals auf Bild 3 zurück. Einige von Ihnen haben bestimmt nun bemerkt, daß zwischen unserem und Ihrem Ausdruck bzw. der Bildschirmdarstellung etwas unterschiedlich war. Alle diejenigen, die dies feststellten, waren im 80-Zeichenmodus. Nicht daß wir Hellseher wären, nein leider nicht. Aber dies muß so sein, denn wir schrieben doch, daß bei diesem Ausdruck eine Menge informative Daten stehen. Damit wären wir bei der nächsten Variablen, die oberhalb des Programmes lag. Es betrifft die Hexfolge 4D CE 04 00 00 00 00 8x, denn diese hat uns gesagt, ob jemand mit 40 oder 80 Zeichen arbeitet. Nun müssen Sie aber wieder alleine weitermachen, denn man lernt am besten durch seibermachen. Wie die Zahlen selbst codiert sind, ist mehr etwas für Spezialisten, deswegen lassen wir das einfach. Eine Information noch zum Schluß dieses Abschnittes. Wenn Sie sich etwas mit dem Herumsuchen beschäftigt haben, werden Sie feststellen können, daß plötzlich bei den ASCII-Ausgaben viele Zahlen kommen, die ähnlich aussehen, wie die Hexausgaben. Dies müssen sie auch, denn die Strings werden ja von oben nach unten abgelegt und wanderten bereits soweit nach unten. Dies betrifft auch Strings die nicht mehr benötigt werden, die sogenannten „Müllstrings“. Um diese zu beseitigen gibt es die Carbage-Collect-, also die Müllstringbesei-tungsroutinen bei vielen Rechnern. Zusammenfassung des Bisherigen Damit wissen Sie nun schon einiges über den Schneider CPC 464. Wir fassen es grob noch einmal zusammen. Der Basicbeginn liegt bei &170 Die Zahlvariablen und die Adreßan-gaben für die Stringvariablen „wachsen“ von unten nach oben. Die bearbeiteten (bzw. erarbeiteten] Stringvariablen „wachsen“ von HIMEM abwärts. Basicbefehle werden als Token (Einbytewerte) eingespeichert. (Wie ein Programm abgelegt wird, war schon in der letzten Ausgabe der ComputerSchau nachzulesen.) Trennzeichen sind vor allem „Nullen“ und sind sowohl am Zeilen-und Basicende als auch bei verschiedenen anderen Dingen zu finden. Wir haben es zwar bisher noch nicht erklärt, aber wir hoffen, daß die kurze Aussage unsererseits reicht, daß dann wenn Speicherumorganisationen durchgeführt werden, wie beispielsweise durch MEMORY sich natürlich die Adreßwer-te ebenfalls ändern können, aber dies geschieht im Regelfälle relativ. Das heißt, wenn MEMORY (also die oberste, vom normalen Basic nutzbare RAM-Speicherstelle) nach unten gesetzt wird, so ändert sich dadurch auch noch ein anderer wichtiger Bereich, der gar nicht so leicht entdeckt werden konnte. Auch mit diesem Programm nicht, nur längeres Suchen und vor allem Überlegungen, haben uns dann doch auf die richtige Spur geführt. Nachdem wir leider noch keine Floppys für den Schneider hatten, mußten auch wir uns, so wie viele Schneider-Fans mit dem eingebauten Kassettenrecorder begnügen. Der Autor dieses Artikels wollte aber ja einen Weg finden, wie man Programme von anderen Computern (nicht nur vom C 64, wie eingangs erwähnt), direkt überspielen kann. Er erinnerte sich vor allem an die Zeit der guten alten Pet-Computer, wo er zusammen mit einem anderen Computerbegeisterten eine Möglichkeit gesucht und gefunden hatte, Programm-Übertragungen von Rechner zu Rechner auf dem Funkwege durchzuführen. Heute mag manch einer darüber lächeln. Aber wer wußte zu diesem Zeitpunkt schon, wie ein Computer überhaupt funktionierte? Eine Möglichkeit kann mit Sicherheit realisiert werden, nämlich durch den Einsatz von Basicode (lesen Sie auch „Basicode - was ist das?“, ebenfalls in dieser Ausgabe). Hierzu müßte aber erst das Basicodeprotokoll und die Programme geschrieben werden, bestimmt auch eine lohnende Aufgabe für die Basicode-Entwickler. Wir versuchen gedanklich a) den Weg, wie bei den damaligen Funkversuchen zu gehen. Sind uns natürlich darüber klar, daß die Lese-bzw. Schreibroutinen umgeschrieben werden müssen und b) wollen wir einen Weg finden, denselben Dreh auch beim Schneider anzuwenden. So einfach, wie wir den C 64 dazu brachten die Schneiderprogramme zu schlucken, wird es nicht sein, darüber sind wir uns im Klaren. Deswegen wollten wir wissen, wo steckt denn' eigentlich der Kassettenpuffer, das heißt, der Bereich in dem Programme eingelesen werden und wie funktioniert das? Hat der CPC 464 einen „Tastaturpuffer“ ja oder nein? Er hat eine derartige Einrichtung, auch wenn wir im Moment noch nicht ganz verstehen, wie diese arbeitet, hoffen wir in einer unserer nächsten Ausgaben darüber berichten zu können. Es läuft nicht im Editierpuffer ab, wie wir anfangs vermuteten. Wir sind dabei mit dem „ASCII-Hexpeeker“ weitere Analysen durchzuführen. Um Augenblick untersuchen wir, ob wir mit irgendeiner uns bisher bekannten Methode Erfolg haben werden. Vielleicht hilft uns das demnächst auf den Markt kommende Firmware-Handbuch weiter oder einer unserer Leser findet den Dreh. Damit klar verständlich ist, was wir meinen, wollen wir dies kurz erklären. Wenn man in einem kleinen Programm, z.B. „for i = 1 to 10000:next“ einige Tasten betätigt, dann werden diese nach dieser Schleife am Bildschirm sichtbar. Daraus folgt, daß sich irgendwo Die Repeatfunktion ist übrigens während der laufenden Schleife abgeschaltet. Aber machen wir erst wieder weiter. Auf der Suche nach dem Kassettenpuffer wurden wir gleich dreimal beglückt. Doch wieder der Reihe nach, denn nun wird es wieder äußerst interessant. Wir hatten erwartet, einen Kassettenpuffer zu finden, der, nachdem der CPC den Header (Kassettenprogramm-Vorspann mit Informationen über Programmname, -länge, Blocknummer usw.) erkannt und akzeptiert hatte, alles einrichten würde, um dann das gewünschte Programm ab der entsprechenden Speicherstelle zu laden. Wir begannen also (bei geladenem Hexpeeker-Programm) irgendwelche Datenfile-Header einzulesen, um dann aber abzubrechen. Was wir daraufhin fanden, waren mehrere Filenamen. Sowohl der Name unseres 1. Programmes, als auch der Name des abgespeicherten Programmes und .....nach einigen „Spielereien“ auch noch einen dritten Programmnamen. Diese jeweils immer mit vielen weiteren Informationen. Damit Sie alles wieder nachvollziehen können, schalten Sie bitte den Computer aus, wieder ein und laden das hoffentlich schon abgespeicherte Programm „ASCII-Hexpeeker“. Setzen Sie entweder in Zeile 190 die Startadresse auf &b803 oder geben diese nach dem ersten Durchlauf ein. Es spielt keine Rolle, wie Sie es tun. Egal, ob Sie nun im 40- oder 80-Zeichen-Mode arbeiten, Sie können dann den Programmnamen des geladenen Programmes zweimal auf dem Bildschirm sehen. Um diesen Namen herum befinden sich noch weitere Zeichen auf die wir später noch ganz genau einge-hen werden. Doch machen wir erst einmal weiter. Bitte tun Sie so, als würden Sie ein Programm, nämlich das im Computer befindliche, abspeichern, aber unter einem anderen Namen! Dazu den Programmablauf abbrechen und save „Name“ eingeben. Speichern Sie aber nicht wirklich ab, denn für das, was wir nun Vorhaben, brauchen wir keine Bandaufzeichnung. Machen Sie am besten den Kassettenschacht auf und folgen dann den Anweisungen Ihres Computers. Sobald Sie die Ready-Meldung auf Ihrem Schirm sehen, starten Sie das Programm wieder (Adresse &b803). Was Sie dann sehen können ist folgendes:
Nun sollten Sie noch folgenden Versuch unternehmen, denn dann wird Ihnen klar, was dies alles zu bedeuten hat. Nehmen Sie eine Kassette mit einem anderen Programm und geben Sie CAT ein. Nachdem Ihnen am Bildschirm der Name eines Programmes mitgeteilt wurde, drücken Sie bitte am Recorder die Stoptaste und anschließend die ESC-Taste am CPC 464. Das Kassettenheader-Format Wenn Sie sich die Speicherinhalte ab der Adresse &b88c ansehen, so können Sie feststellen, daß die ersten 16 davon den Namen des Programmes tragen, welches als letztes „lief“. Falls der Programmname keine 16 Zeichen lang ist, so sind die bis zur 16. Stelle nicht belegten Speicherplätze mit Nullen aufgefüllt. Anschließend an den Namen (Adresse &b89c) steht die Block-Nummer. (Dies konnten wir dadurch identifizieren, daß wir längere Programme durch die CAT-Funktion „laufen“ ließen.) Um das nächste Byte (Adresse &b89e) mußten wir uns dann schon mehr den Kopf zerbrechen. Es gibt den Dateityp an. Dabei muß dieses Byte bitmäßig betrachtet werden. Ein Byte besteht bekanntlich aus acht Bit. Jedes dieser Bit kann wie ein Schalter betrachtet werden, und dieser Schalter kennt nur die Zustände aus oder ein. Und genauso muß dies nun auch betrachtet werden. Versehen wir der Einfachheit halber, die Bits einfach mit der Zahlenfolge null bis sieben. Falls nun Bit 0 gesetzt ist, dann handelt es sich um ein geschütztes Programm. Bei den Bits 1 bis 3 (können 8 Werte bzw. Zustände repräsentieren, nämlich 0 bis 7) gilt:
Die nun diesem Byte folgenden beiden Bytes geben Auskunft über die Länge der Datei. Diese brauchen nur umgekehrt zusammengefügt zu werden, schon hat man die Länge als Hexadezimalwert. Für unser Beispiel (siehe Bild 5) hieße das &058f. Es braucht nur kurz überprüft werden: Basicbeginn + Programmlänge = Programmende. &170 4- &58f = &6ff. Stimmt! Die nächsten beiden Bytes geben dann die Start-Adresse an, von der sie beim Abspeichern herkamen, im Beispiel den Basicstart &170. Das nächste Byte besagt, ob es der erste Block eines Files ist. Null heißt, es ist nicht der erste Block. Die letzten beiden Bytes, die wir nun anführen, beinhalten die Gesamtlänge des Programmes. Die gleiche Folge gilt dann auch für die Informationen, die in den Speicherstellen ab &b803 enthalten sind, nur daß 4 Bytes vorweg stehen. Und genau diese waren es, vor denen wir unsere Augen verschlossen hatten. Wie oft hatten wir uns gewundert, was diese sollten, wenn es Zeiger waren, wieso zeigten diese ins RAM unterhalb der Stringvariablen? Waren es keine Zeiger, was dann? Waren es Systemvariable? Wir rechneten, wir luden Programme, immer wieder und wieder. Sie ergaben keine Länge, keine Prüfsummen, sie ergaben einfach nichts Sinnvolles! Bis... ja bis wir wußten: Es sind die Zeiger auf den Kassettenpuffer!!! Dies herauszufinden war nicht ganz so einfach, denn immer dann, wenn wir dort, wo diese Zeiger hindeuteten, mit dem Hexpeeker nachsahen, hatten uns die Stringvariablen bereits den größten Teil dieses Bereiches überschrieben. Die Bestätigung, daß es der Kassettenpuffer ist, bekamen wir dann, als wir nach dem Laden des Programms HIMEM veränderten und dadurch den Bereich vor den herablaufenden Strings schützten. Ja... dann... hat uns der Schneider doch einiges erzählt. Heute sind wir schlauer geworden, aber es war ein hartes Stück Arbeit.. Bis wir ihm sein kleines Geheimnis entrissen hatten. Nun wollten wir auch wissen, ob denn die mitgelieferte Demokassette Basic- oder Maschinenprogramme enthält. Wir wissen es und wer uns mitteilen kann, welchen Inhalt die Zeile 100 des ersten Demonstrationsprogrammes „Welcome“ hat, bekommt von uns eine Überraschung zugesandt. Dies gilt allerdings nur für die ersten zehn Einsendungen, denn wir wollen ja nicht arm werden, jetzt nachdem wir gezeigt haben, wie man's macht. Fassen wir wieder einmal kurz zusammen: Die Informationen über Kassettenfiles sind den Speicherstellen &b803 bis &b8ff zu entnehmen. Die Lage des Kassettenpuffers ist variabel und hängt von HIMEM/MEMORY, also der obersten RAM-Speicherstelle, ab. Wird die oberste von Basic aus ansprechbare Speicherstelle, auch RAMTOP genannt, um beispielsweise &100 nach unten gesetzt, so verschiebt sich auch der Kassettenpuffer um den Wert &100 usw. Ein Datenblock ist maximal 2048 Bytes lang. Erst wenn der Block korrekt eingelesen wurde, dann wird er an seine im Header genannte Adresse übertragen. Dies kann leicht überprüft werden, indem man einen Ladevorgang einleitet und die Lautstärke so hoch wie möglich einstellt. Nun kann man die eingehenden Daten als Töne hören. Zuerst kommt der Header und anschließend die Programmdaten. Man braucht also nur abzuwarten, bis der Header überlesen und bis echte Daten gelesen werden um dann abzubrechen. Anschließend den Befehl List eingeben, dann kann man feststellen, daß das alte Programm noch korrekt im Speicher steht. Erst wenn der gesamte Block einwandfrei eingelesen wurde, dann wird das alte Programm überschrieben. Alle für den Computer wichtigen Daten sind im Header vorhanden. Da zwischen den Namen der verschiedenen Headerbuffer noch Bytes frei sind, vermuten wir, daß dort noch anwenderspezifische Daten stehen können, aber untersucht haben wir das noch nicht. Es muß nicht immer Mozart sein Nebenbei erwähnt: Hören Sie sich ruhig einmal die Lade- und Abspei-chervorgänge an. Beim „Saven“ sehen und hören Sie, daß der Kassettenrecorder anläuft und - erst mit einer gewissen Verzögerung - dann der Header geschrieben wird. Anschließend erst die eigentlichen Daten, gefolgt von einem Nachspann, den wir aber noch nicht näher kennen. Evtl. enthält er ähnliche Daten wie der Header. Damit haben wir nun alle bisher uns bekannten Kassetteneigenarten mitgeteilt, aber dies ist noch nicht alles, was uns der Schneider bisher verraten hat. Noch mehr gefunden Auf der Suche nach all den bisher mitgeteilten interessanten Speicherbereichen, stießen wir gezwungenermaßen auch auf andere. So konnten wir feststellen, daß ab der Speicheradresse Null immer wieder das gleiche stand. Dort stehen bis einschließlich der Adresse &3f die Restartbefehle (RST). Diese dienen dazu, das System in bestimmter Weise zu initialisieren. So führt beispielsweise der Befehl Call 0 dazu, daß ein Reset ausgeführt wird, der genau das gleiche bewirkt, wie das Einschalten des Computers. Diese Sprungtabelle wird beim Initialisierungsvorgang des CPC 464 aus dem ROM in das RAM geschrieben. Einige dieser Sprungadressen können durch den Anwender selbst definiert werden. (Bild 6: Restarttabelle) Wollen Sie wissen, was Sie als letztes getan haben? Ab &44 steht der Rest der letzten editierten bzw. geschriebenen Basiczeile und dahinter drei Trenn-Nullen. Das heißt, daß die Zeilennummer und das erste Zeichen fehlen. Egal, ob Sie mit Edit arbeiten, oder eine Zeile neu eingeben, dort erscheint ein Teil davon. (Bild 7: Es wurde editiert) Sie können bei der Analyse dieses „Dumps“ erkennen, daß dann, wenn Sie mehrere Zeilen bearbeitet hatten und die letzte von ihnen kürzer als die vorhergehenden war, auch noch Reste dieser anderen zu sehen sind. Haben Sie aber keine Basiczeile geschrieben, sondern nur irgendwelche mehr oder weniger sinnvollen Eingaben (nicht beim Programmablauf!) mit Return abgeschlossen, so finden Sie dies ebenfalls dort. Zum letzten eingegebenen Zeichen wurde &80 addiert. Da dieser Puffer anscheinend nur bis &141 geht, könnte unter Umständen im Bereich von &142 bis zum Basicstart, nämlich &170, auch noch irgendetwas ablaufen, bzw. dieser Bereich vielleicht für eigene Programme trickreich verwendet werden. Reste der zuletzt editierten Zeile usw. finden Sie auch ab der Adresse &aca4, das hejßt Sie finden ab dieser Adresse Ihre letzten Eingaben, wobei wieder die Trennungsnull mit dabei ist. Wie groß dieser Bereich ist, können Sie durch folgenden kleinen Trick herausfinden. Geben Sie bei der Frage nach der neuen Adresse einfach hinter &aca4 lauter Space-Tasten, Doppelpunkte o. ä. ein (bis der CPC akustisch „meckert“), dann können Sie erkennen, daß diese bis einschließlich &ada2 mit abschließender Null „gehen“. Zwei, weiter interessante Adressen, sind &b446 und b900. Während ab der ersten Angabe das in Bild 8 dargestellte zu finden ist, beginnt ab der zweiten eine Sprungtabelle für die Firmware. o, das soll's gewesen sein, was wir über die RAM-Adressen mitteilen wollten. Aber wir sind damit noch nicht am Ende aller unserer Ausführungen. Es folgen noch kleine Tips, Programme und Mitteilungen, wobei wir auch in den nächsten Heften der ComputerSchau noch „schneidern“ werden. Kunterbuntes Obwohl wir in einer anderen Computerzeitschrift lesen konnten, daß durch NEW gelöschte Programme trickreich wieder gerettet bzw. zurückgeholt werden können, teilen wir diese Auffassung nicht, wir sind überzeugt, daß durch den Befehl NEW der Basicbereich mit Nullen beschrieben wird. Bei anderen Computern klappt die Rettung durchaus, beim CPC glauben wir nicht daran. Wir lassen uns aber gerne eines Besseren belehren, denn wir sind auch nicht allwissend. Hoffentlich werden wir nicht zu lange auf die Folter gespannt. Sind Sie vorsichtig bei Schleifen mit Hexzahlen, denn da können Sie einem kleinen, aber heimtückischen Fehler aufsitzen. Uns ist es auch passiert, daß wir uns bluffen ließen. Doch gleich zur Praxis, nachfolgendes Programm zeigt, „wo der Hase im Pfeffer liegt“. 10 for i = &4000 to &a000:print i:next iSchon die Geschwindigkeit, mit der diese Zeile ausgeführt wird, sollte einen stutzig machen, denn es geschieht absolut nichts, nicht einmal eine Fehlermeldung kommt! Der Cursor meldet sich sofort zurück. Wir hatten eine ähnliche Schleife in einem Programm, um Werte mittels PEEK und POKE umzuschaufeln. Es wurde absolut nichts dorthin gepo-ket wo wir etwas haben wollten. Der Grund für dieses Fehlverhalten ist die Tatsache, daß ab der Hexzahl 8000 alle Zahlen mit negativen Vorzeichen ausgegeben werden, wenn man beispielsweise den dezimalen Wert von &xxxx wissen will (xxxx ist eine Zahl größer 8000). In dezimal klappt Peek/Poke natürlich. Also Vorsicht!Ein beliebtes Thema sind immer wieder Listschutztechniken. Aber sie haben alle einen Nachteil, sie überlisten nur diejenigen, die nichts über ihren Computer wissen. Dazu gehören Sie aber nun bestimmt nicht mehr. Vor allem dann, wenn Sie mit dem Demo-Programm Listschutz etwas gespielt haben und außerdem wissen, daß die Methoden immer nur die gleichen sein können, nämlich z. B. das Verstellen irgendwelcher Zeiger, bzw. das Auftreten von Werten, die normalerweise dort nicht vorhanden sein könnten. Dadurch verschluckt sich dann meist der List-Interpreterteil und nur deswegen kommt es zu diesen Effekten. Dieses Programm kann übrigens auch zur Anzeige fast aller Befehlstokens eingesetzt werden. Geben Sie einfach Werte oberhalb von 127 ein und schon sehen Sie den entsprechenden Basicbefehl. Nur bei den im Programm genannten Werten klappt es eben nicht. Die Token, also die Einbytewerte für die Befehlsworte, haben alle Werte größer als 127. Weil wir gerade bei solch' kleinen Programmen sind, lassen wir noch eines zur Ausgabe der Steuerzeichen folgen: 100 a$ = "*" |
Kurz und bündig Das Programm „ComputerSchau-Hexpeeker für Schneider CPC 464“ dient vor allem dazu, zu erfahren, wie ein Basicprogramm im Speicher dieses Computers abgelegt wird. Des weiteren sind natürlich auch darüber hinausgehende Untersuchungen im Speicherbereich möglich. So z. B. die Analyse, wie Variablen abgelegt werden, Feststellung, welche Werte den Basic-befehlen zugeordnet sind usw. Durch „Arbeiten“ mit diesem Programm lernt der Anwender in sehr kurzer Zeit einiges über seinen „Schneider“ kennen. |
|  |
|
