Vs Dualsystem Watchdog Timer

[Goose2k]

I am hitting an issue on the Nintendo Vs. Dualsystem arcade with my game.

When the user presses inputs 1 or 4 to start the game, there is a short "load" and then the game "resets" as if the system was rebooted. (see crude gif attached)

This bug is not present in Messen, FCEUX or Nestopia.

I don't have an real arcade cab to do any tests on, so I am at a bit of a loss.

However, I came across this in the documentation on the wiki:

"The secondary CPU must be present in socket 8J and it must be instructed to read from $4017 at least every 1.2 seconds, or both CPUs, both PPUs, and both CPUs' bit at $4020 are reset"

Interestingly, this crash happens after an, almost exactly, 1.2 second stretch where $4017 is not read at all (I do 76 frames of "delays" during the transition from main menu to gameplay). So perhaps something about reading input from player 2 (buttons 1 and 4 correspond to start and select of player 2) it causing an extra frame or 2, and putting it beyond that 1.2 second limit?

If this is the case, and "both CPUs, both PPUs, and both CPUs' bit at $4020 are reset", could/would that cause a system to reset (it isn't clear to me what reseting a bit a $4020 would do).

Seems like a stretch, but without real hardware myself, I come seeking guidance.

[lidnariq]

Interestingly, this crash happens after an, almost exactly, 1.2 second stretch where $4017 is not read at all (I do 76 frames of "delays" during the transition from main menu to gameplay). So perhaps something about reading input from player 2 (buttons 1 and 4 correspond to start and select of player 2) it causing an extra frame or 2, and putting it beyond that 1.2 second limit?

Does your code ever not read from $4017? If so, is there any possible way you miss reading from $4017 for ≈80 vblanks in a row?

(it isn't clear to me what reseting a bit a $4020 would do).

Cause the coin counter to not self-immolate

[Goose2k]

Interestingly, this crash happens after an, almost exactly, 1.2 second stretch where $4017 is not read at all (I do 76 frames of "delays" during the transition from main menu to gameplay). So perhaps something about reading input from player 2 (buttons 1 and 4 correspond to start and select of player 2) it causing an extra frame or 2, and putting it beyond that 1.2 second limit?

Does your code ever not read from $4017? If so, is there any possible way you miss reading from $4017 for ≈80 vblanks in a row?

(it isn't clear to me what reseting a bit a $4020 would do).

Cause the coin counter to not self-immolate

Yes, that's what I mean by:

"this crash happens after an, almost exactly, 1.2 second stretch where $4017 is not read at all"

I have a long blocking delay right before the crash happens (where basically no code is run other than my loading logic).

I know I need to fix this for coin reasons, but I'm just not sure if it will also fix the crash.

Cause the coin counter to not self-immolate

But does it make sense that it might cause the system to reset?

[Fiskbit]

I interpret the wiki as saying that the watchdog is causing reset to be asserted on the CPUs and the PPUs, and also resetting a separate register at $4020 for coin counting. If the watchdog triggers, your game will be reset as though the reset button were pressed on a frontloader, taking you back to the reset vector.

[Goose2k]

I interpret the wiki as saying that the watchdog is causing reset to be asserted on the CPUs and the PPUs, and also resetting a separate register at $4020 for coin counting. If the watchdog triggers, your game will be reset as though the reset button were pressed on a frontloader, taking you back to the reset vector.

Ok that's great news! I have got a ROM, with a temp fix, into a player's hands who can test it on real hardware. Should hopefully have my answer soon!

[lidnariq]

I've rephrased that section on the wiki to use the active voice instead of the passive voice; I hope that makes it more clear.

[Goose2k]

LOL I somehow made it worse... it now resets every time you put a coin in... What the heck.

[Fiskbit]

I've been looking into this a bit to help figure out why the watchdog is triggering here and am finding myself rather confused about how Vs. games work in general. The wiki says the secondary CPU is in charge of providing the heartbeat, but also seems to imply that only DualSystem games have two CPUs and two PPUs. Do normal Vs. UniSystem games have a secondary CPU? If not, is the one CPU considered the primary CPU or secondary CPU, and does it have to pet the watchdog? Do $4017 accesses from the primary CPU count as a heartbeat, or only from the secondary one? And finally, if there are two CPUs, do they each have their own separate sets of program ROMs?

If these are answered on the wiki, it's unfortunately not clear enough to me (or I've managed to overlook it several times).

[lidnariq]

Do normal Vs. UniSystem games have a secondary CPU? If not, is the one CPU considered the primary CPU or secondary CPU, and does it have to pet the watchdog?

Cabinets with only a single CRT need only one CPU in the mainboard (Vs. Raid on Bungeling Bay notwithstanding), and that CPU must be in the "secondary CPU" slot, and it has to pet the watchdog.

If you look at the schematic linked to from the wiki page ("VSSCHEM.pdf"), the watchdog is made of the following:
1- OR gate (pins 1-3) combines re-shaped NOT(M2) with /RDP1 at PCB 5B schematic J5 (note extra signal going down from there, and missing from the equivalent OR gate at PCB 4B schematic E5)
2- this signal goes to the "right" half of 74LS123 at PCB 1J schematic 2G (pin 10) - this is the actual watchdog
3- the output of this retriggerable one-shot in turn goes to the "left" half of 74LS123 at PCB 1J schematic 1J (pin 1) - which ensures that RESET is asserted for a deterministic length of time
4- the output of the "left" half (pin 13) goes through an inverter to both sockets for 2A03s, both sockets for 2C03s, and both latches that old the coin counter state (PCB 5D, schematic J4 and E4)
4b- the other output (pin 4) goes through a NAND gate (PCB 4C schematic 1G) and inverter (PCB 4E schematic 2G) that so that the CPUs get to execute code for any time between resets

Do $4017 accesses from the primary CPU count as a heartbeat, or only from the secondary one? And finally, if there are two CPUs, do they each have their own separate sets of program ROMs?

Primary CPU access to $4017 does nothing beyond the obvious functionality (i.e. reading joystick and dip switches). And yes, they each have their own entirely separate ROMs.

If these are answered on the wiki, it's unfortunately not clear enough to me (or I've managed to overlook it several times).

Please help me make things easier to understand! When one's too close to something one can't see its flaws.

[rainwarrior]

Interestingly, this crash happens after an, almost exactly, 1.2 second stretch where $4017 is not read at all (I do 76 frames of "delays" during the transition from main menu to gameplay). So perhaps something about reading input from player 2 (buttons 1 and 4 correspond to start and select of player 2) it causing an extra frame or 2, and putting it beyond that 1.2 second limit?

I'm curious whether you have considered having your NMI handler just read $4017 on idle frames?

Or if your answer is that you've turn off NMI at that point... I'd ask if you've considered leaving it on permanently? My general practice for a long time has been to enable NMI once at the beginning of an NES program and never disable it. If I want to do bulk uploads, etc. I just have a control variable that tells the handler that it should be doing "nothing" and won't interfere with the PPU bus. Normally the main reason I do this is so that music can play seamlessly across load transitions, but other advantages seem applicable here.

You could protect your controller reads outside the NMI with a variable. Set it to 1 to tell the NMI not to interfere with $4016/4017, read the controller, then immediately set it back to 0. Inside the NMI, if it's ever 0 (i.e. probably all of the time) it can read $4016/4017 and keep track of coins, etc. without interruption in service.

(There are some special cases, e.g. writing to flash ROM, where I still might want to disable NMI, but I'm not sure if any would apply. I'm not super familiar with the Vs though.)

[Dwedit]

The main case where I'd disable NMI is when switching the NMI handler to another code pointer.

I use different NMI handlers depending on what screen the game is using. A "screen off" NMI handler would still play music, and a "screen on" NMI handler would upload sprites, upload graphics, set up scanline interrupts, and perform scrolling. There could also be another NMI handler for a different screen that doesn't need the same interrupt setup.

[Goose2k]

LOL I somehow made it worse... it now resets every time you put a coin in... What the heck.

FYI This turned out to be user error. He forgot to put in one of the eproms.

I havent been able to confirm if that was the case for the original issue where there was a long 1.2ish second delay in polling $2017.

I will need to consider these suggestions about consistent pooling regardless though, as it is needed for çatching coin events. I'll have to think it through a bit more later; this NMI stuff is pretty foreign to me (neslib hides it all away from me).

[lidnariq]

I havent been able to confirm if that was the case for the original issue where there was a long 1.2ish second delay in polling $4017.

I guarantee that you must read $4017 no less often than every 1.2 seconds.

[Goose2k]

True accept as you said unless I am the primary CPU, which I think I was because in the first version I didn't poll 4107 at all and did not trigger the watchdog.

Not to say that I shouldn't be, but just not sure if that was actually the issue I ran into with the first issue.

[Pokun]

That's strange. I don't think it would be possible to ignore the watchdog.

Maybe you knows this, but a watchdog timer is a device designed to keep an unattended machine (such as an arcade machine) from hanging and becoming useless until a repairman comes and reboots it. Since players can't reboot an arcade machine themselves, it would be loosing money if it didn't reboot right away when something goes wrong. It's the programmers responsibility to design the game so that it never happens during normal gameplay. In this case by kicking the dog every 1.2 sec at all times.