Let me guess, you're using ZSNES, right? ZSNES doesn't emulate FastROM properly. I don't recall the specifics, but suffice to say, that 008000 lda $c00000 will take the same number of cycles regardless of FastROM setting -- actual memory fetches aren't timed. I believe it just shortens the length of the opcode if it is executing in $800000 or higher. It also counts in cycles instead of clocks, which complicates things even more. Plus the tendency to make up for missing accuracy by speeding up emulation doesn't help. The game is most likely already running faster than it should be.

But suffice to say, I don't think you'd see a big difference with a FastROM patch even in SNES9x, which does emulate FastROM properly. There's lots of reasons the game could be slow. For one example, you tried making the NMI routine run in FastROM, but that won't make a huge difference because the game was designed so that NMI would never run out of vblank time. Meaning it's probably hardcoded to only do so much per frame. It's unlikely the NMI routine even realizes it has more time available to do a bit more processing now, so your game probably just sleeps a lot more now.

With ZSNES, you might have more luck screwing with the CPU execution ratios. Won't be a "real" speedup, but it should feel a little faster. Worth a try, anyway. You'll probably run into the same problems above with that approach, though.

It was a godsend.

MathOnNapkins, it's true that DMA always transfers at SlowROM speeds (I imagine trying to strobe the XSlow controller ports with it would either return open bus, or incomplete reads -- nobody's tried it, because it's psychotic), and that NMIs perform lots of DMA transfers. They also usually have some long loops talking to the S-SMP.

But once again, I believe that even if the NMI routine is sped up, it'll just complete sooner (it was designed to finish before vblank ran out before, so it won't change its' design just because it's faster now), and then the non-NMI code will just finish faster and lock itself in a loop waiting on NMI to trigger again. So while the code is technically executing faster, it's all mostly just being transferred to idle wait loops.

If you really want to find out, download bsnes' source code, edit src/memory/memory.h : MemBus::speed() to always return 6 (FastROM speed). If the game doesn't speed up, then a FastROM hack is pointless.

I only mention the NMI handler because nothing related to the game action happens outside of it.  I kept logging frames and changing the JSL pointers until there were only pointers to the FastROM region.  First it'll do all the PPU stuff and then take action for the next frame.  I wanted to do a FastROM patch so it will have frames where instead of spilling past the NMI point for the next frame, it would finish earlier than that.  The patch didn't seem to do much at all, so I think I'll just drop it. 

byuu, what do you mean by the 'S-SMP'?

Wait theres a way to remove slowdown on games? Cause a slowdown removing patch for megaman 7 and a few other games would be AWESOME! Screw accuracy if it means I can play my game at a constent fps.

Only one way to find out. Download my sources and get to compiling! :beer: Or do I have to make you slackers a special version of bsnes that reads its' bus access timings from a text file for you guys? Lowering those values would be like unlocking a special UltraFastROM mode, unlike the cheap way of just bumping the frame counter up. Though I can't guarantee the games would still work right, of course. They should.