It is currently Mon Jun 24, 2019 11:09 am

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 78 posts ]  Go to page 1, 2, 3, 4, 5, 6  Next
Author Message
 Post subject: Fastrom patches?
PostPosted: Mon May 17, 2010 7:46 am 
Offline

Joined: Sun Dec 07, 2008 1:11 pm
Posts: 92
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?


Top
 Profile  
 
 Post subject:
PostPosted: Mon May 17, 2010 11:49 am 
Offline
User avatar

Joined: Wed Dec 06, 2006 8:18 pm
Posts: 2832
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.


Top
 Profile  
 
 Post subject:
PostPosted: Mon May 17, 2010 12:19 pm 
Offline

Joined: Sun Dec 07, 2008 1:11 pm
Posts: 92
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.


Top
 Profile  
 
 Post subject: Re: Fastrom patches?
PostPosted: Mon May 17, 2010 1:40 pm 
Offline

Joined: Mon Jul 14, 2008 4:02 pm
Posts: 88
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).


Top
 Profile  
 
 Post subject:
PostPosted: Mon May 17, 2010 3:07 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21453
Location: NE Indiana, USA (NTSC)
Please post an IPS or XOR, not a self-contained ROM.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
 Post subject:
PostPosted: Mon May 17, 2010 10:21 pm 
Offline
User avatar

Joined: Wed Dec 06, 2006 8:18 pm
Posts: 2832
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?

Quote:
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.

Quote:
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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue May 18, 2010 3:00 am 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue May 18, 2010 11:54 am 
Offline
User avatar

Joined: Wed Dec 06, 2006 8:18 pm
Posts: 2832
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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue May 18, 2010 3:10 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3693
Location: Indianapolis
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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue May 18, 2010 11:15 pm 
Offline

Joined: Thu Aug 28, 2008 1:17 am
Posts: 591
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.


Top
 Profile  
 
 Post subject:
PostPosted: Wed May 19, 2010 10:28 am 
Offline

Joined: Sun Dec 07, 2008 1:11 pm
Posts: 92
@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??".


Top
 Profile  
 
 Post subject:
PostPosted: Wed May 19, 2010 12:28 pm 
Offline
User avatar

Joined: Wed Dec 06, 2006 8:18 pm
Posts: 2832
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.


Top
 Profile  
 
 Post subject:
PostPosted: Wed May 19, 2010 12:48 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21453
Location: NE Indiana, USA (NTSC)
If it has less going on visually than Recca, and it slows down more than Recca, that can mean only one thing: bad programming.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
 Post subject:
PostPosted: Wed May 19, 2010 1:09 pm 
Offline

Joined: Sun Dec 07, 2008 1:11 pm
Posts: 92
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.

Quote:
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.

Quote:
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.

Quote:
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.

Quote:
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


Top
 Profile  
 
 Post subject:
PostPosted: Wed May 19, 2010 2:04 pm 
Offline
User avatar

Joined: Wed Dec 06, 2006 8:18 pm
Posts: 2832
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 78 posts ]  Go to page 1, 2, 3, 4, 5, 6  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: kogami and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group