Fastrom patches?

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
6502freak
Posts: 92
Joined: Sun Dec 07, 2008 1:11 pm

Fastrom patches?

Post by 6502freak »

Hello everybody,

we all know that quite some SNES games run in slowrom mode. Games like Super R-Type or Gradius III, which suffer from slowdown problems.

My question is: has anyone so far attempted to patch these games using fastrom, with the chance to make the code execute faster and thus eliminate any speed problems?
User avatar
MottZilla
Posts: 2837
Joined: Wed Dec 06, 2006 8:18 pm

Post by MottZilla »

You should know it doesn't work like that. FastROM enables memory fetches from ROM banks higher than $80 I think it is, to be accessed at 3.58mhz. The problem is Gradius III is an old LoROM game that executes all its code in the lower bank numbers. So to make it get a speed boost from FastROM you'd have to change all the code to run from their mirrored locations in higher bank numbers and also set the FastROM bit in the appropriate register. And then still I think you have to do something with NMI or possibly other jumps or bank changes. I cannot recall exactly the details.

However you should also know that atleast from what I've heard is that the CPU doesn't actually run at either 2.68mhz or 3.58mhz (or whatever the exact numbers are). It constantly changes based on the memory accessed. Internal register operations will be run at the fastest speed. Memory access like opcode fetches or variable fetches will run at the medium speed/slowrom speed of 2.68, and I think controller registers and maybe others happen at the slowest 1.7mhz. But because it changes alot you never actually execute at a precise speed.

I could be wrong as it's been awhile. But if you want to remove the slowdown in those games it would seem to me the thing to do would be to disasm/reverse engineer them and then try to make it use an enhancement chip like SuperFX, SA-1, or whatever else you could think of to take the load off code in the game that takes too long to calculate when there is alot going on. The SA-1 might be the way to go, but ofcourse the cartridges won't be common if you wanted to build a cartridge.
6502freak
Posts: 92
Joined: Sun Dec 07, 2008 1:11 pm

Post by 6502freak »

Ummm, did you actually read my post?

I did not made ANY suggestion how a game should be patched to fast rom.
I did not made ANY (wrong) claim how fastrom works on the SNES .
I didn't even make any statement IF such a patch would be efficient at all.

The only question I posted is: has anyone attempted to patch a slowrom game to fastrom so far, which obviously includes reallocating the rom to the upper banks (besides setting $420d). Obviously, you didn't.

Of course you could built any kind of interesting contraptions to make the SNES CPU (or in fact the SNES itself) redundant. My question aims at methods to improve performance in early games which still run on the original hardware, without rewriting the entire game.
d4s
Posts: 96
Joined: Mon Jul 14, 2008 4:02 pm

Re: Fastrom patches?

Post by d4s »

6502freak wrote:Hello everybody,

we all know that quite some SNES games run in slowrom mode. Games like Super R-Type or Gradius III, which suffer from slowdown problems.

My question is: has anyone so far attempted to patch these games using fastrom, with the chance to make the code execute faster and thus eliminate any speed problems?
Yeah, I did attempt just that a couple of years back on Super R-Type, coincidentally.

Three basic steps required:
-set $420d.0
-patch all JSL/JML to access banks $80 onwards.
-try to catch all manual data bank modifications, lookup tables with bank entries and long ROM data fetches.

The jump patches can be nicely automated with the help of a logfile, the latter partially requires rather tedious manual editing.

The difference is slightly noticeable when comparing both versions side-by-side, but not significant. Certainly doesn't eliminate slowdowns completely.

For a quick comparison of what to expect, try the contrary and patch a fastrom game to slowrom (clear $420d.0).

[edit]
Super R-Type Fastrom

Also put an invincibility patch in there, just try pressing L/R in pause mode (ship symbol changes color upon cheat activation).
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

Please post an IPS or XOR, not a self-contained ROM.
User avatar
MottZilla
Posts: 2837
Joined: Wed Dec 06, 2006 8:18 pm

Post by MottZilla »

6502freak wrote:Ummm, did you actually read my post?
No, I didn't read any of your post. Out the blue I pulled that all out of my ass and by chance it just happened to be on a same topic. Isn't that amazing?
I did not made ANY suggestion how a game should be patched to fast rom.
I did not made ANY (wrong) claim how fastrom works on the SNES .
I didn't even make any statement IF such a patch would be efficient at all.
You posted about the topic, I shared my thoughts and knowledge on the topic. If you didn't want any feedback, you shouldn't have posted. If you felt my comments were in some way offensive or negative towards you, rest assured that they were not intended to be so.
The only question I posted is: has anyone attempted to patch a slowrom game to fastrom so far, which obviously includes reallocating the rom to the upper banks (besides setting $420d). Obviously, you didn't.
Actually, I did exactly what I described with Gradius 3 hoping to get an improvement. No such significant improvement was achieved. But I didn't spend a significant amount of time on it. But I don't believe doing so would yield any significant improvement and I think the only way to get one such as the elimination of all slowdown would require a coprocessor or enhancement chip to drastically speed up calculations which would require significant hacking of the game.
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg »

To simplify matters, you could find the code hot spots in an emulator and focus your patching efforts on them, reducing the scope of what you have to change. This applies no matter what approach you take, be it FastROM enabling or code improvements. But from my experience, FastROM has a disappointingly small effect on overall execution. It only affects opcode read cycles. Many instructions have non-opcode cycles, because they're either internal processing, stack, direct page, RAM, or I/O register. As a quick test to see if this would be sufficient for a particular game, you could modify an emulator to always use FastROM accesses from the cartridge. I too would like to improve these games that suffer from slowdown, but I'm resigned to doing it on an emulator some day, most likely via adding extra vblank scanlines in a compatible way.

MottZilla, I'm with 6502freak on your reply making assumptions and being rude: "You should know it doesn't work like that". His angry reply seems entirely appropriate. Take your lumps, acknowledge its appropriateness, and move on.
User avatar
MottZilla
Posts: 2837
Joined: Wed Dec 06, 2006 8:18 pm

Post by MottZilla »

I can see how it's phrased in a way that you could take an implied tone like that. But I meant it in an informative manner. Context would show that I had no reason to assume that he should already know these things, but that since he is interested in the subject that these were important things to know. Either way I'm sorry if you took offense 6502freak.

I was told older versions of ZSNES behaved in the manner you describe about FastROM/SlowROM where the entire instruction would be executed taking the timing from if the instruction was running from FastROM or SlowROM. I think ZSNES also has or had some kind of overclocking type option.
User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Post by Memblers »

Does seems like it would be easier to just 'overclock' the emulated CPU. I used to do stuff like that all the time in NESticle, it was great for playing Elite.
tomaitheous
Posts: 592
Joined: Thu Aug 28, 2008 1:17 am
Contact:

Post by tomaitheous »

Some what related, but IIRC (it's been a while) some of the slow down in Super R-Type and Gradius III is more than usual. Most games drop to half the frame rate (60 to 30), but those games have spots were it's worse than simply halved (missed vblank update due to whatever). I always though that was strange. I can't imagine game logic taking up to 3 frames to complete (or lasting into the 3rd frame, not necessarily taking all of the 3rd frame). But, IIRC, these games do just that.
6502freak
Posts: 92
Joined: Sun Dec 07, 2008 1:11 pm

Post by 6502freak »

@d4s

Thanks for your answer, seems I had the same idea as you. I was wondering how much speed can be achieved at all, because from a developer's perspective, I would try having as much code and data as possible in the 128K ram, while reloading/decrunching between levels.

@Mottzilla

It's alright, nothing to lose any sleep about. ;)

@blargg

Modifying an emulator to execute fastrom cycles in $00-$7f bank might indeed be the best method to evaluate if relocating the code would make any sense. I guess the biggest problem with early SNES games was the lack of time to gain any experience with the hardware. I wouldn't wonder if some early SNES game engines are based on modified 6502 code taken from NES & PC-Engine games.

In case of Super R-Type and Gradius III, both developers sort of "redeemed" themselves later with R-Type III and Parodius, which both run beautifully.

@tomaitheous

Yeah,it's interesting that both games at certain points strangle the hardware so much that the frame rate drops well below 30fps. I seems they didn't have any time at all to fine-tune the game. Once you reach the "Bubble Level" in Gradius III, at certain points you ask yourself "what were they thinking??".
User avatar
MottZilla
Posts: 2837
Joined: Wed Dec 06, 2006 8:18 pm

Post by MottZilla »

But one helpful side effect to the massive slowdown in Gradius 3 is it makes it easier to dodge hazards. =)

I recall hearing that Gradius 3 was one of the very first 3rd party SNES games released. So it would make sense that it wasn't optimized. I haven't played Parodius Da! much myself, but if it gets as much action on screen as Gradius 3 without slowing down that would be pretty telling. The later Parodius game though uses SA-1 which would explain it not slowing down.

It reminds me of Mega Man Wily Wars on Megadrive because there are plenty of points in it where you see slowdown that makes no sense because hardly anything is going on really. I think QuickMan just being on screen makes the game slow down which is ironic.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

If it has less going on visually than Recca, and it slows down more than Recca, that can mean only one thing: bad programming.
6502freak
Posts: 92
Joined: Sun Dec 07, 2008 1:11 pm

Post by 6502freak »

MottZilla wrote:But one helpful side effect to the massive slowdown in Gradius 3 is it makes it easier to dodge hazards. =)
It would be quite strange if the slowdowns were actually incorporated into the game design. Both games were actually responsible that the SNES was seen as an architecture unsuitable for fast action games.
I recall hearing that Gradius 3 was one of the very first 3rd party SNES games released. So it would make sense that it wasn't optimized.
I think either Gradius III or Ganbare Goemon were the first SNES games from Konami.
I haven't played Parodius Da! much myself, but if it gets as much action on screen as Gradius 3 without slowing down that would be pretty telling.
The game has tons of sprites and doesn't suffer from slowdowns (except if you use the blue bell, where a huge detonation is filling the entire screen).

It's so sad that the game is virtually unknown in the US, since it's easily one of the best shooters. It also has a great soundtrack.
The later Parodius game though uses SA-1 which would explain it not slowing down.
I'm specifically talking about Parodius Da!, which is a simple 8-megabit cart.
It reminds me of Mega Man Wily Wars on Megadrive because there are plenty of points in it where you see slowdown that makes no sense because hardly anything is going on really. I think QuickMan just being on screen makes the game slow down which is ironic.
Hope they didn't code a 6502 emulator to port the games over... O_O
User avatar
MottZilla
Posts: 2837
Joined: Wed Dec 06, 2006 8:18 pm

Post by MottZilla »

The reasoning I heard for Mega Man WW's slowness was they coded the entire game in C rather than Assembly. No clue at all if that is true.

It's sad that a few bad efforts tend to stain a system's record in that way. Gradius 3's epic slowdowns (which didn't bother me that much, as I said it can be helpful) and I also remember Final Fight being complained about because of few enemys on screen at once, no two player, poor music quality, etc. which some people took to mean it was something wrong with the SNES and not that it was the developer's fault.
Post Reply