bsnes WIP
Some news from byuu :
I was planning to keep this a secret until I got at least one game running correctly, but it didn’t take long at all.
So far, Kirby’s Dream Land 3 and Dragon Ball Z: Hyper Dimension are fully playable. Marvelous has graphical issues. Super Mario RPG and Parodius 3 lock up. Mostly because I’ve only emulated the core SA-1 CPU, the Super MMC and the ALU. Still have to implement interrupts and timers, bitmap<->bitplane character conversion, variable bit-length reading, DMA, RAM protection, etc. I plan to support the entire chip, even if most games don’t use much of it.
Speed isn’t nearly as bad as I thought it was going to be. I get about ~88fps in Kirby 3 in the most intensive parts on an E8400 @ 3GHz. This is compared to ~148fps in Zelda 3. Speed may drop a bit more, especially after supporting the H/V timer, but I’m hoping my theory on how the counters work is correct; such that most games won’t need these to be active most of the time.
Overall, it’s easily the lowest-level SA-1 emulator around. It’s bus-cycle accurate, and syncs immediately with the S-CPU. So even if the S-CPU modifies RAM in the middle of an SA-1 opcode, the SA-1 will immediately detect this ‘just-in-time’, and vice versa. I even have rudimentary bus-conflict timing support. Eg when both the S-CPU and SA-1 attempt to access game pack ROM at the same time, the SA-1 will stall to allow the S-CPU unfettered access. It isn’t perfect, but it should average out to almost exactly the same speed as the real processor. I can improve it easily enough, but it would cause a speed hit in all games. We previously estimated that this level of accuracy would require at least 10GHz. Then again, perhaps it does on the Pentium IV architecture
I’m really happy I was able to get this running at a semi-decent speed. Given it’s the only co-processor to actually have real timing, and I get to use the cycle-perfect S-CPU core with almost no modifications, I intend to get this as bit-perfect as possible.
Speaking of which, the speed hit for adding SA-1 to other games is roughly ~3-5%. This is because the core timing mechanism of the emulator needs to support a co-processor thread. There’s just no easy way to avoid adding co-processor checks to the most CPU-intensive part of the emulator.
Lastly, this isn’t an invitation to harass me about adding SuperFX support
I recently re-wrote the S-CPU opcode macro processor to use a more generic approach, and decided to abstract the opcodes to share them with an SA-1 core. Needless to say, I was quite surprised to get at least two games fully playable with only two days’ worth of effort.
Loading ...