OAM reading isn't reliable

[6502freak]

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.

[Dwedit]

So does Micro Machines fail on a Famicom?

[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.

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?

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]

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.

[blargg]

[...] 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.

[Memblers]

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.

[tokumaru]

Can you test Super Cars on a Famicom?

[Dwedit]

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.

[tepples]

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.

[tokumaru]

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.

[Bregalad]

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 ?

[6502freak]

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.

[Bregalad]

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).

[blargg]

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.

[thefox]

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?