22 May 2026

Reflecting on Region 1 “Fix”

I will have to read more into what John-K had discovered about how the lights data are processed. I was thinking, why would the custom audio play until the lights turned on? Why could the projector know when to start playing the lights, but failed to do so at runtime? The error must lie in the values of the lights, but the structure may be retained, lending to a correct timing calculation, but incompatible light values. But is not the lights just RBG set by hex between 0 and 255? I can technically get any colour and shade I want. I’ll have to review John-K’s format.md.

Another aspect of the light seizure and crash: if it still crashes after fixing the pointer, then I am running into multiple errors, compounding into a confounded result. What errors I observe when I run a new flash is the result of multiple errors interacting. I suppose I could delineate that the wrong pointer seemed to cause the initial light seizure (both the projection light and the back light — which makes sense … except for the projection light control, that is peculiar), but some other error is causing the acute crash and reboot of the whole projector. Because the last couple runs had a delay in crashing, I think I may assume that the delay is due to a correct reading of light runtime as both instances waited for -- what I assume to be -- the initial preamble length in Region 1 before encountering the critical error. I see John-K has done this themselves in format.md, but let us peer-review. Let us see if the crash timing correlates with this assumption:

I am using BSLSBSBaseF.bin in all instances (despite the cartridge films being of the Pokey Little Puppy cartridge). Rough timing estimates are taken from preliminary_data.md in this repository.

Observed duration of preamble, $P_o$, as per observation is 8 seconds.

Observed duration of the entire Region 1, $R_o$, as per observation is 18 seconds.

Observed duration of Region 1's narration ($R_o-P_o=N_o$) is 10 seconds.

BSLSBSBaseF.bin Region 1 audio starting address in hex: 0x4EEE (this is 6 bytes offset from the start of the Region, 0x4EE8)

Sidenote:

I just realized that my Region 1 label in the ImHex folder project of this repository for audio erroneously includes the pointer and frequency. I will have to edit those to separate them to reveal the true lengths of each Region's components. Perhaps this is why there are so many errors -- wrong offsets from my 'source of truth.'

BSLSBSBaseF.bin Region 1 audio last address in hex: 0xD72D.

BSLSBSBaseF.bin Region 1 audio byte length (inclusive), $B_l$, in decimal: 34880.

Calculated duration of the entire Region 1 audio decompressed, $R_c$, (calculated by Claude Sonnet 4.6): 17440 milliseconds.

This would correlate with the observed data. $R_o \approx R_c$. It would also affirm John-K's calculations. I also realize that $R_c = B_l * 2$. We could calculate the audio length in milliseconds from data length without having to decode the .a18 and run it with a stopwatch. This would mean that each byte of a1800 compressed-audio is equal to 2 milliseconds of audio. This is also explained in John-K's format.md. I am playing a game of catch-up here...

Calculated duration of the lights in Region 1 as explained in John-K's format.md:

sixty-seven 0x04 blocks, then eight 0x0c blocks, then thirteen 0x08 blocks

• 0x04 instances (80ms) = 67 (= 5360 ms)
• 0x08 instances (160ms) = 13 (= 2080 ms)
• 0x0c instances (240ms) = 8 (= 1920 ms)

Total light duration, $L_c$, = (5360 + 2080 + 1920) = 9360 ms.

I see John-K's is slightly longer, I assume they accounted for the START and STOP commands, so potentially +160 ms would equal 9520 ms, equivalent to what John-K arrived at.

Calculated light timing ($R_c - L_c$), $L_o$, = (17440 - 9360) = 8080 ms

If our hypothesis is correct, $L_o \approx P_o$. $L_o = 8080$ ms, while $P_o \approx 8000$ ms. Because these are quite close, we can deduce that our theory may be valid. This aligns with the previous work already done by John-K. We can likely assume that audio is right-aligned as claimed.

We can further validate error source by seeing how long the projector test took to crash.

• $A_{start}$, or audio start timestamp of the video: about 0:11.
• $A_{crash}$, or projector crash timestamp of the video: about 0:21. Difference ($A_{crash}-A_{start}$) should be approximately 8 seconds. It was 10 seconds. This may be explained by the incorrect Region 1 length pointer. This test should be replicated on the fixed pointer version. I would assume that the fixed version would be 8 seconds.

If this is true, then I would wager that the light commands are preserved, allowing the light duration and timing to be correctly calculated while allowing for out-of-range channel or RGB values to crash the projector.

A Quick Differential

Well, well, well... A quick diff shows preservation of the light table prior to the start of Region 2... (see 0xD724 onward). The yellow-highlighted region is the custom audio diff, while the clear-highlighted region above is the length pointer for Region 2. This would suggest that the light table is not the problem, but the custom audio itself... a bit stumped at the moment.

Additionally, the possible hex values range from 0x00 to 0xFF which would account for the 255 values possible for a given RGB channel. There is no way that any value would be "out-of-range". From the diff itself, we can see that the distal values 0x00 and 0xFF are represented here, affirming that the whole spectrum of RGB values is valid. It cannot be corrupted light data. Why is it crashing on lights startup? Perhaps corrupted audio to the point of a critical error that just so happens to (potentially, roughly?) align with the timing of the back lights. The pointer fix enabled the projector light and carousel to stabilize (until that delay). I wonder, what encodes silence? Perhaps I could encode silence throughout the audio payload, and truncate the light data to START-STOP only. If blanking the Region works, then I would validate the conserved structure at least.

⟵ Older	Table of Contents	Newer ⟶