One of the later comments on the article offers custom PCB design to make a test harness for the PPUs. It seems like a perfect partner for a manually controllable clock for the whole SNES, e.g. as Ben Eater's 6502 demos use. If you can freeze the clock at will, you can more easily inspect the data and address lines. But this wouldn't work if the PPU latch timing depends on analog effects or the PPUs have an internal clock.
Combine the test harness with a USB logic analyzer and signal generator, and borrow some concepts from fuzzers like AFL, and it should be possible to automatically identify critical phases of the PPU operations.
Question: do the PPUs themselves generate analog video, or is there a separate DAC whose bus could be tapped to figure out what color the PPU is producing?
The PPUs use static logic and an external 21MHz oscillator (which also powers the CPU), so they're perfect for single-stepping in isolation from the rest of the SNES.
The PPUs themselves output only analog RGB, there's an analog pin for each color channel rather than a digital pin for each color bit.
On some level, I don't doubt it's possible to build a test harness that can automate things based on the analog RGB values with some fuzzy matching, but if we are going that far, it just makes more sense to snoop the bus traffic directly. That would reveal a lot more information and in digital form.
> it just makes more sense to snoop the bus traffic directly
It seems the bus traffic won't tell you everything. Just because the PPU reads a specific piece of a sprite from RAM, doesn't tell you which pixels of a scanline it'll get rendered on.
If I were approaching this problem, I would observe that the 'analog' output of a SNES is probably a bunch of discrete values with discrete timing intervals, and therefore can be perfectly captured with no error, especially if you can slow the clock down to eliminate signal reflections etc.
I would then make a test harness consisting of a PPU chip, the ability to read and write registers (either with the rest of the SNES, or some other microcontroller, whichever is easier) and the ability to capture complete frame outputs from the 'analog' outputs without error.
I would then do the same with an emulator, and run code on both which pokes random registers at random (clock accurate) times, and whenever a difference in output appears, debug it.
> It seems the bus traffic won't tell you everything.
Oh it absolutely won't, it's only the external state. It's just another important piece of the puzzle that I think would help us out a lot.
Solving this would most likely require reverse-engineering the netlists from a decapped die scan.
I've since (post article writing) learned that a German forum found a hidden test mode that outputs digital RGB values, but it has a lot of issues on various edge cases, so while it's not a perfect solution, it's definitely a huge help along the way if we can get a testing rig set up around an appropriately modded SNES.
I think you could use a NN to attempt to replicate the circuit under test, perhaps generating verilog, programming a chip and then running it against a set of autogenerated test vectors.
A generalized system for duplicating the functionality of a boolean circuit. If can use its own axioms and generalities, once it "understands" flip-flops and nand gates, can start to directly synthesize more complex logic.
That sounds like a great idea, but you today we can't even synthesize arbitrary VHDL/Verilog code efficiently. The author needs an understanding of hardware architecture to write something that synthesizes versus just a test harness not intended to be synthesized.
Combine the test harness with a USB logic analyzer and signal generator, and borrow some concepts from fuzzers like AFL, and it should be possible to automatically identify critical phases of the PPU operations.
Question: do the PPUs themselves generate analog video, or is there a separate DAC whose bus could be tapped to figure out what color the PPU is producing?