nesdev.com

Actually, I haven't - I don't own an FDS (or even a Famicom for that matter).
But, as far as I know, all 4 games are licensed games, so it seems unlikely that they would contain these obvious bugs that can be noticed within seconds of loading up the game?

And yes, the Wiki is pretty lacking in terms of information (I had to scavenge information from a lot of different emulators to implement FDS support in Mesen originally). But I'm also hesitant to update the wiki with information that may or may not be correct. Writing tests for the FDS would be ideal to validate some of its behavior, but FDS test roms is currently far beyond my (almost nonexistent) NES coding skills.

I made an example template, if you need one:
https://forums.nesdev.com/viewtopic.php?p=193241#p193241


It's a red flag, for sure, but usually worth verifying by whatever reasonable measures you can take. I think a lot of people here could provide a whole library of examples of "I thought it was an emulator bug, but it's actually in the game."

Just to verify, though, I found FDS files of the 4 games in question and spent some time playing them to test. They did not appear to have any of the problems listed:

Druid Kyoufu no Tobira seemed to have a lot of single frame glitches at transition points, like a lot of NES games do, but the status bar stays correctly in one place (though with the usual jittery line of transition).

Lutter I could only find an En translation patched version, but it also played fine. Some minor/brief visual attribute problems, but I would assume these are normal.

Kaettekita Mario Bros appeared normal.

Putt Putt Golf appeared normal.

Same of Konami's VRC IRQs. ^_^;;

What do you mean??? Is the IRQ counter always decrementing? or only if $4022:$02 is true? Plus, what happens when the IRQ counter is zero? A reload + IRQ trigger?

That template should be enough to get me started on writing some very basic tests when I get the chance.

Thanks for testing the games, too.
Druid does have a number of glitches in Mesen as well, but for the most part looks alright (except for the jitter on the first line of the status bar, like you said).
A note on Kaettekita Mario Bros: there are 3 random opening animations before the game asks to switch to side B. 1 of the 3 openings works correctly whether or not the IRQ logic in the emulator is correct, while the other 2 will display a glitchy screen.
Only the one that has 「お茶づけ海苔」 written (vertically) works. The ones written 「五目チャーハンの素」 and 「スーパーマリオブラザーズふりかけTM」 are the ones that start glitching on the following black screen that is supposed to ask for side B.

Assuming VirtuaNES is correct:
The counter only decrements when $4022.1 (bit 1, e.g $02) is enabled. When the IRQ fires, the IRQ's timer is always reset to the value stored in $4020 & $4021. Then if $4022.0 is set, the irqEnabled flag ($4022.1) remains on. If $4022.0 is NOT set when the IRQ fires, the irqEnabled flag is disabled.
The reload value in $4020/$4021 is apparently never cleared (unlike what a lot of emulators currently implement)
Additionally, writing to $4023.0 with bit 0 clear (enable disk reg) also appears to clear the irqEnabled flag.

And yes, it's actually pretty similar to the VRC IRQs now that you mention it (except the FDS disables the IRQ enabled flag on its own after the irq is fired, rather than waiting for the code to acknowledge it manually by writing to a register)

What about the IRQ counter reload value? Can it be zero?

Testing for this, all three appear to proceed to the game without issue.

Let me know now... please. I've updated my emulator.

I ended up making a handful of very primitive IRQ-related tests.

Test #1 - Validate that IRQ doesn't repeat when $4022.0 is cleared
Test #2 - Validate that IRQ repeats when $4022.0 is set
Test #3 - Validate that IRQ reload value is kept even when $4022.0 is cleared
Test #4 - Validate that writing $00 to $4023 clears IRQ enabled flag
Test #5 - Validate that writing $01 to $4023 acknowledges the IRQ
Test #6 - Validate that writing to $4020 acknowledges the IRQ
Test #7 - Validate that writing to $4021 acknowledges the IRQ
Test #8 - Validate that writing $00 to $4022 acknowledges the IRQ
Test #9 - Validate that writing $02 to $4022 acknowledges the IRQ

The results are displayed as a sequence of 9 "X" or "O" characters.

An actual FDS probably fails some of these (I wouldn't be surprised if some of the IRQ acks failed). If VirtuaNES is correct, tests 1, 2, 3, 4 and 8 should pass, the rest should fail.
I tested this on FCEUX, puNES, Nestopia UE, Nintendulator & Mesen - they pretty much all get different results, but the result screen does show up properly, so the test itself should be working correctly.

The test relies on being able to acknowledge the IRQ by reading $4030, which I assume should work on the FDS too.
If it doesn't, you'll get a blank screen.

Looking forward to seeing the results!

My FDS + Famicom gives the result: OOXOXXXOX

Thanks for testing!
I expected #3 to pass (this is needed to fix all 4 games) - I think I might know why it didn't, though.
I wrote $00 to $4022 before writing $02 to $4022 for the 2nd time to trigger a 2nd IRQ - writing $00 might have cleared the reload value.

I fixed the tests that failed so that they pass based on the results you gave and added test 10:
Test #1 - Validate that IRQ doesn't repeat when $4022.0 is cleared
Test #2 - Validate that IRQ repeats when $4022.0 is set
Test #3 - Validate that IRQ reload value is kept even when $4022.0 is cleared
Test #4 - Validate that writing $00 to $4023 clears IRQ enabled flag
Test #5 - Validate that writing $01 to $4023 doesn't acknowledge the IRQ
Test #6 - Validate that writing to $4020 doesn't acknowledge the IRQ
Test #7 - Validate that writing to $4021 doesn't acknowledge the IRQ
Test #8 - Validate that writing $00 to $4022 acknowledges the IRQ
Test #9 - Validate that writing $02 to $4022 doesn't acknowledge the IRQ
Test #10 - Validate that writing $00 to $4022 clears the reload value

Hopefully this gets all Os this time.

On my FDS + Famicom
FdsIrqTestsV2 result: OOXOOOOOOX

Edit: sometimes after power on that X in the third position is an O? after reset it always becomes an X. (This happened 4 times out of maybe 15)

Not sure if that difference could be cause by when specifically i trigger the "insert disk" from the FDSstick, but it seems to happen on both early and late inserts after power on, randomly.

My RAM Adapter with FDSStick produces the same results as Rainwarrior on both test programs. The third test of FdsIrqTestsV2 passes sometimes but never after a reset.

Note that there are many bad disk images on the internet. For example there is a Zelda 2 one that appears to be missing treasures even though you start a new game (this happens on real hardware as well as emulators). I think it's the no-intro dumped disk image that's missing items in Zelda 2. Try TOSEC dumps for hopefully better results.

Thanks for testing.
This is odd since test #3 in V1 is essentially the opposite of test #10 in V2 - I'm not sure how both could fail.

Since the results are a bit hard to debug, I made another version that draws the number of IRQs that are triggered by each test. That should give us a bit more info on what's happening when #3 fails/passes.
I also added test #11, which should be identical to test #3 in V1.

OK now it looks like this (if test 3 passes):



And the cases where the third test fails, the heart pattern is a bit different: