MMI 2G Startscreen Fileformat (.yim)

Irgendwann hatte ich mal Langeweile und habe mir das Dateiformat der MMI 2G Startscreens angesehen.
Die Dateien haben auf den 2G Update-CDs folgende Namen:
Screen0.yim
Screen1.yim
...
Screen5.yim

Schaut man sich die Datei in einem Hex-Editor an, so stellt man ein paar Dinge fest.
Header:

• 0x0 [24 Bytes] - Fileheader start
• 0x0 - 0xb Checksumme ???
• 0x10 [4 Bytes] - Dateigröße (ASCII Encodiert)
• 0x18 [4 Bytes] - Bildtyp [XIM2]
• 0x1c [4 Bytes] - Dateigröße mit Bildheader, aber ohne File-Header und ohne Bildtyp
• 0x20 [2 Bytes] - X-Bildauflösung (480 Pixel)
• 0x22 [2 Bytes] - Y-Bildauflösung (240 Pixel)
• 0x26 [2 Bytes] - Größe Bildheader
• 0x34 [4 Bytes] - hier findet sich die Nutzdatengröße in Bytes (+ 4) 

Ich habe mir dann die weiteren Daten angesehen und dabei festgestellt, dass es sich um eine RLE (Run Length Encoding) Kompression handelt.

Bei einer solchen Kompression werden aufeinander folgende Pattern durch die Anzahl und dann den Pattern ersetzt.
Beispiel: "07 FF 00 00" wird extrahiert als 32767 (0x7ff) mal der Pattern "00 00".

Da es sich um Bilder mit einer Farbtiefe von maximal 16 Bit handelt, ist jeder Pixel 2 Bytes lang. (in diesem Fall "00 00" = schwarz) Genauer gesagt handelt es sich nur um 15 Bit Farbtiefe. (R=5 Bit, G=5 Bit, B=5 Bit)

Weiter hat der Screen eine Auflösung von 480x240 Pixeln, so dass man insgesamt auf 230400 Bytes kommen muss. (115200 Pixel mit jeweils 2 Bytes)

Interessant ist dann natürlich bei einer RLE Kompression, wie denn sich nicht wiederholende Pattern abgebildet werden. Die geschieht über das MSB (Most Significant Bit) der beiden Steuerbytes.
Wenn also z.B. "FF FF" statt "7F FF" (im obigen Beispiel) gestanden hätte, so wäre auch noch das MSB gesetzt gewesen und es hätte sich um eine Zeichenfolge mit 0x7fff Länge gehandelt.

Wichtig, die Länge bezieht sich natürlich auch die "Grundeinheit" und diese ist immer 2 Bytes lang. Es wären also 2 * 32767 Bytes ohne Wiederholung in die Ausgabe zu übertragen.
Eigentlich kann man das File mit diesem Verständnis schon im Hexeditor mit den Augen und einem Taschenrechner decodieren.
Die Nutzdaten fangen immer bei 0x3c an und gehen bis zum Fileende.

Vielleicht hlft es ja jemandem, der bisher vor einem Rätsel gestanden hat?
Versuche Bilder zu encodieren und dann wieder per Software-Update einzuspielen sind leider fehlgeschlagen.
Meine Vermutung ist, dass die Bytes 0x0-0xB eine Form von Checksumme darstellen.
Leider bin ich bisher nicht dahinter gekommen, wie sich diese ASCII dargestellte Zahl errechnet.

Also, wenn es jemand basierend auf diesen hier zur Verfügung gestellten Informationen gelingen sollte einen veränderten Startscreen in ein MMI 2G Display Interface einzuspielen, so möchte ich nur darum bitten Licht in das Dunkel zu bringen was das Thema Checksumme angeht. Das fände ich jedenfalls nur fair...

Wie man die Metainfo-Checksummen berechnet werde ich in einem gesonderten Eintrag mal ausführlich erleutern.
(dieses Wissen braucht es zum Einspielen eines geänderten Files ja auch)