|Reverse emulating the NES!
(31 May at 18:30)
| Oops, I screwed up by forgetting that May doesn't have 32 days. Especially silly since I finished the content of this post days ago, and all I had to do was post it! Backdated 24 hours [cheating].|
I finished the project I've been talking about for a few posts, and uploaded two videos:
Reverse emulating the NES to give it SUPER POWERS!
Making of "Reverse emulating the NES..."
The first video is the project itself, a weird self-explanatory joke, and the second one is a longer explanation of some of the technical stuff and the process that I went through to create it. Of course, up to you, but I think both have something to offer for the audience that reads Tom 7 Radar. :)
I went to Seattle to present basically the first talk to two different audiences (first at Deconstruct and then at UW's PoCSci, which is like their version of SIGBOVIK.) I was delighted to have the privilege to do both of these without so much as telling anybody involved the title of my talk, let alone anything about its context or e.g. weird equipment, which allowed me to do a more sneak-attack "reveal." This was very fun. Here's me on the big stage. The screen is 40' diagonal, so these pixels are about 1.88 square inches each!
Tom 7 at Deconstruct
It was a fun project but pretty hectic. Now I am aggressively relaxing by cleaning my basement and playing some video games (Steamworld Dig 2; great so far!). I have some ideas for the next thing, but also a bunch of travel coming up, so I'm taking it easy.
|This is a great project.
What I don't understand though is what makes the addresses the PPU reads so hard to predict on your side? Doesn't it basically read the attributes and tiles all in the same deterministic sequence in all frames? I mean, perhaps the scrolling can nudge the sequence around a bit, but I still don't understand why it matters so much that it's difficult for the reverse emulator to read the addresses from the bus.
Also, as for the sound, could you reuse some parts of the Tasbot project demonstrated on AGDQ 2017? In that one, they also produced sound on unmodified NES by feeding it data from a fast computer. You'll still have to figure out how to generate the CPU input, but perhaps you can use their software to figure out what the CPU should tell to the sound chip.
|Predicting the PPU is not that hard, but I don't have that many spare cycles to do it. The main challenges are:
- Address reads are noisy, but each address only tells you a little about where rendering is on the screen (nametable/attribute reads are nice and deterministic, but don't tell you the scanline; pattern table reads depend on the tile returned by the nametable, but do include low-order bits of the scanline).
- The PPU does some irregular stuff during "hblank" to read sprites and to prep the next scanline (I don't handle this and I think it's the main reason the left column of the screen is kinda messed up)
- You want each code path to be similar in length, to reduce timing jitter
Ultimately what I did here was pretty simple, but it's also delicate wrt timing, and went through several iterations (some were fancier and worked worse).
For sound: I need to watch this tasbot video since several people have mentioned it! I think making sound is actually pretty straightforward; for me it was just a matter of running out of time (for the project before my talks) and time (within a frame to do significant computation).