byuu - Aug 24, 2006
Ok, basically I was able to find out a little bit about mid-frame OAM writes. But not enough to emulate Uniracers. Unfortunately, it does not look like I'm going to be able to fix this game properly before v0.017, and consequently, before more bug reports come in. Sigh. I did my best, at least.
Basically, this is where SNES emulation at this point really stands:
CPU - 99% of games run, 95% hardware accurate, little headway on bus/event conflicts.
APU - same as CPU.
DSP - 99% of sound in games works fine, ~80% hardware accurate, DSP cores currently read in multiple bytes from DSPRAM "immediately" and run it at 32khz. In reality, it probably runs at 1.024mhz and performs sequential reads that could cause 1-sample differences based on timing of APU memory accesses. This would undoubtedly be the hardest area to get hardware accurate. It's very hard to run timing specific tests on the DSP, and the difference at best is probably only a sample anyway. No tangible benefits and no perceived difference. Very tough work indeed.
PPU - 99% of games display no graphical errors, I would go so far as to say not hardware accurate at all. We're treating the PPU as if it runs at ~13.5khz by rendering entire scanlines at a time. In reality, it needs to be run at ~5.37mhz, *possibly twice that*. An unbelievable difference that has all kinds of consequences and internal variables that have yet to be discovered. We've only discovered how to match SNES output in the most basic cases. Luckily, unlike the NES, very few SNES games attempt to exploit the renderer much more than modifying windows and scrolling regs during HDMA. But the second you start doing things like mid-frame OAM/CGRAM writes, all hell breaks loose and no emulator even comes close to real hardware.
The PPU is going to need massive work and a whole new emulation approach if we're ever going to get true hardware accuracy. We're going to have to decode all kinds of insane internal state machines based solely on megabytes of data logs.
This isn't like emulating a CPU. With a CPU, you control what it executes, it runs your program. And your program can analyze what's going on. With the PPU, you're feeding a custom program input, and reading its output (think DSP-1-4 and how long those took to emulate, and imagine this being even more complex than that).
What we essentially have to do is emulate the internal PPU "program" and run it in sync with the CPU and its clock. I can't begin to estimate how much more power this will require, but suspect it will be quite a lot more than currently used. But I'll try and leave bPPU in there for gaming purposes.
byuu - Aug 27, 2006
bsnes v0.017 released.
Since the Winter Olympics bugs is so trivial and not tested on NTSC hardware, I've decided not to mention it in the readme with this release. Besides, I worked too hard to get that list down to one bug to have you guys ruin it for me at the last minute :P
http://byuu.org/
Also redesigned the site to be a little more simplistic and upped the contrast of all the colors. I'm planning on adding a low-contrast stylesheet for those who prefer darker colored sites.
© 2006 ZSNES board - www.emusource.net/bsnes/index.html