Noah's Ark (E) on PowerPak

[thefox]

As some of you may know, Noah's Ark (E) has corrupted graphics on PowerPak. I looked into it, and it turns out the game is attempting to write to CHR-ROM while rendering is enabled, and some of the writes somehow slip through to PowerPak's CHR-RAM. Note that the mappers do have a configuration flag to disallow writes to CHR-RAM if game uses CHR-ROM, and the corruption only occurs if writing while rendering is enabled.

Any theories on what exactly is happening here? Any suggestions on how it could be fixed on the mapper side?

CHR-RAM gets only /CS from the FPGA, /OE and /WE are hardwired to PPU /RD and /WR, as far as I know.

Attached is the test ROM I used (green = no corruption, red = CHR corrupted).

[tepples]

NEStress has corrupted graphics on PowerPak for what I believe to be the same reason.

I wonder how much of this is related to the common use of mapper 0 to mean NROM modded with CHR RAM, or the conflation of two unrelated boards in mapper 34.

[thefox]

NEStress has corrupted graphics on PowerPak for what I believe to be the same reason.

Yeah, seems to be the same reason in there.

I wonder how much of this is related to the common use of mapper 0 to mean NROM modded with CHR RAM, or the conflation of two unrelated boards in mapper 34.

I don't think it's related at all, or I've misunderstood what you're trying to say.

Somehow, FPGA is not able to pull the CHR-RAM /CS inactive fast enough after PPU makes /WR active. But it's hard to guess up what the details are here, or what's the timing of /RD, /WR and /ALE in this case. If the timing of the signals was "normal", you'd expect there to be no corruption, because CHR-ROM is never corrupted while writing to it without rendering enabled (yes, I've tested this).

[tepples]

I wonder how much of this is related to the common use of mapper 0 to mean NROM modded with CHR RAM, or the conflation of two unrelated boards in mapper 34.

I don't think it's related at all, or I've misunderstood what you're trying to say.

Some mappers have configurations with both CHR ROM and CHR RAM. A misbehaving mapper file would cause similar symptoms. Because of historical complexities related to certain mappers, files implementing a few specific mappers might be more likely to show implementation defects.

On the PowerPak PCB, does PPU /WR go through the FPGA or directly to the CHR RAM?

[thefox]

On the PowerPak PCB, does PPU /WR go through the FPGA or directly to the CHR RAM?

See OP:

CHR-RAM gets only /CS from the FPGA, /OE and /WE are hardwired to PPU /RD and /WR, as far as I know.

[2600]

Could you step back and help me understand something? I'm having trouble understanding where the chr-ram is coming from. Noah's Ark doesn't have CHR-RAM on the cart. So, are you saying that on the Powerpak CHR-RAM is somehow being enabled, written to, and because there is no CHR-RAM section of memory it is actually writing over the CHR-ROM section of memory?

[tepples]

I think so.

PowerPak has CHR RAM. As I understand it, when playing a CHR ROM game, the FPGA will deselect the CHR RAM during writes to make it behave like CHR ROM. But if $2007 is written during rendering, the FPGA doesn't have time to do that before the next scheduled fetch. It's like the MMC3 write glitch, where graphics in Crystalis and M.C. Kids got corrupted when early versions of the MMC3 mapper would mirror $Exxx-$Fxxx writes (IRQ disable/enable) to $6xxx-$7xxx.

Can the FPGA limit how long the RAM is selected during a single write, or perhaps detect a rendering fetch pattern (like MMC2, MMC4, and MMC5) and disallow writes? Otherwise it's back to Bible Adventures for most of us.

[2600]

Does this happen using Loopy's mappers?

I wouldn't of thought the FPGA was capable of being too slow, maybe too fast.

[tokumaru]

Does this happen using Loopy's mappers?I wouldn't of thought the FPGA was capable of being too slow, maybe too fast.

Maybe this isn't about being too fast or too slow, it's just a conflict between a write trying to disable the CHR and a read (for rendering purposes) trying to enable it.

What about the Everdrive N8? Does anyone know if the FPGA can control CHR /OE and /WE?

[thefox]

For completeness sake, here's a list of games that I know of with the same problem:

Noah's Ark (E)
Addams Family, The - Pugsley's Scavenger Hunt (U)
Baseball Stars II (U)
Bigfoot (U)
Krusty's Fun House (U)
Perfect Fit (U)

[2600]

I wonder if any of this has to do with the fact that the PowerPak doesn't use the PPU /A13 line on the cart or if a small cap on the PPU A13 line might help.

[Great Hierophant]

For completeness sake, here's a list of games that I know of with the same problem:

Noah's Ark (E)
Addams Family, The - Pugsley's Scavenger Hunt (U)
Baseball Stars II (U)
Bigfoot (U)
Krusty's Fun House (U)
Perfect Fit (U)

Are you sure about Perfect Fit, which is a Mapper 3/CNROM game?

Does anyone know if the Everdrive N8 also has the same problem?

[thefox]

Are you sure about Perfect Fit, which is a Mapper 3/CNROM game?

Mapper doesn't matter. If a game uses CHR-ROM, it can have this problem.

[Great Hierophant]

I checked every game on thefox's list on my Everdrive N8 and they do not have this problem. Their backgrounds are as they should appear with real carts.

[thefox]

Just to follow up on this, here's one scenario from Visual 2C02 simulation. I simply added write to $2007 at the end of the default "program" (it enables rendering at the end). This is what happens (read from bottom to top):

Code: Select all

cycle   hpos    vpos    ab      ale     rd      wr
348     057     105     1009    1       1       1 
348     057     105     1009    1       1       1 
347     056     105     1000    0       0       1 
347     056     105     1000    0       0       1 
346     056     105     1000    0       0       1 
346     056     105     1000    0       0       1 
345     056     105     1000    0       0       0 
345     056     105     1000    0       0       0 
344     056     105     1000    0       0       0 
344     056     105     1000    0       0       0 <= /RD is asserted, overlapping with /WR
343     055     105     1000    1       1       0 
343     055     105     1000    1       1       0 
342     055     105     1000    1       1       0 
342     055     105     1000    1       1       0 <= /WR is asserted
341     055     105     1000    1       1       1 
341     055     105     1000    1       1       1 
340     055     105     1000    1       1       1 
340     055     105     1000    1       1       1 <= ALE is asserted continuously for 8 clocks (normally 4)
339     054     105     2369    0       0       1 
339     054     105     2369    0       0       1 

So, ALE is still kept asserted at the same time when /WR starts to be asserted. And then /RD comes in to overlap the /WR assertion. Normally ALE would be asserted, then deasserted, then only one of /RD or /WR should get asserted.

NOTE: This is just one possible scenario, but shows that the behavior of $2007 writes while rendering can be quite funky.

Based on this, I think I was able to fix the problem. My earlier logic (based on the assumption that PPU /RD and /WR are mutually exclusive) was:

Code: Select all

ce <= ppu_read or (ppu_write and chr_ram_enable)

New logic:

Code: Select all

ce <= (ppu_read and not ppu_write) or (ppu_write and chr_ram_enable)

This seems to have fixed all the games that I know of which had the problem.

Here's how to reproduce the problem for each game:
- Perfect Fit (U) (CNROM): Select level 1, press B to start level, then select to exit the level, then go back to level
- Addams Family, The - Pugsley's Scavenger Hunt (U) (MMC1): Go to password screen, enter code, go back to title screen
- Krusty's Fun House (U) (MMC3): Simply run the game, the screen with text "hiiiiii kids" is corrupted.
- Noah's Ark (E) (MMC3): Go to first level, background is corrupted.
- Baseball Stars II (U) (MMC3): Press start, then A several times, eventually a corrupted screen will appear.
- Bigfoot (U) (MMC1): Title screen is corrupted

I'll release a new version of PowerMappers at some point with the fix.