22 August 2026

I am really loving how the shield makes flashing so much more reliable. I am so glad I made this thing!

Initial Review

Fresh eyes this morning (was up until ~0300 this morning trying to figure it out yesterday).

What I Notice About ratadon2.bin

• There are light tables in Segment 2 Regions (there should be no light tables, just audio)
• Segment 2.1 is truncated much too short

Next Steps

• Make an ImHex Pattern so I can inspect a cartridge file very quickly.
• Use the sine-test.bin as the springboard for the custom audio as we know this works.
• Optimize the sine-test.bin by testing if I can delete Segment 2 altogether with pointer redirects. Then also incorporate the blanking of the first four bytes. If it runs without changes to the audio payloads or light tables. To make it easier, I can search for the hex pattern 00 80 3E which is the end of each header.

Segment 2 Deletion and Redirect

• Deleted Segment 2
• Moved Region 1 to the end of Segment 1
• Redirected Segment 2 pointers and Region 1 to immediately after Segment 1 @ 0x6C
• Re-extend the file to 1MiB
• Update all pointers in Segment 1
  • record all new pointers by locating each Region by searching for 00 80 3E (success, only 12 found)
• Validate in dreamprojector
  • 14 pages populated with the test beep -- successful
• Flash to cartridge
• Redump newly-flashed cartridge
• Diff redump and payload to validate flash
  • no changes -- successful
• Play on projector
  • Test beep for each frame, no errors or crashes -- successful
  • CONCLUSION = we can delete Segment 2 entirely without error

New Pointers for Segment 3 in mvp-s2-delete-redirect.bin

Region (#)	New Initial Address (Hex)	Little Endian Pointer (Hex)
1	0x6C	6C 00 00 00
2	0x848	48 08 00 00
3	0x1024	24 10 00 00
4	0x1800	00 18 00 00
5	0x1FDC	DC 1F 00 00
6	0x27B8	B8 27 00 00
7	0x2F94	94 2F 00 00
8	0x3770	70 37 00 00
9	0x3F4C	4C 3F 00 00
10	0x4728	28 47 00 00
11	0x4F04	04 4F 00 00
12	0x56E0	E0 56 00 00

*Luckily, I can use 00 80 3E to search for each Region as opposed to waiting for an ImHex pattern to be built

Magic Number Deletion

• Copy mvp-s2-delete-redirect.bin
• Change 0x0-0x3 = 00 00 00 00
• Flash to cartridge
• Play on projector
  • Played with test beeps each frame, no errors or crashes
  • CONCLUSION = the magic numbers of the MVP can be deleted; front-runner template is mvps2mb.bin

Ratadon 3 Re-attempt

• Copy mvps2mb.bin
• Collect .a18 audio files for all 12 frames
• Delete Region 1 onward
• Append .a18s (x12)
• Validate headers (x12)
• Append blank light table after each .a18 (04 F0 00 04 F1 00)
• [] Search 00 80 3E to find Regions
• Note initial addresses per Region
• Update Segment 1 pointers
• Follow and validate each Segment 1 pointer
• Fill to 1MiB
• Fragment using dreamsmith extract
  • expect to fragment with no errors
  • no errors when ran; only produced an id.bin; possibly due to redaction of magic numbers
• Validate using dreamprojector
  • expect to play individual audios
  • "book with 0 pages and 0 effects"; did not play anything due to loop index error; possibly due to redaction of magic numbers setting the iterable to 0
• Flash to cartridge
• Play on projector
  • Exact same errors and crash as yesterday
  • CONCLUSION = there is something directly in the custom payload that the LTSDM does not like; This internal payload error is not an early light table declaration;
  • I did not redump the cartridge immediately after flashing it. Let us see what it looks like after 1 play;
    • hypothesis 1: the projector changed the data;
    • hypothesis 2: the flasher corrupted the flash payload, and is masking the "redumps" as a saved copy of whatever it just flashed;
    • hypothesis 3: the payloads themselves are filled with data the projector does not tolerate.
    • RESULT OF REDUMP = no diff in ImHex between REDUMP_ratadon3.bin and ratadon3.bin
    • CONCLUSIONS = the flasher outputs are true, nothing is cached, corrupted, or changed; Its the payload itself.

Systematic Hex Editing of ratadon3.bin

Region (#)	First-Byte Address (Hex)	Little Endian Address (Hex)	Header's Declared Length (Hex)	Payload Length (Hex)	Last Light Table Intact (Y/N)	Append Blank Light Table (Y/N)
1	0x6C	6C 00 00 00	8560	$8566-6=$ 8560	Y	Y
2	0x21E8	E8 21 00 00	19400	$19406-6=$ 19400	Y	Y
3	0x6DBC	BC 6D 00 00	23480	$23486-6=$ 23480	Y	Y
4	0xC980	80 C9 00 00	28720	$28726-6=$ 28720	Y	Y
5	0x139BC	BC 39 01 00	48840	$48846-6=$ 48840	Y	Y
6	0x1F890	90 F8 01 00	42160	$42166-6=$ 42160	Y	Y
7	0x29D4C	4C 9D 02 00	37680	$37686-6=$ 37680	Y	Y
8	0x33088	88 30 03 00	32800	$32806-6=$ 32800	Y	Y
9	0x3B0B4	B4 B0 03 00	32800	$32806-6=$ 32800	Y	Y
10	0x430E0	E0 30 04 00	37280	$37286-6=$ 37280	Y	Y
11	0x4C28C	8C C2 04 00	23840	$23846-6=$ 23840	Y	Y
12	0x51FB8	B8 1F 05 00	26080	$26086-6=$ 26080	Y	Y

*I can be assured that dreamsmith is converting 16kHz 16-bit signed .WAV files to .a18 accurately. No need to validate headers.

Next Steps

• Test just 1 Region of custom data, while retaining the test beeps for the rest; iterate through them all to check if one completes on its own.
• Read into what the .a18 codec bytes represent (I believe "differences" -- perhaps there are bytes that ask for a difference out of range)
• Experiment with filling a Region with each permutation of differences to detect what crashes the projector; titrate to what is accepted.
• Frame 1 = low differences -- frame 12 = high differences; note the slide it crashes on; CAUTION = the assumption here is that the projector reads the data as it comes, and not all at once; Another explanation could be that the projector pre-loads all the data and crashes if even a single intolerable data mutation is loaded (this way, I cannot know what crashes the projector through a titration; However, I feel like I have seen a spectrum of crashes that suggest the projector crashes only when it reaches the intolerable data serially, not at the very beginning).

---

⟵ Older	Table of Contents	Newer ⟶