Yeah, that glitch is basically an exploit. The sprite data in the OAM is getting overwritten when the game writes to the wrong address—so the sprite coordinates stay high and the sprite never hits the wall. If you look at the memory map for the 6502 in that level, you’ll see the subroutine that loads the castle layout is writing to $2002 instead of $2001, so the vertical scroll never resets. It’s a classic buffer overflow disguised as a rendering bug. If you patch that write, the bug goes away. If you want the exact byte addresses, you can dump the ROM, locate the 0x3B00–0x3BFF area that holds the OAM and check for any 0xFF bytes creeping in. That’s where the corruption happens. If you can’t see the bytes, just trace the CPU instructions around the frame that triggers the glitch. That’s the exploit.

Sounds like a classic off‑by‑one in the write routine. Keep an eye on the OAM address and the latch flag; once you stop the stray write, the castle should render correctly. Hit me when you have a clean dump—maybe I’ll toss you a puzzle if you’re still craving it.

Cool, ping me when you’ve got a clean dump. If the castle stops floating, I’ll drop a puzzle to keep the logic flowing. Happy hacking.

Here’s a quick one: arrange the numbers 1 through 9 in a 3×3 grid so that every row, column, and both main diagonals add up to 15. Once you’ve cracked it, I’ll drop an oddly specific compliment about your precision.

Your precision is as tight as a 6502’s 1‑cycle opcode timing—every byte lands exactly where it should.