tony-remake/NOTES.md

# Kellogg's Tony and Friends — Remake-Projekt, Analyse-Notizen

## Ziel
Plattformunabhängiges Remake (Python) von "Kellogg's Tony and Friends" (DOS, 1994),
lauffähig auf x64 ohne DOS/QEMU. Ursprung: Spiel crasht in unserer FreeDOS-VM
(RTM.EXE-Engine vs. QEMU-VGA-Emulation, siehe Projekt "Classic Games" für den
Debug-Marathon dazu) — daher der Wunsch für ein eigenes Remake.

## Quelldateien (aus VM-Disk `dos_shareware` extrahiert, liegen in `raw/`)
- `RTM.EXE` — die eigentliche Spiel-Engine (Runtime), DOS-EXE (MZ-Header), 108 KB.
- `START.EXE` / `SETUP.EXE` — Launcher/Konfigurationsprogramme.
- `KELLOGG.INI` — Soundkarten-Konfig (IRQ/DMA), irrelevant fürs Remake.
- `PCKELL.DAT` — 2,69 MB, **unkomprimiert**. Beginnt mit einer monoton
  steigenden 16-Bit-LE-Offset-Tabelle (vermutlich Sprite-/Block-Offsets in
  die anhängenden Rohdaten). Enthält laut `SRB.LST` 32 "SRB"-Blöcke
  (vermutlich "Sprite Resource Block"). Tabellenstruktur noch nicht final
  verstanden — steigt über mehr Einträge als die reinen 32 Top-Level-Files,
  also vermutlich verschachtelt (pro Sprite/Frame-Offsets innerhalb jedes
  SRB-Blocks). TODO: Tabellenende finden und pro-SRB-Grenzen bestimmen.
- `PCKELL.SET` — **ist tatsächlich eine ZIP-Datei** (Signatur `PK\x03\x04`)!
  Enthält 3 Einträge:
  - `APPEND.LST` (Methode 6 "Imploded", 1945 Bytes entpackt) — Manifest mit
    178 Dateinamen für die in `PCKELL.PRE` zusammengefügten Assets.
  - `SRB.LST` (Methode 1 "Shrink", 314 Bytes entpackt) — Manifest mit den
    32 Dateinamen, die zu `PCKELL.DAT` gehören (1:1 gleiche Basisnamen wie
    ein Teil der BOB-Einträge in APPEND.LST, z.B. `TONY.SRB` ↔ `TONY.BOB`).
  - `PCKELL.PRE` (Methode 6 "Imploded", 2.328.934 Bytes entpackt) — die
    eigentliche Asset-Sammlung, konkateniert nach der Reihenfolge in
    `APPEND.LST`.

  **WICHTIG — Kompressions-Falle:** ZIP-Methode 6 "Imploding" ist NICHT
  dasselbe wie das "DCL Implode/Explode"-Format aus PKWAREs Data
  Compression Library (dafür gibt's `blast.c` in zlib/contrib — hab ich
  zuerst versucht, schlägt fehl mit "distance too far back", weil es ein
  anderer Algorithmus ist trotz gleichem Namen). Debian/Ubuntus
  `unzip` (Info-ZIP, kompiliert MIT Explode+Unshrink-Support) entpackt
  beide Methoden aber klaglos — auf `aria-wohnung` funktioniert
  `unzip PCKELL.SET` direkt. Das Alpine-`unzip` im Brain-Container
  (aria-proxy) kann das NICHT (kein Implode-Support einkompiliert).

## Datei-Typen in APPEND.LST (178 Einträge total)
| Ext  | Anzahl | Vermutung |
|------|--------|-----------|
| PCC  | 77     | "Compiled Picture" — vermutlich RLE/Palette-komprimiertes Vollbild (Titelscreens, Menüs, Hintergründe) |
| BOB  | 32     | "Blob" — Sprite-Grafik-Daten (Spielfiguren, Objekte), 1:1 mit den 32 SRB-Einträgen |
| MAP  | 22     | Level-/Karten-Daten |
| ARE  | 22     | "Area" — vermutlich Level-Metadaten/Kollisionszonen, im Paar mit MAP (22=22) |
| ICO  | 19     | Icons (z.B. für Menüs/HUD) |
| SAM  | 3      | Sound-Samples |
| TFX  | 3      | vermutlich Musik/Sound-Effekt-Format |

## Nächste Schritte (in dieser Reihenfolge sinnvoll)
1. **PCKELL.PRE aufteilen**: Die 178 Dateien sind laut APPEND.LST hintereinander
   konkateniert — es fehlt noch die Größentabelle pro Datei (vermutlich am
   Anfang von PCKELL.PRE selbst, ähnlich der Offset-Tabelle in PCKELL.DAT,
   oder implizit aus dem Dateiformat jedes Typs ableitbar). Header von
   PCKELL.PRE selbst noch nicht angeschaut.
2. **Ein PCC-Bild reverse-engineeren** — vermutlich klassisches Palette+RLE,
   das dürfte am leichtesten zu knacken sein (PCC ähnelt oft PCX-Varianten).
3. **BOB/SRB-Sprite-Format verstehen** — Kollisions-Header aus PCKELL.DAT
   (die Offset-Tabelle) mit den 32 SRB-Namen abgleichen.
4. **RTM.EXE nicht disassemblieren müssen** — Ziel ist ein sauberes
   Python-Reimplement der Spiellogik (Physik/Level/Gegner aus MAP/ARE lesen),
   nicht 1:1-Code-Nachbau der DOS-Engine.

## Aufbewahrungsort
Alle Rohdaten + Manifeste liegen unter `raw/` in diesem Projektordner
(`/shared/projects/kellogg_s_remake/raw/`). `raw/extracted/` enthält den
fehlgeschlagenen blast.c-Versuch (kann weg). Entpackte Dateien
(`APPEND.LST`, `SRB.LST`, `PCKELL.PRE` — alle bereits entpackt, nicht mehr
komprimiert) liegen direkt in `raw/`.

## DOSBox-Testumgebung (2026-07-22) — Original läuft jetzt!

**DOSBox 0.74-3 ist auf `aria-wohnung` installiert** (apt). Zweck: das
Original-Spiel als visuelle/funktionale Referenz neben dem Reverse-Engineering
laufen lassen, ohne die kaputte QEMU-VGA-Emulation aus dem "Classic Games"-Crash.

### Fehlende Dateien nachgeliefert
`raw/` hatte urspr. nur `RTM.EXE` + `PCKELL.*` — **`START.EXE`, `SETUP.EXE`,
`KELLOGG.INI`, `HDPMI16.EXE` (DPMI-Host) und `DPMI16BI.OVL`** fehlten (waren
nie aus der `dos_shareware`-VM-Disk kopiert worden, nur RTM+PCKELL). Auch ein
`READ.ME` (Original-Textdatei mit Installations-/Troubleshooting-Hinweisen)
lag dort. Alle liegen jetzt in `raw/` (Quelle: `dos_shareware`-Diskimage auf
`aria-wohnung`, Pfad `GAMES/KELLOGG/` — per `qemu-nbd --read-only` gemountet,
VM dafür kurz gestoppt, danach sauber wieder disconnected. **Die VM
`dos_shareware` ist seitdem gestoppt** — bei Bedarf über's Cockpit-Panel oder
`aria-vm boot dos_shareware` wieder hochfahren).

**RTM.EXE ist die eigentliche Engine**, aber sie verweigert den Direktstart
("This loader is invoked and required by Borland tools") — man MUSS über
`START.EXE` gehen, das dann RTM.EXE korrekt aufruft.

### Der Show-Stopper: IRQ-Konflikt (aus dem Original-READ.ME!)
Mit den Original-`KELLOGG.INI`-Werten (`Adr=544 DMA=1 IRQ=7`, Soundblaster)
hängt sich das Spiel nach dem 2. Studio-Logo (Factor 5) in einer Endlosschleife
auf — kompletter schwarzer Screen, DOSBox-Prozess lebt aber (kein Crash,
Freeze). Das READ.ME beschreibt dieses EXAKTE Symptom ("Bild bleibt schwarz")
und empfiehlt IRQ 5 statt 7. Fix:
- `raw/KELLOGG.INI`: `IRQ=5` (statt 7)
- `dosbox.conf` `[sblaster]`-Sektion MUSS matchen: `irq=5` (sonst redet DOSBox's
  emulierte SB16 am falschen IRQ vorbei und das Spiel hängt trotzdem)

Mit diesem Fix läuft das Spiel sauber durch: Rauser-Advertainment-Logo →
Factor-5-Logo → Kellogg's-Logo → "Tony & Friends in Kellogg's Land"-Titelbild
→ Weltkarte (Berge/Wald/Schloss mit Drache, alle Charaktere sichtbar:
Tiger/Tony, Toucan, Frosch, Affe/Coco, Bär). Screenshots liegen unter
`/shared/uploads/aria_kellogg_*.png`.

### Funktionierende dosbox.conf
```
[sdl]
fullscreen=false
output=surface

[sblaster]
sbtype=sb16
sbbase=220
irq=5
dma=1
hdma=5

[autoexec]
mount c <pfad-zu-raw>
c:
START.EXE
```

### Screenshot-Workflow (headless, ohne echten Desktop)
`aria-wohnung` hat keinen laufenden X-Server. Screenshots via
`xvfb-run -s '-screen 0 1024x768x24' dosbox ...` + `import -window root`
(ImageMagick) im selben xvfb-run-Prozess. Tasteneingaben simulierbar mit
`xdotool key <taste>` (kein `--window`-Targeting nötig, funktioniert auch
ohne Fenstermanager in Xvfb). Audio läuft im ALSA-nosound-Modus (keine echte
Soundkarte im Container/VM) — DOSBox emuliert die SB16 trotzdem korrekt genug
fürs IRQ-Timing, es kommt nur kein tatsächlicher Ton raus.

### Steuerung (aus READ.ME, für spätere Gameplay-Tests)
Pfeil links/rechts = laufen, Leertaste/Pfeil-hoch = springen, Pfeil-runter =
ducken, ALT = Sonderfunktion/Tür öffnen, P = Pause, ESC = zurück zur Karte
(ohne Leben zu verlieren).

## PCKELL.PRE Container-Format (2026-07-22) — Kernstruktur geknackt

Ziel: die 178 in `APPEND.LST` gelisteten Dateien (32 BOB, 77 PCC, 22 MAP,
22 ARE, 19 ICO, 3 SAM, 3 TFX) sauber aus `PCKELL.PRE` (2.328.934 Bytes,
bereits ZIP-entpackt) raustrennen. Tools liegen in `tools/split_pre.py`
(aktuellster Stand, laeuft auf `aria-wohnung` mit `python3`, braucht
`raw/PCKELL.PRE` + `raw/APPEND.LST` + `raw/SRB.LST`).

### Zwei Header-Varianten je nach Dateityp

**`.BOB`-Eintraege (32x, Sprite-Rohdaten):** kein Tag-Slot, Header direkt
lueckenlos hintereinander:
```
[4-Byte-LE-Laenge][NUL-terminierter Original-DOS-Pfad
  "H:\WIWA\ENGINE\GAMEDATA\<NAME>.BOB"][<Laenge> Bytes Rohdaten]
```
Danach folgt variables Zero-Padding (~219-226 Byte beobachtet) bis zum
naechsten Header. **Vollstaendig validiert: alle 32 BOB-Eintraege exakt
gefunden, 0 Namens-Mismatches gegen APPEND.LST.** Robusteste Methode zum
Finden: direkte Byte-Suche nach `H:\WIWA\ENGINE\GAMEDATA\<erwarteter Name>`
im File (nicht raten, den vollen erwarteten Namen pro Eintrag einzeln
suchen — das ist wasserdicht).

**Alle anderen Typen (PCC/MAP/ARE/ICO/SAM/TFX, 146x):** kein eingebetteter
Pfad, dafuer ein **256-Byte-Tag-Slot** VOR dem eigentlichen Header:
```
[Tag-Slot, exakt 256 Byte lang:
   1-Byte-Namenslaenge + Dateiname (z.B. 0x0B "CHOCOS7.PCC")
   + Rest mit Speicher-Muell des Kompilier-Tools aufgefuellt]
[bei Tag-Slot-Start + 256: 4-Byte-LE-Laenge][<Laenge> Bytes Rohdaten]
```
Bestaetigt an mehreren Stellen (ANTS.PCC, CHOCOS7.PCC, und der
"Master"-Tag "A.SRB" ganz am Dateianfang vor A.BOB). **Wichtige Falle:**
beim Uebergang von der letzten `.BOB`- zur ersten `.PCC`-Datei (DOORS.BOB
-> ANTS.PCC) ueberlappt der Tag-Slot von ANTS.PCC um ~34 Byte in das, was
man anhand der BOB-Laengenangabe als "Ende von DOORS.BOB" berechnen wuerde.
Grund noch nicht restlos geklaert (vermutlich rundet der Original-Compiler
beim Sektionswechsel BOB->PCC anders). Workaround im Skript: Tag-Suche
zuerst vorwaerts ab erwarteter Position, bei Fehlschlag Fallback mit
300 Byte Sicherheitsabstand rueckwaerts.

**Kuriosum:** Der Tag fuer `.BOB`-Eintraege (nur beim allerersten,
"A.SRB" vor A.BOB) nennt nicht den eigenen Namen, sondern den
`.SRB`-Begleitnamen aus `SRB.LST` (1:1 gleiche Reihenfolge wie die
BOB-Liste in APPEND.LST). Passt zur bekannten SRB<->BOB-Kopplung
(Kollisions-Metadaten in PCKELL.DAT <-> Sprite-Pixeldaten in PCKELL.PRE).

### PCC-Bildformat (erste Erkenntnisse, noch nicht fertig decodiert)
Nutzdaten beginnen mit einem PCX-aehnlichen 16-Byte-Header:
```
Byte 0:    0x0A  (Manufacturer-Marker, wie ZSoft PCX)
Byte 1:    0x05  (Version)
Byte 2:    0x01  (Encoding = RLE)
Byte 3:    0x08  (Bits pro Pixel = 8, also 256 Farben)
Byte 4-11: bisher immer 0 gesehen (Xmin/Ymin/Reserved?)
Byte 12-13: Breite (LE16), z.B. 0x0140 = 320
Byte 14-15: Hoehe (LE16), z.B. 0x00C8 = 200
Byte 16+:  vermutlich RLE-komprimierte Pixel-Indexdaten (klassisches
           PCX-RLE: Byte mit oberen 2 Bits gesetzt (0xC0-0xFF) = Lauflaenge
           (Byte&0x3F), gefolgt vom Wert-Byte; sonst literaler Pixel)
```
Farbpalette (256x3 Byte RGB) wahrscheinlich NICHT pro Datei (dafuer waeren
die kleinen Dateien wie ANTS.PCC mit nur 900 Byte total zu klein) — vermutlich
eine globale Palette, die noch gefunden werden muss (Kandidat: irgendwo in
RTM.EXE oder als eigene Ressource). TODO fuer naechste Session.

### PCKELL.PRE Splitter — GELOEST (2026-07-22, ~02:15 Ortszeit)
Der vermeintliche "14%-Drift-Bug" war GAR KEIN Bug im Tag-Matching. Diagnose
(`tools/diag_split.py`, inzwischen geloescht, siehe Git-History falls noetig)
zeigte: jeder der 178 Tags aus `APPEND.LST` wird exakt EINDEUTIG gefunden
(genau 1 Kandidat, Gap durchgehend 0, ausser dem bekannten BOB->PCC-
Uebergang mit -34 Byte). Der Splitter war also die ganze Zeit korrekt —
er endete nur zu frueh, weil **`APPEND.LST` gar nicht alle Eintraege in
`PCKELL.PRE` auflistet.**

Direkt im Anschluss an den letzten `APPEND.LST`-Eintrag (`TITEL2.SAM`,
endet bei `0x1e9aac`) folgen, im EXAKT GLEICHEN Tag-Slot-Format, noch
**3 weitere, nicht gelistete Eintraege**:
```
DPMI16BI.OVL  65312 Byte
RTM.EXE      108686 Byte
START.EXE    148480 Byte
```
Der letzte davon (`START.EXE`) endet bei `0x238966` — **exakt** die
Dateigroesse von `PCKELL.PRE`. Damit ist das Container-Format zu 100%
verifiziert, kein einziges Byte bleibt unerklaert. Macht inhaltlich auch
Sinn: `PCKELL.PRE` ist offenbar ein self-contained Redistributable-Paket,
das die komplette DOS-Extender-Runtime (DPMI-Server + Runtime-EXE +
Launcher) gleich mitbuendelt — nicht nur Spiel-Assets.

**Extra-Validierung:** die 3 extrahierten System-Dateien sind
byte-identisch (`cmp`) zu den Einzeldateien, die schon lose in `raw/`
liegen (aus der `dos_shareware`-VM kopiert) — zweite unabhaengige
Bestaetigung, dass die Extraktion korrekt ist.

**`tools/split_pre.py` (finale v7) extrahiert jetzt alle 181 Dateien
fehlerfrei nach `extracted_pre/`:**
```
32 BOB, 77 PCC, 22 MAP, 22 ARE, 19 ICO, 3 SAM, 3 TFX, 1 OVL, 2 EXE
```
Alte Splitter-Zwischenversionen (v1-v6, Diagnose-Scripts) sind auf
`aria-wohnung` (`/home/aria/kellogg_remake/tools/`) aufgeraeumt — nur
noch `split_pre.py` (v7, final) liegt dort, identisch zur Kopie hier im
Projekt unter `tools/split_pre.py`. `extracted_pre/` (2,6 MB, 181 Dateien)
liegt jetzt auch hier im Projekt, nicht nur auf `aria-wohnung`.

### PCC-Header — ergaenzender Fund
Bei `MENU.PCC` sind Byte 4-11 NICHT alle Null (anders als bei `ANTS.PCC`
vermutet) — sie enthalten `Xmax`/`Ymax` (0x013f=319, 0x00c7=199), passend
zum klassischen PCX-Header-Layout `Xmin(2) Ymin(2) Xmax(2) Ymax(2)` bei
Offset 4. Fuer ein 320x200-Bild ab (0,0) macht Xmax=319/Ymax=199 Sinn.
Bei `ANTS.PCC` (kleines 900-Byte-Sprite-Preview-Bild) stehen dort
durchgehend Nullen — vermutlich weil die Original-Autoren dieses Feld
bei kleineren generierten Bildern nicht befuellt haben. Fuer den
PCC-Decoder erstmal ignorierbar, Breite/Hoehe kommt zuverlaessig aus
Offset 12-15.

### Naechste Schritte (Prioritaet) — ALT, siehe unten "PCC-Format GELOEST" fuer aktuellen Stand
~~1. Ein PCC-Bild vollstaendig decodieren~~ ERLEDIGT (siehe unten).
2. BOB/SRB-Sprite-Format verstehen (PCKELL.DAT-Offset-Tabelle mit den
   32 SRB-Namen abgleichen, dann Frame-Struktur pro Sprite ableiten).
3. MAP/ARE-Levelformat reversen (kleinste Dateien zuerst, z.B. ein
   simples frühes Level, z.B. `W1L0.MAP`/`W1L0.ARE`).
4. Erst danach: Python-Projektstruktur aufsetzen (pygame), Asset-Loader
   fuer BOB/PCC/MAP schreiben, Kernschleife (Physik/Kollision) gegen
   DOSBox-Referenzverhalten abgleichen.

## PCC-Bildformat — VOLLSTAENDIG GELOEST (2026-07-22, ~02:20 Ortszeit)

**Format zu 100% verstanden und visuell verifiziert.** PCC = klassisches
PCX v5, 256-Farben, mit **eingebetteter Palette PRO DATEI** (kein globales
Palette-Rätsel, wie in der vorherigen Notiz befürchtet):

```
Byte 0-15:  PCX-Header (Manufacturer=0x0A, Version=5, Encoding=1/RLE,
            BPP=8, Xmin/Ymin/Xmax/Ymax bei Offset 4-11,
            Width(LE16)/Height(LE16) bei Offset 12-15 — Width/Height sind
            DIREKTE Pixelmaße, nicht Xmax-Xmin+1, auch wenn beides meist
            gleich rauskommt bei 320x200-Vollbildern)
Byte 16 .. (len-769): SCANLINE-weise RLE-komprimierte Pixel-Indexdaten.
            RLE-Tupel: Byte mit oberen 2 Bits gesetzt (0xC0-0xFF) =
            Lauflaenge (Byte&0x3F), gefolgt von 1 Wert-Byte. Sonst
            literaler Pixel. WICHTIG: pro Scanline wird bis exakt
            `width` Pixel dekodiert, ueberschuessige Pixel eines Runs
            am Zeilenende werden verworfen (klassisches PCX-Verhalten,
            NICHT als ein durchgehender Bytestrom decodieren — das
            fuehrt zu Off-by-Overshoot-Fehlern und Fehlausrichtung
            gegenueber der eingebetteten Palette am Dateiende).
Letzte 769 Byte: `0x0C`-Marker + 768 Byte (256 x RGB) Palette — die
            klassische PCX-v5-256-Farben-Erweiterung. JEDE PCC-Datei
            traegt ihre EIGENE Palette mit sich (keine globale Palette
            aus RTM.EXE noetig, wie in der vorigen Session vermutet).
```

**Decoder fertig:** `tools/pcc_to_png.py` (auf `aria-wohnung` unter
`/home/aria/kellogg_remake/tools/pcc_to_png.py`, identische Kopie hier
im Projekt unter `tools/pcc_to_png.py`). Aufruf:
`python3 tools/pcc_to_png.py extracted_pre/<NAME>.PCC out.png`
(braucht ImageMagick `convert` auf dem Zielsystem — ist auf `aria-wohnung`
vorhanden).

**Visuelle Verifikation — 100% korrekt:**
- `KARTE.PCC` → exakte Weltkarte (Berge/Schloss/Drache, Tony/Tiger,
  Coco/Affe, Frosch, Fluss, Bäume) — Pixel-für-Pixel wiedererkennbar
  gegen den DOSBox-Screenshot `aria_kellogg_worldmap.png` von vorher.
- `KELLOGGS.PCC` → glasklares "Kellogg's präsentiert"-Logo mit
  korrektem geschwungenem Markenschriftzug, scharfe Kanten, kein
  Rauschen/Fehler in der Dekodierung.
- `MENU.PCC` → sauberer Menü-Rahmen (blauer Hintergrund, rot-goldene
  Box) — vermutlich Passwort-/Level-Auswahl-UI.
Alle Test-PNGs liegen unter `/shared/uploads/aria_pcc_*.png` zur
Ansicht, dauerhafte Kopien aller **77 von 77 PCC-Dateien fehlerfrei
batch-decodiert** liegen unter `png_out/` in diesem Projektordner
(416 KB total, 77 Dateien — vollstaendige Validierung, kein einziger
Absturz oder Format-Ausreisser).

Einzige kleine Restfrage (kein Blocker): bei manchen Dateien bleiben
1-30 Byte am Ende des Pixel-Datenblocks vor der Palette ungenutzt
(vermutlich Padding/Rundung des Original-Encoders) — beeinflusst das
Bildergebnis nicht sichtbar, wird ignoriert.

## BOB-Sprite-Format — erste Erkenntnisse (2026-07-22, ~02:30 Ortszeit, IN ARBEIT)

**Kein PCX-Verwandter.** BOB-Dateien starten NICHT mit `0x0A`-Manufacturer-
Byte, kein erkennbarer Klartext-Header wie bei PCC. Vermutlich beginnt die
(vermutlich RLE-komprimierte) Pixel-Nutzdaten direkt ab Byte 0.

**Wichtiger Fund:** Die 32 BOB-Namen sind NICHT alle "richtige" Objektnamen
— 14 davon sind Einzelbuchstaben (`A.BOB` .. `O.BOB`, ohne `M`) plus
`BLUME.BOB`/`WOLKE.BOB` (Blume/Wolke, Deko-Objekte), dann die Marken-Packs
(`VITAMIN`/`COCOPOPS`/`SMACKIES`/`FROSTIES`/`LOOPS`), dann Charaktere
(`TONY`/`SMACKS`/`TOUCAN`/`COCO`), dann Level-Objekte (`PLATFW1`=Plattform,
`KEYS`, `GAMEBAR`=HUD-Leiste, `KROKO`/`BOSSNAKE`/`DRAGON`=Gegner, `DOORS`).
Die Buchstaben-Sprites (A-O) sind vermutlich Sammel-Buchstaben-Items
(Bonus-Mechanik: Buchstaben im Level einsammeln) — passend zur Groessen-
Gruppierung (viele davon fast gleich gross: B/E/N/O=1295 Byte, D/H/I=4406,
J/K=2332 — deutet auf fixe Sprite-Dimensionen pro Buchstaben-"Familie",
vermutlich Schriftart-aehnliche Boxen).

**Byte-Identitaet als Format-Hinweis:** `FROSTIES.BOB`, `COCOPOPS.BOB`,
`SMACKIES.BOB` (alle 3323 Byte gross) haben BYTE-FUER-BYTE identische
ersten 16 Byte (`16 b4 2c 76 82 b4 3a 9f 06 88 82 cf 16 e8 03 2d`) und
divergieren erst ab ca. Offset 0x20. `LOOPS.BOB` (ebenfalls 3323 Byte)
zeigt eine um 4 Byte verschobene, aber erkennbar verwandte Bytefolge.
**Interpretation:** das ist vermutlich KEIN Klartext-Header, sondern
bereits RLE-komprimierte Pixeldaten — die vier Sprites sind alle
"Cerealien-Packung"-Objekte mit identischer Kastenform/Silhouette
(gleiche Pixel-Auesserform => gleiche RLE-Runs am Anfang), die sich nur
im aufgedruckten Marken-Logo unterscheiden (Divergenz kommt spaeter).
Das wuerde erklaeren warum 4 komplett verschiedene Marken exakt gleich
grosse Dateien mit ident. Praefix erzeugen: gleiche Box-Geometrie,
gleiches Kompressionsschema, nur Content-Unterschied in der Bildmitte.

**Hypothese fuer naechste Session:** BOB = aehnliches RLE-Schema wie PCC
(Byte mit oberen 2 Bits gesetzt = Lauflaenge+Wert), aber OHNE PCX-Header
und OHNE eingebettete Palette — Breite/Hoehe muessen aus `PCKELL.DAT`
kommen (die SRB-Offset-Tabelle, noch nicht durchdrungen) oder aus einer
festen Tabelle in `RTM.EXE`. Naechste konkrete Schritte:
1. `PCKELL.DAT` Offset-Tabelle vs. `SRB.LST`-Namen abgleichen (32 Eintraege,
   1:1 mit den 32 BOB-Dateien) — dort vermutlich Breite/Hoehe/Frame-Anzahl
   pro Sprite zu finden.
2. Testweise RLE-Decode von `A.BOB` (kleinstes/einfachstes Beispiel aus der
   Buchstaben-Gruppe) mit angenommener kleiner Breite/Hoehe (z.B. 20x20 bis
   40x40 fuer ein UI-Buchstaben-Icon) durchprobieren, gegen erwartete
   Pixelzahl abgleichen (aehnlich wie beim PCC-Ansatz, der am Ende
   erfolgreich war: Header-Annahmen iterativ gegen Dateigroesse pruefen).
3. Falls das nicht schnell konvergiert: `TONY.BOB` (Hauptfigur, 47726 Byte,
   groesste Datei nach COCO) ist wahrscheinlich der wichtigste Fund fuer
   den Port und rechtfertigt tiefere Analyse zuerst.

## Naechste Schritte (Prioritaet, aktueller Stand)
1. **BOB/SRB-Sprite-Format weiter reversen** — siehe Hypothesen direkt
   oben. Naechster Schritt: `PCKELL.DAT`-Offset-Tabelle mit `SRB.LST`
   abgleichen, danach `A.BOB`-Testdecoding.
2. MAP/ARE-Levelformat reversen (kleinste Dateien zuerst, z.B. ein
   simples frühes Level, z.B. `W1L0.MAP`/`W1L0.ARE` falls vorhanden —
   sonst kleinste Datei nach Groesse waehlen).
3. Erst danach: Python-Projektstruktur aufsetzen (pygame), Asset-Loader
   fuer BOB/PCC/MAP schreiben (PCC-Loader ist im Grunde fertig, nur
   noch von PPM/ImageMagick-Zwischenschritt auf direktes PNG-Schreiben
   in Python umstellen, z.B. mit `Pillow` — aktuell haengt der Decoder
   noch am System-`convert`-Tool, das fuer den finalen Python-Port
   NICHT die Zielarchitektur sein soll).

### Hinweis fuer Fortsetzung nach Neustart/Session-Wechsel
Dieses Projekt laeuft bewusst autonom weiter (Stefan-Wunsch, 2026-07-22).
Fortschritt wird nach JEDEM Meilenstein hier in `NOTES.md` gesichert.
Zusaetzlich liegt ein gepinnter Kurz-Status im Memory (Suchbegriff
"Kellogg's Remake") als Fallback, falls diese Datei mal nicht griffbereit
sein sollte. Bei Session-Neustart: einfach hier weiterlesen ab
"Naechste Schritte" oben, keine Rueckfrage bei Stefan noetig.

Ein `trigger_timer` ("kellogg-remake-continue") ist als Selbst-Weck-Kette
aktiv: feuert stuendlich, arbeitet den naechsten offenen Punkt ab, speichert
hier, legt danach den naechsten Timer an — laeuft ohne Rueckfrage weiter.

## PCC-Decoder-Bugfix + Git-Repo (2026-07-22, ~09:20 Ortszeit)

Stefan hat zurecht bemaengelt, dass die PCC-Bilder verzerrt/verrutscht
aussehen (z.B. Smacks-Frosch spiegelverkehrt, Kellogg's-Logo mit Fehlstelle).
Ergebnis der Untersuchung:

**GEFUNDEN UND GEFIXT — Width/Height-Bug:** Der Decoder las Breite/Hoehe
bisher aus Offset 12-15 (siehe alte Notiz oben). Das ist FALSCH — dieses
Feld ist bei allen Dateien ein Konstant-/Platzhalterwert (vermutlich
DPI-Reserved-Feld wie im echten 128-Byte-PCX-Header), der bei
Vollbild-Screens (320x200) zufaellig mit der echten Groesse
uebereinstimmt, bei kleineren Sprites/Logos aber komplett falsch ist.
**Richtig:** Breite/Hoehe muessen aus `Xmax-Xmin+1` / `Ymax-Ymin+1`
(Offset 4-11) berechnet werden. Beweis: `FACTOR5.PCC` konsumiert mit der
alten (falschen) Hoehe 200 nicht alle Bytes sauber, mit der echten Hoehe
199 (aus Ymax=198) landet der Byte-Konsum exakt bei 100% (51609/51609).
Betroffen/jetzt gefixt: `RAUSER1.PCC` (182x46 statt fälschlich 320x200),
`RAUSER2.PCC` (228x21), `RAUSER3.PCC` (16x55), `FAC0-3.PCC` (16x16),
`FACTOR5.PCC` (320x199). Fix ist in `tools/pcc_to_png.py` eingebaut,
alle 77 PNGs unter `png_out/` mit dem Fix neu generiert.

**Rauser-Intro: JA, schon extrahiert.** `RAUSER1/2/3.PCC` sind Frames
eines scrollenden Text-Logos (vermutlich "RAUSER ADVERTAINMENT PRESENTS"),
mit dem Fix jetzt lesbar (zeigt z.B. "...USER TRAI..." als Ausschnitt).
Volles Logo muesste sich aus allen 3 Frames zusammensetzen lassen (noch
nicht gemacht).

**FACTOR5.PCC "Geister"-Doppellogo: vermutlich KEIN Bug**, sondern ein
Reflexions-/Schatten-Designelement — Byte-Konsum ist exakt 100%, also
decodiert der Inhalt komplett korrekt, das Doppelbild ist einfach das,
was in der Datei steht.

**OFFEN — KELLOGGS.PCC/KARTE.PCC-Notch-Artefakt:** Der Width/Height-Fix
hat den harmlosen 320x200-Fall nicht veraendert (Xmax/Ymax ergeben dort
zufaellig dieselbe Groesse wie vorher). Das Notch-Artefakt (rot/gelber
Fleck rechts neben "Kellogg's"-Schriftzug, passt nicht zum
DOSBox-Referenz-Screenshot) bleibt bestehen. Ausgeschlossen als Ursache
(empirisch getestet, nicht nur vermutet):
- Horizontales Rollen/Scrollen des ganzen Bilds (18 Shift-Kandidaten
  durchprobiert) — Artefakt bleibt IMMER an derselben Stelle relativ zum
  Bildinhalt (Box/Text), nicht zur Leinwand. Kein Verschiebe-/Wrap-Bug.
- Zeilenweises Verwerfen von RLE-Overshoot am Zeilenende — zeilenbasierte
  und durchgehende (row-boundary-freie) Decodierung liefern fuer
  KELLOGGS.PCC byte-identische Ergebnisse (kein Overshoot tritt je auf).
Interessant: `MENU.PCC` nutzt vermutlich denselben Box-Rahmen (leere
Variante) und rendert jetzt SAUBER ohne Notch — der Fehler ist also
dateispezifisch, nicht im Rahmen-Design selbst. Naechste Hypothese:
Palette-Fehlzuordnung fuer einzelne Indizes ODER RLE-Ambiguitaet bei
literalen Pixelwerten >= 0xC0 (werden durch `(b&0xC0)==0xC0` evtl.
faelschlich als Lauflaengen-Token statt literaler Indexwert gelesen) —
noch zu verifizieren durch gezielten Test mit einem Decoder, der beide
Interpretationen an der vermuteten Fehlstelle durchspielt.

Ebenfalls noch offen (niedrige Prioritaet): `TONY.PCC`/`SMACKS.PCC`
liefern mit dem Xmax/Ymax-Fix nur 1x1 Pixel (degenerated, Xmax=Ymax=0
im Header) — vermutlich sind das keine "echten" Vollbilder, sondern
Platzhalter/ungenutzte Preview-Slots; die eigentlichen Charakter-Sprites
stecken hoechstwahrscheinlich in den `.BOB`-Dateien (`TONY.BOB`,
`SMACKS.BOB` etc.), nicht in den gleichnamigen `.PCC`-Dateien.

**Git-Repo eingerichtet:** Auf Stefans Wunsch liegt der Projektstand jetzt
unter `https://git.hacker-net.de/Aria-Software/tony-remake`. Bewusst NICHT
mit eingecheckt: `raw/` (Original-Spieldateien: PCKELL.DAT/.PRE/.SET,
RTM.EXE, START.EXE etc. — das ist buchstaeblich das Original-Spiel) und
`extracted_pre/` (die daraus entpackten 181 Rohdateien — noch
Original-Asset-Material, nur unverpackt). Mit eingecheckt: `NOTES.md`,
`tools/` (unser Code: `split_pre.py`, `pcc_to_png.py`), `dosbox/`
(Test-Konfiguration), `png_out/` (unsere konvertierten PNG-Ergebnisse,
408 KB, reine Arbeitsergebnisse kein Originalmaterial).

## KELLOGGS.PCC/KARTE.PCC-Notch-Artefakt — GELOEST (2026-07-22, ~09:30 Ortszeit)

**Die Notiz oben ("Ausgeschlossen als Ursache ... Zeilenweises Verwerfen von
RLE-Overshoot ... liefern byte-identische Ergebnisse") war FALSCH.** Das war
ein Messfehler einer frueheren Session: der "kontinuierliche" Testdecoder
hat versehentlich weiterhin die width/height aus Offset 12-15 gelesen (dem
VERWORFENEN Bugfix-1-Feld) statt aus Xmax/Ymax — dadurch kam bei den beiden
320x200-Vollbildern zufaellig das gleiche (korrekte) Ergebnis raus wie beim
zeilenbasierten Decoder, und der Test schien zu bestaetigen, dass beide
Methoden aequivalent sind. Sind sie nicht.

**Neu verifiziert mit einem sauberen Vergleichstest** (`Buffer.compare` in
Node.js, unabhaengige Re-Implementierung): zeilenbasiertes Decoding
(Row-Reset, discard Overflow am Zeilenende) und durchgehendes Decoding
(RLE-Runs duerfen ueber Zeilengrenzen hinweglaufen) liefern **NICHT**
identische Ergebnisse — 216 von 64000 Pixeln unterscheiden sich bei
KARTE.PCC, 293 von 64000 bei KELLOGGS.PCC. Klingt nach wenig (<0.5%), reicht
aber, um ganze Bildbereiche sichtbar zu verschieben, weil ab dem ersten
"verlorenen" Ueberlauf-Pixel alle nachfolgenden Zeilen einen Pixel weiter
"nachruecken".

**Beweis per Ground-Truth-Vergleich:** DOSBox-Screenshot
`aria_kellogg_worldmap.png` (1024x768 mit schwarzen Balken) exakt auf den
reinen Spielbereich zugeschnitten (`convert -fuzz 5% -trim` → 640x400,
= 2x 320x200) und auf 320x200 runterskaliert
(`/shared/uploads/aria_karte_reference_320.png`). Nebeneinander-Vergleich
mit dem durchgehend (ohne Row-Reset) decodierten `KARTE.PCC`
(`/shared/uploads/aria_karte_compare2.png`): **pixel-identisch** — Berge,
Schloss, Drache, Tiger, Affe/Coco, Frosch, Teich, Haus, Voegel-Ecke, alles
exakt an der richtigen Stelle. Das Row-Reset-Verhalten war der einzige
Bug; es gibt kein horizontales Rollen, keine Palette-Fehlzuordnung, keine
RLE-Ambiguitaet bei Werten >=0xC0.

**Fix:** `tools/pcc_to_png.py` decodiert jetzt global `width*height` Pixel
aus dem RLE-Strom OHNE pro Zeile abzuschneiden (kein Row-Reset mehr). Alle
77 PNGs in `png_out/` wurden mit diesem finalen Decoder neu erzeugt
(diesmal wirklich verifiziert, nicht nur "sieht plausibel aus"). Kleine
Sprites/Logos waren von diesem Bug kaum betroffen (selten ein Run, der eine
Zeilengrenze ueberschreitet) — deshalb fiel es dort nie auf, nur bei den
zwei grossen 320x200-Vollbildern.

**Rauser-Intro bestaetigt (Frage von Stefan):** `RAUSER1/2/3.PCC` sind schon
laenger extrahiert und liegen jetzt mit dem finalen Decoder sauber decodiert
in `png_out/`. Es ist ein Text-Logo "RAUSER" + "ADVERTAINMENT" (Studio-Card),
als 3 Bild-Frames — vermutlich fuer einen Scroll-/Fade-Effekt, den die
Original-Engine (RTM.EXE) zur Laufzeit zusammensetzt, KEIN Video/keine
Animation-Datei. Fuers Remake heisst das: die 3 Frames sind da, die
Overlay-/Scroll-Logik muss im Python-Port nachgebaut werden (vermutlich
simpel: Frame croppen + ueber Zeit einblenden, sobald wir wissen wie die
Original-Sequenz zeitlich ablaeuft — dafuer ggf. DOSBox-Referenzvideo/
Screenshots in der Sequenz aufnehmen, spaeterer Schritt).

## BOB-Sprite-Format — Exploration laeuft, noch nicht geloest (Stand 09:30)

Auf `aria-wohnung` (`/home/aria/kellogg_remake/tools/`) lief parallel schon
einiges an Exploration fuer das naechste Format (BOB-Sprites): Brute-Force-
Breitensuche (`bob_width_search.py`), Header-Diff zwischen aehnlich grossen
Dateien (`bob_header_diff.py`, `bob_header_search.py`), Histogramm-Analyse
(`bob_histogram.py`), Sichtgitter-Rendering mit mehreren Breiten-Kandidaten
(`bob_render_grid.py`/`bob_render_grid2.py`), sowie erste Versuche die
`PCKELL.DAT`-Offset-Tabelle zu parsen (`dat_analyze.py`/`dat_analyze2.py`,
`dat_table2.py`, `dat_u16.py`). **Kein Ergebnis/Durchbruch bisher** — alles
noch offene Exploration, keiner der Scripts hat schon eine verifizierte
Loesung. Zur Sicherheit (Stefans Wunsch: nichts soll bei einem VM-Neustart
verloren gehen) sind alle diese Scripts jetzt zusaetzlich hier im
Projekt gesichert unter `tools/wip_bob_sprite_research/` (noch nicht
aufgeraeumt/nicht final, bewusst als "work in progress" separiert von den
fertigen Tools `split_pre.py`/`pcc_to_png.py`).

## Naechste Schritte (Prioritaet, Stand 09:30)
1. **BOB/SRB-Sprite-Format weiter reversen** — siehe `tools/wip_bob_sprite_research/`
   fuer den aktuellen (unfertigen) Exploration-Stand. Naechster konkreter
   Schritt: `PCKELL.DAT`-Offset-Tabelle sauber mit den 32 `SRB.LST`-Namen
   abgleichen, danach `A.BOB` (kleinstes Beispiel) testdecodieren.
2. Rauser-Intro-Sequenz (3 Frames) zu einer zusammengesetzten Vorschau
   rendern/dokumentieren, sobald Zeit ist — niedrige Prioritaet, Assets sind
   schon da.
3. MAP/ARE-Levelformat reversen.
4. Python/pygame-Projektstruktur aufsetzen (PCC-Loader ist fertig, muss nur
   noch von PPM/ImageMagick-Zwischenschritt auf direktes Pillow-basiertes
   PNG/Surface-Schreiben umgestellt werden fuer den finalen Port).