First, I think FuSoYa already reported, is that bit 7 of Super MMC Registers ($2220-$2223) aren't emulated, making impossible to you set banks $C0-$FF use last 4MB and at same time $00-$3F and $80-$BF use the first 4MB of a ROM. Bit 7 was supposed to control if banks $00-$3F and $80-$BF should mirror the banks $C0-$FF or simply use the default bank switching. Snes9X seems to force bit 7 on.
Second, there is a pretty bizzare thing going with the INY opcode on SA-1 CPU. If INY opcode is on a page boundary (for example, $10:AFFF), it will decrease Y by one instead of increasing. I don't have much experience with C/C++, but I think it's related to this:
Code: Select all
static void OpC8X1 (void)
{
AddCycles(ONE_CYCLE);
Registers.YL++;
SetZN(Registers.YL);
}
static void OpC8X0 (void)
{
AddCycles(ONE_CYCLE);
Registers.Y.W++;
SetZN(Registers.Y.W);
}
static void OpC8Slow (void)
{
AddCycles(ONE_CYCLE);
if (CheckIndex())
{
Registers.YL--;
SetZN(Registers.YL);
}
else
{
Registers.Y.W--;
SetZN(Registers.Y.W);
}
}Third issue is related to BW-RAM's "Virtual RAM". Banks $60-$6F lets you store only 2 or 4-bits to the BW-RAM (depending on register $223F). For example, assuming it is on 4-bit mode, storing to $600000 will set the lower 4-bits of $400000 and storing to $600001 will set the higher 4-bits of $400000. So this implies, for example on a 128KB SRAM file, you can store from $600000 up to $63FFFF, but apparently Snes9X seems to mask the address by the SRAM file size, not by SRAM file size * 2, so storing $620000 will be like storing to $600000, making impossible to you store anything to address $410000-$41FFFF.
Another thing is, according SNES Dev. Book II, SA-1 section, section 1.1.5 and 3.3.6.2, you can have up to 256KB of BW-RAM, but apparently none of the emulators seems to support it. I have no idea how supposed you can have or activate 256KB of BW-RAM, even that the book says on section 3.3.3 that you can have up to 1M (128KB) of backup RAM. So maybe you can have 256KB of BW-RAM but only 128KB is savable...? Also apparently I-RAM can be savable too, but I don't know any SA-1 game that used it nor an internal ROM header that tells any emulator to save I-RAM. Same goes to 256KB.
And finally, the fourth issue is with the SA-1 emulation speed. Snes9X seems to emulate the chip around 25% slower than it should. I made a homebrew ROM that measured the speed by making the SA-1 CPU starts increasing A at start-end of V-blank until V-Blank gets triggers and end again. Any bsnes version gave 10.73 MHz while Snes9X gave around 6~7 MHz. Try it yourself: https://dl.dropboxusercontent.com/u/162 ... a1test.smc. "Normal Speed" is the SA-1 core speed when SNES is waiting in WRAM. "Par. Speed" is the SA-1 core speed when SNES is running on ROM and doing random read/writes on ROM, I-RAM and BW-RAM.
At "Normal Speed", obviously Snes9X should give a value near to 10.74 MHz while "Par. Speed" should be something between 5.37 to ~8 MHz (or around 10.74 MHz if the emulator don't care about bus conflict, like what bsnes does). (In theory, 5.37 MHz, but SA-1 only runs at said speed when reading a ROM value, while other operations are still at 10.74 MHz, so the value can be jumpy).
If someone for some reason can't run the ROM, here is the results I got: higan/bsnes snes9x.
I don't know why it's slower than it should, but I think snes9x applies the WRAM refresh to the SA-1 CPU too, but of course SA-1 shouldn't get affected by WRAM refresh since it's on a cart and the SA-1 CPU itself can't access the WRAM.
That's all, I think. I don't know what is the policy your guys applies here about these type of bugs since technically it only affects homebrew/hacked ROMs, but it would be good if you guys fix it for the next version.
Oh and sorry for my poor english, I'm not native speaker (I'm brazilian). >_>
