help with oam_stress test

[Zepper]

- Is this related with sprite evaluation thing? If someone needs source code, let me know.

[cpow]

- Is this related with sprite evaluation thing? If someone needs source code, let me know.

Are you correctly masking the attribute bytes on reads? When reading the attribute byte it is masked (ANDed) with 0xE3 then returned. Looks like you're getting wrong read-back at that byte for everything but sprite-0.

[Zepper]

Are you correctly masking the attribute bytes on reads? When reading the attribute byte it is masked (ANDed) with 0xE3 then returned. Looks like you're getting wrong read-back at that byte for everything but sprite-0.

- Nope, I'm not masking the value. Is this info present in the wiki???
- Is there any difference of reading sprites when rendering is turned on/off?

[cpow]

Are you correctly masking the attribute bytes on reads? When reading the attribute byte it is masked (ANDed) with 0xE3 then returned. Looks like you're getting wrong read-back at that byte for everything but sprite-0.

- Nope, I'm not masking the value. Is this info present in the wiki???
- Is there any difference of reading sprites when rendering is turned on/off?

The sprite_ram.nes test in blargg_ppu_tests_2005.09.15b, test case 5:

5) Third sprite bytes should be masked with $e3 on read

Unfortunately this test tests the wrong byte, so it returns a false positive pass result, as discussed in a previous post (that I unfortunately can't find).

[tokumaru]

Is this info present in the wiki???

Yup: http://wiki.nesdev.com/w/index.php/PPU_OAM

Code: Select all

76543210
   |||
   |||
   +++--- Unimplemented, reads back as 0

[Zepper]

- Thank you. I did a minor modification in the wiki to clarify it. Anyway, well, it's subject to undo my changes...?

[tokumaru]

- Thank you. I did a minor modification in the wiki to clarify it. Anyway, well, it's subject to undo my changes...?

The problem is that, because you are an emulator author, the modification you made describes how an emulator should behave, not how the real console works. The real console doesn't mask anything... when the OAM is written to, those bits don't even get stored anywhere, they simply don't exist. The reason those bits read back as 0 is probably because of open bus, since $20 (the upper byte of $2004) has those bits cleared.

That's why I, a person interested in documenting the console itself rather than how to emulate it, don't agree with your edit. But I'll let someone more used to working with the wiki figure out what's the best way to word that.

[clueless]

Then I humbly propose that the wiki be edited with tokumaru's first paragraph. I see no reason why the wiki can't explain a) why the real NES reads those bits as zero, and b) what emu authors should do.

[tokumaru]

Then I humbly propose that the wiki be edited with tokumaru's first paragraph.

Note that I'm not 100% sure that's what actually happens, that was just my best guess.

Anyway, there have been discussions about how to present information on the wiki before. I believe we considered doing pages aimed at NES programmers, emulator programmers, and even the hardware folks. Personally I think that would result in a lot of redundancy and would be hell to maintain. Also, I really believe that good documentation can serve everyone.

[Zepper]

- I didn't anything that could hurt or represent a wrong information. Take a) the test suite regarding those bits being masked $e3 on $2004 reads and b) the Famicom treats $2004 as an "unused" PPU register. I just wrote "subject for undo" because I'm okay with such thing.

- So, "unimplemented" gives a more solid meaning than "read back as zero", in my opinion.

[tepples]

I clarified on the wiki that 1. not all PPU revisions support OAM readback (which addresses some Famicoms), and 2. it isn't yet clear whether the zero is a driven zero or a capacitive zero. But I thought of one way to distinguish the two. First fill $0700-$07FF (which mirrors to $1F00-$1FFF) with some value. Then run either of these snippets, which should read $1F04 (that is, $0704) before $2004:

Code: Select all

; -- either this --
  ldy #8
  lda $1FFC,y

; -- or this --
  ldy #8
  lda #$1F
  sta $01
  lda #$FC
  sta $00
  lda ($00),y

I'd bang out a test ROM myself, but my PowerPak's data bus capacitance differs from that of a mask ROM- or flash-based Game Pak.

[tokumaru]

I'm not against keeping the "AND with $e3" thing, but can we please make it clear that this is for emulators? Changing this:

"In other words, this byte should be ANDed with $e3 when read back."

to this:

"In other words, emulators should AND this byte with $e3 when reading it back."

Would do the trick. Does everyone agree?

[clueless]

I agree.

[Zepper]

"In other words, emulators should AND this byte with $e3 when reading it back."

- Didn't blargg make a test in a NES? It's not something empiric, that's what I mean.

- In short words, I disagree. No sense to say "for NES only" or "for emulation only".

[tokumaru]

- Didn't blargg make a test in a NES?

A test wouldn't AND with $e3, it would AND with $1c (the inverse) to keep only the bits that should be 0, to make sure that they are. So technically, the test is NOT doing what's written in the wiki.

No sense to say "for NES only" or "for emulation only".

My point is that a NES program has absolutely no reason to mask out bits that are already supposed to be 0, so as far as I see it, this information is only for emulation.