nesdev.org

Im trying to add MMC5 emulation to my emu so my first target is "Castlevania 3"
I have a couple of questions i hope to find help since background when i start playing is not looking good.

About CHR swapping the wiki says: - What does that "ONLY" mean?

Maybe is noob i know, but i know im misunderstading something. I cannot find a way the get the background looks fine.

I have also noticed that the game is trying to use Extended Ram as a nametable, the reason i have an extra 1K array. I change my function pointers to something like "RadExRam(addr)" and a "WriteExRam(addr)" but it always write zeroes "0"!!

Any idea where the problem could be? thnks.

it means that when 8x16_sprite is enabled (PPU reg 0, bit 5 = 1), then BG and OAM uses different registers
when 8x16_sprite is disabled (PPU reg 0, bit 5 = 0), both BG and OAM use the same set of registers.

this is basically the only thing you need for Castlevania 3. OTOH, CV3 does not really use Extended RAM mode (the latter is used extensively by JustBreed and by Koei games)

I can't get it to work. I don't know what im doing bad.

I even created a separated 4K for sprite (OAM) so 5120-5127 swap into this area and all oam reads goes to this area.
I swap 512A-5128 separatly for bk graphics.
Sprites look fine but BG doesn't when i enter the game.
I really don't know what im missunderstanding and it seems simpler that what could be expected.

etabeta wrote:it means that when 8x16_sprite is enabled (PPU reg 0, bit 5 = 1), then BG and OAM uses different registers
when 8x16_sprite is disabled (PPU reg 0, bit 5 = 0), both BG and OAM use the same set of registers.

this is basically the only thing you need for Castlevania 3. OTOH, CV3 does not really use Extended RAM mode (the latter is used extensively by JustBreed and by Koei games)

How does the MMC5 know that 8x16 sprite mode is active? I'm familiar with the basics of the PPU fetch patterns, but nothing seems to be standing out.

natt wrote:How does the MMC5 know that 8x16 sprite mode is active? I'm familiar with the basics of the PPU fetch patterns, but nothing seems to be standing out.

I have the same question, as well as the question of what possible internal logic causes ExRAM to act the way it does when used as extra nametables.

natt wrote:How does the MMC5 know that 8x16 sprite mode is active? I'm familiar with the basics of the PPU fetch patterns, but nothing seems to be standing out.

It could be (and probably is) keeping its own copy of writes done to the PPU registers $2000 and $2001 (the relevant bits).

thefox wrote:

natt wrote:How does the MMC5 know that 8x16 sprite mode is active? I'm familiar with the basics of the PPU fetch patterns, but nothing seems to be standing out.

It could be (and probably is) keeping its own copy of writes done to the PPU registers $2000 and $2001 (the relevant bits).

Yes, I thought it might be the possibility, but that leads to wonder what happen about mirroring of PPU registers. All of this could be tested by connecting the cartridge to special testing devices that would pretend to do such things, so it is a falsifyable hypothesis that can be tested using a scientific method.

etabeta wrote:it means that when 8x16_sprite is enabled (PPU reg 0, bit 5 = 1), then BG and OAM uses different registers
when 8x16_sprite is disabled (PPU reg 0, bit 5 = 0), both BG and OAM use the same set of registers.

this is basically the only thing you need for Castlevania 3. OTOH, CV3 does not really use Extended RAM mode (the latter is used extensively by JustBreed and by Koei games)

I fixed it. The problem was with the IRQ counter. Now im going for Uncharted Waters... wich i think will be another difficult problem.
Thanks for the help.

nice catch!

concerning the question of how the MMC-5 is aware of what the PPU is fetching, I have no clear answer, even if I'd guess there is some counter which monitors PPU accesses as others have suggested. some hardware tests would be of help

concerning Uncharted Waters, you shall first implement Extended Attribute Mode. This alone should give you some gfx in most Koei titles. Uncharted Waters also requires correct PRG-RAM mapping and paging for its sprites.

about Ex1 mode, Just Breed is a good test case, because it needs you to use bits 0-5 of ExRAM as CHR additional register, but only for BG and not for sprites (or sprites would be glitchy)

I've added support for most features of MMC-5 to MESS last weekend, and that's why I have fresh in mind the details (even if my code still have some PRGRAM bankswitch problem, and as a result a couple of Koei titles are still not working)

etabeta wrote:concerning Uncharted Waters, you shall first implement Extended Attribute Mode. This alone should give you some gfx in most Koei titles. Uncharted Waters also requires correct PRG-RAM mapping and paging for its sprites.about Ex1 mode, Just Breed is a good test case, because it needs you to use bits 0-5 of ExRAM as CHR additional register, but only for BG and not for sprites (or sprites would be glitchy)

Taking note man... thnks

Castlevania III does use exram for one specific stage where the water level is rising.

uh, thanks for rectifying my mistake. I did not know about that level: if it is the level I think, I did not get there in my latest tests... I will check in the weekend

Since i started this topic im gonna say im confused with prg-ram swapping and Uncharted Waters.

Maybe you can help me and i will be the most verbose and noob i can:

The chip (ram-memory) is on the cart, but it's RAM it must be filled some way and that way is swapping prg-rom into it? That's is logical, the game is effectivly writing to $5113 to swap prg-ram and then Reading from $7XXX to get an opcode.
So i am correct saying that that swaps prg-rom into prg-ram.

The thing im swapping bad.
I have a complete 64k array as Disch say.
I don't know what to do with $5113 swapping. I have read the wiki and Disch' doc and tried different things.

can somebody explain me?

Edit: i forget to say that the opcode that gets is 0xFF not an official one.

Unless it's copying something from PRG ROM to PRG RAM and executing from there.

$6000-7FFF will have RAM, never ROM. So you are correct there.

Uncharted Waters will not jump to $7xxx without first writing necessary PRG data to RAM. Though I don't think it does that (it wouldn't have any reason to).

Are you sure UW is actually supposed to be jumping to $7xxx? Maybe you have some other PRG swapping mistake that's making it erroneously jump to a bad address?