Suckerpinch's Reverse Emulation Videos

Does anyone understand what he's doing in these videos?

https://youtu.be/ar9WRwCiSr0

https://youtu.be/hTlNVUmBA28

I see that he wired a Pi to a cartridge, and I'm assuming that he's changing CHR-RAM on the fly. But I don't get how the attribute tables can be changed every scanline without turning rendering off.

So each 8x1 sliver gets its own attribute table byte, they are just mapped to the same address for the whole 16x16 area. But if you are manipulating what bytes get read back, you can mess with the attribute byte for each 8x1 sliver.

Also there is no CHR-RAM, just a program that makes the PPU read back the bytes it wants it to read.

You don't even need to use an external processor for it; I did so using just a raster effect on a mapper that supported 16 nametables (in this case, in ROM)—caveat: my attribute zones are 16x1 instead of 8x1, but I believe more careful timing could have switched nametable registers every 16 pixels (offset by 8 pixels relative to the native 16x16 pixel attribute grid) to achieve 8x1 attribute zones also.

So...he's changing PPU addresses during the attribute read?

I'm assuming that this sort of manipulation isn't feasible for a game? (without a Pi)

No, not at all. He's just directly taking advantage of the PPU's predictable fetch cadence. It always fetches the same four type of bytes over and over: the first byte is from the nametable, and that determines what address will be used later on. The second byte is from the attribute table, and two bits of it determine the palette used for that 8x1 sliver. The next two bytes are the two bitplanes for that 8x1 sliver.

(During sprites the nametable and attribute table fetches still happen, but their contents are ignored)

He can provide any raw numbers he wants, and the PPU just obligingly turns that into a picture.

That I can do something similar using 100% of the CPU time isn't really the same.

The MMC5's 8x8 attribute mode is the closest "real" thing to what he's done.

Tom7's method is really a hack: the Pi is really not designed for emitting bytes at 5.42.7MHz (and especially not in response to external stimuli); a cleaner prior design was linked in one of our discussion threads about tom7's instantiation.

For a game, without adding schmancy external hardware (i.e. MMC5, N163, VRC6, Sunsoft 4), the closest you'll get is GTROM with its 8 nametables. Those could be used with timed code to make 8x4 attribute zones to make a really pretty title screen, I guess.

By the way there is already a thread about these videos: https://forums.nesdev.com/viewtopic.php?f=9&t=17398

However it was maybe not so focused on specific questions about how. Mostly people started coming up with arbitrary definitions for "NES game" in response instead.

Apparently there's no CHR-RAM or NT/AT RAM that the NES can write to, the cart is actually wired to disable the internal VRAM (cartridges using 4-screen layout may do this too, if the memory for the 4 name tables is inside the cartridge), and the Raspberry Pi watches the PPU bus to supply the appropriate data every time the PPU tries to fetch data from VRAM.

Even though attributes are limited to 16x16-pixel areas on the NES, the PPU actually fetches an attribute byte for every 8x1-pixel area, so if a mapper (like the MMC5) or a coprocessor (like the Raspberry Pi) keeps track of the memory fetches, it can supply different attribute data for each fetch, allowing for finer attribute distribution than the typical 16x16 chunks.

This was the answer I was looking for. I understand now.

Yeah, you can use the CIRAM /CE line on the cartridge connector for this... Just tie it to +5V and the internal VRAM will be permanently disabled. The cartridge/mapper is then free to respond to VRAM fetches however it wants.

You can also do the opposite and keep the internal VRAM always enabled, even for CHR accesses, so that the NES would use its internal 2KB for both patterns and NTs/ATs, while the cartridge wouldn't have a CHR chip at all. This would result in a pretty challenging configuration to make a decent game with, since you'd only have 64 tiles and 1 name table (maybe more tiles if you blanked part of the screen) to work with. This had been discussed before ("1-chip NES games" or something).