OAM reading isn't reliable

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

6502freak
Posts: 92
Joined: Sun Dec 07, 2008 1:11 pm

Post by 6502freak » Mon Jun 07, 2010 6:26 am

Dang, I just checked the Famicom schematics here, and they also have deactivated the PPU reset line. But I swear I read somewhere that pushing the Famicom RESET button also resets the PPU. Maybe an earlier or later PCB revision?

@jsr

What happens when you push RESET on your Famicom?

EDIT: Argh, too much caffeine! On the Famicom, the PPU reset is tied to VCC, while the NES resets the PPU!

Nevertheless, it might be related to this problem.

User avatar
Dwedit
Posts: 4329
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Post by Dwedit » Mon Jun 07, 2010 10:00 am

So does Micro Machines fail on a Famicom?
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

jsr
Posts: 42
Joined: Thu Oct 07, 2004 2:47 am
Contact:

Post by jsr » Mon Jun 07, 2010 4:53 pm

6502freak wrote:What happens when you push RESET on your Famicom?

EDIT: Argh, too much caffeine! On the Famicom, the PPU reset is tied to VCC, while the NES resets the PPU!

Nevertheless, it might be related to this problem.
If you mean it would affect $2004 on the famicom, then I don't see the connection. Making that register write-only requires a change in the PPU hardware, right?
Dwedit wrote:So does Micro Machines fail on a Famicom?
I only have the famicom so I cannot compare against a NTSC NES, but the game actually runs but clearly with visible glitches. I don't know how sprite reads affects the picture (haven't disassembled it) but I assume that is the source of the glitches. (I don't own the game so I'm running it on the powerpak but I don't think that's a problem since it only uses mapper 2.)

Actually, I found that the FCE ultra emulator appears to emulate $2004 reads as open bus and behaves almost identical to the famicom (while every other emulator I tried instead returned OAM data), and the errors are very similar when running the game on that emulator. This would be one way to detect famicom/NES, does anyone know if there are more differences?

6502freak
Posts: 92
Joined: Sun Dec 07, 2008 1:11 pm

Post by 6502freak » Mon Jun 07, 2010 5:01 pm

jsr wrote:
6502freak wrote:What happens when you push RESET on your Famicom?

EDIT: Argh, too much caffeine! On the Famicom, the PPU reset is tied to VCC, while the NES resets the PPU!

Nevertheless, it might be related to this problem.
If you mean it would affect $2004 on the famicom, then I don't see the connection. Making that register write-only requires a change in the PPU hardware, right?
According to blargg's findings, it depends on the CPU<->PPU clock alignment, which is random on an NES. In 3 out of 4 possible cases, the readback fails. One particular alignment however yields success. This case seems to never occur on the Famicom.

The Famicom uses the same PPU as the NES. However, on the NES, the RESET line of the PPU is connected to the reset button/circuit, while on the Famicom, it is disabled. This could be the reason for the behaviour, as it seems to affect the initial state of the PPU on power-up.

If you push RESET on your Famicom, the picture remains stable and visible, while on the NES, the TV loses sync due to the PPU H and V counters being reset.
Last edited by 6502freak on Mon Jun 07, 2010 5:03 pm, edited 1 time in total.

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg » Mon Jun 07, 2010 5:03 pm

6502freak wrote:[...] on the Famicom, [PPU reset] is disabled. This could be the reason for the behaviour, as it seems to affect the initial state of the PPU on power-up.
As I wrote, on Famicom, $2004 reads back no differently than say $2000; it's a write-only register. It never behaves this way on NTSC or PAL NES.
If you push RESET on your Famicom, the picture remains stable and visible, while on the NES, the TV loses sync due to the PPU H and V counters being reset.
Wow. That's enough proof right there that its reset line isn't connected. I had never realized there were so many small differences between the systems.

I got fed up with OAM weirdness on my NES a few days ago. There's just too much obscure behavior when setting even $2003. As far as I'm concerned, the only things a game should do are write 0 to $2003 then write to $4014 to DMA sprites. Anything else is going to give you headaches and break your game for some systems/phases of the moon.

User avatar
Memblers
Site Admin
Posts: 3859
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Post by Memblers » Mon Jun 07, 2010 5:50 pm

6502freak wrote: If you push RESET on your Famicom, the picture remains stable and visible,
I'm pretty sure this is the case on the top-loading NES as well, from what I remember.

User avatar
tokumaru
Posts: 11755
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Mon Jun 07, 2010 6:14 pm

Can you test Super Cars on a Famicom?

User avatar
Dwedit
Posts: 4329
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Post by Dwedit » Mon Jun 07, 2010 6:25 pm

If you push RESET on your Famicom, the picture remains stable and visible, while on the NES, the TV loses sync due to the PPU H and V counters being reset.
So this means that any game that uses any raster screen effects will show a garbage screen while reset is held down on the Famicom? Interesting. Punch out would probably still show a stable picture.

I guess Nintendo changed this so that the lockout chip would actually lock you out.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

tepples
Posts: 22017
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Mon Jun 07, 2010 6:44 pm

Dwedit wrote:So this means that any game that uses any raster screen effects will show a garbage screen while reset is held down on the Famicom?
Super Mario Bros. 3 on a PlayChoice corrupts when time expires and uncorrupts once more credits are added.

User avatar
tokumaru
Posts: 11755
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Mon Jun 07, 2010 7:06 pm

Memblers wrote:
6502freak wrote: If you push RESET on your Famicom, the picture remains stable and visible,
I'm pretty sure this is the case on the top-loading NES as well, from what I remember.
I think my Famiclones are like that too... Games with raster effects do glitch.

User avatar
Bregalad
Posts: 7889
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Post by Bregalad » Tue Jun 08, 2010 1:39 am

Yes, on the toploader NES the picture remains stable when the RESET button is held. There is even a few games (at least Hanjuku Hero) that manages to fade out the palette nicely when you release the button, before resetting :p
As I wrote, on Famicom, $2004 reads back no differently than say $2000; it's a write-only register. It never behaves this way on NTSC or PAL NES.
I don't see how this would have anything to do with clock alignment. I guess your famicom has a earlier PPU revision, that's the only possible explanation. Then it opens up to the possibility that later FCs allow OAM reading, and that earlier NES don't. Some eariler Famicoms also lacks short-repeating noise I've heard. Does yours fall in that category ?
Life is complex: it has both real and imaginary components.

6502freak
Posts: 92
Joined: Sun Dec 07, 2008 1:11 pm

Post by 6502freak » Tue Jun 08, 2010 4:19 am

Bregalad wrote: I don't see how this would have anything to do with clock alignment. I guess your famicom has a earlier PPU revision, that's the only possible explanation. Then it opens up to the possibility that later FCs allow OAM reading, and that earlier NES don't. Some eariler Famicoms also lacks short-repeating noise I've heard. Does yours fall in that category ?
I would be careful with terms like "only possible explanation", unless you have seen the PPU schematics. On blargg's NES, the clock alignment apparently DOES determine the read behaviour, which on the other hand is dependant on the power-up state. So on the Famicom, it may very well be related to the fact that the PPU is in a different power-up state than the NES. It may of course also be true that this is because of a different PPU revision (though not being able to read something flaky sounds more like FIXING a glitch).

One practical way to find out is to run the test on a NES where the /RES pin of the PPU is tied to VCC in a similar fashion as the Famicom.

User avatar
Bregalad
Posts: 7889
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Post by Bregalad » Tue Jun 08, 2010 6:27 am

On blargg's NES, the clock alignment apparently DOES determine the read behaviour, which on the other hand is dependant on the power-up state.
It affacts reads behavior, but it DOESNT affect the fact it read something. (as opposed to open bus).
Life is complex: it has both real and imaginary components.

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg » Tue Jun 08, 2010 3:00 pm

Bregalad, I think his point was that since the synchronization affects that, it could therefore affect anything. I don't think that's a useful premise. I'm satisfied with JSR's $2004 read test in all sorts of situations, always returning PPU open bus on his Famicom.

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

Post by thefox » Sun Sep 19, 2010 6:43 pm

jsr wrote:
Dwedit wrote:So does Micro Machines fail on a Famicom?
I only have the famicom so I cannot compare against a NTSC NES, but the game actually runs but clearly with visible glitches. I don't know how sprite reads affects the picture (haven't disassembled it) but I assume that is the source of the glitches. (I don't own the game so I'm running it on the powerpak but I don't think that's a problem since it only uses mapper 2.)

Actually, I found that the FCE ultra emulator appears to emulate $2004 reads as open bus and behaves almost identical to the famicom (while every other emulator I tried instead returned OAM data), and the errors are very similar when running the game on that emulator. This would be one way to detect famicom/NES, does anyone know if there are more differences?
Sorry for digging up an old thread, but this topic came up again at IRC #nesdev so, just for fun, I took a look at what Micro Machines does. I know the principle of this is old info, just wanted to see how this specific game ticks.

In the title screen it reads $2004 8 times on scanlines 16..23 around scanline clock ~310:

FD6E BIT $2004
FD71 BMI $FD73
FD73 ...

So it adds an extra cycle whenever the value returned by $2004 has the top bit set. It's exploiting the fact that at certain times $2004 read always returns $FF and at certain times proper values from OAM, depending on which PPU cycle the read falls on. That way they get a more precise CPU-PPU sync.

So yeah, no reason for this game to fail on Famicom.

...

On the same note, has anybody tested if the palette readback through $2007 works on Famicom?

Post Reply