nesdev.org

thefox wrote:

ulfalizer wrote:Hadn't thought of there not being enough bits to output the entire palette memory index. How does the following sound?

Seems fine to me.

Does setting bit 6 affect the normal drawing in any way?

Not that I know of.

Ok, updated the wiki.

Okay, here goes, per the labels in the attached picture: ======== (1) ======== This starts, stops, and resets the simulation. The 'Scanline:' and 'Pixel:' status displays are based on internal PPU counters and should be self-explanatory. The starting state to use when resetting the simulation can be...

If more people want to help out, I could put together a short "user's manual" for Visual 2C02 by the way.

Here's a new version with the updated sprite 0/pixel output timing information. What assumptions do sprite 0 test roms make w.r.t. timing btw?

Don't think I've screwed up anywhere, but would be nice to have some third-party verification. beannaich?

spr0_hit and vid_ are good nodes to watch.

Does the following change sound right? (http://wiki.nesdev.com/w/index.php/PPU_registers) Setting bit 6 causes the PPU to output pixel values to the EXT pins in the form of palette indices - since the EXT pins are grounded on an unmodified NES, doing this is discouraged as it could potentially dama...

OK, this is how it seems to work (though I don't know why): Sprite zero hits take effect as if the image starts drawing at h=2 (the third PPU tick on the scanline). The actual pixel/dot corresponding to that point is output two PPU ticks later though, at h=4 (and the last pixel is correspondingly ou...

I'm pretty sure the first pixel is output during dot 2 now. Putting $FF in $0000 and $0001 (second one needed to get a sprite zero hit during scanline 1) and disabling the $2003/$2004 writes so you get an all-0 OAM entry for sprite 0 you can see the following: - the tile_l/h shift registers are shif...

Heh... I have almost the exact same idea for my emulator. Looks like you beat me to it.

The download link seems broken though.

Does the following change sound right? (http://wiki.nesdev.com/w/index.php/PPU_registers) Setting bit 6 causes the PPU to output pixel values to the EXT pins in the form of palette indices - since the EXT pins are grounded on an unmodified NES, doing this is discouraged as it could potentially damag...

Some quick question: Do changes in pixel_color correspond immediately to changes in what's currently being drawn? The waveform graph seems to lag a bit behind it, but maybe that's just due to the way its drawn. Does pixel_color include sprites? If so, the "BG pixel color, sent to EXT pins"...

Figured out what's going on with the right-shifting. Turns out the pattern stored in tile_l is both reversed and bit-flipped, so that e.g. $01 turns into $7F. $AA was an unlucky choice of test data, as that turns into $AA. :) Here's some related Visual 2C02 "bug reports": - "// lower ...

If the first pixel is output at dot 1, then maybe the updated timing is identical to the old one, only we've renamed dots according to the internal PPU counters.

Linked it from a few different relevant spots on the wiki. I know some browsers still don't scroll nicely through large SVG files, so I made the PNG the primary link. On the rendering section it says dot 0 outputs the first pixel of the scanline. Is that right? Wouldn't that cause a missing column ...

"...and reading $4016/$4017 will keep returning the current state of the first button (A)." The "over and over" somewhat implied that it would give the same reading each time, rather than the current state. Yeah, that's a clearer way of putting it. I'll assume the three bits bei...

Linked it from a few different relevant spots on the wiki. I know some browsers still don't scroll nicely through large SVG files, so I made the PNG the primary link.