apu test on hardware plz?

[Zepper]

- I'd like to request to someone else with a devkit to run the following test in the NES.

1. boot up (around 1 second)
2. SEI to prevent IRQs to trip
3. select apu mode 0 (4 steps) by writting to 4017h.
4. wait a few frames (around 1 second too)
5. select apu mode 1 (5 steps) by writting to 4017h.
6. wait a few frames (around 1 second too)
7. CLI to allow IRQs to trip
8. check if an IRQ was triggered and print the result.

- Please, let me know the results. I would thank you a lot. ^_^;;

[Disch]

Don't blargg's APU tests already cover this?

[Zepper]

No.

[Zepper]

I though this behaviour would be interesting to investigate, but since nobody has interest... fair enough.

[tokumaru]

Maybe if you coded the demo you want people to test... Asking someone else to code it may be a bit too much.

[blargg]

Here's an old post, maybe you saw it. I didn't look closely. http://nesdev.com/bbs/viewtopic.php?p=5415#5415

I can tell you that your test would find an IRQ the moment it did CLI, since the APU's frame IRQ flag would get set within a frame of powering up, and if not there, during step 4. The only way to clear it is to disable it via $4017 (set bit 6 I believe), or read $4015. And of course a dummy read of $4015 will clear it, as any read will.

[Zepper]

As expected, it's an hard-to-fix bug that affects Time Lord. In that post, there's an hack to start the frame after 10 lines of VBlank; I'm having the exact same problem described there. The only do-able fix is to cancel any IRQ pending on 4017 write when the apu mode changes from 4 to 5.

[jargon]

As expected, it's an hard-to-fix bug that affects Time Lord. In that post, there's an hack to start the frame after 10 lines of VBlank; I'm having the exact same problem described there. The only do-able fix is to cancel any IRQ pending on 4017 write when the apu mode changes from 4 to 5.

<apu> Thank you and come again!
<Time Lord> I just did.
<apu> You and your crazy time-bending shenanigans!

lol