AWJ wrote:According to nocash, during Mode 7 rendering, the values read from 2134-2136 constantly change based on the Mode 7 calculations. This doesn't seem to be emulated by bsnes at all. Has anyone investigated exactly how this works (particularly timing-wise)?
No. I know that it's using it for the mode 7 multiplication calculations, but I have not emulated it. I don't even believe I'm caching the mode 7 multiplications themselves yet (it should only be adding things per-pixel.)
The PPU multiplication updates are like one piece of a large jigsaw puizzle. Trying to tackle it alone would just make a mess of things. If we were to form proper cycle stepping of all PPU operations, $2134-2136 would naturally fall seamlessly into place.
I desperately need jwdonal's test ROMs and PPU timing findings to improve bsnes further. But ... I have three other emulation cores to keep me busy in the mean time, so I guess it's no great rush.
jwdonal wrote:You'd want to show that at least one game depends on reading a very specific byte value in order to justify all that coding/testing effort. Given that BSNES doesn't implement the behavior, and every SNES game already runs on BSNES, then I think you might have a hard time finding that justification.
I emulate all kinds of things that no games rely on. It's not so much about making regular games run better, it's about ensuring someone in the future doesn't decide to use those registers as "free, fast multiplication" while also using mode 7, and then end up surprised when their game breaks on real hardware.
I've been on the other end of that (with different limitations) ... it's not fun.
I don't think most
emulators should bother. Especially not Snes9X/bsnes-performance/bsnes-balanced. But we should ideally have one emulator that a person uses as a final test before releasing their games, and that should emulate anything that is humanly possible.
koitsu wrote:I also now sympathise with byuu having literally 3 separate CPU/PPU cores to maintain. What a fucking nightmare.
After probably 4+ years of maintaining them all (and building profile-optimized binaries for all three, in both 32-bit and 64-bit configurations), I finally threw in the towel and discontinued the performance/balanced cores.
I'm very appreciative that someone out there understands why I had to do that. It was a very difficult decision for me, and one that's obliterated most of the small userbase I still had left.
By the way, if you guys want an even bigger
rabbit hole to chase ... the regular CPU mul/div stuff isn't 100% emulated either.
As most of you know, it's a multi-cycle process of updating the math computations one bit at a time. And thanks to blargg, we know the algorithms and have that emulated.
But it is possible to start a division during a multiplication, and even easier to start a multiplication during division. The result is that both run simultaneously, only they share some transistors along the way. The resultant computations are a complete mess, and even blargg was unable to make sense of them. This is currently unemulated, and probably the easiest way to quickly detect bsnes versus real hardware today.