PPU wait for ready in Donkey Kong

[dink]

I have found a contradictory game with regards to ppu warmup emulation (this might be relevant to you as well after you get mappers in): Magic John on Famicom.
The game immediately starts putting stuff in PPU registers @ boot w/o waiting for the ppu to warm up(wait for vbl etc).
If they are ignored -- as documented on the wiki by ppu ignoring certain registers @ power on until a certain line... things go weirdly wrong..
Ideas, guys?

[lidnariq]

The front-loading NES-001 ties CPU and PPU reset together, and releases them at the same time. The behaviors prohibiting writes are 100% accurate for this situation.

However, the Famicom doesn't. There, PPU /reset is just tied to 5V, and a 0.47µF capacitor attached to CPU /reset means that CPU will be released from reset later ... I don't know how much, but it looks like it's very roughly 1/60th of a second. So for a Famicom-only release, a game probably could get away with not waiting for the PPU.

[rainwarrior]

Someone should test Magic John on an NES to verify that it's actually broken, then? (Does it really have different startup code than Totally Rad?)

Edit: answering my second question, yes there's an added wait in Totally Rad, and it's kinda cute cause it waits 6 frames. That might speak to some developer frustration.

[Dwedit]

When run on FCEUX, Magic John waits 83578 CPU cycles before doing anything real with the PPU (address and memory writes). Before that, it is writing zeroes to PPUADDR, and writing values to PPUMASK and PPUCTRL.

It attempts to enable NMI at cycle 9217. If I change what is written to PPUCTRL so that NMI remains disabled, the game does not proceed.

Will Real Famicoms boot the game, or does it always require a reset?

[Dwedit]

The front-loading NES-001 ties CPU and PPU reset together, and releases them at the same time. The behaviors prohibiting writes are 100% accurate for this situation.

However, the Famicom doesn't. There, PPU /reset is just tied to 5V, and a 0.47µF capacitor attached to CPU /reset means that CPU will be released from reset later ... I don't know how much, but it looks like it's very roughly 1/60th of a second. So for a Famicom-only release, a game probably could get away with not waiting for the PPU.

So the capacitor thing (delaying the CPU Reset from the PPU reset) provides another way to distinguish a Famicom from a NES. Does the toploader behave that way too?

[lidnariq]

Probably? I think I remember people saying that the PPU always draws a picture on the top-loader, so that'd be equivalent.

We don't know exactly how long it'll take for the capacitor to charge. Evidently it's at least (29667-9217)÷1.789MHz = 3.6ms 11.4ms, but it could be longer.

Because the CPU's /RESET input has a weak n-MOSFET pull-up on the die instead of a resistor, the time isn't just a simple RC either.

And I know I've seen different famiclones using different capacitors there also.

[Fiskbit]

Unless I'm misunderstanding, that works out to about 11.4 ms, not 3.6 ms.

[rainwarrior]

Just to clarify, the Famicom PPU doesn't do any kind of reset at all when the reset button is pushed, correct?

This stuff about /reset being delayed for the CPU relative to the PPU is talking about power-on behaviour, not pushing the reset button, right?

[lidnariq]

Just to clarify, the Famicom PPU doesn't do any kind of reset at all when the reset button is pushed, correct?

Correct. PPU /RESET there is always tied to +5V.

This stuff about /reset being delayed for the CPU relative to the PPU is talking about power-on behaviour, not pushing the reset button, right?

Yes. Cold boots only. Might be funny behavior with only having it off for a few seconds, too.

[BMF54123]

So, at Fiskbit's request, I tested both my Magic John and Lord of King carts (same developers) on my modified front-loader. Both of them initially boot fine, BUT if you either press Reset or cycle the power too quickly, they freeze at a black screen. Holding Reset does not work; the console must be completely powered off to get them to boot again. The amount of time required between power cycles also varies slightly between the two:

Magic John: 5-6 seconds
Lord of King: 4-5 seconds

I also tested the games on my AV Famicom and they booted normally every time, regardless of how many times I pressed Reset or power-cycled the console. I also have a top-loading NES, but don't currently have a way to hook it up (I need to dig out an RF box).

[UPDATE]
I really need to organize my closet

I tested Magic John on the top-loading NES, and it exhibits the same behavior as the modded front-loader w/r/t power-cycling (need to wait 5-6 seconds between attempts); however, pressing Reset does allow the game to boot, presumably because the PPU has warmed up by this point. So the question is, why does the top-loading NES behave differently from the AV Famicom? The only real difference is that my AV Famicom has rev. H CPU/PPU, whereas the two NESes both have rev. G. But if the game works properly on older Famicoms, wouldn't that rule out CPU/PPU revisional differences? I'm confused.

[Dwedit]

First, big thanks for trying this out!

Second, I'll assume that booting with RESET held down will always fail?

[BMF54123]

First, big thanks for trying this out!

Second, I'll assume that booting with RESET held down will always fail?

I tried it a few times, and yeah, it failed each time.

So, another update: I borrowed a roommate's top-loader, which has rev. H CPU/PPU. Magic John booted every time, though occasionally the screen would be half-filled with a garbage tile for several frames. However, today my rev. G top-loader is also booting the game normally every time, with the same occasional garbage tiles. There was maybe one time it booted to a purple screen, but pressing Reset fixed it. I then tried my modded front-loader, and its behavior was the opposite: I had to wait 20-30 seconds between power cycles before the game would boot, as opposed to 5-6 seconds last night. The only difference today is that the ambient temperature in my room is a couple degrees warmer than it was last night. This probably explains the behavior of the front-loader, since the PPU will take a little longer to cool down in a warmer room, but why is it having the opposite effect on the top-loader?