It is currently Sat Dec 16, 2017 4:25 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 12 posts ] 
Author Message
PostPosted: Wed Jun 22, 2011 9:49 am 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
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.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 29, 2011 12:29 pm 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
Wow, so nobody knows? That's really surprising.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 29, 2011 1:01 pm 
Offline

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


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 29, 2011 1:33 pm 
Offline
User avatar

Joined: Thu Oct 21, 2004 4:02 pm
Posts: 210
Location: San Diego
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.


Top
 Profile  
 
PostPosted: Wed Jun 29, 2011 2:09 pm 
Offline
User avatar

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


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 01, 2011 8:06 pm 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 01, 2011 8:23 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10165
Location: Rio de Janeiro - Brazil
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).


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jul 02, 2011 1:29 pm 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jul 02, 2011 2:59 pm 
Offline
User avatar

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


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jul 02, 2011 3:43 pm 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jul 02, 2011 4:11 pm 
Offline
User avatar

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


Top
 Profile  
 
 Post subject:
PostPosted: Tue Jul 19, 2011 7:06 am 
Offline
User avatar

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

_________________
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  [ 12 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 8 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