Glitches in Dr. Mario with a GamePak

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
Feuerwerk42
Posts: 17
Joined: Fri Mar 18, 2016 3:59 am

Glitches in Dr. Mario with a GamePak

Post by Feuerwerk42 »

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 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
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Glitches in Dr. Mario with a GamePak

Post by lidnariq »

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.
Feuerwerk42
Posts: 17
Joined: Fri Mar 18, 2016 3:59 am

Re: Glitches in Dr. Mario with a GamePak

Post by Feuerwerk42 »

Hi,
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.
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.
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
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Glitches in Dr. Mario with a GamePak

Post by lidnariq »

Feuerwerk42 wrote:Am i missing a source of error?
Looks right.
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.
Nice, am i right that first signal is PPU ADDR, second is ALE and third PPU /RD?
Looks like it.
Post Reply