Firmware Structure Analysis

[thephenakist]

Using the script below, I plotted the data from one of my firmwares onto a graph for analysis. What I discovered was 12 discrete chunks of what visually looks like sound data, separated by sharp triangular transitions which I'm guessing would be tones to indicate things like changing light colors, or progressing the projector to the next slide. I also noticed that the majority of the firmware is unused (FF FF FF FF's for at least half of the file) with the exception of 16 bytes starting at location 0x0FFF80 (108448). Search for 04 F1 in your firmware, and follow it down 8556 to the 4E 0E that's just before all of the FF's. Those 8556 bytes are identical in each of the firmwares I've inspected. My hypothesis is that those 8556 bytes contain a digital signal processor (DSP) which can convert the waveforms back into actual sound files, which then get played on the speaker.

So the structure of the firmware seems to be:
A) Chapter Map
B) Chapter
C) Transition
D) Chapter
E) Transtion
... (repeat for number of chapters in cassette) ...
F) 8556 bytes of code, common across all chip dumps
G) Empty space (FF FF FF FF...)
H) 16 byte chip ID and/or key (or possibly the chapter marks)
I) FF's to end of file

Script:

import numpy as np, matplotlib.pyplot as plt
d = np.fromfile('firmware.bin', dtype=np.uint8)
plt.plot(d)
plt.show()

[mtkimmins]

This is a great breakdown! Appreciate the identification of the last similar chunk before the sea of "FF" bytes.

[mtkimmins]

I have verified that this is terminal part of the data does indeed match the last 8556 bytes prior to the empty residue of the chip.

[jayseet]

Has anyone been able to dump the data from the memory chip in the dream machine itself yet?

[mtkimmins]

Talking with Jon (GainSec), I know he was sniffing the main chip in the projector as it ran a while ago. Here is his blog post on the subject.

[jayseet]

Thanks. I'm thinking of picking up a second projector or finding a used one and a test clip to get a dump from the P25D40SM in the projector itself to see if that sheds any light. I've enjoyed reading your progress and gleaning what you've learned along the way.

[j-te]

I've come to the conclusion all of the files in the structure are compressed using the same algorithm due to a similar signature. We need the huff table key from the projector chip. Attached is my READ of Big Shark Little Shark Goes to School. XGecu T48 was used with a clip (no soldering required).

BSLSGTS_P25D80SH_SOP8.zip

[mtkimmins]

Looks similar to my copies (I have not purified these dumps for this book yet, so I would trust yours over mine for this). Another confirmation that we are getting the right data.
That'll be my next target, the table key.

[John-K]

I've published my documentation of the format, as used by my dreamprojector tool.

Warning: the duration and starting offset of the LED lightshow data needs to be confirmed.

It's worth noting that the first two "Pages" are the same between every cartridge and are not played by the device. Also, the effects do not appear to be used and often are made up of a few sounds and then the numbers 0-9 spoken.

[John-K]

I replied to the wrong thread below. I've implemented extract and build commands now in dreamsmith

[thephenakist]

That can be the new thread for testing build/extract. Regarding pages 1 & 2, as well as the last 12 pages - I've tested several carts and they're all nearly identical. The last 9 are numbers 0-9 as you've said, but just prior to those are a high-pitched beep and then a letter (it's been B for all my carts, but it's possible this could vary). I also seem to think the beep is distinct, so I want to try extracting that and slowing it down. These are likely for a different product and are kept in for compatibility.

[thephenakist]

This would also explain why the last 8556 bytes before the null data are identical across all carts.

[John-K]

I just added a digest command and measured a bunch of different cartridges and the first two "pages" and all "effects" are identical.

There are likely outliers though

[John-K]

Just pushed another change, now the digest command will print a warning if any of the common audio clips & effects don't match the well known values.

All dumps I have pass this check.

[John-K]

Not difficult at all, I’ll add a command to dreamsmith for it

…

On Mon, Feb 16, 2026 at 5:59 PM PHΞN∆KIST ***@***.***> wrote: Your dreamprojector is *awesome*! It worked perfectly for the binary dumps I've been collecting. This is the validation I needed before diving in and making dumps of all my carts. I wanted to be sure that the bins contained all the necessary information, and now with your tools I'm confident they do! Out of curiosity - how difficult would it be to implement the ability to "export" the audio? (i.e. direct output to aiff/wav instead of sound device) — Reply to this email directly, view it on GitHub <#5 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADCSVRK7Q5ST44PVPDOFJ34MJDUPAVCNFSM6AAAAACLB3KCD2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKOBSHA3TCOI> . You are receiving this because you commented.Message ID: ***@***.***>

[John-K]

I've added extract and build commands to dreamsmith so you should be able to extract, modify and then re-assemble the image, or just make your own from scratch.

I haven't put any work into making the LED editing friendly yet - we still need to figure out the timings better there first anyway.

/cc @mtkimmins

[thephenakist]

Sweet, you've hopefully just unlocked the ability to make custom carts. If I get some spare time this week I'll test out the LED timing/offset. I'll also give extract / build a fair shake and try flashing the result of build back to a chip to see if custom carts will work.