Super Castlevania IV FastROM Patch - Improves performance

[Barone]

Brazilian hacker Vitor Vilela (@HackerVilela) (the same guy responsible for the Gradius III and Contra III SA-1 patches) has released a FastROM patch for Super Castlevania IV which dramatically improves the performance of the game:
https://github.com/VitorVilela7/fastrom/releases

https://sneslab.net/wiki/How_to_apply_ROM_patches

Some games like Castlevania were made in SlowROM (2.68 MHz). Project FastROM makes them run in FastROM (3.58 MHz) instead. FastROM allows the SNES CPU to read data and opcodes from the ROM 33.58% faster compared to SlowROM.

Link to his SA-1 patches:
https://github.com/VitorVilela7/SA1-Root/releases

He's currently working on a Super R-Type SA-1 patch.

[Black_Tiger]

When these started coming out I was surprised that they didn't already exist, given the popularity of the SNES.

It's cool to be able to see the real performance that devs got out of the hardware for launch window games.

[BonusKun]

This is cool. Thanks for posting this Barone.~

[gamevet]

When these started coming out I was surprised that they didn't already exist, given the popularity of the SNES.

It's cool to be able to see the real performance that devs got out of the hardware for launch window games.

It appears that you need a cart with an SA-1 chip on it, for this to work.

[Barone]

When these started coming out I was surprised that they didn't already exist, given the popularity of the SNES.
It's cool to be able to see the real performance that devs got out of the hardware for launch window games.

I was a bit blown away by Gradius III without slowdown. The parts where you have lots of bubbles on screen is quite impressive and the music has always been great.

This is cool. Thanks for posting this Barone.~

Thanks, you're welcome.

It appears that you need a cart with an SA-1 chip on it, for this to work.

Not for Super Castlevania IV, any regular flashcart is enough for this one.

For the SA-1 hacks (Contra III, Gradius III), then you'll need something like a SD2SNES.

[gamevet]

I do have an SD2SNES cart. I definitely want to check out Gradius III with the mods.

Thanks for the heads up.

[cleeg]

Very interesting thread this. Is there anything similar for the MD? Or would it just melt CPU on account of the blast processing?

Serious question though.

[Black_Tiger]

Very interesting thread this. Is there anything similar for the MD? Or would it just melt CPU on account of the blast processing?

Serious question though.

I don't remember the MD having a slower cpu speed available.

The PCE can run at the same slower speed as the SNES but I don't think any games use it and it may still require extra fast memory for games.

There is a thread somewhere on here about overclocking Mega Drive hardware. I believe that Barone contributed a lot of test results.

[axel]

I don't remember the MD having a slower cpu speed available.

The PCE can run at the same slower speed as the SNES but I don't think any games use it and it may still require extra fast memory for games.

There is a thread somewhere on here about overclocking Mega Drive hardware. I believe that Barone contributed a lot of test results.

Sort of, the PCE can run at the same speed as the NES and some games have been converted from NES to PCE.

The PCE CPU is much faster than the SNES at 8-bit operations, but it would need more cycles for 16-bit stuff.

To get the MD equivalent of what Vitor is doing, it would be like adding a 30 MHz 68k into a Genesis cart. Except I don't think such a chip exists so the closest would be like a 33 MHz 68020.

[Barone]

I do have an SD2SNES cart. I definitely want to check out Gradius III with the mods.
Thanks for the heads up.

You're welcome, gamevet.

Very interesting thread this. Is there anything similar for the MD? Or would it just melt CPU on account of the blast processing?
Serious question though.

I don't remember the MD having a slower cpu speed available.
The PCE can run at the same slower speed as the SNES but I don't think any games use it and it may still require extra fast memory for games.
There is a thread somewhere on here about overclocking Mega Drive hardware. I believe that Barone contributed a lot of test results.

Thanks for the inputs.

Regarding the clock discussion:
- Like Black_Tiger was saying, early SNES games used slowROM and that implicated in the CPU running 33% slower; games like SCIV ended up running at below optimal framerate for that reason.
The fastROM hack basically makes the SNES run at its full speed.

- The Mega Drive doesn't have a slower mode like that but some early games also used slower ROM chips. They don't affect the regular performance but if you try to run them on an overclocked Mega Drive then you'll run into issues.
The rev00 of Super Hang-On is known for having unlocked frame rate and can be boosted from 20 fps to 30 fps once you overclock the Mega Drive to either 10 MHz or 12 MHz. BUT we've seen that the old original carts would glitch out at times, supposedly due to the ROM chip they use, while it runs fine from an Everdrive or in the later re-release of the rev00 contained in the Mega Games collection.
Not all games have uncapped framerate, but several ones do benefit. Most enjoyment I got from it was probably Super Hang-ON and Zero Tolerance (which is actually quite playable at 12 MHz).

- There's a thread I created years ago which compiles a lot of valuable info related to overclocking on the Mega Drive. The results depend on the hardware revision you own, with the Mega Drive 1 VA5 and VA6 being those which can run stable at 12 MHz most games. Other models are usually stable up until 10 MHz.
https://www.sega-16.com/forum/showth...atibility-List
Years ago there was a belief that you had to use more expensive oscillators, shielded and very short wiring in order to achieve better results. I was able to come up with a cheapo alternative at the time which would rely on the use of a Schmidt trigger to output a more stable clock signal and then I used the cheapest oscillators I could find at the time on eBay (from a Czech seller) with regular wires and it worked fine for me: https://docs.google.com/drawings/d/1...it?usp=sharing

- Other than overclocking, you can also replace the 68000 with a 68010 processor but then you'll run into many compatibility issues with several games, since it has a bit different handling of some specific instructions. The 68010 should give you a 5 to 10% boost due to it being more efficient with division and multiplication; difference would be more noticeable in polygonal games which use those instructions a lot. ComradeOj did a lot of tests with that, this an interesting one:


But the incompatibility issues are annoying and include games such as Sonic 3. We failed to fix Sonic 3's compatibility at the time, for an example. You would need to come up with patches for each incompatible game and in some cases it might be quite difficult.

- SNES overclocking is a no-go as far as the console hardware goes, it doesn't support even the least amount of it. But people did came up with lots of overclocking mods for the SuperFX carts.
Thunderblaze16 has a good tutorial on it: https://www.sega-16.com/forum/showth...Super-FX-games
Modern premium flashcarts also support some overclock to the SuperFX implementation IIRC.
For general use on other games though, the solution came from these Vitor Vilela's recent hacks. And they are extremely laborious for what I've seen.
But you get the advantage of not needing to mod your console or worrying about shortening the life cycle of them.

- In terms of software patches for MD games, I tried years ago to hand-optimized Corporation (yeah, that damn old FPS game) for the MD but it didn't get where I wanted. I still have like revision 30 of the hack here with me and I need to release it to the public. I did managed to improve the controller responsiveness by accident, lol. I figured there was a UI loop used to control the pointer speed which also deteriorate the controls in game.
Such hacked hand-optimization is a thankless job because unless you stumble onto some really big fuck up, you won't gain much even if you rewrite hundreds of assembly lines as I did. You'd need to have proper profiling tools and more knowledge of the logic of the game and the VDP itself than I have (which is not much).

- Another thing that nobody tried so far but that I think that could bring some nice in-game results for some MD games would be to decompress old small-sized games into bigger ROMs that any Everdrive would run fine nowadays.
Some games, such as Gaiares, take a long time (full seconds) without in-game action to decompress the next wave of enemies to the VRAM. You could increase the pace of the game if you eliminated the need to do that on-the-fly and worked with uncompressed graphics like SFII SCE does.
This is something I'd like to try one day since there are some tools available for some of the old and most used compression schemes in MD games.

To get the MD equivalent of what Vitor is doing, it would be like adding a 30 MHz 68k into a Genesis cart. Except I don't think such a chip exists so the closest would be like a 33 MHz 68020.

It depends on the game.
Some SNES games use the SA-1 chip mostly for graphics decompression since the SNES uses planar graphics and the compression favors other formats, so the decompression is usually more complex on the SNES than on the Mega Drive (see Mickey Mania for an example of much longer loading times).
In such cases, if you could just use a bigger ROM you could achieve similar results. IIRC, some of the slowdowns you see in MD's Crude Buster is due to the enemies graphics decompression running on the fly. Other old MD games have full pauses that could have been eliminated if you used decompressed graphics data instead.

AFAIK, Krikzz has been working on something that would allow patched MD games to use a FPGA-implemented coprocessor for division and multiplication and that would accelerate some MD games tremendously.
Not my cup of tea though. I prefer something like Vitor is doing which sticks to the enhancements available during the original life cycle of the platform.

[Joe Redifer]

The problem with that Super Hang-On overclock is the entire game runs in fast-forward mode. It's not just a higher frame rate but the entire game is running faster. That's not cool. Same with Super Castlevania IV. I noticed that some things are definitely moving faster than normal rather than the same speed with an increased framerate, which would be preferable.

[axel]

AFAIK, Krikzz has been working on something that would allow patched MD games to use a FPGA-implemented coprocessor for division and multiplication and that would accelerate some MD games tremendously.
Not my cup of tea though. I prefer something like Vitor is doing which sticks to the enhancements available during the original life cycle of the platform.

I agree with you in principle, but it sounds like what Krikzz is doing is just using the FPGA to speed up the 68000 instructions, as if there had been a faster 68k in the cart. To me that seems plausible during the MD lifespan (just like the faster CPU in the Sega CD) versus using entirely new tech that didn't exist in the 1990s. I guess it depends how much faster it runs.

The thing about the 4th gen is that the SNES needed all these extra chips to compensate for the dog slow CPU, on the Genesis most games don't really need extra processing power. They would benefit more IMO by adding more color palettes, so if an emulator or FPGA clone wants to add support for 32 palettes and then people want to hack the games to support that I think the results could be interesting.

[zyrobs]

The thing about the 4th gen is that the SNES needed all these extra chips to compensate for the dog slow CPU, on the Genesis most games don't really need extra processing power. They would benefit more IMO by adding more color palettes, so if an emulator or FPGA clone wants to add support for 32 palettes and then people want to hack the games to support that I think the results could be interesting.

Megadrive VDP had native support for a 128 colour mode, by using an external ram chip for the extra palettes. I'm not sure if any emulators support this mode.

There's also a 128k VRAM mode, which is useful because it allows for uploading nearly twice as much data to the VDP during vblank. This alone would make framebuffer based games significantly faster (this includes all FMV games, all Sega CD scaler games, Virtua Racing, and any other game that is handicapped by the amount of tiles it is uploading on-the-fly to the VDP such as games using software 3d graphics). The downside is that the memory is interleaved, so enabling this mode breaks all existing games. But an emulator could create a standard, such as a bit in the header indicating support, that an emulator could interpret and selectively turn the mode on for certain ROMs.

Kind of thinking about it, do any emulators allow for either of these? I think Exodus is the only one that possibly could, given how much research Nemesis put into this, but I don't know if the emulator actually can do it.

On a side note, the 128k VRAM mode was available in the Teradrive and possibly some development hardware (unconfirmed). The extra palette mode may have been used in the arcade C2 hardware (a mostly megadrive based board).

[gamevet]

I agree with you in principle, but it sounds like what Krikzz is doing is just using the FPGA to speed up the 68000 instructions, as if there had been a faster 68k in the cart. To me that seems plausible during the MD lifespan (just like the faster CPU in the Sega CD) versus using entirely new tech that didn't exist in the 1990s. I guess it depends how much faster it runs.

The thing about the 4th gen is that the SNES needed all these extra chips to compensate for the dog slow CPU, on the Genesis most games don't really need extra processing power. They would benefit more IMO by adding more color palettes, so if an emulator or FPGA clone wants to add support for 32 palettes and then people want to hack the games to support that I think the results could be interesting.

They do other things like decompressing files to keep cart sizes down. Street Fighter Alpha 2 actually has some load times, while the data is being decompressed using the S-DD1 chip inside of the cart. The downside is, that the music is horrendous, because all of the sprite data used up most of the cart's space.

[axel]

Megadrive VDP had native support for a 128 colour mode, by using an external ram chip for the extra palettes. I'm not sure if any emulators support this mode.

There's also a 128k VRAM mode, which is useful because it allows for uploading nearly twice as much data to the VDP during vblank. This alone would make framebuffer based games significantly faster (this includes all FMV games, all Sega CD scaler games, Virtua Racing, and any other game that is handicapped by the amount of tiles it is uploading on-the-fly to the VDP such as games using software 3d graphics). The downside is that the memory is interleaved, so enabling this mode breaks all existing games. But an emulator could create a standard, such as a bit in the header indicating support, that an emulator could interpret and selectively turn the mode on for certain ROMs.

Kind of thinking about it, do any emulators allow for either of these? I think Exodus is the only one that possibly could, given how much research Nemesis put into this, but I don't know if the emulator actually can do it.

On a side note, the 128k VRAM mode was available in the Teradrive and possibly some development hardware (unconfirmed). The extra palette mode may have been used in the arcade C2 hardware (a mostly megadrive based board).

Wow, I had no idea the Teradrive had that. Mentioning the arcade hardware gives me an idea, has anyone ever tried converting MD games over to the System 16A? That would open up a ton of possibilities for ROM hacks with a faster CPU, more colors, more sprites, scaling, translucency etc and it's still authentic to hardware that actually existed back in the day.