VS System coin acknowledge

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

VS System coin acknowledge

Post by Zepper »

How does it work? I read the wiki article, but it's unclear. All I got was about $4016 reads returning $60 (coin inserted, my prehistorical doc says $40), but what about the acknowledge???
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: VS System coin acknowledge

Post by lidnariq »

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.
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 D latch's /CLEAR input is connected to two monostable multivibrators (74'123s) but I'm having a lot of trouble parsing what they do. The schematic implies they're somehow triggered by reads from $4017, as well as on powerup. Somehow /CLEAR has to be asserted at some point so that writing 1 to the latch does anything.

$4016 bits 5 and 6 are connected to harness pins 7 and 8, "S coin 1" and "S coin 2" respectively. These go through rather aggressive debouncing (1kΩ pullup and 10µF bypass → 10ms)
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.
I have no idea how the DualSystem coinbox differs.
User avatar
oRBIT2002
Posts: 687
Joined: Sun Mar 19, 2006 3:06 am
Location: Gothenburg/Sweden

Re: VS System coin acknowledge

Post by oRBIT2002 »

I have debugged a few VS games but haven't found any game that uses the "acknowledge" bit, if I am not mistaken.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: VS System coin acknowledge

Post by lidnariq »

In Balloon Fight, at $801A, there's a STA $4020...
Cursorily looking through all the ones I can trivially find, they all seem to have STx $4020
(pcregrep '[\x8C-\x8F] @' *nes returns ≈all of them)
User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: VS System coin acknowledge

Post by Zepper »

Yeah, but what are "the basics" for emulating coin in$ertion, like in VS SMB?
zzo38
Posts: 1096
Joined: Mon Feb 07, 2011 12:46 pm

Re: VS System coin acknowledge

Post by zzo38 »

It also says "it is not known what the effect would be of writing 0 without a coin to be acknowledged" and this is the unknown part. Knowing about light bulb and shutter would also help, in case you are emulating this, building a clone hardware in an arcade cabinet, or even making an arcade cabinet with the emulator (in the latter two cases especially, it seems likely that you might write your own arcade games too; writing it for the 2C03 is probably simplest, and it would still be helpful to know what it does so as to not cause incompatibility).
(Free Hero Mesh - FOSS puzzle game engine)
User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: VS System coin acknowledge

Post by Zepper »

Original quote:

Code: Select all

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
They do not turn off until the program acknowledges the credit by writing (LSB = 1?) (or reading $4020 &C?) here.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: VS System coin acknowledge

Post by lidnariq »

I still can't describe what the coin acceptor does, but I've revised the document on the wiki:
changes, current version of page

Is anything still unclear?
User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: VS System coin acknowledge

Post by Zepper »

I will test this behaviour in my emulator.
perilsensitive
Posts: 13
Joined: Mon Jul 15, 2013 3:35 pm

Re: VS System coin acknowledge

Post by perilsensitive »

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=235454
http://donkeykongrestore.blogspot.com/2 ... -door.html

This one's a DK3 cabinet:

http://www.chompingquarters.com/2010/10 ... -3-harness

The 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. :-)

Code: Select all

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.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: VS System coin acknowledge

Post by lidnariq »

Thank you very much for that information! I didn't really have any ideas where to look for it. (I also may have not tried very hard)

Do you have any information about the mechanical timing, such as how long the coin switches read as true, or how long the electromagnet must be driven?
perilsensitive
Posts: 13
Joined: Mon Jul 15, 2013 3:35 pm

Re: VS System coin acknowledge

Post by perilsensitive »

Not really. Obviously there would be some variation due to the kind of coin or token, switches or mech being used, but the games allow for that by ensuring that the release occurs within the maximum time limit. It's possible that the check routine could vary enough from game to game to make a significant difference in the maximum time limit as well, but I wouldn't think so.

MAME's VS. System driver sets the coin status bits to 1 for exactly one frame after the user presses the "insert coin" key/button, then sets them back to 0 automatically. This isn't an indication of how long the switch is actually pressed for though, but rather the maximum amount of time it takes for the game to notice the coin insertion. Some of the other drivers keep their coin status bits set for 5 frames, for example.

Regarding the counter, I don't anything for that either. Examining the writes to $4020 is interesting though. I tried four games and observed the following values and approximate delays between writes:

Vs. Super Mario Bros. $01, $00 four frames later
Vs. Duck Hunt: $00, $01 one frame later, $00 three frames later
Vs. Clu Clu Land: $15, $13, $11, $0f, $0c, $0a, $08, $06, $04, $02 (one frame between each write)
Vs. Gradius: $01, $01 (just over one frame), $01 (just under one frame), $01 (one frame), $00 (21 cycles!), $00, $00, $00, $00, $00 (all one frame between writes)

It's odd that Clu Clu Land writes the values it does, since only bit 0 matters. Anyway, it looks like the magnet is turned on for approximately 3-4 frames, so at least 1/20th of a second.
zzo38
Posts: 1096
Joined: Mon Feb 07, 2011 12:46 pm

Re: VS System coin acknowledge

Post by zzo38 »

Is there a coin return? The coin acknowledge controls a counter, but on any cabinet does the coin acknowledge can be used to disable a coin return? Perhaps if someone is making a cabinet and/or game, you could use this not only to advance a counter but also to disable a coin return, so that if you insert a coin when it isn't expecting one, or when the maximum number of credits is already inserted, it can return the coin; would this work?

An emulator could provide a coin counter display if they want to, I suppose; it might help some things.

Also, if you can figure out what the minimum and maximum and maximum (if any) delay for writing the coin counter register is, this can help for use of mappers that have other registers/RAM/ROM in $4020-$5FFF when being used with Vs.System (maybe this doesn't work with the actual Vs.System hardware, but it can be useful with clone hardware and emulators, in order to accurately emulate actual Vs.System hardware and in case you make up a game using some of those mappers that is made into both a home version and arcade version).
(Free Hero Mesh - FOSS puzzle game engine)
perilsensitive
Posts: 13
Joined: Mon Jul 15, 2013 3:35 pm

Re: VS System coin acknowledge

Post by perilsensitive »

zzo38 wrote:Is there a coin return? The coin acknowledge controls a counter, but on any cabinet does the coin acknowledge can be used to disable a coin return? Perhaps if someone is making a cabinet and/or game, you could use this not only to advance a counter but also to disable a coin return, so that if you insert a coin when it isn't expecting one, or when the maximum number of credits is already inserted, it can return the coin; would this work?

An emulator could provide a coin counter display if they want to, I suppose; it might help some things.
You could do this with lock-out coils, but you need to have coin mechs that already have them; most don't, since they weren't used much beyond early pinball machines. The VS. System board isn't designed to use them and therefore has no connection for them, although you could possibly use the 'S counter' line to power them instead of the counter. Obviously, existing ROMs would need to be modified to make use of them. The counter could still be used by connecting it to a relay controlled by the coin switches directly instead of letting the game control it.

It's probably not worth all the effort though, as the problems they prevent are mostly non-issues:
  • - Most players would ensure that the machine is powered on and appears to be working properly before putting coins in.
    - The maximum number of credits is probably high enough (99, for example) that nobody is going to dump enough coins into the machine in one go to actually hit it.
    - Since lock-out coils aren't common, games are written to check for coins all the time (VS. games seem to check at least once per frame) so there's essentially no risk of losing coins except during the self-test sequence at boot.
zzo38 wrote:Also, if you can figure out what the minimum and maximum and maximum (if any) delay for writing the coin counter register is, this can help for use of mappers that have other registers/RAM/ROM in $4020-$5FFF when being used with Vs.System (maybe this doesn't work with the actual Vs.System hardware, but it can be useful with clone hardware and emulators, in order to accurately emulate actual Vs.System hardware and in case you make up a game using some of those mappers that is made into both a home version and arcade version).
I've thought about this too. All of the VS. games that don't use mapper 99 are installed on daughter boards that are connected to the CPU and PPU sockets (images here). It looks like all of the CPU pins just get passed straight through on these, which works since all of the mappers only care about $8000-$FFFF (which are now open-bus since the EPROMs must be pulled from the main PCB).

A similar solution could be used for mappers like MMC5 that have registers in the $4020-$5FFF range, except some additional logic would be necessary to ensure that accesses of the mapper registers would only be seen by the mapper. That would require that the CPU pins not all pass straight through (the CopyNES PCB does this). This would let both the mapper and the coin counter be used normally, as long as $4020 (or one of its mirrors) is still handled by the main PCB.
Post Reply