nesdev.com

My results.
If I don't acknowledge the IRQ at $4022, I got a blank screen.

Can confirm the same results as Pokun. (The alignment of those diagrams is off, for me, I think that heart isn't properly monospaced, but it should be clear from context where the columns lie.)

Again, random after power on and load whether it's the 3=X or 3=O version. (Always 3=X after reset.)

BTW, two posts down from my example template there was a version that skips the licensing screen. Would help for faster iteration on tests if you used that (unless you think that would throw off the test). Didn't matter at first when doing just one test, but the power vs. reset variation seems to necessitate multiple tests.

So it seems like the IRQ is somehow triggered an extra time under some scenarios.
What I don't understand is that test #11 is virtually identical but appears to consistently trigger the IRQ only twice (as it should)


The IRQ handler is essentially this (ignoring all the conditions used for some of the tests):


It seems unlikely that writing $00 to $4022 before writing $02 again would change the behavior.
Either way, since the difference is between having 2 IRQs or 3 IRQs, it's pretty much confirmation that the irq reload value is never reset (which is the behavior Kaettekita needs).

Something else is triggering an IRQ (maybe the FDS' floppy drive?) or there must be something wrong with my code.
I'd be curious to see the behavior if I added a large delay before starting the tests (e.g a couple of frames maybe), and/or if I added a copy of the 3rd test as test #12. I think I'll try both and see how that goes.
There's also a few more test ideas I'd like to add to it and I'll try switching over to the version that skips the copyright screen, too.

The drive only uses IRQ while data is being loaded. It's stopped doing that before the code is even run. (After loading I could unplug the FDSStick and reset, doesn't change anything.) Though, you could put an additional test in that waits around and counts any spurious IRQs; I don't believe this is the case though.

All I would suggest is that something done in tests 4-10 is affecting the state of success for test 3. A state that's "random on power up".

I stared at the reset/init code for a while and couldn't really see anything that would be different between power on/reset (but I'm definitely not qualified for this).
I added some tests, removed some leftover unused code from the template (that should have no impact) and modified it to use the copyright screen skip technique.

#1 - Validate that IRQ doesn't repeat when $4022.0 is cleared
#2 - Validate that IRQ repeats when $4022.0 is set
#3 - Validate that IRQ reload value is kept even when $4022.0 is cleared
#4 - Validate that writing $00 to $4023 clears IRQ enabled flag
#5 - Validate that writing to $02 to $4023 does not acknowledge the IRQ
#6 - Validate that writing to $4020 does NOT acknowledge the IRQ
#7 - Validate that writing to $4021 acknowledges the IRQ
#8 - Validate that writing to $4022 acknowledges the IRQ when bit 1 is cleared
#9 - Validate that writing to $4022 acknowledges the IRQ when bit 1 is set
#10 - Validate that IRQ reload value is not cleared when $4022 is set to $00
#11 - (Copy of test 3) Validate that IRQ reload value is kept even when $4022.0 is cleared
#12 - Validate that writing $02 to $4022 while counter is running will reset counter
#13 - Validate that writing $02 to $4022 when irq reload value is $00 does not trigger an irq
#14 - Validate that no IRQ occurred before the tests started

Note: I deleted the old #10 test since it failed on the FDS (and it was essentially the opposite of another test).

Test #14 is the first one to run, I just didn't want to change the order of all the previous tests visually. It does: to enable IRQs, and then waits for ~400k cpu cycles - during which no IRQ should occur.

Test #11 is an exact copy of #3 - so they *should* get the same result (unless the state is inconsistent between both tests)

v4 does not boot for me. Just a black screen.

Maybe try it without the license screen skip just in case that's adding something weird to the equation.

Mostly same of before.
100% OK now.

I made 3 versions to try and figure out what is causing the issue:
4b-14tests: Has copyright screen, same tests as v4
4b-12tests: Has copyright screen, missing tests 12 & 13 (the 2 new tests)
4b-11tests: Has copyright screen, missing tests 11, 12 & 13 (the 2 new tests + the delay loop at the start that checks for unexpected IRQs)

That should cover most of the changes between v3 and v4 - I don't believe I've done any other significant change (hopefully).


@Zepper, if you're testing this on your emulator - it's a bit too early for that. We're still trying to figure out what the FDS' behavior is exactly, so the tests aren't really something you can apply to an emulator just yet.

Will suggest one thing: in your IRQ routine you SEI and CLI? Why?
SEI is already implied/forced by the IRQ itself, and RTI will clobber the interrupt flag.

If there is a second IRQ here that $4030 does not ack, the CLI will end up retriggering it in an infinite loop?

Maybe relevant is this curious note about a delay in the BIOS after a disk IRQ ack?

Ok, so v4b-11 confirms that test 3 is supposed to work (since test 11 is identical and does work). Also seems to confirm that it's the delay test at the start that is causing the black screen.

As for the sei/cli, the best answer I can give is: because I only have limited understanding of how to make programs for the NES :p
I removed both of them. I also changed the code so that NMI is disabled until after all the tests are done running, one less thing to worry about.

v5 has all 14 tests (including the delay test at the start), v5-nodelay is missing the delay test at the start. Both versions skip the copyright screen.

Sorry about the billion different tests, by the way :\

There seems to be no more variation at power on for these. The results are consistent? (Tested 20 or so times.)

I was interested in the idea that some unknown extra IRQ might fire some short period after boot/load, so I wrote a test that I think should catch it and log it.

My results were negative, though. I couldn't see any such IRQ (either with the license screen or skipping it).

Attached source code and FDS files.


Basically this test spins for a seconds or so after boot trying to log any IRQs that happen. It spits out the result starting with a number indicating the number of IRQs seen, then a series of log entries, each of 3 8-bit numbers in HEX. The first indicates the 'intended' value of $0101 for the IRQ, and the other 2 are just a timestamp.

There's an "APU" version of the FDS files, this uses $4017 to generate an IRQ for testing to see how a positive result should look. Gives a count of $3B with the corresponding timing logs.


Anyhow, was just trying to rule out the idea that maybe there's extra IRQs flying around shortly after boot, either normally or because of the FDSStick, etc. but I don't think it's the case based on this result. All quiet here. (It's possible I could have botched the test, though.)


Also this code has a simple BYPASS constant at the top of example.s that lets you quickly turn the license bypass on and off, as well as a tileset with ASCII characters and a row of hex numbers etc. in case that's useful.

I checked my code again for a half hour this morning and made some minor tweaks, but I would expect it will still probably generate a black screen.
I attached the source code as well, if you have a few minutes to take a look, maybe you'll notice something really obvious that I'm doing wrong.

Same as before: a single heart.

I'll take a look at the code a little later.