Hacker News new | past | comments | ask | show | jobs | submit login

There are 52 registers comprising approximately 100 settings, there are probably close to twice that number if you include the internal register latches (some of which we know about, some of which we don't know exist yet.) The SNES PPUs are heavily based around combinatorial logic. Changing the timing of one variable can alter the timing needed by other variables. Think of each setting as potentially doubling the number of tests needed (at least when it comes to a blind, brute-force approach.) There are more combinations of settings and pixel generation patterns than atoms in the universe.

The way we've gotten as far as we have is that not every combination needs to be tested. It is a ballpark estimate on my part, but I'd estimate us needing a few million tests to have a high degree of confidence our emulation is correct.

If we had to make those tests into visual patterns on a screen that had to be checked by eye each time, it would be overwhelming even if we only needed a few thousand tests made.

I can test code on a live SNES extremely easily with my 21fx board ( https://github.com/defparam/21FX ), but it's still far too much to do this by hand.




byuu I'm curious, is there some magical piece of documentation/schematic that would break open an entirely untapped area in your SNES research? Or are you at the point the hardware is almost entirely transparent, and it's just a matter of chipping away at the edge cases, or halo projects like a replacement clock for the dual oscillators?

It'd be interesting if some Nintendo engineer for the early 90s has a box in his garage with documents that could change the whole course of your current work.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: