nesdev.org

There was -- and it was quite a closely-knit and friendly community -- but is long over with for a lot of different reasons. Consider that I wrote the SNESTECH documents *before* the NESTECH stuff.

Man, people really aren't as smart as they were a long time ago.

Hi! No slowdown patch more available?

Heck of a threadbump. Anyway, if not running on real hardware is okay, an emulator can do this without ROM patches, by simply always returning 6 clock timings for ROM accesses both in the $80-ff *and* $00-7f regions.

If nothing else, it's a quick way to assess whether patching a ROM for real hardware use is worth it.

How do I do with the emulator? I'm not a developer, I do not know.

For Gradius 3, look here:
http://www.romhacking.net/forum/index.php?topic=27609.0

I like that thread. I'm going to make an account on romhacking.net now.

whicker wrote:For Gradius 3, look here:
http://www.romhacking.net/forum/index.php?topic=27609.0

Nice to see someone making progress on the idea of improving Gradius III.

I applied the 2 patches from ROMhacking.net and then started writing my own optimization patch on top of it.

Then I played Gradius III, got to level 2, kept getting hit by bubbles. I said to myself, "that's funny, I don't remember the bubbles moving this fast. Oh wait, they weren't."

I know super mario world has an sa-1 patch that improves frame rate and performance, fastrom isn't the only solution.

Optimization on stock hardware is more impressive.

I can think of cases where an SA1 patch would slow down the whole emulator, particularly if you're using a modern emulator (that is, not Snes9x or ZSNES) on hardware that is optimized for power consumption at the expense of raw speed (such as Atom/Pentium N/Pentium Silver or ARM).

psycopathicteen wrote:Optimization on stock hardware is more impressive.

I agree, however given that SD2SNES supports SA-1 now it wouldn't be a bad alternative way to try to eliminate or reduce slowdowns in performance. Of course seeing what is possible with only enabling FastROM and optimizing some code has a special quality since in theory given more development time and slightly faster MaskROMs it could have been that way originally.

Makes me wonder when the first game using FastROM was released.

MottZilla wrote:Makes me wonder when the first game using FastROM was released.

SuperFamicom.org appears to be a rough counterpart to BootGod's NesCartDB. It lists (among other properties) release date, ROM speed, and mapper ($20/LoROM or $21/HiROM) for each game. Unfortunately, its search isn't as thorough as NesCartDB, nor could I immediately find a download.

hibber22 wrote:I know super mario world has an sa-1 patch that improves frame rate and performance, fastrom isn't the only solution.

The spectacular thing is the game benefits of huge enhancement in term of speed and stuffs on screen, and only with a patch,without using the SA-1 specificities.

Oh boy, I completely wrecked up the source code for this stupid Gradius III optimization patch, trying to cram in code in whatever blank space the original game had. It looks like I would need to start over, this time with a larger ROM size. I guess this should be a rule of thumb to never start an optimization patch without making sure I have a lot of space to work with.