GoDot Infos

Zitat von GoDot

Ich hab hier ein ganzes Programmierhandbuch liegen.
[...]
Na, ich such das mal raus und melde mich.

Hab's gefunden. Muss das Ganze aber noch ein wenig überarbeiten, weil ich zwischendurch die Labelbezeichnungen anders organisiert hab und dadurch deren Namen länger geworden sind. Und... ehrlich gesagt, manche Passagen würd ich heute komplett anders schreiben... Klingt bisweilen viel komplizierter als es in Wirklichkeit ist... na ja.

Also, das ist Zwischenstand.
Arndt

EDIT by FXXS: Threadsplit.

EDit2: Titel gekürzt, Langform war: GoDot Infos (Programierkurs / Handbuch / Quellcode-PDFs)

Zitat von GoDot

Also, das ist Zwischenstand. Arndt

Ich hab jetzt die Quellcode-Dateien von GoDot Main (UI und Disk-Handling) und GoDot Upmem (Mainscreen-Funktionen und Grafik-Rendering) als PDF aufbereitet. Der Code ist in englischer Sprache ziemlich umfangreich kommentiert. Wenn Interesse besteht, sollte man hier vielleicht einen neuen Thread aufmachen?
Adressen der PDFs: GoDot Main, GoDot Upmem.
Das Programmierhandbuch ist in der (Überarbeitungs-)Mache.

Schaut's euch an.
Arndt

Zitat von FXXS

Ich hoffe die Überschrift passt....

Passt scho...

Arndt

Und hier der Quellcode für einen einfachen Lader. Dieser ist für das Image-System-Format, das ist ein Multicolor-Malprogramm, ähnlich wie Koala Painter (dessen Lader ist komplizierter, weil da noch das komprimierte Koala-Format eingeschlossen ist). Aus dem Quellcode geht hervor, wie ein Image-System-File aufgebaut ist. Außerdem sieht man da die Funktionsweise des Aktivitätsbalkens beim Einlesen des Bildes (und anderen Vorgängen) und wie dann die Farb- und Bitmapdaten umgerechnet werden ins 4Bit-Format. Schließlich sorgt der Lader für die Informationsanzeigen im GoDot-Hauptbildschirm. In einem anderen Posting schreibe ich mal auf, was man bei so einem Lader beachten muss beim Coden.

Arndt

Also für Unverdrossene:

1. Du hast 3500 Bytes Platz für ein Modul.
2. Du hast nur wenig weiteren Platz für Puffer und so.
3. Jedes Modul wird für *= $c000 assembliert.
4. Jedes Modul hat einen obligatorischen Header.
5. Es gibt eine Systembibliothek mit den GoDotlabels.
6. Texte gibt das System aus (dafür gibt es fertige Code-Schnippsel).
7. Module haben ein UI oder sie haben keins. (Der Unterschied muss dir klar sein!)
8. Die Routinen für die Tastatureingaben sind Bestandtteil von jedem Saver.
9. GoDots Grafikdaten sind Graustufendaten. (Die 16 Farben repräsentieren Graustufen.)
10. Was ein Modul macht, ist völlig egal. Hauptsache, es macht Sinn (und Spaß).

Noch Interesse?

Arndt

Zitat von H.T.W

Mehr...

Dann auf vielfachen (hehe...) Wunsch zuerst die Label-Bibliothek, schwerst kommentiert.

Arndt

Alle GoDot-Module beginnen mit einem 54 Bytes langen Header, der einen festen Aufbau hat. Wie schon erwähnt, laufen Module grundsätzlich im $c000-Bereich (der in GoDot den Namen "Execution Area" trägt). Das sieht dann so aus:

Bytes 0 bis 2:
JMP start
- Der Einsprung ins Modul führt immer über $c000.

Byte 3:
type
- Hier wird der Typ des Moduls codiert, wobei gesetzte Bits signalisieren, welches Modul gemeint ist. Es gilt:
- $80 = Loader (Filenamen beginnen mit "ldr.")
- $40 = Saver (Filenamen beginnen mit "svr.", Saver enthalten immer die Input-Routinen)
- $20 = Modifier (Filenamen beginnen mit "mod.")
- $10 = Device (Filenamen beginnen mit "dev.", ein Device startet an einem anderen Ort: $cab0)

Byte 4:
ownreq
- Dies ist ein Flag, das angibt, ob ein Loader ein eigenes UI mitbringt. Es gilt nur für Loader.
- $00 = kein eigener Requester im Loader (und Defaultwert für alle anderen Module)
- $04 = der Loader hat einen eigenen Requester.

Byte 5:
dirty
- $00 = Modul kann aus der REU heraus gestartet werden, ohne dass es zu einem instabilen System kommt.
- $01 = Modul stört das RAM-Device und kann nicht aus der REU heraus gestartet werden.

Byte 6 und 7:
modend
- Zeiger auf die erste freie Stelle hinter dem Modul (was auch eventuelle Puffer und Variablenbereiche einschließt). Gleichbedeutend mit "Länge des Moduls" (Länge gleich modend minus $c000).

Byte 8 und 9:
reserved
- reserviert für spätere Zwecke

Byte 10 bis 25:
name
- Der Name des Moduls in PETSCII, 16 Zeichen, der Name weicht üblicherweise vom Filenamen ab. Füllzeichen ist das Leerzeichen.

Byte 26 bis 29:
version
- Versions- und Revisionsnummer des Moduls in der Form "v.rr".

Byte 30 bis 37:
date
- Datum der letzten Revision in der Form "tt.mm.jj".

Byte 38 bis 53:
author
- 16 Zeichen Platz für den Namen des Programmierers in PETSCII. Füllzeichen ist das Leerzeichen.

Bei ganz wenigen Modulen folgt an dieser Stelle noch ein unterschiedlich langer Kommentarbereich mit Informationen zu dem speziellen Modul.
Ansonsten beginnt hier das eigentliche Modul. Es darf einschließlich aller Puffer und Variablen nicht länger sein als 3500 Bytes.

Ein Beispiel (der Header von "mod.ClipWorks"):

Wer was ausprobieren will, hängt hier folgenden Code ein:

So ein Testmodul sollte als Modifier ("mod.Test" oder so) deklariert werden. Der obige Code lässt GoDot nach einem Klick aufs Gadget diesen Test-Modifier sofort wieder verlassen, es passiert also scheinbar gar nichts (das Gadget blinkt, wenn es angeklickt wird, standardmäßig). Man kann aber mit "ldr..Version" die Header-Informationen anschauen. Sind die in Ordnung, hat's geklappt.

So.

Falls sich noch jemand für Quelltexte und Modulentwicklung für GoDot interessiert, ich habe seit einiger Zeit ein Github-Repository, wo man das alles nachvollziehen kann: Godot auf Github.

Die Entwicklung von neuen Modulen und Updates von alten ist außerdem ungebrochen, was man sich hier ausführlich reinziehen kann. Die d64-ZIPs der Systemdisketten werden übrigens bei jedem Modul-Update ebenfalls upgedatet, sind also immer aktuell.

Ich könnte noch Ideen gebrauchen, was man im Rahmen so eines Projektes wie GoDot noch sinnvoll alles einbauen könnte. Zum Beispiel bin ich ja in den Überlegungen für einen NuFLI-Saver, nachdem das mit dem Lader so super geklappt hat. Ich könnte ja so einen ähnlichen Thread für den künftigen Saver aufmachen, in dem ich meine Gedanken und Fortschritte dazu dokumentiere. Wär das was?

Im Übrigen verweise ich auf das Online-Handbuch, das ich im letzten halben Jahr stark überarbeitet habe, vor allem ist jetzt alles reich bebildert.

Bis dann!
Arndt

Zitat von GenerationCBM

Bei GoDot denke ich mir immer leicht unterschwellig, dass das auch als Crossplatform-Werkzeug hilfreich wäre. Wenn die Sourcen bereits da sind, gibt's irgendwelche Bestrebungen, die Funktionalitäten irgendwohin zu portieren?

Eigentlich nicht. Was GoDot macht, machen Nicht-8-Bit-Programme besser. Du hast nur nicht die Möglichkeit, durch die Kombination der Module in GoDot, so viel auszuprobieren und dadurch auf neue Ideen bei der Bildbearbeitung zu stoßen. Ist halt ein C64-Photoshop, das macht es aus...

Arndt

Zitat von peiselulli

Unterstützung fürs DTV, dann könnte man sich die interne Darstellung mit den 4 Bit/Pixel auch darstellen lassen.

Woran denkst du da genau? Den DTV-Speicher nutzen im Sinne, wie der REU-Speicher genutzt wird (als RAM-Device)? Oder meinst du was mit den Farbfähigkeiten des DTV? Wo gibt's denn auf die Schnelle die nötigen Infos?

Arndt

Zitat von GenerationCBM

was mit anderen Programmen mindestens viel mehr Gefummel und Rumprobieren erfordern würde

Du glaubst aber nicht, wie viel ich fummele und dadurch erst auf die guten Ideen komme. Sowas wie die drei hier:

(also verschiedene Überlagerungen mithilfe von Maskierung) hab ich auch erst nach viel Probieren rausgefunden (mir fiel ein, wie es ist, wenn man durch ein Fliegengitter guckt, und dann hatte ich die zugehörige Erleuchtung... )

peiselulli: Danke für den Link!

Arndt