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.
OAM reading isn't reliable
Moderator: Moderators
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?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.
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.)Dwedit wrote:So does Micro Machines fail on a Famicom?
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?
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.jsr wrote: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?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.
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.
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.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.
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.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.
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.
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.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.
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!
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
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 ?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.
Life is complex: it has both real and imaginary components.
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).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 ?
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.
It affacts reads behavior, but it DOESNT affect the fact it read something. (as opposed to open bus).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.
Life is complex: it has both real and imaginary components.
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.jsr wrote: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.)Dwedit wrote:So does Micro Machines fail on a Famicom?
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?
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?