Hacker News Reader

Comment by near | Hacker News Reader

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.

View on HN

> 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.

While I'm sure this solution will work, knowing if it will take milliseconds or millennia to solve is the big question...

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.

Reply on news.ycombinator.com