User File #637810967022224841

Upload All User Files

#637810967022224841 - Kirby's Adventure DPCM (Failed Console Verification, Works in Emulator)

Kirby_DPCM.bk2
In 00:04.00 (240 frames), 294 rerecords
5 comments, 92 downloads
Uploaded 2/22/2022 3:18 AM by OnehundredthCoin (see all 10)
Download (3.45 KB)
This is an unbelievably sloppy TAS that I made back in December to test if the DPCM audio bug exploit could be done in Kirby's Adventure. Unfortunately, after many tests for Console Verification, there has been no luck. I imagine the culprit is the DPCM audio bug, as unlike Super Mario Bros. 3, the title screen has DPCM audio.
I honestly don't know all the details of the DPCM audio bug or how emulating it works, but my hypothesis is that the bug is inconsistent on console, and so emulating here isn't "inaccurate", but the results may vary.
Anyway, the trick that made this TAS work happened by mistake, and reproducing it on purpose has been exceedingly difficult. I manipulated the stack in such a perfect manner to pop a value of the stack, store it in X, and use X as an offset that ends up storing a NOP at the JMP instruction that rests inside the programmable interrupt. From there, the programmable interrupt happens, and I use the bytes that appear after where the JMP was to write code, as that's where the controller data is stored.
Again, this TAS is crude and sloppy, but until I can get it working on console (or figure out why it doesn't work), I have no desire to attempt improving it.
Rerecord count is inaccurate. VBlankCount is also probably inaccurate. I don't know why, but the .bk2 file didn't include VBlankCount.
DJ_Incendration
on 2/22/2022 3:41 AM
This is interesting! Shame there's no console verification, since I'd really like to hear what this sounds like.
OnehundredthCoin
on 2/22/2022 4:38 AM
Good point! I've uploaded a video of this TAS to youtube. It doesn't load the credits music, and the title music gets really funky. It was a pretty sloppy payload that I wrote to jump to the credits, but it was mostly a test to see if I could make anything happen at all.
ThunderAxe31
on 2/22/2022 9:36 AM
I'm mostly ignorant, so pardon me if I'm bringing a wild hypothesis: could it be the same reason why Super Metroid occasionally desync in real console, due to the SNES using a non-deterministic clock for audio work? Because I clearly remember some people at GDQ noting how the countdown in the very first level of Super Metroid can vary its speed, since it relies on the SNES audio clock, which tends to give different results for every play.
CasualPokePlayer
on 2/22/2022 9:40 AM
The NES only has 1 master clock (so the worse thing that happens is different alignments with the divided clocks ie with CPU and PPU, but this rarely causes issues anyways), The SNES had multiple clocks instead. The audio clock used a ceramic clock, which drifts at a very significantly higher and faster rate than a quartz clock normally used.
OnehundredthCoin
on 2/22/2022 5:05 PM
Quoting CasualPokePlayer
the worse thing that happens is different alignments with the divided clocks ie with CPU and PPU
Ooh, that might actually be the reason. Since the data I'm filling inside the stack would be the program counter while stalling inside the controller input loop (for multiple frames in a row) any deviation from where the PC was at the beginning of a NMI (determined by PPU) would throw off the TAS. I'm not simply returning to the PC Address that got pushed to the stack, as the stack pointer gets offset by one at some point, so the return address is a combination of the PC's low byte, and the register data that gets pushed after the PC. Hence why in this instance, the CPU and PPU being in a different alignment would make a large difference, while in every other instance, it doesn't matter.
In short, if the CPU and PPU are in a different alignment than the emulator, the NMI could fire on a different instruction, pushing a different low byte to the stack, which is then used as the high byte of a return address after the stack pointer gets shifted. This is still just speculation, but it would make a good explanation for why it desyncs.