nesdev.org

I haven't gone through the sprite evaluation page in detail, but it's pretty easy to get a feel for how the sprite evaluation algorithm works in Visual 2C02. Sprite evaluation is basically just a linear search through the entire primary OAM, looking for sprites with an in-range y coordinate. If/when...

I've found many games that do weird stuff when left+right and up+down are pressed at the same time. Thought it might be fun to make a list of some of the stranger ones, so here's the ones I can think of off the top of my head. Feel free to add more. :) Battletoads - up+down in level 2 (vertical tunn...

A wiki page for the Visual 2C02 tutorial with some small corrections is now at http://wiki.nesdev.com/w/index.php/Visual_2C02 .

After it wraps around, it still reads from the primary OAM like if it's looking for more matching sprites though (but never finds any, even if the y is within range). What I'm guessing happens is that the same sprite evaluation logic keeps ticking throughout the entire sprite evaluation period, only...

tepples wrote:So what happens when $FC is written to OAMADDR during the prefetch (321-340) or the start of the next line (0-64)? Does that effectively hide most sprites?

Looks like it. Once the end of OAM is reached during sprite evaluation, no more data gets written into the secondary OAM.

I did some tracing in Visual 2C02 to figure out what's going on with OAMADDR and sprite evaluation. Turns out to be pretty straightforward. Here's what I added to the PPU register page: ==== Obscure details of OAMADDR ==== OAMADDR is set to 0 during each of ticks 257-320 (the sprite tile loading int...

proxy:

Is the glitchy copying required to get Huge Insect to run, or is it sufficient to emulate the $2003 clear and changed start of sprite evaluation (which should affect which sprite gets treated as sprite 0 i think)?

I can't reproduce the copying behavior in Visual 2C02 if I set $2003 = 8 and fill S007-S00F with some non-zero bytes. Nothing seems to get copied at tick 257 of the pre-render scanline. :/ Has it actually ever been seen in practice? Seems like it'd be a pretty bad hw bug since it means setting $2003...

proxy wrote:* Sprite evaluation appears starts at OAM[$2003] not OAM[0]

I had missed this bit in my write-up. Does that also affect Huge Insect?

Is this known behavior explicitly assumed by the test roms btw, only undocumented on the wiki?

We did some Visual 2C02 tracing on IRC and figured out what's probably going on. See http://wiki.nesdev.com/w/index.php/PPU_ ... of_.242003.

Some of this stuff could probably be verified pretty easily in Visual 2C02. I put together a tutorial on it my PPU diagram thread that might help with getting started.

After some discussion in #nesdev I felt a little bad about maybe making basic emulator implementation seem way trickier than it really is, so I added a note to the diagram.

Edit: Delete a "not".

I talked to _Q in #nesdev, and it does look like something like the above is going on. (PM me for the full chat log if you want. :)) The following nodes have been added to Visual 2C02 now: spr_slot_0_transparent:1349, bg_pixel_transparent:1459, sprite_0_on_cur_scanline:5834, sprite_0_on_next_scanlin...

I guess it might need two such flags though for the sprite evaluation for the next scanline not to trample on the sprite logic for the current one.

I have nothing to back this up and might not be thinking straight, but maybe it does something like this: 1. If sprite zero is found to be within y range for the next scanline, a has_sprite_zero flag gets set. 2. Sprite zero will get the first position in the secondary OAM if it matches for the next...