[Tiptoi] gme Dateiformat & integrierte binaries

[Ulrich Sibiller]

2015-01-07 1:52 GMT+01:00 Patrick Spendrin <ps_ml at gmx.de>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hallo,
>
> ich schaue mir gerade das gme Dateiformat an und habe festgestellt,
> dass in der Beschreibung des Formats noch ein paar Lücken sind. Unter
> anderem wird in dem Weltatlas file am Ende ein paar ARM Binaries
> angehängt, weiss jemand etwas genaueres darüber? Soweit ich das
> gesehen habe, scheinen das nur Testbinaries zu sein, ich habe das Buch
> allerdings nicht und kann das nicht weiter testen.

Oh, das höre ich zum ersten Mal! Wir haben ja auch ein paar
unverstandene Einträge im Header, gibt es da eventuell Verweise auf
die Binaries? tttool weiß von dieser (möglichen) Struktur IMHO nichts
und kann daher auch nichts dazu anzeigen.

> Dies führt mich zur nächsten Frage: Was ist normalerweise bei
> Auslieferung auf dem Stift zu finden? Ich habe mehrere Testdateien
> gefunden; was genau damit gemacht wurde, ist mir aber schleierhaft.

Die Testdateien werden IIRC angelegt, wenn du den Stift im Debug-Modus
startest. Vorher existieren sie nicht. Ich muss zuhause mal schauen,
ich hab mir IIRC einen Dump einen relativ jungfräulichen Stiftes
gemacht (Alles schon wieder ein Jahr her, meine Erinnerung kann mich
also trügen).

> Welche OIDs werden denn eigentlich für die Aktivierung der anderen
> Sprachen benutzt? Für Deutsch ist es bei mir die 999 (==> 0x39f6
> graphisch). Und, kann man den Stift später noch auf andere Sprachen
> umschalten?

Wieder IIRC ist es so, dass die Initialisierung eine Datei auf dem
Stift anlegt oder updatet, in der die Sprache hinterlegt wird. Über
die entsprechenden Codes haben wir auch mal diskutiert, da muss ich
aber auch erst suchen.


> Und zum letzten:
> Was für Theorien gibt es denn bezüglich der Zuordnung von der
> graphischen OID und der tatsächlichen Objekt-ID?
> - - Es ist nicht notwendig nahe beieinanderliegende OIDs zu trennen um
> die Erkennung zu erhalten.

Wie meinst du das?

> - - eine echte Verschlüsselung ist das auch nicht, die Zuordnung ist
> (jeweils getrennt nach Object und Media-IDs) trotzdem immer ansteigend.

Wenn es sowas wie Object- und Media-IDs überhaupt gibt...

> - - grossartige Lücken scheint es ja auch eher nicht zu geben, und wenn
> dann nur durch die systematische Verteilung der Zahlen in den Büchern.

In dem Zusammenhang wäre evtl. mal zu fragen, warum immer nur ein
Umfang von  ca. 15000 Codes angegeben wird, obwohl es eigentlich
wenigstens 16384 sein sollten.

Mit dieser Zuordnung habe ich mich auch ein wenig beschäftigt (leider
ohne bahnbrechende Erkenntnisse). Allerdings ist es ja so, dass wir
derzeit über 18 Bit verfügen (je zwei für jedes der 9 Felder in der
graphischen Darstellung). 2 davon werden derzeit als Checksumme
angenommen. Für ~15000 Codes reichen 14 Bit, weswegen es eventuell sei
könnte, dass wir zuviele Bits auswerten und daher diese - bisher
unverstandene - Zuordung herauskommt.

Uli