It is currently Fri Oct 20, 2017 11:57 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 4 posts ] 
Author Message
PostPosted: Fri Sep 09, 2016 9:46 am 
Offline

Joined: Fri Mar 18, 2016 3:59 am
Posts: 17
Hi

My second try to build a logic level converter board to connect a GamePAK to my NES FPGA project is complete. Running Super Mario Bros. 1 (European) works like a charm, no glitches or crashes. As a next step i tested other modules (Dr. Mario, SMB2, SMB3, EverDrive N8) with mostly catastrophic result. It's a pity that the everdrive module isn't working so i can't test with self written code :(

Here is a video from the Dr. Mario (European) intro: http://www.boxx-it.de/~cfruth/IMG_0888/
As you can see the game randomly switches the CHR Bank and there are these tiny horizontal pixel lines which are visible for a very short time.
While the background changes sometimes every second the sprites remain unchanged most of the time.

I don't think its a electrical problem with my board since SMB1 is running perfectly. I use 8x SN74LVC8T245 for the voltage conversion between my fpga board (2.5V) and the GamePak (5V). Reading the datasheet the timing and voltage characteristics looks good to me.

Things i tested so far:
- It's not a timing-problem, i reduced the system clock to 5MHz (i use PAL dividers) => no change
- It's not a problem of the cpu side signal generation, i shifted the phase of M2 to have only changes to CPU ADDR and CPU R/W while M2 is low, like described in http://wiki.nesdev.com/w/index.php/Cartridge_connector => no change
- It's not a problem of the ppu reading from the memory, i added the possibility to force CPU Ready to 0, so i can halt the cpu while the ppu is still running, with the result that i get a perfectly still picture with no glitches (if i halt in the right moment :wink:), so i think the problem must come from something the cpu is doing with the MMC1

Does anyone have an idea what my problem could be or what i should test?
I only found http://forums.nesdev.com/viewtopic.php?f=9&t=13993&hilit=logic+analyzer which shows reading/writing to the cpu side. Is there also a diagram of the ppu signals for reading/writing?
It may sound strange, but does anyone have a ROM-Dump of the EverDrive N8, so i can test it in my FPGA-Simulator and get an idea why i only get a green screen?

Chris


Top
 Profile  
 
PostPosted: Fri Sep 09, 2016 1:53 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6289
Location: Seattle
I don't know about the massive corruption, but whenever you see a single 8x1 pixel error, that's got to be a translation or timing problem—you're only getting one single fetch that's wrong there, and it's rare.

It's interesting that I don't think I see the same problem on sprite fetches; only on background tile fetches.

As far as logic analyzer traces, I know I'd seen one from ... hardwareman? ... yeah, here.

There's also the (visual) one here.


Top
 Profile  
 
PostPosted: Mon Sep 12, 2016 5:51 am 
Offline

Joined: Fri Mar 18, 2016 3:59 am
Posts: 17
Hi,

Quote:
It's interesting that I don't think I see the same problem on sprite fetches; only on background tile fetches.


This and the fact that if i halt the cpu the picture stops showing glitches let me think its not a problem of the ppu reading from CHR-ROM / CIRAM.

Quote:
I don't know about the massive corruption, but whenever you see a single 8x1 pixel error, that's got to be a translation or timing problem—you're only getting one single fetch that's wrong there, and it's rare.


Ok, what could lead to the pixel error?
- the Attribute Byte was read wrong => wrong color is displayed
- the Tile Index Byte was read wrong => the succeeding tile fetch is corrupted
- the High Tile Byte was read wrong => wrong picture
- the Low Tile Byte was read wrong => wrong picture

Am i missing a source of error?

Since this problem only occurs while the CPU is running there is only two problems i can imagine:
- CPU is controlling the PPU through the ports $2000 - $2007 while not in vblank => i simply have a bug inside my PPU implementation which can't be ruled out
- CPU is controlling MMC1 Bank Switch permanently which causes the glitch (my favorite at the moment) => no idea why a) the CPU is permanently writing to the MMC1 registers and b) the write commands sometimes are corrupted. I also added a phase shift of the /ROMSEL-signal like shown here with no change of the problem. I think as a next step i will debug Dr. Mario with FCEUX to see if CHR bank switch is really happen permanently in the title screen, but im not sure how this brings me one step further :-/ Maybe i can redirect CPU reads to an internal ROM to control bank switching with self written code.

Quote:
As far as logic analyzer traces, I know I'd seen one from ... hardwareman? ... yeah, here.


Nice, am i right that first signal is PPU ADDR, second is ALE and third PPU /RD?

Chris


Top
 Profile  
 
PostPosted: Mon Sep 12, 2016 12:28 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6289
Location: Seattle
Feuerwerk42 wrote:
Am i missing a source of error?
Looks right.

Quote:
Since this problem only occurs while the CPU is running there is only two problems i can imagine:
You're missing "analog effects", like crosstalk.

Quote:
Nice, am i right that first signal is PPU ADDR, second is ALE and third PPU /RD?
Looks like it.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

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