It is currently Wed Nov 22, 2017 4:21 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Sun Jun 15, 2014 5:33 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2981
Location: Tampere, Finland
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).


Attachments:
chr-rom-writability-test.nes [24.02 KiB]
Downloaded 124 times

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi
Top
 Profile  
 
PostPosted: Sun Jun 15, 2014 9:11 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19239
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Mon Jun 16, 2014 2:13 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2981
Location: Tampere, Finland
tepples wrote:
NEStress has corrupted graphics on PowerPak for what I believe to be the same reason.

Yeah, seems to be the same reason in there.

Quote:
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).

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Mon Jun 16, 2014 7:25 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19239
Location: NE Indiana, USA (NTSC)
thefox wrote:
tepples wrote:
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?


Top
 Profile  
 
PostPosted: Mon Jun 16, 2014 11:18 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2981
Location: Tampere, Finland
tepples wrote:
On the PowerPak PCB, does PPU /WR go through the FPGA or directly to the CHR RAM?

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

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Mon Jun 16, 2014 11:57 am 
Offline

Joined: Tue Aug 07, 2007 10:28 am
Posts: 95
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?


Top
 Profile  
 
PostPosted: Mon Jun 16, 2014 12:05 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19239
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Mon Jun 16, 2014 12:33 pm 
Offline

Joined: Tue Aug 07, 2007 10:28 am
Posts: 95
Does this happen using Loopy's mappers?

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


Top
 Profile  
 
PostPosted: Mon Jun 16, 2014 1:00 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10117
Location: Rio de Janeiro - Brazil
2600 wrote:
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?


Top
 Profile  
 
PostPosted: Sun Sep 28, 2014 12:56 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2981
Location: Tampere, Finland
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)

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Mon Sep 29, 2014 6:42 am 
Offline

Joined: Tue Aug 07, 2007 10:28 am
Posts: 95
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.


Top
 Profile  
 
PostPosted: Mon Oct 06, 2014 7:38 pm 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 620
thefox wrote:
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?

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog


Top
 Profile  
 
PostPosted: Mon Oct 06, 2014 11:49 pm 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2981
Location: Tampere, Finland
Great Hierophant wrote:
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.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Fri Jan 16, 2015 8:50 am 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 620
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.

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog


Top
 Profile  
 
PostPosted: Fri Dec 18, 2015 6:33 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2981
Location: Tampere, Finland
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:
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:
ce <= ppu_read or (ppu_write and chr_ram_enable)

New logic:
Code:
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.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group