- Is this related with sprite evaluation thing? If someone needs source code, let me know.
- Is this related with sprite evaluation thing? If someone needs source code, let me know.
Zepper wrote:
- 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.
NESICIDE wrote:
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?
Zepper wrote:
NESICIDE wrote:
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).
Zepper wrote:
Is this info present in the wiki???
Yup: http://wiki.nesdev.com/w/index.php/PPU_OAM
Nesdev wiki wrote:
Code:
76543210
|||
|||
+++--- Unimplemented, reads back as 0
|||
|||
+++--- Unimplemented, reads back as 0
- Thank you. I did a minor modification in the wiki to clarify it. Anyway, well, it's subject to undo my changes...?
Zepper wrote:
- 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.
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.
clueless wrote:
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.
- 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.
- So, "unimplemented" gives a more solid meaning than "read back as zero", in my opinion.
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:
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.
Code:
; -- either this --
ldy #8
lda $1FFC,y
; -- or this --
ldy #8
lda #$1F
sta $01
lda #$FC
sta $00
lda ($00),y
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.
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?
"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?
I agree.
tokumaru wrote:
"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".
Zepper wrote:
- 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.
Quote:
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.
tokumaru wrote:
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.
- You see, if a NES program has no reason to mask, why would an emulator do such masking?
Zepper wrote:
tokumaru wrote:
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.
- You see, if a NES program has no reason to mask, why would an emulator do such masking?
Because emulators should emulate the behavior of the hardware platform as closely as possible. If you write "$ff" to byte 2 of OAM on real hardware, and then read it back as $e3, you should get the same result in an emulator.
If the emulator doesn't try to emulate the hardware accurately, you'll end up with nesticle.
The reason for the hardware behavior is nice to know, but in the end it does not affect the need to mask in the EMU, or the need to understand that you'll lose those bits when writing game code that might want to store info in them (which would be really weird).
Zepper wrote:
- You see, if a NES program has no reason to mask, why would an emulator do such masking?
Because when an emulator masks those bits out it's just trying to simulate the fact that on the real NES the bits don't exist at all. When you code an emulator in C or whatever, and declare your array of 256 bytes for the OAM, you can't tell the computer that some of those bits don't exist, every byte will have 8 bits and there is nothing you can do about that. So, in order to "pretend" that they don't exist, you just discard them in case the program tries to read them back. A NES program would have absolutely no reason to do such masking, because those bits never even got stored in the first place.
- Sorry, but the things have ended up here. If you write $FF and read back $E3 on hardware, it's ok about an emulator take such behavior. Pretty pointless to extend such discussion.
So did anyone test what does those bits returns when used with the $1fff,X adressing mode ?
If they return open bus, then they don't return zero, and that info was wrong
If they return open bus, then they don't return zero, and that info was wrong
Zepper wrote:
- Sorry, but the things have ended up here. If you write $FF and read back $E3 on hardware, it's ok about an emulator take such behavior. Pretty pointless to extend such discussion.
(I know it's not nice to write in languages other than english because not everyone will understand, but I feel like Zepper isn't fully understanding what I'm saying, so if you excuse me I'll try it in portuguese)
Zepper, eu não disse que essa informação está errada, mas sim que ela é relevante somente à emulação. O wiki é utilizado tanto por programadores de emulador, como você, e programadores de NES, como eu. Ao colocar uma informação que é relevante apenas à emulação, eu acho importante que isso seja explicado, senão pessoas que estão estudando sobre programação de NES podem ficar confusas, achando que precisam fazer algo que de fato não precisam.
Particularmente, eu acho a forma como está agora no wiki legal, pois ela explica bem que esse é um meio de simular o comportamento do hardware, e inclusive diz que você pode mascarar os bits tanto na hora de escrever quanto na hora de ler, já que o resultado final é o mesmo.
O que eu queria que você entendesse é que essa não é a forma como o NES trabalha, ele não mascara bit nenhum. Quando esse byte é escrito na OAM, esses bits simplesmente se perdem, não são armazenados em lugar nenhum. Então quando você lê, eles retornam como 0. A forma mais óbvia de simular isso num emulador é mascarando os bits com um AND, mas o fato é que isso é apenas uma "imitação" do comportamento verdadeiro, então eu acho importante que isso seja explicado.
Google-assisted translation of tokumaru's last post for the 'guese impaired, if you don't mind:
tokumaru wrote:
Zepper, I didn't say that this information is wrong, but it is only relevant to emulation. The wiki is used both by emulator programmers, like you, and NES programmers, like me. By placing information that is relevant only to emulation, I think it's important that it be explained, but people who are studying on NES programming can become confused, thinking they need to do something that does not really need.
Personally, I think the way it is now on the wiki is OK, because it explains that this is a good way to simulate the behavior of the hardware, and even says that you can mask the bits at either reading time or writing time since the end result is the same.
What I wanted you to understand is that this is not the way the NES works, it does not mask any bit. When this byte is written to OAM, those bits are just lost, not stored anywhere. So when you read, they return 0. The most obvious way to simulate this in an emulator is masking the bit with an AND, but the fact is that this is only an "imitation" of actual behavior, so I think it's important that it be explained.
Personally, I think the way it is now on the wiki is OK, because it explains that this is a good way to simulate the behavior of the hardware, and even says that you can mask the bits at either reading time or writing time since the end result is the same.
What I wanted you to understand is that this is not the way the NES works, it does not mask any bit. When this byte is written to OAM, those bits are just lost, not stored anywhere. So when you read, they return 0. The most obvious way to simulate this in an emulator is masking the bit with an AND, but the fact is that this is only an "imitation" of actual behavior, so I think it's important that it be explained.
Bregalad wrote:
So did anyone test what does those bits returns when used with the $1fff,X adressing mode ?
If they return open bus, then they don't return zero, and that info was wrong
If they return open bus, then they don't return zero, and that info was wrong
I would think it most likely that open bus is the correct return...rather than having implemented logic tied to ground or some such taking up 3x64 bits of space on the PPU die.
- I won't extend such discussion for a very easy question that has been answered. Tokumaru, you should have sent me a PM, I'm not upset.
Zepper wrote:
I'm not upset.
Me neither. If everyone is OK with the info on the wiki, it's all good. =)
- Is the OAM address ($2003 write) set to zero on VBlank or dummy scanline times? Is this a myth?
Can someone point me to this oam_stress app? Thanks!
jwdonal wrote:
Can someone point me to this oam_stress app? Thanks!
- There are even more tests in the NESICIDE's collection. I don't remember of having lost such tests, but it seems I did. However, nobody has pointed me to a discussion in this forum.
And no, sorry, I don't remember where's his collection of test suites.
- Would someone answer me about clearing the sprite address at the VBlank end?
jwdonal wrote:
Can someone point me to this oam_stress app? Thanks!
NESICIDE's master branch tarball.
The above is a git-less way to get you the source-base for NESICIDE. Within that you will find test_roms folder with all the test ROMs I've collected.
NESICIDE wrote:
NESICIDE's master branch tarball.
The above is a git-less way to get you the source-base for NESICIDE. Within that you will find test_roms folder with all the test ROMs I've collected.
The above is a git-less way to get you the source-base for NESICIDE. Within that you will find test_roms folder with all the test ROMs I've collected.
Rockin!!! ...only one problem, the link doesn't work.
Browser just sits there and spins for a long time and says "Waiting for gitorius.org..." and then stops and says that the connection was reset. Maybe it's just a temporary thing. I'll try again later.jwdonal wrote:
Rockin!!! ...only one problem, the link doesn't work. Browser just sits there and spins for a long time and says "Waiting for gitorius.org..." and then stops and says that the connection was reset. Maybe it's just a temporary thing. I'll try again later.
Browser just sits there and spins for a long time and says "Waiting for gitorius.org..." and then stops and says that the connection was reset. Maybe it's just a temporary thing. I'll try again later.Yeah it was slow/down this morning. Seems ok now though.
3gengames wrote:
Yep.
Sorry the bump. 
I got oam_stress ok, but it fails if the sprite address is cleared "manually" during the VBlank or nearby.
Discussion..
Any help?
I got oam_stress ok, but it fails if the sprite address is cleared "manually" during the VBlank or nearby.
Discussion..
Any help?