Mid-frame PPU writes causing glitches...

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
User avatar
kevtris
Posts: 504
Joined: Sat Oct 29, 2005 2:09 am
Location: Indianapolis
Contact:

Mid-frame PPU writes causing glitches...

Post by kevtris »

I have been working again on my FPGA NES console, and I now pass *all* of the Blargg PPU tests. This includes the original PPU tests, the VBL/NMI tests, sprite 0 tests, and all the sprite overflow flag tests.

Because of this, I assume my PPU/CPU are in good working order and everything is synched up. Battletoads and every other "hard to emulate" game seems to be working fine also, which leads me to...

I am having issues with The Fantastic Adventures of Dizzy, during the "unrolling scroll" part in the very beginning. I have isolated the code which is causing the commotion, and it is this:

Code: Select all

200AE: A2 E0    LDX #$E0
200B0: 8E 01 20 STX $2001
200B3: 8C 06 20 STY $2006
200B6: 8D 06 20 STA $2006
200B9: A9 F8    LDA #$F8
200BB: 8D 01 20 STA $2001
This is performed at the end of every scanline during rendering to reload the T/V counters (using "Loopy terminology" here), to do the unrolling effect. So far, so good. On my FPGA though, this causes some very slight tearing, and there is even a little bit on Nintendulator, somewhat similar to what I'm seeing. The programmers disabling the PPU during this time is part of the cause of the problem I think.

So, question #1 is... do we really know what happens when the PPU's render flags are turned off mid-scanline? On the console, I just stop what I'm doing and enter an idle loop on the state machine, and when it's re-enabled, it picks back up where it was, which can cause issues with corrupted graphics and such. This probably isn't right, but I'm not sure about what a real PPU does.

There's a couple options I can think of.

1) it does what I do, that is, when rendering is disabled, the state machine just drops like a rock and halts wherever it was.

2) It only lets rendering halt/start every 2 pixels (or 1 memory fetch)

3) It only lets rendering halt/start every 8 pixels (or 4 memory fetches)

4) something else entirely


For information purposes, I hooked the red colour emphasis bit up to the "render enable" flag on my PPU which turns the bit on when both rendering flags are turned off. I noticed that codemaster's code isn't 100% cycle timed apparently. The red emphasis line creeps left on susccessive scanlines until it's touching the rendered pixels. Not surprisingly, it's a bit more "Tear-ey" at the bottom.

--------

And on a related note, this brings me to the game Final Lap. If you run this on nintendulator, it has the same tearing problem that I have exactly. The first player's display area is fine, while the second player's is not. There's some tearing every 2-4 scanlines or so. This game works by altering 2006 every scanline to shift the "road" around.

So, question #2 is... is there some kind of unresolved timing issues that we haven't thoroughly inspected on a real PPU?


I'm stumped on both of these problems at the moment, and I don't have alot to go on.
/* this is a comment */
Josh
Posts: 69
Joined: Sat Mar 19, 2005 11:18 am

Post by Josh »

Silly question: Have you checked on a real NES to see if the glitches appear there?
User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Post by Zepper »

Man, you did the stupid quote of the year now... :D
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

Josh wrote:Have you checked on a real NES
RealNetworks doesn't make game consoles ;-)
User avatar
hap
Posts: 355
Joined: Thu Mar 24, 2005 3:17 pm
Contact:

Post by hap »

I'm not sure what you mean with the problem in The Fantastic Adventures of Dizzy unrolling scroll effect, as it looks OK here. The Final Lap problem is due to fine X scroll having effect immediately instead of resetting the same way as regular X scroll.

examples:
Akumajou Densetsu: the scrolling mist in the intro, and the mist-effect in-game
Double Dragon 2: the scanline above the statusbar in-game
Final Lap: the bottom screen in-game
Kaijuu Monogatari: scrolling titlescreen
Super Mario Bros 3: at rotating mushroom/star/flower bonus round
World Grand Prix: in-game

The above games, probably more, will look better if you hack fine X scroll behaviour. But, it is correct, at least for SMB3 (tested on Famicom, USA NES, PAL NES). The problem in Final Lap might also be due to misunderstanding of N106 IRQs, maybe in combination with fine X scroll behaviour(?)
User avatar
kevtris
Posts: 504
Joined: Sat Oct 29, 2005 2:09 am
Location: Indianapolis
Contact:

Post by kevtris »

hap wrote:I'm not sure what you mean with the problem in The Fantastic Adventures of Dizzy unrolling scroll effect, as it looks OK here. The Final Lap problem is due to fine X scroll having effect immediately instead of resetting the same way as regular X scroll.

examples:
Akumajou Densetsu: the scrolling mist in the intro, and the mist-effect in-game
Double Dragon 2: the scanline above the statusbar in-game
Final Lap: the bottom screen in-game
Kaijuu Monogatari: scrolling titlescreen
Super Mario Bros 3: at rotating mushroom/star/flower bonus round
World Grand Prix: in-game

The above games, probably more, will look better if you hack fine X scroll behaviour. But, it is correct, at least for SMB3 (tested on Famicom, USA NES, PAL NES). The problem in Final Lap might also be due to misunderstanding of N106 IRQs, maybe in combination with fine X scroll behaviour(?)
Come to find out, I had some issues when the PPU was written to during rendering that was causing the glitching on dizzy... easily fixed.

Final Lap's problem was due to the IRQ counter behaving slightly differently than originally was known. Specifically, when the low byte of the counter is written after it expires, it continues counting from that point, rather than waiting until the upper byte is rewritten.

I also fixed Micromachines which requires exact cycle accuracy on the 2004 readback during rendering. even being off a cycle or two is too much- it won't work right. Once I fixed that so the readback is exactly what it should be, the game worked great.

At this point, my FPGA NES is about as bug free as it can get. The only thing that I would like to test more is DPCM IRQ's maybe. I'm a bit shady on those- while they work, they may not be timed exact. The "tank demo" works OK for the most part, but if you get too close to objects they flicker some. Other than that, the 183 mappers I have implemented, and all the games I've tested work 100% perfectly without any glitches or crashes. All known PPU/APU/CPU behaviour is implemented and all tests now pass. Even the most difficult games work flawless.

Thanks so much for answering my questions, instead of whining and complaining about how I asked them rather than actually helping me.

As for me calling it a "real NES" vs. my FPGA NES, I did it to prevent confusion. When I talk about the two of them, it can get very ambiguous which I'm talking about, so I like to specify real vs. FPGA.
/* this is a comment */
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

I prefer the terminology "NES" vs "Doctor PC Jr" vs "Dendy" vs "PolyStation" vs "Kevtendo" (your project).
User avatar
hap
Posts: 355
Joined: Thu Mar 24, 2005 3:17 pm
Contact:

Post by hap »

Here, that IRQ fix makes Final Lap indeed look OK, but Digital Devil Story 2 looks messed up in battles, and in that fake-raycasted dungeon.

*edit* nevermind that, my mistake, it works fine
Post Reply