Hello there,
I'm quite a newbie to NES emulation programming, and I've some questions about it.
1: according to Nintech.txt, a sprite 0 hit on x coordinate 255, the right border, doesn't count as a valid hit. true ?
2: does a sprite 0 hit still count if sprite 0 is low priority ?
3: how does a real NES interpret a user pressing up+down or left+right on a (worn out but not broken) joypad ?
4: is the maintainer of GoodNES actually maintaining it ? many iNES headers in it are broken.
5: the incrementing of the ppu address (2006) after a read or write to 2007. does it really just increment, or does it wrap around somewhere ?
1: Sounds right to me. I don't think sprite #0 hit works with single-pixel accuracy.
2: I'm pretty sure it does.
3: All the buttons can be pressed at the same time electrically, but the controller's mechanical design restricts it from happening. Some games would have glitches if both directions are pressed.
5: It would wrap around after $3FFF. For $2006 register writes you could discard the upper address bits.
Thanks a bunch.
3: yeah, i noticed mario doing a moonwalk in smb1 :p
Memblers wrote:
5: It would wrap around after $3FFF. For $2006 register writes you could discard the upper address bits.
With $2006 writes, you MUST discard (clear, actually) the upper address bits - if this did not happen, it would be possible to to mid-screen smooth vertical scrolling without using special tricks.
On $2007 accesses, however, it appears to increment it from $3FFF to $4000 (which would be $0000 for VRAM accesses, but $000 with YSCROLL=4 for rendering); some testing needs to be done with this...
I have a hard time convincing myself of #1. I don't see any logical reason why pixel 255 would be a special case for sprite 0 hit. Is this really the behavior?
Qix seems to rely on only a single pixel for sprite 0 collision -- so I don't think it needs multiple pixel hits for the flag to be set properly.
Disch wrote:
I have a hard time convincing myself of #1. I don't see any logical reason why pixel 255 would be a special case for sprite 0 hit. Is this really the behavior?
Qix seems to rely on only a single pixel for sprite 0 collision -- so I don't think it needs multiple pixel hits for the flag to be set properly.
Pixel 255 is a special case which has been verified on the real hardware - 0-254 all work fine.
nesdev wiki MMC3: "The MMC3 scanline counter is based entirely on PPU A12, triggered on rising edges (after the line remains low for a sufficiently long period of time)."
Has it ever been measured how many cycles this sufficiently long period of time is ? I'm currently guessing it at each hblank, but that gives problems in some games (could also be due to something else of course).
Quietust wrote:
Disch wrote:
I have a hard time convincing myself of #1. I don't see any logical reason why pixel 255 would be a special case for sprite 0 hit. Is this really the behavior?
Qix seems to rely on only a single pixel for sprite 0 collision -- so I don't think it needs multiple pixel hits for the flag to be set properly.
Pixel 255 is a special case which has been verified on the real hardware - 0-254 all work fine.
I didn't get the idea... Is 255 a valid check or not?
The observed behavior is that the sprite 0/BG overlap bit ($2002.D6) will not be set if the overlap occurs only on a pixel whose X screen coordinate is 255.
Is there any explanation to this behaviour?
Nessie wrote:
Is there any explanation to this behaviour?
Nope - it just happens.