Background graphics for Zelda1 MMC5 + CHR-ROM not showing up

[RetroRain]

I tested adding CHR-ROM to Zelda1 with its original mapper, MMC1. And, there doesn't seem to be a problem.

But when I add CHR-ROM to my Zelda1 MMC5 mapper, even if both the sprites and backgrounds are loaded into the PPU Viewer, only the sprites are showing up on the screen. The mapper prep setup is fine. There is no problem at all. For whatever reason, the background tiles are not being drawn to the screen.



Any ideas on what the problem could be? I never had a problem when I made Megaman 2 Optimum (MMC5 + CHR-ROM).

[Disch]

IIRC, Zelda1 uses 8x16 sprites.

When in 8x16 sprite mode, MMC5 uses 3 pattern tables instead of the normal 2.  You can think of it as the normal 2 pattern tables are reserved for sprite usage, whereas the BG uses its own reserved pattern table.

Regs $5120-5127 control the pattern tables for the sprites
Regs $5128-512B control pattern tables for the BG

My guess is you are initializing the sprite patterns, but not the BG patterns.



EDIT:

Also, I found this somewhat humorous:

The mapper prep setup is fine. There is no problem at all.

...except for it's not fine because you have this huge problem.  XD

[RetroRain]

Thank you Disch.  I didn't realize that Zelda was using 8x16, and that the mapper's CHR configuration was sensitive to that.

EDIT:

Also, I found this somewhat humorous:

"The mapper prep setup is fine. There is no problem at all."

...except for it's not fine because you have this huge problem.  XD

Haha.  What can I say?  Ya got me.

It actually would've been fine though if Zelda wasn't using 8x16 mode. 
August 31, 2015, 01:05:32 AM - (Auto Merged - Double Posts are not allowed before 7 days.)
Disch, the other problem I'm having, is because Zelda uses 8x16, the last 4 CHR addresses ($5128 - $512B) which I'm supposed to use for the background graphics, works for both sides, sprite and background.

http://wiki.nesdev.com/w/index.php/MMC5#CHR_Bankswitching_.28.245120-.245130.29

I don't understand why it does both.  It's so stupid.  I can't have background graphics being mirrored on the sprite side.  I want to use 2K CHR pages for each side.  Two 2K on the left, and two 2K on the right.

I honestly don't know what to do, because doing it the other way I had it, doesn't show the background graphics on screen at all.  And this one mirrors it.  What am I doing wrong?

[Disch]

Disch, the other problem I'm having, is because Zelda uses 8x16, the last 4 CHR addresses ($5128 - $512B) which I'm supposed to use for the background graphics, works for both sides, sprite and background.

No, that's just for 8x8 sprites.

Since you have 8x16 sprites... 5120-5127 is sprites... and 5128-512B is BG.

I honestly don't know what to do, because doing it the other way I had it, doesn't show the background graphics on screen at all.  And this one mirrors it.  What am I doing wrong?

Maybe the game has 8x8 sprites for the title screen?  Have you checked?

I know it uses 8x16 during the actual game so I assumed it uses that everywhere, but it might use 8x8 for the title.


Anyway, it works like this:

If 8x8 sprites:
- Use 5120-5127 to swap CHR
- Usual 2-pattern-table setup (left and right) that exist in other NES games
- Do not touch 5128-512B at all.  Or if you do, make sure you write to 5120-5127 afterwards.


If 8x16 sprites:
- Use 5120-5127 to swap CHR for sprites
- Use 5128-512B to swap CHR for BG
- FCEUX pattern table display is unreliable, as it only shows 2 pattern tables and now there are 3



EDIT:

I just checked, the title screen uses 8x16 sprites.  So yeah.. BG and sprites do not share patterns.

[RetroRain]

Coincidentally, I just figured it out on my own before you replied.  It was a pain in the ass, but I figured it out.

What I had to do, was this.

I had to write $5128-$512B first.  THEN, I had to write to $5120-$5127.  As you said, the FCEUX PPU Viewer is unreliable.  Because apparently, I can write to the PPU, but just because it doesn't SHOW UP in the PPU Viewer, doesn't mean that it is not loaded in to the PPU.  That is why I was having the problem.  So, in a sense, at least at the moment, I have a total of 12 custom RAM addresses that I can write to.  I don't know if 4 of them are necessary, but I'm going to keep them for convenience.  I like to see what I have currently loaded into the PPU, so I'll have to write to two sets of addresses instead of one.

What a pain.  I got up early this morning, and just went and experimented with it.  It made no sense to me why it wasn't working.  But appparently, like you said, just because it is not loaded into the PPU viewer, doesn't mean it is not loaded.  I just didn't like the fact that it was mirroring my CHR, because I couldn't have that.

But I do appreciate your help, and your reply.  I'll re-read your post anyway, and keep this thread as a reference.

Thank you so much Disch!

[Disch]

I had to write $5128-$512B first.  THEN, I had to write to $5120-$5127.

To my knowledge... with 8x16 sprites this shouldn't matter.  The order in which these two groups are written to only has an impact when in 8x8 sprite mode.

So, in a sense, at least at the moment, I have a total of 12 custom RAM addresses that I can write to.

Registers are not RAM  ;P   </technicality>

I don't know if 4 of them are necessary, but I'm going to keep them for convenience.

How many of the regs are necessary depends on the size of your CHR swapping.  You said before you wanted 2K swapping, so you need:

$5121, 5123   ("left" sprite CHR)
$5125, 5127   ("right" sprite CHR)
$5129, 512B   (BG CHR)

Other regs in that range are unnecessary.


Note that if you plan on expanding CHR beyond 512K or if you want to use MMC5's Ex-Attribute mode, you'll also have to deal with $5130, which is a whole other can of worms.

[Thanatos-Zero]

You can ask Infidelity more on this matter as he was the first to convert Zelda to MMC5 for his hack and added the Capcom sound engine to boot.

I still wonder of what could have been, because Infidelity wasn't interrested to study the Oracle games so he could create a more rich experience. But this project was for himself and on one else.

As such the end product was a chimera of some sorts, which still suffered from the hard coded limitations from the original game.
Thus no custom bosses, sprites or story for that matter, except the Ganon battle, the Epona mini game and the few new items.
It was frustating for me to say the least, because some of my sprites and even different tilesets for each dungeon couldn't be put in, due the hard coded limits.

Also, since the game is but a mirrored Cocolint Island, playing it alienates me and rather makes me want to play the original Link's Awakening over it instead.

Good luck Rockman,
hopefully your own project will fare better than Infidelity's.

[RetroRain]

Disch, when I was talking about the custom RAM addresses, what I really meant was my custom RAM addresses.   I know what the registers are.  My custom RAM addresses are the free unused memory addresses, in this case, the stack ($100 - $1FF) that are not being used by the game, in which I am using for my CHR pages, which then get written to the CHR registers.

I don't mind that you wanted to post in this thread, instead of PM.  I sent you the PM to get your attention, since the downside of editing a post doesn't let anyone know that there has been an update in thread, and you can't double post until a certain time.

I have used $5130 before when doing Megaman 2 Optimum, so for the most part I know what is involved in using $5130.  It wasn't easy at first, but I figured it out.

I was merely curious though, if the left and right side of the pattern table can be used for sprites, how does one access the second batch of sprites, since the byte limit is #$FF?

[Disch]

With 8x16 sprites, even tiles use the left pattern table, and odd tiles use the right pattern table.

So if you give a sprite a tile of $06, it will draw $06 (top) and $07 (bottom) from the left pattern table.
And if you give a sprite $07, it will draw $06 (top) and $07 (bottom) from the right pattern table.

8x16 sprites work this way always -- not just on MMC5

[RetroRain]

It's good to know.  Thanks for the information.  It was extremely helpful to know these things.  This is a good thread to lookup for future reference.

Thank you Disch!

[Dr. Floppy]

You're using FCEUX 2.2.2, so this may not be relevant.

But FCEUxD_SP 1.07 has a weird timing problem with MMC5 CHR-ROM pages. I've found that it can be bypassed by doing a double-write to $5127 (assuming 8kB CHR-banks and regular 8 x 8 sprites).