[Tiptoi] gme Dateiformat & integrierte binaries

[Patrick Spendrin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Am 07.01.2015 um 11:03 schrieb 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.

Ja, das steht bei den bis jetzt ignorierten Einträgen ab 0x8c.

Ich habe in den letzten Abenden immer mal wieder an einer
Strukturdefinition für den KDE Hex-Viewer Okteta gearbeitet (und hoffe
auch noch ein bisschen weiter dran zu schrauben). Falls jemand
Interesse hat: https://github.com/sengels/okteta-gme
In der .osd Datei kann man auch die zusätzlichen Einträge sehen, einen
merge request für die Dokumentation im tiptoi-reveng repo kann ich
noch machen, wenn gewünscht.

> 
>> 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).

Hm, meines Erachtens waren die drauf *bevor* ich zum ersten mal der
jungen chinesischen Damen gelauscht hab.

> 
>> 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.

Hm, bis jetzt habe ich nichts gefunden, ich kann es mir allerdings
auch nicht anders vorstellen.

> 
> 
>> 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?

Die "Toolbar" am unteren Rand hat in unserem Buch sowohl fortlaufende
graphische als auch objekt-IDs. Meine ursprüngliche Theorie war ja das
man die objekt-IDs gleich lässt, und die graphischen variiert um
scharfe und gut erkennbare Trennlinien zu bekommen. Dem ist aber nicht so.

> 
>> - - 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...

siehe nächste Antwort.
> 
>> - - 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.

Dazu möchte ich folgendes sagen: Alle herausragenden Zahlen sind in
einem dezimalen System festgelegt worden, nicht, wie man es
normalerweise bei einem digitalen System macht, im hexadezimalen
System. z.B. ist die deutsche Sprach-ID 999 (oder die 1000. ID), die
Bücher fangen mit IDs ab n*1000+1 an usw. Insofern würde ich mich
darüber nicht wirklich wundern.

> 
> 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.

Hm, das halte ich für unwahrscheinlich, denn:
das jetzige Paritätsdoppelbit lässt sich ja sowohl gut lokalisieren,
als auch genau berechnen. Ein weiteres lässt sich erstmal nicht so
leicht finden.
Was mich dennoch stutzig macht (und weshalb du doch Recht haben
könntest ;-)), ist die Tatsache, dass die Parität die ungeraden Bits
nicht überprüft.

> 
> Uli
> 

Viele Grüße,
Patrick
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.21 (MingW32)

iQIcBAEBAgAGBQJUrSBaAAoJEPAKI6QtGt1xjasQANPRR8CzIXOJ68m/zZerJmQP
TykPiql9GZg1GVxNm0AxFGgzHewIh4WcPEGC9eV4d0hmXWw7aTPwKjqvbbXH8scv
Gu645LPDtmdmZJo64rDcT8kO7injUtQsKW9pEZu85+QI1/Zj/j3sNMUXn/4umO9C
pQby/TmanFY8VvPkResHeAacjG/urHxKoADxJU7OsMjuEaW0hOtBp8qDf0FTV0Zj
Zw2BHfBAuPooIzVm6Y8ljtTnaxLpNkCyNHg29KhVF2edu24PCP3jUvrTJFx7X+gm
RYujdk4u6wHaeQGEarZ7McQnp0SPE6sRixqzsjMP/ZRb7vV41YLTUNkJs+ZOEOOK
eHxV7X+LCD7clm4AhUjadgPSKyhST38tKpklJQmdx0xF1GyLoJ1SIKcqzP5UegO8
dS1nHzGvdjTAXGs9w/NPg8JqQFCt0a2eW+mcMwPkUve+iDvbLt8SA+dqZ3XhBZsV
99julSkzUPDrPiIPxOG7JrKLP2ggEN81o/aHKwPiKSjGsEmYnv33pC5kD728cnUh
QJI0tpURiTE1aFFTbodhyMVsN3TxhfbtZsjG/bz+bMuw7+WGyXPLC0G7YVZT5O12
6MSsyJDdifBezcNRmksA8hF8BtdFtor1xsggj/J9/YC7Utchm3mSHsx6HrzSKSq4
yD06vUtcJfKWrPTnIKeC
=fLoK
-----END PGP SIGNATURE-----