Vs. System: Difference between revisions
(→Controller 2 data, coins, and DIP switches ($4016 read): fixed info, my bad!) |
(→Controller 2 data, coins, and DIP switches ($4016 read): explain observed behavior) |
||
Line 37: | Line 37: | ||
||| |+--- Service button (commonly inserts a credit) | ||| |+--- Service button (commonly inserts a credit) | ||
||+-+---- DIP switches | ||+-+---- DIP switches | ||
++------- Coin inserted | ++------- Coin inserted | ||
The "coin inserted" signals are the contact switches in the coin acceptors. By default, the hardware connects both coin acceptors in parallel, and only to the 0x20 bit. However, games must check both bits because each coin acceptor could have been separated. Some games refuse to grant a credit if the "coin inserted" signal is true for too long, to protect against malicious arcade-goers. | The "coin inserted" signals are the contact switches in the coin acceptors. By default, the hardware connects both coin acceptors in parallel, and only to the 0x20 bit. However, games must check both bits because each coin acceptor could have been separated. Some games refuse to grant a credit if the "coin inserted" signal is true for too long, to protect against malicious arcade-goers. | ||
Line 43: | Line 43: | ||
Unlike previous advice, it is not ''necessary'' to acknowledge a coin insert by driving the coin counter, but the arcade operator would be cross if the game didn't! (How long does this signal read as true when a real coin falls through the acceptor?) | Unlike previous advice, it is not ''necessary'' to acknowledge a coin insert by driving the coin counter, but the arcade operator would be cross if the game didn't! (How long does this signal read as true when a real coin falls through the acceptor?) | ||
Games may, and even probably should, parse the two "coin inserted" bits independently: emulators should NOT set both bits high when a single virtual coin has been inserted. For example, VS Super Mario Bros. gives 2 credits/coin when $4016 is ORed with $60, and 1 credit/coin with $40. | |||
=== Controller 1 data, DIP switches, and [[wikipedia:watchdog timer|watchdog timer]] ($4017 read) === | === Controller 1 data, DIP switches, and [[wikipedia:watchdog timer|watchdog timer]] ($4017 read) === |
Revision as of 02:27, 16 September 2013
The Vs. Unisystem and Vs. Dualsystem are arcade system boards based on the NES.
Palette
There are several different RGB PPUs used in Vs. games. To determine which PPU is used, read the PPU type byte of the NES 2.0 header if available; otherwise, use the hash of the PRG and CHR ROM data.
- 2C03
- This PPU is used in Duck Hunt and Tennis, as well as the PlayChoice, Famicom Titler, and Famicom TVs. Its colors closely resemble those of the 2C02 in the standard NTSC NES.
- 2C04
- There are four versions of this PPU with different palettes. This was used as a form of copy protection, so that games would have wrong colors if someone were to burn a new PRG ROM and CHR ROM and put them on the game PCB.
- 2C05
- This PPU has the same colors as the 2C03, but it swaps the meanings of $2000 and $2001 and returns a constant identifying value in bits 4-0 of $2002. This is also for copy protection.
Registers
Registers $4016 and $4017 have additional bits related to coin insertion and difficulty switches, and $4020 is a new register. The controllers are swapped: $4017 on the left and $4016 on the right. The 2C05 swaps PPUCTRL and PPUMASK. Otherwise, all registers have the same meanings as on the NES or PlayChoice.
Controller and CHR ROM bank ($4016 write)
7 bit 0 ---- ---- xxxx xCRS ||| ||+- 1 then 0: Request a report from the controller ports |+-- In the DualSystem, connects to 1- /IRQ of the other CPU and 2- when high on the primary | specifies that 2KiB of RAM is mapped from $6000-$7FFF, else mapped for the secondary CPU +--- Select 8 KiB CHR ROM bank for PPU $0000-$1FFF (mapper 99 games only) Note: In case of games with 40KiB PRG-ROM (as found in VS Gumshoe), the above bit additionally changes 8KiB PRG-ROM at $8000-$9FFF.
Controller 2 data, coins, and DIP switches ($4016 read)
7 bit 0 ---- ---- xCCD DSxB ||| || | ||| || +- Buttons for player 2 (A, B, 1, 3, Up, Down, Left, Right) ||| |+--- Service button (commonly inserts a credit) ||+-+---- DIP switches ++------- Coin inserted
The "coin inserted" signals are the contact switches in the coin acceptors. By default, the hardware connects both coin acceptors in parallel, and only to the 0x20 bit. However, games must check both bits because each coin acceptor could have been separated. Some games refuse to grant a credit if the "coin inserted" signal is true for too long, to protect against malicious arcade-goers.
Unlike previous advice, it is not necessary to acknowledge a coin insert by driving the coin counter, but the arcade operator would be cross if the game didn't! (How long does this signal read as true when a real coin falls through the acceptor?)
Games may, and even probably should, parse the two "coin inserted" bits independently: emulators should NOT set both bits high when a single virtual coin has been inserted. For example, VS Super Mario Bros. gives 2 credits/coin when $4016 is ORed with $60, and 1 credit/coin with $40.
Controller 1 data, DIP switches, and watchdog timer ($4017 read)
7 bit 0 ---- ---- DDDD DDxB |||| || | |||| || +- Buttons for player 1 (A, B, 2, 4, Up, Down, Left, Right) ++++-++--- More DIP switches
The game must read from $4017 more often than once every second, or the CPU, PPU, and bit at $4020 are reset. The time limit is an analog effect, so may vary by up to a factor of 3 in either direction.
Coin counter ($4020-$403F, &c)
The game is expected to keep track of the total number of coins inserted by toggling this line every time a coin is seen while reading $4016.
15 address 4 0 7 bit 0 ---- ---- ---- ---- ---- ---- 010x xxxx xx1x xxxA xxxx xxxC | | | +- (write) 1, delay, 0: Increment coin counter +------------ (read) Same as write, but see below
The port is mirrored across the entire range of $4020-$5FFF and may interfere with mappers that put ports, ROM, or RAM in this range. When the latched value is 1, it drives an electromagnet in the coin counter. Writing 1 then 0 will increment the counter. Several games have been found to keep the increment signal turned on for 3 to 4 frames. (How long must the software wait between writes? Will too long damage anything?) This register is explicitly cleared on powerup and reset. Reading from the register effectively writes the value of open bus (i.e. the last byte fetched from ROM, usually the LSB) No games use any of this bit's mirrors, or try to read from it.
See also
- VS System mainboard schematic
- VS UniSystem cabinet harness hookup diagram
- VS UniSystem conversion kit installation guide for converting an older single-game Nintendo arcade machine to a VS UniSystem
The hardware used by games released during the Vs. System's commercial life is equivalent to the following mappers:
- iNES Mapper 099 (games provided without a daughterboard)
- iNES Mapper 001 (MMC1)
- iNES Mapper 002 (UxROM)
- iNES Mapper 067 (SUNSOFT-3)
- iNES Mapper 075 (VRC1, erroneously iNES Mapper 151)
- iNES Mapper 206 (Namco 108, erroneously MMC3/iNES Mapper 004)