What Mapper Did Gradius II Repro Use?

A place that you can discuss reproduction of classic titles or "licensed-for-reproduction" homebrew for personal use.

Moderators: B00daW, Moderators

Forum rules
1. NO BLATANT PIRACY. This includes reproducing homebrew less than 10 years old, with the exception of free software.
2. No advertising your reproductions, with the exception of free software.
3. Be nice. See RFC 1855 if you aren't sure what this means.
rbudrick
Posts: 284
Joined: Wed Sep 21, 2005 3:20 pm

Post by rbudrick »

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).
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
User avatar
MottZilla
Posts: 2837
Joined: Wed Dec 06, 2006 8:18 pm

Post by MottZilla »

$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. ='(
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Post by Bregalad »

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

Post by MottZilla »

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.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

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.
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!
User avatar
MottZilla
Posts: 2837
Joined: Wed Dec 06, 2006 8:18 pm

Post by MottZilla »

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.
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Post by Bregalad »

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

Post by MottZilla »

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.
Tormenter
Posts: 306
Joined: Sat Jun 03, 2006 9:17 pm

Post by Tormenter »

is this now 100% complete? I dont wanna play it until its good to go =) Thanks Alot
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Post by Bregalad »

is this now 100% complete?
Not yet.
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).
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.
rbudrick
Posts: 284
Joined: Wed Sep 21, 2005 3:20 pm

Post by rbudrick »

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
User avatar
kyuusaku
Posts: 1665
Joined: Mon Sep 27, 2004 2:13 pm

Post by kyuusaku »

Castlevania 3 (JPN is VRC6).
User avatar
MottZilla
Posts: 2837
Joined: Wed Dec 06, 2006 8:18 pm

Post by MottZilla »

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
User avatar
kyuusaku
Posts: 1665
Joined: Mon Sep 27, 2004 2:13 pm

Post by kyuusaku »

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.
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Post by Bregalad »

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.
Post Reply