I've been lurking on this forum for a while, but I figured it was time to actually post something. I've been cleaning up the VS. Unisystem emulation in my emu recently, so this topic has been of particular interest to me.
lidnariq wrote:
Writes to or reads from $4020-$403F (and $4060-$407f, &c) clock a D latch where the D is the LSB of the data bus.
The output of the D latch is inverted 3 times and goes to harness pin 17, the "S counter", which drives a relay.
That's not a relay, that's the coin counter. There's an electromagnet inside that ratchets the number wheels forward exactly one "notch" when current is passed through it. The coil on the schematic is just the electromagnet itself. This is a common arcade part, and can be seen on the inside of these Donkey Kong cabinets:
http://forums.arcade-museum.com/showthread.php?t=235454http://donkeykongrestore.blogspot.com/2009/03/unrestored-coin-door.htmlThis one's a DK3 cabinet:
http://www.chompingquarters.com/2010/10/controversial-cloners-clone-rare-donkey-kong-3-harnessThe VS. Unisystem Kit was intended for converting Donkey Kong cabinets (among others). The original coin door hardware is left intact after the conversion, so it clearly works with VS. Unisystem boards as-is.
The counter just connects directly to pin 16 on the PCB (+24V) and pin 17 (S counter). I can't see any reason to suppose that pin 17 connects to something else as well since neither the schematic nor the wiring diagram indicate that. If this is true, then $4020 only controls power to the coin counter.
lidnariq wrote:
I'm not exactly clear what the relay does. Guessing: it possibly re-enables the light bulb inside the coin insertion mechanism, and probably resets the switches in the coin inserter. It's conceivable it might reset a shutter so that the user can insert more coins.
The coin mechanism used in the Donkey Kong cabinet is entirely mechanical: no shutters, no lock-out coils, and no light bulbs. It's part number TKGU-01-02 according to the Vs. Unisystem Kit Manual, and can be ordered as an OEM replacement from
Mike's Arcade.
The switches shouldn't need resetting; they're standard SPDT coin switches so they'll open again once the coin has dropped off into the coinbox. There's also nothing connected to them except (as can be seen in the links above) ground and +5V, so I don't see any way they could be electronically reset. Latching the values shouldn't be necessary either; $4016 appears to get polled often enough to catch the coin insertion.
lidnariq wrote:
According to the Vs. Unisystem schematic on the front page (
http://nesdev.com/VS_Wiring.pdf ), only "S coin 1" is actually connected to the coin insertion, and both coinboxes are wired in parallel.
This is true. All of the games I tried (which should be most of them) actually check
both bit 5 and bit 6 of $4016 though, so in theory you could wire the second coin switch up to 'S coin 2' instead and still have it work.
Quote:
Code:
Coin acknowledge ($4020-$403F, &c)
Inserting a coin turns the coin bits of $4016 on. They do not turn off until the program acknowledges the credit by writing here.
15 address 4 0 7 bit 0
---- ---- ---- ---- ---- ----
010x xxxx xx1x xxxA xxxx xxxC
| |
| +- 1: (write) Acknowledge coin insertion
+------------ 1: (read) Acknowledge coin insertion
After adding some debugging statements to my emu (before implementing the above behavior), it appears that $4020 is only written to
after the coin status bit returns to 0, not before. This would indicate that the $4020 write depends on the switch status being reset, which means that the write cannot be what's resetting the status. Additionally, the write only happens (and a credit is only added) if the switch is closed for less then some maximum time limit (it's less than a second, but I don't know exactly how long). Otherwise the "coin" is ignored. This seems like a measure to prevent attacks on the coin switch to get free credits.
I modified my code to implement the above behavior, and coin insertion stopped working. After the coin status was set to 1, nothing wrote to $4020, therefore nothing reset the coin status back to 0.
Unless I completely screwed something up (entirely possible
), I don't see how the documented behavior could work. There's nothing in the schematic or wiring diagram that supports it, and it doesn't hold up under empirical testing.