What Mapper Did Gradius II Repro Use?

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
What Mapper Did Gradius II Repro Use?
by on (#29868)
Sorry if this has been covered somewhere, but I can't seem to find this information anywhere. Both repro sites don't even have this reproduction available anymore (or am I just hallucinating?).

Was there ever a Gradius II repro, & if so, what mapper did it use?

by on (#29916)
You could try finding the ROM and seeing with an emulator which mapper it uses. It's just an idea...
Re: What Mapper Did Gradius II Repro Use?
by on (#29919)
Jedi QuestMaster wrote:
Both repro sites don't even have this reproduction available anymore (or am I just hallucinating?).

A takedown order from Konami was likely, especially given that Konami might be preparing it for a release on Virtual Console.

by on (#29926)
Gradius 2 (jp) is iNES 25, which is a VRC 4 version. With 8x 1KB chr swapping its not likely someone has put it on a USA mapper like MMC3.

As far as I know, no companies have contacted the repro makers. You would think Nintendo would to protect their IP like Zelda (Outlands) and Mario (SMB2j).

by on (#29927)
Lots of 8 x 1K mapper games swap in 4K or even 8K chunks however, so it may be possible.

by on (#29930)
After taking a very quick look at it playing, I think the 1KB swapping is happening only at banks 5 and 6 ($1400/$1800) so hacking for mmc3 looks possible. The rest is 4 or 8KB swapping. Theres 128KB chr so expanding to 256 and duplicating some banks could get around other swapping problems. I would guess the background half doesn't get swapped in sections.

by on (#29975)
Okay, thanks. I thought there must've been a reproduction made since I saw a custom label (was it Jeremy Red?); I can't find the site anymore.

by on (#30152)
I've never been able to find a working ROM (much less the original IPS patch) of this hack. It honestly might be an aborted project.

by on (#30369)
You could certainly get the FC board and put it in a Gyromite style adapter and put it in a NES case with a fancy label. ;)

-Rob

by on (#30619)
It'd be neat to see a MMC3 hack of it since the PowerPAK doesn't do VRC games. Is there anywhere that details any of these hacks that change what mapper games use? I know there have been other games that were hacked like that EarthWorm Jim pirate.

by on (#30628)
My PowerPak does VRC games albeit I still had to hack them since bus-capacitance gets eaten on the PowerPak setting off copy-protection.
Re: What Mapper Did Gradius II Repro Use?
by on (#30629)
Jedi QuestMaster wrote:
Sorry if this has been covered somewhere, but I can't seem to find this information anywhere. Both repro sites don't even have this reproduction available anymore (or am I just hallucinating?).

Was there ever a Gradius II repro, & if so, what mapper did it use?



I run GameReproductions.com .... I have never had this game for sale....I dont remember offhand, but I think it used a fami only mapper from what I remember.


And correct, Jeremy Red made a label for it.

by on (#30642)
kyuusaku wrote:
My PowerPak does VRC games albeit I still had to hack them since bus-capacitance gets eaten on the PowerPak setting off copy-protection.


Did you make your own mapper config file or was support added recently? Last I checked there was no official support. ='(

By the way, I found a Gradius II hack that runs with MMC3. The game plays, but graphics are messed up. Pretty much all sprites are wrong, the windowing of the ship background on the title is wrong, etc. Not exactly repro worthy. ;p

by on (#30644)
I bet it's possible to hack it to MMC3 quite easily in fact. It shouldn't be too complicated. Maybe doubling CHR to 256 KB is needed, but there is chances that it's not.
If you want to still have it being 128/128 and use a U.S. mapper one could have it hacked to FME-7, which has supperior banking abilities than any VRC mapper I know. There isn't many FME-7 carts available however.

EDIT : I could try to do it if someone wants a MMC3 version but I'd need proper VRC4 doccumentation somewhere, and I cannot find any. It seems like Gradius 2 relies on CPU clock IRQs, which wouldn't be very easy (but still possible) to turn into MMC3 IRQs.

by on (#30648)
I forgot to mention, the Gradius 2 hack I found uses a Trainer so for real hardware it's probably worthless unless you put it in a save file to load with the rom on a powerpak maybe.

If you need VRC info, go here: http://nesdevwiki.org/

Getting the game to "run" is probably easy, but I'm guessing any IRQ or CHR banking will take a bit more effort. But I agree I think a MMC3 conversion is possible and I think that would be pretty sweet. Ofcourse I'd also love to see a Contra (J) conversion to MMC3, because the VRC2b version kicked the ass of the UNROM version.

by on (#30655)
Quote:
Ofcourse I'd also love to see a Contra (J) conversion to MMC3, because the VRC2b version kicked the ass of the UNROM version.

This is already done.

This is weird, for some reason I was sure that all non-Nintendo mappers weren't doccumented on the wiki. I didn't even check there ;-) I'll try to convert Gradius II to MMC3, but I won't be able to test it on hardware right now because I have no EPROM programmer at this time, I'll have to buy a new one.

EDIT : This whole adress pin swap thing is really confusing, Konami really got nasty here, but I'll still try to do something.

by on (#30658)
Okay, I've spent my day hacking the game to MMC3 with sucess.
I still haven't completed the game as a whole to see if there is scrambled graphics later, but for now I encountered none, I haven't had to change anything in the CHRROM (yet). The game works perfect in all inacurate emulators (including Nesticle !), but I've the two following issues :

- Nintendulator : The status bar is shaking by one pixel for some reason. I cannot find why, I always setup the IRQ at the exact same time during NMI.

- Nestopia : This is the weirdest thing I've ever seen in emulation. The graphics are scrabled at opening for some reason I don't know, they work perfect in any other emulator. But the really weird thing is that as soon as the game starts, graphics are perfect, but the player dies immediately, and again, again until it's game over. There is absolutely nothing to do about this !! This is really the thing that makes we wonder what the f... is happening.

Also the game uses a 2KB SRAM I think so TSROM will be needed at least, I guess. Or add a 2KB RAM on a TLROM board yourself if you want.

by on (#30659)
I'll test them on the Powerpak if you like. Ignore my private message about Contra as I replied before reading this. Sweet stuff man. Send me a patch for Gradius 2 and I'll test it out.

by on (#30660)
Okay, I've temporarly updated data of the last 8k PRG bank ($e000-$ffff) here http://jonathan.microclub.ch/contra/gradius2_patch.bin.
To run the game as an iNES ROM just go with an hex editor to offset $1E010, paste this (overwriting previous data), and change the header so that it is mapper 4 and not mapper 25 (so that nobody can call me illegaly distributing the ROM).
I really wonder how it looks on real hardware, status bar is probably shaking, I tried change the timing a bit but I couldn't get rid of this shaking. Tell me if your ship is always destroyed as it is in Nestopia, this is really weird.

by on (#30661)
I got the same results on Nestopia as you. Ship dieing always. Also the first screen of the ship had all wrong gfx. Nintendulator didnt have either problem. I'm assuming you know the sprites are messed up. I'm going to try it on the powerpak shortly.

On Powerpak it performs like it does on Nintendulator. The ship doesn't constantly explode. Just the sprites are wrong, and the status bar jumps around a whole bunch. More so when I got past the first space area and where the red fireball planetoids were and was shooting lasers.

by on (#30662)
Bregalad wrote:
To run the game as an iNES ROM just go with an hex editor to offset $1E010, paste this (overwriting previous data), and change the header so that it is mapper 4 and not mapper 25 (so that nobody can call me illegaly distributing the ROM).

Do you know how to work an IPS patcher?

by on (#30664)
tepples wrote:
Do you know how to work an IPS patcher?

Yeah but for some reason I didn't want to go though the trouble of making a ips file.

I now played though the whole game (savestates rules !!) and yeah, a lot of sprites are screwed on later levels (comes from the wrong CHR bank), but everything is perfect on the first level, and I don't know how an human person is able to pass it on the real hardware (who lack savestates) even with the 30 lives code. The ending has screwed up graphics as well because the game swaps bg and sprites banks to normal via $2000 (I've made them backwards so that MMC3 IRQ counter works). I don't know if there is any sprites from the BG bank exept the cursor in the secret sound mode. (if there is any during gameplay this may screw IRQs up). Finally I've got the game freeze randomly several time when too much objects are on screen, don't know why (with VirtuaNES).

I guess I could go through the trouble of editing the game's CHRROM in order to work on MMC3, but I fell I've done enough work with this game today.

Anyone is free to try it, for information the games swaps "virtual 8 KB banks", which are consisted of 8 bytes of 1 KB bank. The game have a huge table of 256 bytes (that's 32 "virtual" 8 KB banks) located in the main PRG bank at $EA1D (location in iNES ROM is $1EA2D). Bytes comes in this order : BG part 1, BG part 2, ..., Sprites part 3, sprites part 4. In the MMC3 version sprites part 2 and sprites part 4 are ignored, and are "substitued" by sprites part 1 + 1 and sprites part 3 + 1 instead, which don't always works. I guess one have to try to change the order of the banks, possibly duplicating data so that each numbers in sprite data are consecutive numbers (this can be applied to the original ROM), and thrus re-arrange the CHRROM as needed. Note that I'm unsure if dynamical BG animation is based on this table or not, at the end of the first level the games changes the BG bank used via IRQ, so I guess it's not, it adds or substract from the "normal" bank.

Also if anyone has an idea why a MMC3 IRQ could vary randomly by an amout of one (resulting in a shaking bar) I'm listening. I've got a lot of shaking bars in VirtuaNES, and weirdly when the real bar is shaking it's not in VirtuaNES. So VirtuaNES is always wrong, that's kind of fun.

Finally, I found interesting how Gradius II handles its IRQs. There is always a IRQ triggering at 2 different positions on the screen, regardless of other parameters. Then the IRQs does something like change the CHR banks, or change scrolling to the status bar, only if the main game ordered it so. That's quite of a good idea I think.

by on (#30666)
I'm guessing you must have changed the CHR, cause the sprites for me are always messed up with just that 8kb prg change. If you're done with it, and not just done with it for the day, I'd love to see any notes and get a copy of where you are at. I'd like to see the first level with correct sprites.

by on (#30667)
Bregalad wrote:
I now played though the whole game (savestates rules !!) and yeah, a lot of sprites are screwed on later levels (comes from the wrong CHR bank), but everything is perfect on the first level, and I don't know how an human person is able to pass it on the real hardware (who lack savestates) even with the 30 lives code.

Have you ever watched any DoDonPachi or Espgaluda videos on YouTube? Some people who play scrolling shooters are obse^H^H^H^H dedicated enough to survive that kind of enemy firepower.

by on (#30668)
Could the exploding ship have anything to do with Konami's infamous copy protection? I don't know if this game has it, but some other games become either much more difficult (Yume Penguin Monogatari) or entirely unplayable (Kid Dracula; enemies and sprite platforms disappear at level 2) if they're tampered with. Kinda weird that it wouldn't happen on other emulators, though.

by on (#30669)
BMF54123 wrote:
Could the exploding ship have anything to do with Konami's infamous copy protection? I don't know if this game has it, but some other games become either much more difficult (Yume Penguin Monogatari) or entirely unplayable (Kid Dracula; enemies and sprite platforms disappear at level 2) if they're tampered with. Kinda weird that it wouldn't happen on other emulators, though.


Considering the exploding ship fails to happen on the actual NES when I tested, I doubt it's that protection in Nestopia.

by on (#30674)
MottZilla wrote:
I'm guessing you must have changed the CHR, cause the sprites for me are always messed up with just that 8kb prg change. If you're done with it, and not just done with it for the day, I'd love to see any notes and get a copy of where you are at. I'd like to see the first level with correct sprites.

I didn't remember changing anything outside of the main PRG bank, but I guess I was wrong, because this was needed to swap pattern tables, I've done an IPS Patch instead (apply on the original Gradius II) hoping you'll get better results.

Note that my original Gradius II ROM has C71D4CE7 as PRG CRC and 537B6F6A as CHR CRC, I don't know if there is any variants floating arround.

I'll try to change the order of CHR banks todays, and that's the only thing left to do, among with fixing that damn shaking status bar, and removing the point where the games sets BG pattern table to 1 again at the ending.
I guess I'll try to figure this out today, but I cannot guarantee anything. Feel free to try change the CHR banks, I've tell above how they function (at least for most part of the game), the game just swaps them in 8 KB chunks made of 8 1KB chunks.

EDIT : I've fixed the exploding ship problem. This was due to SRAM to be disabled by default in Nestopia, and enabled by default with other emus. If there is no SRAM, the ship explodes, Konami is pretty cool.

by on (#30675)
Okay, guys I have very good news. The hack is 100% finished, and graphics should in theory be 100% intact on MMC3, and that with still 128 KB CHR ROM a bit rearanged (altrough I haven't played through the whole game again yet), status bar is no longer shaking (this was due to the IRQ to be set before the game does it's nametable updates, who caused the counter to ocasionally clock during VBlank !).

I've updated my IPS file, tell me if it works on real hardware, and if it does, I'll update my Contra page to fix the spelling errors and turn it into a dual Contra/Gradius II page.

by on (#30685)
There are 2 dumps of Gradius 2 I know of. I'll check if they are that different. I'll also test out the ips patch. I'll edit or post again when I have tested.

Edit: Initial tests with my Gradius 2 (J) show good sprites and all, really everything looked flawless, on Nestopia so far. I will test on Powerpak next. But I compared the alternate dump of Gradius 2. It seems to have a different CHR. CRC32 is 7E31C1D7. That's for the CHR, not the whole rom. Rom name was Gradius 2 (J) [a1].nes

Oddly, the program roms are identical. And there's no visible difference. But i'm not sure if it wouldn't work on it. I'll test it later. But so far it looks like you've done a great job, now I just need a game genie code to help me play through the whole game. ;)

Edit:
From NESTopia

File: Gradius 2 (J).nes
Directory: D:\ROMS\NesFC\Japan\
CRC: 0x5ADBF660
Region: NTSC
Board/Chips: KONAMI VRC4 Y
Mapper: 25
PRG-ROM: 128k, CRC: 0xC71D4CE7
CHR-ROM: 128k, CRC: 0x537B6F6A
Mirroring: Mapper Controlled
Battery: No
Trainer: No
Condition: Good

---

File: Gradius 2 (J) [a1].nes
Directory: D:\ROMS\NesFC\Japan\
CRC: 0x779158DD
Region: NTSC
Board/Chips: KONAMI VRC4 Y
Mapper: 25
PRG-ROM: 128k, CRC: 0xC71D4CE7
CHR-ROM: 128k, CRC: 0x7E31C1D7
Mirroring: Mapper Controlled
Battery: No
Trainer: No
Condition: Good

Both work with the MMC3 ips. Atleast they play into the first level.

About the status bar, it stays where it should, except when there are alot of sprites on screen. Then it will glitch. I'll have to try the original rom to see if that happened in it or not. But it's still perfectly playable. Haven't tried it on Powerpak yet.

GTSVLGLA - Start with 99 Lives

by on (#30688)
You can do the UUDDLRLRBA code at title screen to get 30 lives, however the game is still almost as hard because you restart back on each live (unlike in Life Force where this code makes the game significantly easier).
Quote:
About the status bar, it stays where it should, except when there are alot of sprites on screen. Then it will glitch. I'll have to try the original rom to see if that happened in it or not. But it's still perfectly playable. Haven't tried it on Powerpak yet.

Yes. I've noticed this too, I don't know why. At some points, there is sprites from the BG pattern table who accidentally clock the IRQ counter, making the status bar higher. I'm a bit screwed here, either the status bar is wrong, or either I force the sprite to be in the right pattern table, then the status bar will be right but the sprites will look wrong.

by on (#30690)
Bregalad wrote:
You can do the UUDDLRLRBA code at title screen to get 30 lives, however the game is still almost as hard because you restart back on each live (unlike in Life Force where this code makes the game significantly easier).
Quote:
About the status bar, it stays where it should, except when there are alot of sprites on screen. Then it will glitch. I'll have to try the original rom to see if that happened in it or not. But it's still perfectly playable. Haven't tried it on Powerpak yet.

Yes. I've noticed this too, I don't know why. At some points, there is sprites from the BG pattern table who accidentally clock the IRQ counter, making the status bar higher. I'm a bit screwed here, either the status bar is wrong, or either I force the sprite to be in the right pattern table, then the status bar will be right but the sprites will look wrong.


Yes, the 30 lives code definitely makes the game harder for that reason. If you get every power up pod in level 1, the rest of the game isn't that hard. I used to think level 1 was impossible until I strived to get all the pods. Once I set out to do that, I beat the game in a day or two with no 30 lives code.

-Rob

by on (#30691)
$0501, Set to 05 and you have infinite force field. Helps for testing through the game. You can still die by crashing into things though.

The status bar thing is somewhat annoying. I don't understand what you mean though. I do see how when certain enemys are on the screen that's when it has problems. Like the Fire dragons and the fire birds. Somehow that's triggering the IRQ and messing up the scroll changes? Does this have something to do with the way MMC3 banks CHR or something?

The status bar was madly flicking on me in level 2 and then the cpu crashed. ='(

by on (#30692)
Quote:
The status bar was madly flicking on me in level 2 and then the cpu crashed. ='(

Yeah, same here, this is really annoying.

The fire birds comes from a BG pattern table, for some reason, Konami just decided so when they develooped the game. On the MMC3, having sprites from the BG pattern tables clocks the IRQ timer more than one per scanline, so the IRQ happens too soon, and then the status bar goes too high. This happen at the end of level 1. There is no way to fix this bug because it's due to how the MMC3 works, I can force the sprites to be from the sprite pattern tables, but the fire birds won't look like fire birds anymore.

What happen in level 2 is probably another unrelated problem. When there is too much enemies, the CPU cannot perfom frames fast enough, and so each frames takes 2 frames. Since Konami games does all in their NMIs, there is no NMI triggering at the second frame since the first is still running. For some reason, I suppose IRQs aren't initialised proprely, but the counter continue to run on its own, and will trigger NMIs faster than supposed, resulting as the status bar being in the middle of the screen (however always at the same place). I don't know why this problem woudln't happen with the VRC4 as well.
I don't have a single idea why the CPU crashes ocasionally when it slow downs. Probably something with the stack ? Unfortunately, I probably will ever be able to fix that couple of bugs : They looks much more complicated than anything that happened before.

by on (#30704)
I see what you mean now about the fire birds are on the BG table size. But what I don't get is how that is even possible. Some sort of trick to allow for more room for sprites? If there was room couldn't you bank the birds in on the sprite side inplace of something not used at the time? Or is it just an impossibility on MMC3? I hope you can figure out a solution to some of the issues. Either way the work you've done on it is awesome.

by on (#30707)
MottZilla wrote:
I see what you mean now about the fire birds are on the BG table size. But what I don't get is how that is even possible. Some sort of trick to allow for more room for sprites?

When the PPU is set to use sprites that are 8x16 pixels in size (as opposed to 8x8), it's possible to use patterns from the background side, as well as from the sprites side. Even indexes result in patterns from one side while odd indexes result in patterns from the other side. This has nothing to do with mappers, this is a native feature of the NES.

Since MMC3's scanline counter functions by counting access to the background patterns, when sprites are read from that side the MMC3 mistakes them for background pattern fetches and that screws up the counter.

Quote:
If there was room couldn't you bank the birds in on the sprite side inplace of something not used at the time?

Yes, this is possible, but all the possible CHR combinations might need more space than what's avaliable in CHR-ROM...

Bregalad, I don't know where you find the patience to do this kind of work. You're doing well!

by on (#30708)
Thanks for explaining that. So it's essentially a known bug with the MMC3? And the only way to fix that would be some attempt at trying to make it only read sprites from the one side.

by on (#30709)
Quote:
So it's essentially a known bug with the MMC3?

Yes, and I could force it to read sprites only from the sprites side, but then the sprites will look wrong. I could try to force the CHR on the sprite side to match with the BG side in the end of level 1, but I don't think it will work, as other sprites will probably look corrupted then.
Unless I can hack the game to work with sprite zero hit, which is very unlikely, there is no way it'll work exactly fine on MMC3.
Alternatively, maybe it's possible to hack it to MMC5 or something, as MMC5 has the power to emulate almost every mapper in the world, but I doubt this will be usefull to anyone.
I guess I'll just leave this bug.

However, the other bug (when CPU slowdowns) bothers me, I'll try to fix it someday, by tracing code with Nintendulator (hoping to get a CPU crash while tracing !). For some reason I don't feel like doing it right now, I haven't advanced my NES project for a few day cause of Gradius II and after all making games is much funnier than hacking an existing game (but both are fun).

EDIT : I shink the status bar shouldn't jump when the CPU slows down now, check again my IPS patch. However, I don't know if the crash problem will still occur, because I haven't been able to log a crash to know what caused it. The status bar still jumps when fire birds are on screen, but I really cannot do anything about it now. Also I won't be here this weekend so don't exept me to answer immediatly or something.

by on (#30719)
I'll give the new patch a try on the Powerpak. My test in emulators didn't have it jumping from I suppose it was slowdown from the fire dragon things which before it did jump.

What I mean by reading sprites from the sprite side is, are there any sprites that are banked in on the sprite side that aren't in use during the fire birds? Atleast in the first level there don't appear to be any other enemys on screen at the time. So couldn't you change the bank that some early enemys use for the firebirds while they are in use? I guess you'd have to play all the levels and make sure it's not possible for both things to be on screen at the same time.

And I agree, hacking it to MMC5 would be silly since the mapper is only found in 1 NES game. And that NES game is not one to be sacrificing for another. :p

Edit: I tested the first patch, and managed to make it crash in the first level by causing slowdown. I did the same thing in the new patch and it didn't crash. I'll do further testing, but I think your changes make the game stable now, and the remaining issue would be the sprites on BG side.

Edit: I went through to level 2 and again, no crashing due to slowdown. But I noticed the ship eating plant things cause the status bar to bounce around too, I suppose they are like the firebirds. But while they are on screen, there are no other enemys... so I don't see why they need to be on the BG side.

by on (#30842)
is this now 100% complete? I dont wanna play it until its good to go =) Thanks Alot

by on (#30852)
Quote:
is this now 100% complete?

Not yet.
Quote:
And I agree, hacking it to MMC5 would be silly since the mapper is only found in 1 NES game. And that NES game is not one to be sacrificing for another. :p

In fact there is quite a few MMC5 games, but only one is rather common, and yes you wouldn't sacrify this one. The other rarer MMC5 games are rather bad in my opinion (Laser Invasion and Koei strategy games).
Quote:
Edit: I went through to level 2 and again, no crashing due to slowdown. But I noticed the ship eating plant things cause the status bar to bounce around too, I suppose they are like the firebirds. But while they are on screen, there are no other enemys... so I don't see why they need to be on the BG side.

Well there is other enemies maybe not at the exact same time, but the game doesn't change the ROM bankswitched in, and I cannot change it myself as I haven't coded the levels for this game. That's why making games is funnier than hacking them in my opinion, you actually are free of what you do.
I'll try to log a crash to know what happens, and *maybe* to fix this sprites/BG thing but I really don't think I'll ever be able to fix this without adding graphics glitches somewhere.

by on (#30857)
Sorry, brain fart here...what is the other MMC5 game? I can't remember. Anyway, Laser Invasion wouldn't be that bad to sacrifice for a MMC5 Gradius 2.

-Rob

by on (#30861)
Castlevania 3 (JPN is VRC6).

by on (#31066)
Castlevania 3 is the only MMC5 game that was released outside Japan as I recall. So I don't see the point in hacking up a famicom cart with an MMC5 to put Gradius 2 on it.

Like I said before, I think the game is perfectly stable now, just that you have to put up with the issue of sprites and the status bar jumping.

I still think the best thing to do would be to try to alter the game to bankswitch the sprites and avoid the error that way. Seems like the only reasonable option. MMC5 isn't reasonable. :p

by on (#31069)
MMC5 is the best chance at success, that or FME7. And there are 4-5 games that use MMC5, one game that uses FME7 in the US. So I think that makes it the most reasonable. FME7 is implemented in the PowerPak while MMC5 is not however.

by on (#31074)
No, the game still crashes regularaly and COMPLETELY randomly on sprite overload. I am unable to find out why, and that problem is unrelated to 8x16 sprites and jumping status bar.
I won't be ever able to fix any of those problems. The game relies on sprites on the same adress to show something from BG patten and something from sprite pattern at the same time, unless I can completely reverse-engineer how sprite data works in Gradius II, which would be way too hard and time consumming, I won't be able to fix the jumping status bar.

For the crashing problem I tried to log it and after one million of tries the only sucessfull thing is that the game does an indirect jump to nowhere. It's unclear where it gets its data from, but that's from a place I haven't modified.
Also the game display completely wrong attributes for later levels, I don't know why bacause I made sure I know everything I modified, and I'm tired of this and officially give up Gradius port to MMC3 here.

by on (#31141)
Do you have any notes on what you did you could make public incase anyone else wants to try to take it further?

And I realize now that MMC5 isn't a bad idea as there are other games, I didn't realize they had US releases. Maybe stepping it up to MMC5 wouldn't be a bad idea if you wanted to make a repro. FME-7 would make sense if you aimed or the powerpak. I didn't even realize the PowerPAK supported it till now.

by on (#31200)
I guess hacking Gradius II to MMC5 wouldn't be too hard, maybe it would even be possible to redirect SRAM to EXRAM so that $5cxx is used instead of $6xxx, so that ELROM would run it, but since Gradius II uses 2k of SRAM (however, not all of it is used) and MMC5 have just 1k of EXRAM, I doubt this is possible, in that case EKROM (Gemfire) or any supperior MMC5 board will be needed. I doubt anyone would test it on real hard, since MMC5 is really a comfortable mapper to code for, hacking the game to it should be really easy in fact. If anyone would be ready to sacrifice a Koei game for it say it so and I'll hack the game to MMC5.

I have a few notes I guess, just one page where I noted important adresses in PRGROM :
- PRG swapping is (originally) done arround $fcdc, and $fee6.
- CHR swapping is done at $fe3b and $fb78, and CHR bank swapped are in RAM at $7f0-$7f7 (for all 8 1kb chunks respectively).
- IRQ countown value is set at $fc10
- The IRQs are enabled at $fa90
- IRQ routine is at $fb35

And about the game workings, all there is to know is that :
- The game always have IRQs triggering at scanlines 107, 203 and 225. Whenever the game actually do something only depends of the IRQ routine, which typically change CHR banks and/or change scrolling for the status bar. During gameplay, the game usually display blank tiles (but still have rendering on) from scanline 225 to end of the frame, which is fun.
- Since Konami mapper have really different IRQ working than MMC3 I used some dirty ticks to have them work in the closest way I could do it (but I haven't had much experience with MMC3 IRQs prior to this hacking).
- The game does everything in its NMI routine, like most Konami games. The main programm spends 100% of its time to generate pseudo random numbers, which is kind of weird.
- Originally, the game take all most of its sprite from pattern table 0 and all BG from pattern table 1. It always used 8x16 sprites. I hacked the game so that both pattern tables are reversed (MMC3 IRQ counter), but there is still some sprites fecthed from the left pattern table.
- The game switched CHR banks in pseudo 8KB banks, formed by 8 values of smaller banks. In theory, the game could almost have 256 KB CHRROM and only switch the whole 8 KB chunks at once like CNROM does, exept when banks are changed during IRQs. I've already posted the location of the big 256-byte CHR table above, I haven't noted it on paper.
- The mid-screen IRQ at scanline 107 is used on the pre-title screen and sometimes during gameplay too. The IRQ at scanline 203 turn off sprites, and set another BG bank set for the status bar. Eventually the IRQ on 225 switch all black CHR banks in the BG pattern table. All those switches bypass the normal pseudo-8KB engine mentionned above.

In order to make the game work with the MMC3's 2kx2 - 1kx4 CHR sheme, I've changed the banks and their order in order from them to work in a more suitable way. I've noted this in a text file I'll paste just below. Now everyone should know everything needed to hack Gradius II. Also I'll let the IPS patch on my server for some more time in case it can be helpfull to anyone, but I won't let it forever (until someone can made a stable version of it, in that case I'll actually made a page about it like Contra).

Code:
Gradius II sprite CHR banks :

OLD      NEW
40 41 42 43   40 42
40 41 44 45   40 44
40 41 47 48   40 48
40 41 47 64   40 4a
40 41 49 4a   40 64
40 41 65 4a   40 66
40 41 70 43   40 72
40 41 42 43   40 42
40 41 42 43   40 42
40 41 42 43   40 42
40 41 44 46   40 46
40 41 44 46   40 46
40 41 44 46   40 46
40 41 47 48   40 48
40 41 47 48   40 48
40 41 47 64   40 4a
40 41 49 4a   40 64
40 41 49 4a   40 64
40 41 49 4a   40 64
40 41 49 4a   ....
40 41 49 4a
40 41 49 4a
40 41 66 4a   40 70
40 41 65 4a   40 66
40 41 42 43   40 42
40 41 42 43   40 42
40 41 70 43   40 72
40 41 47 64   40 4a
40 41 47 64   40 4a
40 41 65 4a   40 66
71 72 73 74   7c 7e
71 72 73 74   7c 7e

USED (19) : 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 4a, 64, 65, 66, 70, 71, 72, 73, 74
FREE (6) : 6B, 6C, 7c, 7d, 7e, 7f

GROUPS (12)

40 41   UNCHANGED AT $40, $41
42 43   UNCHANGED AT $42, $43
44 45   UNCHANGED AT $44, $45
44 46   RELOCATED AT $46, $47
47 48   RELOCATED AT $48, $49
47 64   RELOCATED AT $4a, $4b (*)
49 4a   RELOCATED AT $64, $65
65 4a   RELOCATED AT $66. $67 (*)
66 4a   RELOCATED AT $70, $71
70 43   RELOCATED AT $72, $73
71 72   RELOCATED AT $7c, $7d
73 74   RELOCATED AT $7e, $7f

BG bank at $4b RELOCATED AT $6b
BG bank at $67 RELOCATED AT $6c
Re: What Mapper Did Gradius II Repro Use?
by on (#139474)
I know this is an old thread, but the URL''s mentioned in this post are now 404'd, has anyone ever attempted to pickup on this topic ?
Re: What Mapper Did Gradius II Repro Use?
by on (#190254)
sorry for bumping this old thread, but does anybody still have those IPS patches?
the links in the thread are all dead
Re: What Mapper Did Gradius II Repro Use?
by on (#190262)
DutchC64 wrote:
sorry for bumping this old thread, but does anybody still have those IPS patches?
the links in the thread are all dead



I never received a response to my last inquiry. I still haven't located the patches either.
Re: What Mapper Did Gradius II Repro Use?
by on (#190287)
I don't think Bregalad will ever share this again.
The problem is that there were some people selling his ROMs conversions for high profit.
He just didn't like this at all and now he just don't endorse repros.

Maybe MottZilla has a copy of it?

I have a Gradius2 ROM converted do MMC3, it's not Bregalad's version, and it's very badly done.
I can generate an IPS and post here later, if needed.
Re: What Mapper Did Gradius II Repro Use?
by on (#190290)
Fisher wrote:
I don't think Bregalad will ever share this again.
The problem is that there were some people selling his ROMs conversions for high profit.
He just didn't like this at all and now he just don't endorse repros.

Exactly, thank you for summing up my thoughts :)

Back then when this was a thing (in 2008) the repro market was still low/not really a thing. But this is only half of why I don't share it any longer, the other reason is that :

Quote:
and it's very badly done.

My version was also "very badly done". Some sprites were still messed up (from the wrong bank), the status bar jumped vertically like crazy because some 8x16 sprites came from the BG pattern table, cleating additional clocks to the MMC3's IRQ counter. This is a limitation of the MMC3 and without a major rewrite of the game it can't be worked around, since the game was designed to use more than 256 sprite tiles simultaneously. Also the game crashed randomly on heavy CPU usage, and despite having spent time trying to resolve the problem I didn't.

So, in summary, the project of convert Gradius II to MMC3 was a failure and was doomed to fail because the MMC3 is not adapted to Gradius II without significant changes in the game. Also mapper hacking is not very interesting exept for reproduction, which I am not in favor of anymore, because of the problem it can be sold for high profit.