MegaAssembler V3.7 im Quelltext verfügbar

Ich hab Teil D des MegaAssembler-Handbuchs aktualisiert und auf die Area6510 hochgeladen.

Der Teil wurde neu organisiert und es gibt einen neuen Anhang "K": Hier sind jetzt alle 225 GEOS- und MegaPatch-Routinen tabellarisch mit den benötigten Parametern aufgelistet. Teilweise mit zusätzliche Informationen aus dem GEOS programmers reference guide und dem Hitchhikers guide to GEOS. Bei den zusätzlichen 90 Seiten dürfte es sicherlich auch ein paar Tippfehler geben, angesichts der 170 "Korrekturen" im Teil A-C kann ich aber damit leben

Im (nicht veröffentlichten) Teil A-C hab ich 12 weitere Unstimmigkeiten gefunden bzw. 2 Angaben korrigiert. Sind in den Fußnoten 26,76,77,82,105,106,107,110,112,113,124,128,136,143 im Teil D zumindest aufgelistet.

Damit ist für mich die Überarbeitung des Handbuchs zum GEOS-MegaAssembler weitestgehend abgeschlossen und ich kann mich bald wieder wichtigeren Projekten widmen

Nach dem es eine neue Version des "Hitchhikers Guide to GEOS" gibt (Klick!) hab ich mir das PDF heruntergeladen und mit dem Teil D verglichen. Ich hatte das schon mal mit der Original-Version gemacht, aber ein zusätzlicher Vergleich kann ja nicht schaden

Bei rund 95% sind die Angaben zu den Parametern/veränderten Registern identisch. Bei einigen Routinen hab ich was korrigiert (CallRoutine verändert nicht a, GetDimensions verändert nur x/y) bzw. präzisiert warum die Routine bestimmte Register verändert.

Bei ca.10 Routinen weichen die Angaben ab wobei ich da jede Routine nochmal überprüft habe und ich bin der Meinung so wie es im Teil D steht ist es "richtiger" (z.B. SetGEOSDisk, verändert auch r3 durch SetNextFree...). Aber das sind Kleinigkeiten.

Als ich mit Teil D angefangen hab und dabei den "Official GEOS programmers reference guide" und dem "Hitchhikers guide to GEOS" als Referenz herangezogen hatte, da hatte ich auch die Idee die beiden Bücher zu "digitalisieren". Jetzt bin ich froh das PBM das gemacht hat, ich würde das nicht nochmal machen wollen. Man findet da einfach kein Ende...

Der HHG2G ist das umfassendere Werk, das MA-Handbuch zielt mehr auf die Programmierung selbst ab und Teil D auf die neuen Versionen von MA/MP3. Daher haben alle Werke Ihre Berechtigung.

Ich hab jetzt eine korrigierte Fassung von Teil D hochgeladen. Ich werde mir in der nächsten Zeit einen Druck vom Buch bestellen, wenn der i.O. ist bekommt das PDF auch ein Deckblatt... s.u. Bis dahin bleibt es beim Entwurf.

Zitat von wweicht

- S. 484 plötzlich 12.1.4

- S. 485 nach 2.6 kommt 4.30

- S. 488 jetzt haben wir 12.3.2

- S. 492 von 12.3..23 wird auf 14.12 gesprungen

Im Teil D.2.6 werden zuerst die neuen Routinen von MP3 besprochen, diese sind fortlaufend zum Teil B nummeriert. Das hat auch seinen Grund weil die Nummern dann in der Kurzreferenz im Teil D dann durchgehend sind, alte und neue Routinen.

Also das Kapitel D.2.6 beschreibt die neuen Routinen, die darunterliegende Nummerierung ist eine Fortführung von Teil B (Grafik 4.x, Laufwerke 12.x, Sonstiges 14.x). Würde ich hier statt 4.30 mit 2.6.1 weitermachen, dann hätte man in der Kurzreferenz das totale Chaos.

P.S. Deshalb steht da auch:

Zitat

Neue Grafikroutinen (Ergänzung: Teil B, Kapitel 4 ab Seite 223)

Die Nummerierung wird also von Teil B fortgesetzt.

Zitat von wweicht

- S. 465 ist zumindest beim ersten Lesen verwirrend ($8fe8, 16 Byte, $8fe8 8 Bytes)

Stimmt... ab $8fe8 liegen 16 (eigentlich) nicht genutzte Bytes.

Desktop V2 nutzt davon 8 Byte für Farbe und für das Pad das darauf folgende Byte.

Wenn das nummeriert wäre könnte man sagen x.1 sysApplData, x.1.1 PADCOLDATA und x.1.2 DESKPADCOL.

Evtl. rücke ich das etwas ein, dann ist es klarer das es hier um Teilmengen von sysApplData geht.

Zitat von wweicht

- S. 480 nach Kapitel 2.5 kommt 3.1

Siehe oben, D2.5 beschreibt geänderte Routinen aus Teil B und 3.1 ist auch in teil B "Dialogboxen".

Ich könnte da ein "B" davorsetzen, dann wäre evtl. klarer das sich die Nummerierung auf den Teil B bezieht.

Bei der Kurzreferenz hab ich ja auch ein "K" davorgesetzt. Dann kann man B.3.1 mit K.3.1 vergleichen und meint einmal die Beschreibung aus Teil B und einmal die Tabelle aus Teil D und bezieht sich immer auf die Dialogboxen.

Die Kurzreferenz hat da einiges durcheinander gebracht, gebe ich zu, aber um dort eine fortlaufende Nummerierung zu haben, die keine komplett neuen Nummern verwendet, hab ich mich zu der Variante entschlossen. Dann hat jede Routine Ihre eigene Nummer, nur mit einem ggf. anderen Prefix. Aber die Nummer ist an allen stellen identisch.

Aber Danke für die Anregungen, ich wollte heute Abend eigentlich bestellen, aber dann passe ich das noch etwas an. Evtl. klärt das ein paar ???

Die erste Anregung hab ich versucht umzusetzen, Auszug aus der aktuellen Arbeitsversion:

Ich denke der Abschnitt dürfte jetzt klarer sein.

Bei der Nummerierung der geänderten bzw. neuen Routinen in Kapitel D.2.5/D.2.6 bin ich mir noch unschlüssig:

B.4.30 würde jetzt klar von 2.6 abweichen und soll auf Teil B verweisen. Dummerweise gibt es auch einen Anhang B. Allerdings steht ja in der Überschrift das es sich auf Teil B/Kapitel 4 bezieht...

So ganz richtig ist es aber auch nicht, da im Teil B der Prefix "B." vor den alten Routinen auch nicht verwendet wird. Logischer wäre es für mich ohne den Prefix.

Man könnte es auch umdrehen... D.2.6.... (also beim Kapitel den Prefix verwenden) und 4.30 belassen (ohne Prefix). Das ist bei Teil A und Teil B aber auch nicht der Fall...

So ganz rund wird das nicht werden...

Ich hab das Handbuch Teil D aktualisiert. Kleinere Korrekturen. Neu ist nur der Abschnitt über den NativeMode-Bootsektor in Kapitel 2.9. Die Information wurde letztens in anderen Threads hier im Forum diskutiert, kann nicht schaden das in der Beschreibung zum NativeMode im handbuch zu ergänzen auch wenn nicht GEOS spezifisch.

Kleiner Tipp am Rande:

Wer genau wissen will was sich geändert hat, der kann die PDFs vorher und nachher über PDF24.org vergleichen. Alt/Neu wird dann in rot/grün-Darstellung hervorgehoben. Das Layout geht dabei verloren, aber um mal schnell zu sehen was sich geändert hat, dazu reicht das aus.

Für GEOS-Programmierer ein kleiner Hinweis:

Nachdem ich den DeskTop64-V2 dokumentiert habe gibt es zwei weitere Speicherbereiche, die von Anwendungen genutzt werden können. Paul hat im HHG2GEOS die beiden Bereiche als "APP_LVAR" ($0200-$0258) und "APP_LRAM" ($0334-$03ff) bezeichnet. Die Bezeichnungen hab ich so übernommen.

DeskTop64 verwendet diese beiden Bereiche um "Variablen" abzulegen, ähnlich dem Bereich APP_VAR ($7f40-$7fff).

Damit hat man für extrem große Programme zusätzlichen Ablagespeicher. Und nachdem DeskTop selbst ja zeitnah zum Kernal entwickelt wurde kann man davon ausgehen das dies mit dem System abgestimmt ist.

Auf Grund der Namensgebung würde ich davon ausgehen das die Bereiche für Anwendungen reserviert sind, d.h. DeskAccessories sollten den Bereich nicht verwenden.

Ich werde das bei Gelegenheit im MA-Handbuch Teil D (in der MemoryMap in Kapitel K1.1) ergänzen .

Ich überarbeite aktuell nochmal die Gesamt-Ausgabe des Handbuchs. Dabei ist mir noch was zu curRecord (S.187) aufgefallen:

Zitat

In curRecord findet man die Nummer des aktuellen Datensatzes einer geöffneten

VLIR-Files. In der Adresse curRecord erhält man auch den Wert $ff, wenn sich nach

dem Aufruf der VLIR-Routine OpenRecordFile in der geöffneten VLIR-Datei kein

Datensatz befindet. Ansonsten steht hier nach dem Aufrufen von OpenRecordFile

der Wert 1 für den ersten Datensatz.

Das ist nicht ganz korrekt... ich hab das wie folgt abgeändert:

Zitat

In curRecord findet man die Nummer des aktuellen Datensatzes einer geöffneten

VLIR-Datei. In curRecord findet man auch den Wert $ff, wenn sich nach dem Aufruf

der VLIR-Routine OpenRecordFile oder nach DeleteRecord in der geöffneten VLIR-Datei

kein Datensatz befindet. Ansonsten steht hier nach dem Aufrufen von OpenRecordFile

der Wert 0 für den ersten Datensatz.

Der erste Datensatz hat immer den Wert #0. Wundert einen das ausgerechnet hier der falsche Wert 1 angegeben wurde, wo doch sonst an fast allen Stellen darauf hingewiesen wurde das der erste Datensatz den Wert #0 und nicht #1 hat.

Ich hab noch zwei weitere Unstimmigkeiten gefunden:

Auf S.264 steht das MoveData nur Verschiebungen innerhalb von Bank 0 durchführen kann. Richtig ist: MoveData kann nur Verschiebungen im FrontRAM (Bank 1) durchführen, da die Routine selbst ebenfalls im FrontRAM (Bank 1) liegt. Das BackRAM ist außerdem nicht Bank 1 sondern Bank 0.

Auf S.288 steht bei GetDirHead und PutDirHead das die beiden Routinen in r4 einen Zeiger auf curDirHead zurückliefern. Das gibt auch der HH2G2022 so an.

Richtig ist: Nur GEOS 1.0 bis 1.3 liefern in r4 einen Zeiger auf curDirHead, ab GEOS 1.5 findet sich in r4 ein Zeiger auf curDirHead (1541), dir2Head (1571) oder dir3Head (1581), da das die Adressen des zuletzt gelesenen BAM-Sektors im Speicher sind.

Handbuch Seite 246:

* SmallPutChar unterstützt keine Verdopplung der x-Koordinate mit DOUBLE_W/ADD1_W (siehe HitchHikers Guide to GEOS S.275). Wird hier nicht explizit erwähnt, führt aber dazu das bei gesetztem DOUBLE_W keine Ausgabe des Zeichens erfolgt sondern nur die x-Koordinate für das nächste Zeichen angepasst wird..

* Das Clipping mit negativer x-Koordinate funktioniert (m.E.n.) nur am linken Bildschirmrand, nicht am linken Fensterrand. Und dann auch nur ab GEOS V1.4.

Das NativeMode-Format wird ja im Handbuch nicht erwähnt, aber es gibt bei einigen Disk-Routinen etwas zu beachten:

Routinen wie ":SetNextFree", welche die BAM bearbeiten, müssen bei NativeMode ggf. einen Block von Diskette einlesen der zum Sektor passt. Bei NativeMode kann nicht die gesamte BAM im Speicher gehalten werden, das erfordert also ggf. den Aufruf von GetBlock, PutBlock usw...

Das bedeutet aber auch das bei Routinen, welche die BAM verändern, das TurboDOS aktiv sein muss! Zumindest bei realen NativeMode-Laufwerken, RAM-Laufwerke haben kein TurboDOS, daher spielt das bei diesen Laufwerken keine Rolle...