[bsnes] SA-1 support

the developer said: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 :P

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