However, specifically in the case of a 4 player DualSystem game - using both CRTs, both PPUs, and both CPUs - the primary CPU has to hand off control to the shared memory to the secondary CPU, and the seconary CPU should probably deliberately stop reading $4017 if it doesn't get that RAM when it thinks it should
Unless maybe using the opposite of the lockout I suggested, i.e. set a flag when you're not going to read controllers for a while that says "I'm going idle for a while, start polling it for me until I get back".
Though, as an alternative it's probably not hard to stick a few BIT $4017 instructions into a loading loop or whatever it is you're doing that takes a bunch of frames to process.
It still feels like a good idea to always read and process the coin slot in NMI though?
Yes, I agree. I think I will catch coin events in NMI, and cache in a temp counter, which my main game loop will pick up when it can, and clear the NMI cache when it does.
(It's a ridiculous concern, though. I'm hard pressed to believe there are any Vs. Systems still being paid with real money)
I am curious how you would handle coins dropping faster than the counter can handle? I assume you mean that before the coin bit is cleared, another coin is dropped, so there will be no "break" where the bit goes from 1 to 0 and then 1 again?
So in this case I'd say one should do something like
Code: Select all
vsync [$4020] [$4016]&$60 0 0 00 1 0 60 <- first two coins, one in each slot 2 0 60 3 0 60 4 1 00 <- don't grant credits or count coins until they disappear 5 1 00 6 1 60 <- second two coins, 84ms later 7 0 60 8 0 60 9 0 00 10 1 00 11 1 unchanged hereafter 12 1 four coins need to be counted 13 0 but we've only had enough time to count 2 so far 14 0 15 0 16 1 17 1 18 1 19 0 20 0 21 0 22 1 23 1 24 1 25 0 26 0 27 0 these final three 0s are still required by the 10Hz coin counter
I haven't hooked up the coin counter at all yet. Unfortunately, I can't find any emulators that emulate it so far, but the guy who is testing on real hardware for me does have a working one, so I will try testing it out.
This part of the Wiki makes a lot more sense now that I see your example above too, thanks!
"driving the signal high for 50ms (3 vblanks) and then low for 50ms is guaranteed to work"
I've started a new thread on the Coin Counter just so this doesn't go too far off topic with my additional questions