Was kann man mit GoDot über dieses Bild herausfinden?
Was ist das? Wie geht das?
Mithilfe von GoDot lassen sich drei Dinge analysieren: Bilder, Dateien und das GoDot-System selbst.
In diesem ersten Abschnitt geht es nicht darum, wie man herausfindet, mit welchem Editorprogramm ein Bild entstanden ist (und in welchem Dateiformat es folglich abgelegt wurde). Dafür hat GoDot Module wie .FileType, die im Abschnitt "Dateien" behandelt werden. Es geht hier darum, unbekannte Bilder zu analysieren, herauszufinden, wie sie vielleicht gemacht wurden, evtl. bestimmte darin verwendete Tricks aufzuspüren. Dazu braucht man Werkzeuge zum Zählen der Farben und zum Eingrenzen des im Bild verwendeten Grafikmodus, also der Anordnung der Pixel im Bildspeicher, und weitere Tools.
Nehmen wir einfach mal dieses ungewöhnliche Bild (s. am Seitenanfang: Monroe6569 von Digger nach einer Vorlage von no-ee-ko (Michal Sysz) aus dem Jahr 2011) und versuchen, mehr darüber herauszufinden.
Die Bildgröße ist 320×400 Pixel, ein doppelt hohes Bild. Es liegt im GIF-Format vor, d.h. es lässt sich nicht herausfinden, mit welchem C64-Programm es erstellt worden sein könnte. Mit geeigneten Darstellungsroutinen ist das Anzeigen von doppelt hohen Bildern auch auf dem C64 kein Problem. Das Originalbild löst diese Aufgabe so, dass es die Anzeige fortlaufend auf- und abscrollt, damit man das Bild im Ganzen sehen kann. Beim Anschauen fällt dabei sofort die hohe Pixelauflösung ins Auge: Es scheint sich um ein Hiresbild zu handeln. Erkennbar am Ohr, im Netz oberhalb des Auges und im Haarschmuck oben und links.
Also an die Arbeit, zuerst das Bild nach GoDot laden: Da es von c64pixels.com stammt, stellen wir zunächst mit SetColorBase die entsprechende Palette ein und laden das GIF-Bild mit dem zugehörigen Lader (da es ja offenbar Hires ist, zusammen mit DecodeGIFhir).
Schauen wir doch gleich mal nach, wie viele Farben denn überhaupt im Bild verwendet werden: ColorCount sagt uns (hinter "GoDot"), dass im Bild 10 Farben enthalten sind. Ein Durchlauf mit Histogram verrät uns auch, welche das sind (und welche nicht, siehe Screenshots). Aus der Anzeige von ColorCount entnehmen wir (hinter "Multi") weiterhin, dass ebenfalls 10 Farben in Doppelpixeln im Bild abgelegt wurden, als wären sie für den Multimodus gedacht. Bereits mit bloßem Auge, noch besser aber mit PixelEdit, erkennen wir, dass diese Doppelpixel überall dort zu finden sind, wo im Hiresmodus vorher zu wenige Farben angezeigt wurden: um das Auge und um die Wange herum. Hier waren also mehr Farben auf engerem Raum für das Bild erforderlich. Kann man vielleicht sichtbar machen, welche Farben den größten Teil dieser Doppelpixel ausmachen?
Schon haben wir ein klares Bild von den Doppelpixelbereichen im Bild (siehe den großen Schwarz-Weiß-Screenshot).
Haben wir es hier mit Sprite-Overlays zu tun? HowMany bestätigt diese Vermutung: Eingestellt auf 4 Farben (die Maximalzahl in einer Multicolor-Kachel) entsteht die Ziffernanzeige im kleinen Bild hier. Alle grünen Ziffern benennen die Kacheln mit vier Farben, rot bedeutet gar, dass es in dieser Kachel noch mehr Farben gibt (was im Hiresmodus ausschließlich mit Sprite-Overlays realisierbar ist, im Hiresmodus können ja nur zwei Farben pro Kachel ausgewählt werden). Womöglich ist an diesen Stellen für die zusätzlichen Farben auch eine weitere Schicht aus Hires-Sprites oder einfach aus Multicolor-Sprites verantwortlich.
Fazit: Dieses Bild (Monroe6569) ist ein Hires-Bild mit darübergelegten, expandierten Sprites, ebenfalls in Hires (was man sieht, wenn man die drei Graus mit 4Bit&Mask oder Histogram/Join aus dem Bild entfernt, s. kleines Bild) und evtl. zusätzlichen Multicolor-Sprites für Farbakzente. Wahrscheinlich hat Digger das Bild für einen speziellen Anlass mit selbst programmierten Tools erstellt.
Verwendete Analysewerkzeuge: ColorCount · HowMany · Histogram · QuickMask · MaskEdit · PixelEdit · SetColorBase
Übrigens: Ein reines Multicolorbild (wie das folgende) erkennt man mit ColorCount. Alle drei Zahlenangaben sind dann gleich.
Eigentlich weiß man ja, was sich auf den Disketten, die man im Lauf der Zeit so gehortet hat, alles befindet. Hin und wieder aber kommt einem doch die eine oder andere Datei nicht ganz geheuer vor und man weiß sie nicht richtig einzuordnen, vor allem, wenn in ihrem Namen keinerlei Hinweise auf ihren Verwendungszweck auszumachen sind.
Für einen solchen Fall bietet GoDot eine Art "Ermittler-Team" aus vier Modulen an: .FileType, .FileCopy, RawBytes und .SMON. Dabei ist .FileType immer erste Anlaufstation bei der Suche nach Antworten. Sehr häufig reicht bereits sein Einsatz zur Lösung des Problems aus.Manchmal jedoch führt die .FileType-Angabe auf ein falsches Gleis, wie hier im Beispiel (s. Bild). Obwohl der Name der angeklickten Datei und die Antwort von .FileType nahelegen, dass es sich um ein (A)FLI-Bild handelt, zeigt das nach dem Laden der Datei gerenderte Bild, dass diese Angaben nicht stimmen können (es erscheinen nur wirre Farben).
Stimmt denn die Dateilänge für ein AFLI-Bild (65 Diskblocks)? Um das herauszukriegen, brauchen wir .FileCopy, das als einziges GoDot-Modul die Länge einer Datei anzeigen kann (Dateilängen spielen ansonsten unter GoDot keine Rolle). Nein, auch dadurch kommen wir nicht weiter, die Datei ist genauso lang, wie sie sein soll: 65 Blocks, Standardlänge eines ungepackten AFLI.
Also schauen wir uns das Innere der Datei an: RawBytes lädt sie in den GoDot-Speicher, .SMON zeigt, woraus sie besteht. Die Startadresse für AFLIs stimmt auch ($4000), daher laden wir sie noch einmal ohne Startadresse, damit wir die Struktur besser erkennen können.
Zunächst fällt auf, dass die Daten am Anfang der Datei keine VideoRAM-Daten sein können (AFLI fängt mit den acht VideoRAMS an), sie sehen eher so aus wie Bitmap-Daten. Das probieren wir aus: Die Bitmap eines Bildes ist 8 KB lang, reicht also von $4000 bis $6000. Diesen Bereich kopieren wir einfach mit .SMON in die GoDot-Bildanzeige (w4000 5f40 2000, bitte nicht 6000 als Kopierende angeben, es werden GoDot-Bereiche ab $3f40 beeinträchtigt, was zum Absturz führt) und schauen mit MaskEdit/O oder QuickMask/View nach, was dort angekommen ist. Ja, eine Bitmap!
Dann sind die Daten ab $6000 VideoRAM-Daten. Sehen sie auch so aus? So etwas ist am besten erkennbar an der Übergangsstelle von einem VideoRAM zum nächsten, also am Ende des vorherigen VideoRAMs, hier also an der Stelle um $6400 herum (ein VideoRAM ist 1000 Bytes lang, reicht daher von $6000 bis $63e7, das nächste beginnt bei $6400, dazwischen befinden sich meistens Leerbytes, hier $00 und $fe). Ja, es sind VideoRAMs! Offenbar haben wir es hier mit einem bisher in GoDot nicht bekannten Hires-FLI-Format zu tun!
Das überprüfen wir dann aber auch noch: Die beiden Teile der Datei (die Bitmap und die VideoRAMs) einzeln abgespeichert (mit .SMON: s"teil1" 4000 6000 und s"teil2" 6000 8000), sofort in der umgekehrten Reihenfolge wieder geladen: l"teil2" 4000 und l"teil1" 6000 und schließlich als AFLI gespeichert: s"afli" 4000 8000.
Diese Datei mit dem AFLI-Lader geholt und gerendert: Bingo! Tatsächlich ein Hires-FLI-Bild (wenn auch mit einigen Color Clashes, das sind die kurzen waagerechten Striche, wahrscheinlich handelt es sich um die unbearbeitete Konversion eines Fotos).
Dies war ein Beispiel für die Untersuchung eines Bildes. Natürlich ist der SMON aber auch gut für das Untersuchen von Maschinenspracheprogrammen oder für sonstige unbekannte Dateiinhalte zu gebrauchen. Die Datei "fliview 36 bytes" im ersten Screenshot hier sieht als Assembler-Listing unter .SMON so aus:
(Das Bild "flipic webster" ist ein Bild im ungepackten Hires-Manager-Format. Zwischen Hires Manager und AFLI kann .FileType leider nicht unterscheiden, wenn der Name des Bildes nicht im Hires-Manager-Standard angegeben ist.)
Verwendete Analysewerkzeuge: .FileType · .FileCopy · RawBytes · .SMON · ebenfalls nützlich: .ShowFiles
Der Guru (rechts oben auf "GoDot!" klicken) transportiert selbstverständlich auch Informationen: Wer wissen will, ob er ein aktuelles GoDot-System benutzt, schaut sich die GoDot-Creation-Number an, sie kodiert (in den Ziffern vor dem Punkt) die Versionsnummern der beiden wichtigsten Systemdateien god.main (Kernel) und god.upmem (Grafikroutinen).
Um gleich beim Stichwort "aktuell" zu bleiben: Sowohl die Versionsnummer des installierten Laders als auch die des verwendeten Savers (heißen hier im Bild beide "4BitGoDot") erfährt man mit dem Modul Version. Man vergleicht die dort gefundene Nummer mit den von diesen Seiten her erreichbaren Nummern (immer ganz oben rechts in den Beschreibungen). Unterscheiden sie sich, lädt man einfach das komplette GoDot-System neu, der Download ist immer aktuell. Die Versionsnummer eines installierten Modifiers (im Bild hier: "ClipWorks") erfährt man über den Lader Version und geht dann ganz genauso vor. Alle diese Informationen zusammengefasst und erweitert um Angaben zum eingebundenen Extra-RAM und der angeschlossenen Hardware erhält man über .SystemInfo.
Die GoDot-Oberfläche lässt sich optisch verändern: Für die Farben und den Mauszeiger gibt es Einstellmöglichkeiten zur Laufzeit (.SysColors und .NewPointer), aber auch bereits beim Systemstart per Konfigurationsdatei.
Hilft gar nichts mehr, weil das System z.B. eingefroren ist, kann man - den entsprechenden Schalter vorausgesetzt - immerhin noch einen Hardware-Reset auslösen. Die 4Bit-Grafikdaten bleiben davon weitgehend unbehelligt, nur am Ende des freien BASIC-Speichers werden Bytes verändert: an Speicherstelle $9fff (und rückwärts) erscheinen die Werte für den eingegebenen Dateinamen beim GoDot-Neustart, z.B. die Bytes für den Namen der Bootdatei "godot" (zehn betroffene Pixel, die meisten rot) oder einfach nur das Zeichen $2a (das ist der Platzhalter-Stern, in der Grafik ein brauner und ein grüner Pixel). Eine Position weiter, an $a000, sieht man den Wert $55, der vom C64-Reset erzeugt wird (zwei purpurne Pixel). Will man diese Stellen reparieren, geht man in PixelEdit zur Position X: 7, Y: 18 und überschreibt diese Stellen wie gewünscht (s. Bild, hier wären die Farben weiß und schwarz sinnvoll).
Einen Schwarz-auf-Weiß-Überblick über sein System schließlich verschafft man sich mit dem (für einen MPS-Drucker geschriebenen) GoDot-Zusatzprogramm "pvers". Es ergänzt die oben beschriebenen Versionsmodule mit der Möglichkeit, Ausdrucke zur Archivierung anzulegen.
Verwendete Analysewerkzeuge: .Version · .SystemInfo · .ShowFiles · .ScanDrives
zurück - zurück zu den Tutorials
Arndt Dettke