[Vanya]

Hi. I'm working on a small addendum patch for the Akumajou Densetsu translation's title screen.
I ran out of space in the tile map to add in the "sprocket holes" that are used in the intro sequence, not to mention that I'd have to change the background palettes to accommodate one more color that doesn't really fit the rest of the palettes well.

So I decided a better solution would be to simply draw the "sprocket hole" sprites using the OAM since there should be plenty of space for the 28 sprites I'd need to draw. However, I immediately noticed something I've never seen before and don't know how to deal with.

The OAM in AjDen is constantly being written to in a way that doesn't make any sense to me at all.
The title screen only has two sprites visible on it; the left and right sides of the "Holy Cross" sub-weapon which is used as a cursor. The actual attributes for these sprites are there, but they're constantly shifting around the OAM in a pattern. And on top of that instead of the rest of the space in the OAM being empty it's filled copies of the two sprites written to Y-position F4.
The code that writes to the OAM is constantly running so I haven't been able to make heads or tails of where the hell it's pulling attributes from much less how to get it to draw additional sprites. So, please help & thanks in advance.

[snarfblam]

I've seen this before. It's probably a sprite shuffling algorithm to mitigate sprite flicker. One way or another it probably "shuffles" the OAM entries by doing something like adding (a suitable prime number * oam size) to the oam pointer instead of just adding (oam size). The F4 y-position, of course, is just how the oam is "cleared" each frame.

Try breaking on writes to the oam cache and you should be able to find the routine(s) used to write oam and advance the pointer.

[Vanya]

Thanks a lot!one more quick question... what's the OAM cache?

[henke37]

Games very often keep a copy of the OAM region in normal ram so that they can access it without worrying about timing requirements. The HBlank handler then copies the entire region to the real location each frame.

[Vanya]

Ah, I see. AjDen seems to have the OAM mirrored in at least 4 places from what I can see.

[KingMike]

Every NES game I've ever looked at keeps a sprite/OAM table in RAM.

I hear part of is that Vblank time on the NES is so limited, it's easier to just use the sprite DMA register $4014 to copy a block of 256 bytes to sprite RAM. (write the value nn to $4014 to copy page $nn00 to sprite RAM).
The reason I've heard is that the sprite RAM in the NES is not auto-refreshed, so games need to manually refresh the RAM often.
As to why a game would keep 2 sprite tables? Maybe the 8 sprites per line limit (when the sprite limit flag is set, swap to the other sprite table? This is what causes the flicker that allows more semi-visible sprites on the screen at once.)

[Vanya]

Megaman 5 was sooo much easier to hack than AjDen.

[Bregalad]

This is called Sprite Cycling.
The game just write the sprites to shadow OAM (usually $200-$2ff) in a "random" order, so that if sprites will dissapear because there is more than 8 on the same scanline, they will disapear "randomly", instead of having the same sprite always completely hidden. Konami games does this in a particularly elegant way.
The game just have this system always active, even when there is no risk of having more than 8 sprites on the same line.

You just need to find the routine which writes to $200-$2ff and from where it maps the sprites.

[snarfblam]

Ah, I see. AjDen seems to have the OAM mirrored in at least 4 places from what I can see.

NES has $800 bytes RAM, mirrored four times, so the OAM data should appear four times, $800 bytes apart, in a memory viewer, but will actually be the same RAM. You should see it at $200, $A00, $1200, and $1A00.

[Vanya]

Thanks for the info guys. I think the first thing I should do is disable this sprite cycling code.
Then it should be a simple task to make the changes I need to make.