Fastrom patches?
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
Fastrom patches?
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?
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?
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.
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.
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.
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.
Re: Fastrom patches?
Yeah, I did attempt just that a couple of years back on Super R-Type, coincidentally.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?
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).
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?6502freak wrote:Ummm, did you actually read my post?
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.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.
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.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.
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.
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.
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.
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.
-
- Posts: 592
- Joined: Thu Aug 28, 2008 1:17 am
- Contact:
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.
@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??".
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??".
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.
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.
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.MottZilla wrote:But one helpful side effect to the massive slowdown in Gradius 3 is it makes it easier to dodge hazards. =)
I think either Gradius III or Ganbare Goemon were the first SNES games from Konami.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.
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).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.
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.
I'm specifically talking about Parodius Da!, which is a simple 8-megabit cart.The later Parodius game though uses SA-1 which would explain it not slowing down.
Hope they didn't code a 6502 emulator to port the games over... O_OIt 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.
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.
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.