There are two new quirks with the ppu that I don't understand.
First is the sprite oam glitch when you turn off rendering early. I'm under the impression that you cannot disable rendering on a scanline that has sprites on it, unless you turn it off sometime after ppu cycle 64 and before hblank. Otherwise, you risk corrupting one of the sprites on the next frame. Is this correct? Also, does the glitch still occur if you turn off sprites, and then turn off the bg on the next scanline?
Second is the young indiana jones discovery. Reading $2007 during rendering will increment fine H or fine V counters, depending on whether 1 byte or 32 byte increment is set? I don't care about how to implement this on an emulator (and thus don't feel like contending with the original thread), I want to make sure I understand the basic principle behind it, since I'm not even sure why the hardware behaves like this.
If anyone could clarify these things for me, I'd greatly appreciate it and add it to the wiki.
Wow, so nobody knows? That's really surprising.
Disabling sprite rendering while leaving background rendering enabled, or disabling background rendering while leaving sprite rendering enabled, has no effect on the operation of the PPU's rendering. It just blocks the pixels from hitting the compositor stage. In order to have an effect, you need to disable both.
Once the PPU is decapped properly, we might be able to add a Visual 2C02 to our Visual 2A03 and puzzle out exactly why this $#!+ happens.
tepples wrote:
Once the PPU is decapped properly, we might be able to add a Visual 2C02 to our Visual 2A03 and puzzle out exactly why this $#!+ happens.
I'm desoldering one from a frontloader this weekend and mailing it off so they can have another try.
Drag wrote:
Second is the young indiana jones discovery. Reading $2007 during rendering will increment fine H or fine V counters, depending on whether 1 byte or 32 byte increment is set? I don't care about how to implement this on an emulator (and thus don't feel like contending with the original thread), I want to make sure I understand the basic principle behind it, since I'm not even sure why the hardware behaves like this.
I'm also very interested about this. Can somebody summarize what we know so far? The Indiana Jones thread kinda blew up.
Also as a reminder, in case somebody want's to analyze/verify something, blargg posted some experimental data about reading $2007 some time ago:
http://wiki.nesdev.com/w/index.php/Read ... _rendering
Ok, so about the sprite glitch, I've gone over the thread again and again.
You need to disable rendering between pixels 64-255, and when you disable, you'll cause a strange hardware bug that corrupts a pair of sprites, but only if one of the first six sprites (so sprites 0-5) overlaps the scanline after the one you disable rendering on.
The effect is a seemingly random section of 8 bytes will be overwritten with whatever section of 8 bytes 2003 is pointing to.
I went to my old standby, Startropics II, because the dungeon sections feature PPU render disabling in order to upload new colors for the status bar. Mike never overlaps the section of the status bar that's blanked, his entire sprite disappears when he's about to. The same thing with any sprites that reach that part of the screen, they disappear right before they're about to overlap. I guess this is how this game avoids the bug. Unfortunately, I wasn't able to determine which pixel the scanline is disabled on, since fceux doesn't have a PPU cycle counter.
Another game to check would be Krusty's Fun House. If I remember correctly, it disables rendering mid-frame, and sprites are allowed to overlap the blanked section.
The 2007 scrolling quirk, that may be just be down to playing around with test roms to figure it out. For now though, I'll just assume it'll increment fine h/v scrolling depending on the status of the 1/32 byte increment bit of $2000.
Drag wrote:
I wasn't able to determine which pixel the scanline is disabled on, since fceux doesn't have a PPU cycle counter.
Yes it does. At least the version I'm using does. Look below the CPU flags in the debugger, there's a "PPU Pixel" field.
Quote:
Another game to check would be Krusty's Fun House.
You might want to check the game mentioned in
this thread too. I just saw that it uses a sprite 0 hit to disable rendering at the bottom of the screen. There are sprites in the region where rendering is disabled (kill yourself and you'll see).
Alright, I'll have to look into it then. I have an older copy of FCEUX, which only has the scanline counter, no pixel counter.
In the meantime, I think StarTropics II wouldn't be affected by the glitch as terribly, because it turns rendering back on for the status bar (duh! Why didn't I think of it before?), and even though the status bar has sprites on it, they're the first six sprites, which are supposedly the only ones that cause the glitch in the first place. If they're stationary, ALWAYS under the blanked out region, then the glitch is averted.
This is assuming that it's only the first six sprites that cause the oam glitch. Blargg only mentioned it in a post about him testing whether the corrupted sprites can be predicted, so I don't know if it's ONLY the first six sprites that can ever cause the glitch, or if it was only just because of that specific test.
Also, I don't know if anyone knows what this is, but has anyone noticed SMB occasionally spits out a garbage scanline? I've noticed this on my actual cart, and so has Acmlm (who even caught a screenshot of it with his capture card device gizmo doodle), but no emulators will do this. Yesterday, I was playing Kid Icarus, and when I got to the horizontally scrolling stages (2-1 through 2-3), I was seeing weird scanlines a lot, which is strange because I've never seen them in Kid Icarus before, nor have I seen them in Goonies 1 or 2, which are also horizontally scrolling games.
Drag wrote:
I think StarTropics II wouldn't be affected by the glitch as terribly, because it turns rendering back on for the status bar
I'm not sure if this actually helps... In my own tests, I figured that if I enabled rendering back an exact number of scanlines after disabling it (like, 15 scanlines or 1705 CPU cycles later) the sprites wouldn't glitch because the PPU wouldn't "realize" I interrupted the process, but that wasn't the case. The sprites glitched pretty bad no matter what I did.
This is still a big mystery to me, and as personal rule I decided to never disable rendering early in my programs, at least until someone figures this bug out.
I think the main tip was, don't have any sprites where you're going to disable ppu rendering. The exact specifics of the bug are up for debate.
Yeah, for now, that's the only way I'm aware that's completely safe. That's a hard thing to guarantee in my programs though (i.e. that sprites won't be at the place where rendering is disabled), so I'd rather not do it at all.
Drag wrote:
Unfortunately, I wasn't able to determine which pixel the scanline is disabled on, since fceux doesn't have a PPU cycle counter.
I checked in Nintendulator and it disables rendering around cycles 317-327.