83 KiB
Konami System 573
The System 573 is a PlayStation-based system used in a number of Konami arcade games from the late 90s and early 2000s, most notably Dance Dance Revolution and other early Bemani (Konami's rhythm game division) games.
- Differences vs. PS1
- Register map
- I/O boards
- Security cartridges
- External modules
- Connectors
- BIOS
- Game-specific information
- Misc. notes
- Pinouts
- Credits, sources and links
This document is currently work-in-progress. Here is an incomplete list of things that are still missing:
- The BIOS and games are notoriously picky about ATAPI drives. Konami's code shall be disassembled and tested in order to find out where and why drive initialization fails with most drives.
- JVS communications and the microcontroller that handles them have to be documented. The microcontroller's firmware has already been dumped.
- I/O boards, especially the digital I/O board, need to be properly reverse engineered and documented. The order of light outputs on the analog and digital I/O boards might be completely wrong. The fishing controls board has been fully reverse engineered but documentation for it is missing.
- The DDR stage I/O board's communication protocol is largely unknown. More tests need to be done on real hardware and its CPLD shall be dumped if possible.
- The 700B01 BIOS contains references to the ability to boot from a FAT filesystem on a CF card inserted into a PCMCIA slot, which would actually be impossible due to the way the slots are wired up. The H8/3644 check is also completely different from the one performed by the 700A01 shell.
Differences vs. PS1
Main changes
- Main RAM is 4 MB instead of 2 MB and VRAM is 2 MB instead of 1 MB. SPU RAM is still 512 KB.
- The CD drive is completely different. While the PS1's drive is fully integrated into the motherboard and uses a custom protocol, the 573 employs a standard ATAPI drive. This means there is no provision for playing XA-ADPCM, even though CD audio can still be played (as long as the 4-pin audio cable between the drive and the 573 motherboard is present). There is no wobble groove to worry about, but some drives the system shipped with are reportedly unable to read CD-Rs. Most 573 units have had their drive replaced (usually with a DVD drive) at least once, so this should not be an issue.
- The SPI bus for controllers and memory cards is unused. It is broken out to a connector, however no known I/O board uses it. Some games supported PS1 memory cards through an adapter connected over JVS, with its own CPU and local SPI bus (more details about this later).
- The "parallel I/O" expansion port is replaced by 2 PCMCIA slots. These
slots are wired in parallel and mapped at the same address as the internal
flash through bank switching. They are fairly limited though as they only
support 16-bit bus accesses (i.e.
/CE1
and/CE2
are tied together, even though the CPU actually exposes them as separate signals!), have no DMA and don't expose the PCMCIA I/O and configuration space (/IORD
and/IOWR
are not connected at all). This makes them incompatible with CF cards and most PCMCIA devices.
Additional hardware
- JAMMA interface and built-in I/O ports: the 573 provides multiple digital and analog ports for interfacing with arcade cabinet controls. Depending on the I/O board the system came with, these signals might be broken out through connectors on the system's case.
- Internal 16 MB flash memory: the 573's BIOS is capable of booting either from the CD drive or from an array of flash memory chips soldered to the motherboard, which are also memory-mapped. Most Konami games are designed to run from flash: when attempting to run them from CD without also having them installed, the executable on the disc will erase the flash and install the game before starting. Most games still require the CD, in some cases a different one, to be kept in the drive after installation as they use it for music playback or to stream additional data.
- PCMCIA memory card: some games shipped with additional flash memory in the form of a PCMCIA card, with sizes ranging from 16 to 64 MB. Note that these are "linear" memory-mapped cards without any built-in controller, not CF or ATA-compatible cards (which would be incompatible with the 573's PCMCIA wiring).
- RTC and battery-backed 8 KB RAM: used by games to store settings, save data and installation info (possibly including serial numbers). Unfortunately the RTC chip is one of those all-in-one things with a battery sealed inside, soldered directly to the motherboard. It goes without saying that 573 boards with a working RTC are rare.
- JVS bus: allows connection of multiple daisy chained peripherals using a standardized protocol based on a serial (RS-485) bus. The JVS specification requires devices to use USB connectors (USB-A at the host side, full size USB-B on peripherals) to carry RS-485 signals. The JVS port on the 573 was only ever "officially" used for the PS1 memory card reader module, however some games seem to support JVS I/O boards and input devices in addition to the built-in JAMMA connector.
- Security cartridge: optionally installed on the 573's side, contains a password protected EEPROM that holds factory pre-programmed data as well as keys generated during game installation, plus in some case a 64-bit serial number ROM. Security cartridges were bundled with most game discs as a way to prevent copying, as the discs themselves had no other protection of any kind. The CPU's serial port (SIO1) is also wired to the security cartridge slot.
Register map
All standard PS1 registers, with the exception of the CD drive's, are present.
System 573-specific hardware is mapped into the EXP1 region at 0x1f000000
.
IRQ10 and DMA5, normally reserved for the expansion bus (and lightguns) on a
regular PS1, are used to access the ATAPI CD drive, while IRQ2 and DMA3 go
unused.
NOTE: EXP1 must be configured prior to accessing any of these registers.
The proper configuration value to write to the EXP1 delay/size register at
0x1f801008
is 0x24173f47
. Afterwards, all bus writes shall be 16 or 32
bits wide. The behavior of 8-bit writes is undefined (8-bit reads work as
intended).
Address range | Description |
---|---|
0x1f000000-0x1f3fffff |
Bank switched, can be mapped to flash or PCMCIA slots |
0x1f400000-0x1f40000f |
Konami ASIC registers |
0x1f480000-0x1f48000f |
IDE register bank 0 |
0x1f4c0000-0x1f4c000f |
IDE register bank 1 |
0x1f620000-0x1f623fff |
RTC registers and battery-backed RAM |
0x1f640000-0x1f6400ff |
I/O board registers |
Konami ASIC registers
The Konami 056879 ASIC, used in most of their late 90s arcade boards, is nothing more than a single 16-bit output port and 6 (possibly more?) 16-bit input ports in a single package.
0x1f400000
(ASIC register 0): ADC SPI, coin counters, audio
Bits | RW | Description |
---|---|---|
0 | W | SPI MOSI to ADC |
1 | W | SPI CS to ADC |
2 | W | SPI SCK to ADC |
3 | W | Coin counter 1 (1 = energize counter coil) |
4 | W | Coin counter 2 (1 = energize counter coil) |
5 | W | Built-in audio amplifier enable (0 = muted) |
6 | W | External audio input enable? (0 = muted) |
7 | W | SPU DAC output enable (0 = muted) |
8 | W | Status bus clock to microcontroller |
9-15 | Unused? |
The ADC chip is an ADC0834 from TI, which uses a proprietary SPI(-like)
protocol. Its four inputs are wired to the ANALOG
connector on the 573
motherboard. Refer to the ADC083x datasheet for details on how to bitbang the
protocol.
Mechanical coin counters are incremented by games whenever a coin is inserted by setting bit 3 or 4 for a fraction of a second and then clearing them. Bit 5 controls whether the onboard audio amp is enabled, but does not affect the RCA line level outputs (which are always enabled). Setting bit 5 has no effect immediately as the amp takes about a second to turn on.
The exact purpose of bit 6 is unclear. Games use it to mute audio from the CD drive or digital I/O board; in particular, this bit is cleared during attract mode if attract mode sounds are disabled. However, testing on real hardware seems to suggest it is some sort of downmixing or attenuation control rather than a proper mute.
Unknown what reading from this port does.
0x1f400004
(ASIC register 2): Misc. inputs
Bits | RW | Description |
---|---|---|
0-3 | R | DIP switch status |
4-7 | R | Status bus from microcontroller |
8-15 | RW | From I0-I7 on security cartridge |
The highest 8 bits read from this register are the state of the security
cartridge's pins I0-I7
. See the security cartridge section for an explanation
of what each bit is wired to.
Bit 3 (DIP switch 4) is used by the BIOS to determine whether to boot from the internal flash or CD drive. If set, the BIOS will attempt to search for a valid executable on the flash before initializing the drive.
0x1f400006
(ASIC register 3): Misc. inputs
Bits | RW | Description |
---|---|---|
0 | R | SPI MISO from ADC |
1 | R | SAR status from ADC |
2 | R | From SDA on security cartridge |
3 | R | JVS sense input |
4 | R | JVS receive buffer status (1 = not empty) |
5 | R | Unknown (JVS-related) |
6 | R | ISIG status on security cartridge |
7 | R | DSIG status on security cartridge |
8 | R | Coin switch input 1 (inverted) |
9 | R | Coin switch input 2 (inverted) |
10 | R | PCMCIA card 1 insertion (0 = present) |
11 | R | PCMCIA card 2 insertion (0 = present) |
12 | R | Test button (built-in and JAMMA pin 15) |
13-15 | Unused? |
See the security cartridge section for more details about ISIG
and DSIG
.
For bit 2 to be valid, SDA
should be set as an input by clearing the
respective bit in the bank switch register.
0x1f400008
(ASIC register 6): JAMMA controls
Bits | RW | Description |
---|---|---|
0 | R | Player 2 joystick left (JAMMA pin X) |
1 | R | Player 2 joystick right (JAMMA pin Y) |
2 | R | Player 2 joystick up (JAMMA pin V) |
3 | R | Player 2 joystick down (JAMMA pin W) |
4 | R | Player 2 button 1 (JAMMA pin Z) |
5 | R | Player 2 button 2 (JAMMA pin a) |
6 | R | Player 2 button 3 (JAMMA pin b) |
7 | R | Player 2 start button (JAMMA pin U) |
8 | R | Player 1 joystick left (JAMMA pin 20) |
9 | R | Player 1 joystick right (JAMMA pin 21) |
10 | R | Player 1 joystick up (JAMMA pin 18) |
11 | R | Player 1 joystick down (JAMMA pin 19) |
12 | R | Player 1 button 1 (JAMMA pin 22) |
13 | R | Player 1 button 2 (JAMMA pin 23) |
14 | R | Player 1 button 3 (JAMMA pin 24) |
15 | R | Player 1 start button (JAMMA pin 17) |
NOTE: since buttons are active low (wired between JAMMA pins and ground), all bits are 0 when a button is pressed and 1 when it isn't.
The BIOS and games often read from this register and discard the result as a way of (inefficiently) keeping the CPU's write queue flushed.
0x1f40000a
(ASIC register 5): JVS receive buffer
Bits | RW | Description |
---|---|---|
0-15 | R | JVS data output from microcontroller |
0x1f40000c
(ASIC register 6): JAMMA controls / External inputs
Bits | RW | Description |
---|---|---|
0-7 | Unused? | |
8 | R | Player 1 button 4 (JAMMA pin 25) |
9 | R | Player 1 button 5 (JAMMA pin 26) |
10 | R | Service button (JAMMA pin R) |
11 | R | Player 1 button 6 |
12-15 | Unused? |
NOTE: since buttons are active low (wired between JAMMA pins and ground), all bits are 0 when a button is pressed and 1 when it isn't.
The signals for buttons 4 and 5 are wired in parallel to both JAMMA and the
EXT-IN
connector, while button 6 can only be connected through EXT-IN
and
is usually unused.
0x1f40000e
(ASIC register 7): JAMMA controls / External inputs
Bits | RW | Description |
---|---|---|
0-7 | Unused? | |
8 | R | Player 2 button 4 (JAMMA pin c) |
9 | R | Player 2 button 5 (JAMMA pin d) |
10 | Unused? | |
11 | R | Player 2 button 6 |
12-15 | Unused? |
NOTE: since buttons are active low (wired between JAMMA pins and ground), all bits are 0 when a button is pressed and 1 when it isn't.
The signals for buttons 4 and 5 are wired in parallel to both JAMMA and the
EXT-IN
connector, while button 6 can only be connected through EXT-IN
and
is usually unused.
IDE registers
The IDE interface is already well documented in many places. It consists of a
16-bit parallel data bus with a 3-bit address bus and 2 bank select pins
(/CS0
and /CS1
), giving a total of 16x 16-bit registers of which only 9 are
typically used. The 40-pin IDE cable carries a few other signals, such as an
interrupt pin and DMA control pins (unused on the 573). On the 573 the two IDE
banks are mapped to two separate memory regions at 0x1f480000
(CS0) and
0x1f4c0000
(CS1). The interrupt pin is routed into IRQ10 through the CPLD,
while DMA and status pins are not connected.
On the 573 most (but not all) games expect an ATAPI CD drive to be always connected and set as master. Connecting an additional ATA hard drive, CF card or IDE-to-SATA bridge configured as slave does not seem to interfere with the BIOS. Homebrew games and apps can leverage such a drive to e.g. dump the flash or save arbitrary data, or to load assets for debugging without having to burn discs.
Note that ATAPI gives slightly different meanings to most IDE registers, so homebrew apps that support an additional ATA drive will have to interpret registers differently depending on whether they are accessing the master ATAPI drive or the slave ATA drive. Refer to the ATA and ATAPI specifications for more details.
0x1f480000
(IDE address 0, CS0): Data transfer
Data transfers can also be performed through DMA5, see below for details.
0x1f480002
(IDE address 1, CS0): Error / Features
0x1f480004
(IDE address 2, CS0): Sector count
0x1f480006
(IDE address 3, CS0): Sector number
0x1f480008
(IDE address 4, CS0): Cylinder number low
0x1f48000a
(IDE address 5, CS0): Cylinder number high
0x1f48000c
(IDE address 6, CS0): Head number / Drive select
0x1f48000e
(IDE address 7, CS0): Status / Command
0x1f4c000c
(IDE address 6, CS1): Alternate status
IDE DMA and quirks
DMA channel 5, normally unused/reserved for the expansion port on a PS1, can be
used to transfer data to/from the IDE bus... with some caveats. The "correct"
way to connect an IDE drive to the PS1's DMA controller would to be to wire up
DMARQ
and DMACK
from the drive directly to the respective pins on the CPU,
allowing the DMA controller to synchronize transfers to the drive's internal
buffer seamlessly.
However, Konami being Konami, they didn't do this on the 573. Instead the drive
will "see" a DMA read or write as a burst of regular (PIO) CPU-issued reads or
writes. As such, the drive shall be configured (using the IDE "set features"
command) for PIO data transfer rather than DMA transfer, and bits 9-10 in the
DMA5_CHCR
register shall be cleared to put the channel in manual sync mode.
The DRQ
bit in the status register must also be polled manually prior to
starting a transfer to make sure the drive is ready for it.
RTC registers
The RTC chip is an ST M48T58. This chip behaves like a normal 8192-byte 8-bit static RAM; in the System 573 it's connected to the lower 8 bits of the 16-bit data bus and should be accessed by performing 16-bit bus accesses and ignoring/masking out the upper 8 bits (like when accessing IDE/ATAPI control registers).
As explained in the M48T58 datasheet, the first 8184 bytes are just regular SRAM while the last 8 bytes are mapped to the RTC. Note that all clock values are buffered, i.e. they are stored in intermediate registers rather than being directly read from/written to the clock counters. Bit 6 in the control register must be set before reading the time to fetch the current time from the clock, and bit 7 must be set after writing new values to copy them over.
NOTE: in the "RWC" column, "C" means the value is updated by the clock logic when bit 6 in the control register is set.
0x1f623ff0
(M48T58 addr. 0x1ff8
): Calibration / Control
Bits | RWC | Description |
---|---|---|
0-4 | RW | Calibration offset (0-31), adjusts oscillator frequency |
5 | RW | Sign bit for calibration offset |
6 | W | Read trigger, write 1 to update registers from clock |
7 | W | Write trigger, write 1 to set clock to match registers |
8-15 | Unused |
0x1f623ff2
(M48T58 addr. 0x1ff9
): Seconds / Stop
Bits | RWC | Description |
---|---|---|
0-3 | RWC | Seconds (0-9) |
4-6 | RWC | Tens of seconds (0-5) |
7 | RW | Stop flag, write 1 to pause clock or 0 to resume |
8-15 | Unused |
0x1f623ff4
(M48T58 addr. 0x1ffa
): Minutes
Bits | RWC | Description |
---|---|---|
0-3 | RWC | Minutes (0-9) |
4-6 | RWC | Tens of minutes (0-5) |
7-15 | Unused |
0x1f623ff6
(M48T58 addr. 0x1ffb
): Hours
Bits | RWC | Description |
---|---|---|
0-3 | RWC | Hours (0-9, or 0-3 if tens = 2) |
4-5 | RWC | Tens of hours (0-2) |
6-15 | Unused |
Hours are always returned in 24-hour format. Unlike other RTC chips there is no way to switch to 12-hour format.
0x1f623ff8
(M48T58 addr. 0x1ffc
): Day of week / Century
Bits | RWC | Description |
---|---|---|
0-2 | RWC | Day of week (1-7) |
3 | Unused | |
4 | RWC | Century flag |
5 | RW | Century flag toggling enable, write 0 to disable |
6 | RW | Enable 512 Hz clock signal output on pin 1 |
7-15 | Unused |
The day of week register is an independent counter that is incremented at midnight. There is no logic for calculating the day of week, it is the user's responsibility to calculate it when changing the time. It's unclear whether Konami games interpret 1 as Monday or Sunday.
Bit 4 is a single-bit "counter" that gets toggled on each turn of the century (not something that happens that often). It can be frozen by clearing bit 5. Setting bit 6 will route the internal oscillator's output to M48T58 pin 1, which does not seem to be connected to anything on the 573.
0x1f623ffa
(M48T58 addr. 0x1ffd
): Day of month / Battery state
Bits | RWC | Description |
---|---|---|
0-3 | RWC | Day of month (range depends on tens and month) |
4-5 | RWC | Tens of day of month (range depends on month) |
6 | R | Low battery flag (1 = battery voltage is below 2.5V) |
7 | RW | Battery monitoring enable (1 = enabled) |
8-15 | Unused |
0x1f623ffc
(M48T58 addr. 0x1ffe
): Month
Bits | RWC | Description |
---|---|---|
0-3 | RWC | Month (1-9, or 0-2 if tens = 1) |
4 | RWC | Tens of month (0-1) |
5-15 | Unused |
0x1f623ffe
(M48T58 addr. 0x1fff
): Year
Bits | RWC | Description |
---|---|---|
0-3 | RWC | Year (0-9) |
4-7 | RWC | Tens of year (0-9) |
8-15 | Unused |
The year counter covers a full century, going from 00 to 99. On each overflow the century flag in the day of week register is toggled.
Other registers
These registers are implemented almost entirely using 74-series logic and the XC9536 CPLD on the main board.
0x1f500000
: Bank switch / Security cartridge
Bits | RW | Description |
---|---|---|
0-5 | W | Bank number (0-47, see below) |
6 | W | SDA direction on security cartridge (0 = input/high-z) |
7 | Unknown (goes into CPLD) | |
8-15 | Unused |
Bit 6 controls whether SDA
on the security cartridge is an input or an
output. If set, SDA
will output the same logic level as D0
, otherwise the
pin will be floating. Bits 0-5 are used to select what shall be mapped to the
first 4 MB of the expansion region at 0x1f000000
, according to the following
table:
Bank | Mapped to |
---|---|
0 | Internal flash 1 (chips 31M , 27M ) |
1 | Internal flash 2 (chips 31L , 27L ) |
2 | Internal flash 3 (chips 31J , 27J ) |
3 | Internal flash 4 (chips 31H , 27H ) |
4-15 | Unused |
16-31 | PCMCIA card slot 1 |
32-47 | PCMCIA card slot 2 |
48-63 | Unused |
0x1f520000
: JVS MCU reset control?
Bits | RW | Description |
---|---|---|
0-6 | Unused | |
8 | W | Reset pin output (0 = pull reset low) |
9-15 | Unused |
This register hasn't been tested nor confirmed to exist, but it is supposed to reset the H8/3644 microcontroller.
0x1f560000
: IDE reset control
Bits | RW | Description |
---|---|---|
0 | W | Reset pin output (0 = pull reset low) |
1-15 | Unused |
Since the IDE reset pin is active-low, resetting the CD drive is done by
writing 0 to this register, then waiting a few milliseconds and finally writing
1 again. Note that the IDE protocol also specifies a way to "soft-reset"
devices using the SRST
bit in the device control register.
0x1f5c0000
: Watchdog clear
Bits | RW | Description |
---|---|---|
0-15 | Unused |
This register is a dummy write-only port that clears the watchdog timer embedded in the Konami 058232 ASIC when any value is written to it. The minimum rate the watchdog must be cleared at is currently unknown, but the BIOS and most games seem to write to this port at least once per frame.
If the watchdog is not constantly cleared, it will generate a reset pulse and reboot the 573. There is no way to disable the watchdog other than physically modifying the 573 and desoldering the 058232 ASIC (which also drives coin counters), or cutting its reset output pin.
0x1f600000
: External outputs
Bits | RW | Description |
---|---|---|
0-7 | W | To OUT0-OUT7 on EXT-OUT connector |
8-15 | Unused |
The lower 8 bits written to this register are latched on pins OUT0-OUT7
on
the external output connector (see the pinouts section). This connector is used
by some games to control cabinet lights without using an I/O board.
0x1f680000
: JVS transmit buffer
Bits | RW | Description |
---|---|---|
0-15 | W | JVS data input to microcontroller |
0x1f6a0000
: Security cartridge outputs
Bits | RW | Description |
---|---|---|
0-7 | RW | To D0-D7 on security cartridge |
8-15 | Unused |
The lower 8 bits written to this register go to the cartridge's pins D0-D7
.
See the security cartridge section for an explanation of what each pin is wired
to. Bit 0 additionally controls the SDA
pin when set to output (see the bank
switch register). According to MAME, reading from this register will yield the
last value written to it.
I/O boards
Having been used in all sorts of games, from DDR to fishing simulators, the
System 573 was designed to be expanded with game-specific hardware using I/O
boards mounted on top of the main board, custom security cartridges or both.
I/O boards have full access to the 16-bit system bus and are mapped to the
0x1f640000-0x1f6400ff
region.
Several boards are known to exist although so far most of them haven't yet been documented nor fully emulated in MAME.
Analog I/O board (GX700-PWB(F)
)
The name is misleading as the board does not deal with any analog signals whatsoever, all it does is providing a few registers for controlling lights on the cabinet through high-current optocouplers. The name was given retroactively to differentiate it from the digital I/O board.
This board provides up to 32 light outputs through 4 connectors. See the game-specific information section for details on how lights are wired up on each cabinet type.
0x1f640040
: Light control 0
Bits | RW | Description |
---|---|---|
0 | W | To light output 3 |
1 | W | To light output 2 |
2 | W | To light output 7 |
3 | W | To light output 6 |
4 | W | To light output 5 |
5 | W | To light output 4 |
6 | W | To light output 1 |
7 | W | To light output 0 |
8-15 | Unused |
0x1f640044
: Light control 1
Bits | RW | Description |
---|---|---|
0 | W | To light output 11 |
1 | W | To light output 10 |
2 | W | To light output 15 |
3 | W | To light output 14 |
4 | W | To light output 13 |
5 | W | To light output 12 |
6 | W | To light output 9 |
7 | W | To light output 8 |
8-15 | Unused |
0x1f640048
: Light control 2
Bits | RW | Description |
---|---|---|
0 | W | To light output 19 |
1 | W | To light output 18 |
2 | W | To light output 23 |
3 | W | To light output 22 |
4 | W | To light output 21 |
5 | W | To light output 20 |
6 | W | To light output 17 |
7 | W | To light output 16 |
8-15 | Unused |
0x1f64004c
: Light control 3
Bits | RW | Description |
---|---|---|
0 | W | To light output 27 |
1 | W | To light output 26 |
2 | W | To light output 31 |
3 | W | To light output 30 |
4 | W | To light output 29 |
5 | W | To light output 28 |
6 | W | To light output 25 |
7 | W | To light output 24 |
8-15 | Unused |
Digital I/O board (GX894-PWB(B)A
)
This board was used for pretty much all Bemani games besides earlier ones which used CD audio and the analog I/O board. In addition to the usual light control circuitry, this board features an FPGA and an MPEG decoder ASIC to play encrypted MP3 files. The FPGA has 24 MB of dedicated RAM onto which the files are preloaded on startup, then decrypted on the fly and fed to the decoder. The board also features two RCA jacks for communication with other cabinets and a 64-bit unique serial number, copied to the security cartridge during installation in order to prevent operators from installing the same game on multiple systems.
NOTE: the vast majority of the registers provided by this board (including light control) are handled by its FPGA, which requires a configuration bitstream to be uploaded to it through the appropriate register in order to work. There are two known versions of Konami's bitstream, with the only difference being the decryption algorithm. All games that use the digital I/O board upload the bitstream to the FPGA on startup before accessing any other register.
A homebrew game would have to do the same, however distributing Konami's bitstream would be problematic from a copyright standpoint. The digital I/O board is thus currently unusable by homebrew. This might change in the future if a custom FPGA bitstream is ever going to be developed; the custom bitstream would not only skip decryption but also implement a custom set of registers (rather than the ones described below), sidestepping the lack of documentation entirely.
0x1f6400e0
: Light control 1 (impl. by bitstream)
Bits | RW | Description |
---|---|---|
0-11 | Unused? | |
12 | W | To light output 4 |
13 | W | To light output 7 |
14 | W | To light output 5 |
15 | W | To light output 6 |
0x1f6400e2
: Light control 0 (impl. by bitstream)
Bits | RW | Description |
---|---|---|
0-11 | Unused? | |
12 | W | To light output 0 |
13 | W | To light output 3 |
14 | W | To light output 1 |
15 | W | To light output 2 |
0x1f6400e4
: Light control 3 (impl. by bitstream)
Bits | RW | Description |
---|---|---|
0-11 | Unused? | |
12 | W | To light output 12 |
13 | W | To light output 15 |
14 | W | To light output 13 |
15 | W | To light output 14 |
0x1f6400e6
: Light control 7 (impl. by bitstream)
Bits | RW | Description |
---|---|---|
0-11 | Unused? | |
12 | W | To light output 28 |
13 | W | To light output 31 |
14 | W | To light output 29 |
15 | W | To light output 30 |
0x1f6400f6
: FPGA status
0x1f6400f8
: FPGA bitstream upload
0x1f6400fa
: Light control 4 (impl. by bitstream)
Bits | RW | Description |
---|---|---|
0-11 | Unused? | |
12 | W | To light output 16 |
13 | W | To light output 19 |
14 | W | To light output 17 |
15 | W | To light output 18 |
0x1f6400fc
: Light control 5 (impl. by bitstream)
Bits | RW | Description |
---|---|---|
0-11 | Unused? | |
12 | W | To light output 20 |
13 | W | To light output 23 |
14 | W | To light output 21 |
15 | W | To light output 22 |
0x1f6400fe
: Light control 2 (impl. by bitstream)
Bits | RW | Description |
---|---|---|
0-11 | Unused? | |
12 | W | To light output 8 |
13 | W | To light output 11 |
14 | W | To light output 9 |
15 | W | To light output 10 |
0x1f6400ee
: DS2401 ID chip (impl. by bitstream)
Alternate analog I/O board (GX700-PWB(K)
)
This board is currently undocumented.
Fishing controls board (GE765-PWB(B)A
)
This board is currently undocumented.
DDR Karaoke Mix I/O board (GX921-PWB(B)
)
This board is currently undocumented.
Gun Mania I/O board
This board is currently undocumented.
Hypothetical debugging board
There is no proof whatsoever of this board having ever existed, but the BIOS and some games attempt to access the hardware on it. In particular it seems to contain at least a Fujitsu MB89371 UART and a 7-segment display, although these might have actually been on two separate boards. The only game known to access the serial ports is Great Bishi Bashi Champ.
The MB89371 does not have a publicly available datasheet.
0x1f640000
: UART data
0x1f640002
: UART control
0x1f640004
: UART baud rate select
0x1f640006
: UART mode
0x1f640010
: 7-segment display
Bits | RW | Description |
---|---|---|
0 | W | Second digit segment G (0 = on) |
1 | W | Second digit segment F (0 = on) |
2 | W | Second digit segment E (0 = on) |
3 | W | Second digit segment D (0 = on) |
4 | W | Second digit segment C (0 = on) |
5 | W | Second digit segment B (0 = on) |
6 | W | Second digit segment A (0 = on) |
7 | Unused | |
8 | W | First digit segment G (0 = on) |
9 | W | First digit segment F (0 = on) |
10 | W | First digit segment E (0 = on) |
11 | W | First digit segment D (0 = on) |
12 | W | First digit segment C (0 = on) |
13 | W | First digit segment B (0 = on) |
14 | W | First digit segment A (0 = on) |
15 | Unused |
The BIOS shell shows "00" on this display (but contains a function to show any hexadecimal value). Kick & Kick shows an animated spinner, some other games show error or status codes on it. This might have been meant to be a POST display to be integrated into the 573 main board at some point.
Security cartridges
There are several different security cartridges, most of which feature game specific hardware and connectors to e.g. drive lights or interface to external boxes. All of them fall into five categories, based on the actual security chips they contain:
Type | Security EEPROM chip | ID chip |
---|---|---|
X | X76F041 |
|
XI | X76F041 |
DS2401 |
Y | X76F100 |
|
YI | X76F100 |
DS2401 |
ZI | PIC16C625 (ZS01 ) |
DS2401 |
NOTE: the existence of Y/YI cartridges has never been confirmed. All known games that support Y/YI cartridges can also use X/XI cartridges interchangeably and no actual X76F100-based cartridge was ever found in the wild.
The following cartridges are currently known to exist:
Name (on PCB) | Type | Used by | Additional I/O connectors | Additional hardware |
---|---|---|---|---|
GX700-PWB(D) |
X | Analog I/O games | Unpopulated (T)QFP footprint | |
GX894-PWB(D) |
XI? | Unknown | Unpopulated SOIC footprints | |
GX700-PWB(J) |
XI | PunchMania | Analog in (12-pin), unknown (10-pin) | SPI ADC chip for analog inputs |
GX883-PWB(D) |
XI | Digital I/O games | Network (5-pin), amp box (6-pin) | RS-232 transceiver powered by isolated DC-DC module |
GE949-PWB(D)A |
ZI | Digital I/O games | Network (5-pin), amp box (6-pin) | RS-232 transceiver powered by isolated DC-DC module |
GE949-PWB(D)B |
ZI | Digital I/O games | Unpopulated 5-pin, 6-pin | Same as above but only security chips are populated |
PWB0000068819 |
X | Hyper BB Champ | 12V input (4-pin), lights (16-pin) | Latch controlled light outputs |
PWB0000088954 |
XI | Salary Man Champ | 12V input (4-pin), lights (16-pin) | Shift register controlled light outputs |
The main security chip in all types other than ZI is actually just a simple password-protected I2C EEPROM whose datasheet is readily available. ZI cartridges use a microcontroller running custom firmware (which hasn't yet been dumped) instead. XI, YI and ZI cartridges also feature a Dallas/Maxim DS2401 chip that communicates using the 1-wire protocol and, like all 1-wire devices, provides a supposedly unique 64-bit serial number to identify the cartridge. The DS2401 on ZI cartridges isn't directly accessible, it's instead read by the ZS01.
PunchMania cartridges additionally contain an ADC0838 chip, which is identical to the ADC0834 on the main board except with 8 channels instead of 4. The ADC's inputs are broken out to a connector on the cartridge. Hyper Bishi Bashi Champ and Salary Man Champ cartridges contain some 74 logic to control cabinet lights and are fed 12V through a separate cable on the JAMMA harness.
Different game/install cartridges
Some games used an XI cartridge for running the installer and a ZI cartridge for the actual game; MAME calls these games "XZI". MAME also declares some games as "YYI" (YI cartridge for the installer and another YI cartridge to run the game), however no YI cartridges are known to exist.
Interface
The 573 motherboard has no dedicated SPI, I2C or 1-wire peripherals (other than the unused PS1 controller SPI bus), so all communication with these chips is bitbanged in software through a set of 6 UART pins, two 8-bit fixed direction I/O ports plus a bidirectional pin:
Name | Dir | Common to all cartridge types | XI/YI/ZI cartridges | Salary Man Champ cart | Hyper BB Champ cart | PunchMania cart |
---|---|---|---|---|---|---|
TX |
W | Network connector TX1 (via RS-232 PHY) | ||||
RX |
R | Network connector RX1 (via RS-232 PHY) | ||||
/RTS |
W | Serial port enable (shorted to CTS) | ||||
/CTS |
R | Serial port enable (shorted to RTS) | ||||
/DTR |
W | Not wired to the cartridge slot? | ||||
/DSR |
R | Cartridge presence detection (grounded) | ||||
D0 |
W | I2C SDA to security chip (through SDA ) |
Player 3 light latch | SPI CS to ADC | ||
D1 |
W | I2C SCL to security chip | Player 2 light latch | SPI SCK to ADC | ||
D2 |
W | I2C CS to security chip | ||||
D3 |
W | Security chip reset | Player 1 light latch | |||
D4 |
W | Drives 1-wire bus low when pulled high | Green button lights | |||
D5 |
W | SCK to shift register | Blue button lights | SPI MOSI to ADC | ||
D6 |
W | Shift register reset | Red button lights | |||
D7 |
W | Network connector TX2? (via RS-232 PHY) | MOSI to shift register | Start button light | ||
I0 |
R | SPI MISO from ADC | ||||
I1 |
R | SAR status from ADC | ||||
I2 |
R | |||||
I3 |
R | |||||
I4 |
R | Network detect (unclear how this works) | ||||
I5 |
R | |||||
I6 |
R | 1-wire bus from/to DS2401 readout | ||||
I7 |
R | Network connector RX2? (via RS-232 PHY) | ||||
SDA |
RW | I2C SDA from/to security chip (see note) |
SDA
is a bidirectional pin that can be set by the 573 as an input (presumably
with a pullup resistor, as mandated by the I2C specification) or it can be set
to output the same logic level as D0
.
Bus signalling
In addition to the signals above the cartridge slots carries two status lines
unofficially known as ISIG
and DSIG
and two inputs named /IREQ
and
/DACK
, probably meant for synchronization with cartridges that would actually
use the I/O ports as a parallel data bus rather than for bitbanging. No known
cartridge ever used these pins.
DSIG
is set whenever the 573 writes to the output port, even if no bits have
actually changed. The cartridge can monitor this signal to know when to read a
byte from the port and then pull /DACK
low to reset it. To send a byte to the
573 the cartridge can pulse /IREQ
, which will cause ISIG
to go high until
the 573 accesses the input port. The 573 can read the status of ISIG
(as well
as DSIG
) through the Konami ASIC and wait for it to be set before reading the
next byte.
Basically the cartridge I/O ports can be thought of as a single-byte FIFO, with
DSIG
being the "TX buffer full" flag and ISIG
the "RX buffer not empty"
flag.
Note about RTS/CTS
The CPU's SIO1 has hardware flow control and will not transmit anything if CTS isn't asserted. To get around this all known cartridges wire CTS to RTS, allowing it to be controlled in software. Cartridges that use the serial port (i.e. the ones with the network port) simply have the pins shorted together, while all other types break them out to a 2-pin jumper that is either unpopulated or shorted out with a piece of wire.
It turns out that many games that don't use SIO1 for networking redirect their
debug log output to it (by calling the AddSIO()
function provided by the Sony
SDK) if they detect that CTS and RTS are shorted on startup. Additionally on
later 573 revisions the SIO1 pins are broken out to a separate pin header
(CN24
) and made accessible without needing any kind of adapter or probe
between the cartridge and the 573. Thus, was the normally unpopulated jumper
actually meant as a "debug switch" of sorts?
NOTE: I2C SDA from/to the security chip and the DS2401 1-wire bus are
open-collector bidirectional lines, which means they can be controlled by
both the 573 and the cassette. This is accomplished by having them pulled high
by a resistor, and using a transistor on each side to force them low. On the
573's side, the bits that control the transistors (D0
and D4
) are outputs
separate from the inputs used to read the lines (SDA_I
and 1WIRE
), with
D4
being inverted (i.e. set D4
high to pull the 1-wire bus low).
Details on how to bitbang SPI, I2C and 1-wire are out of the scope of this document, but plenty of documentation can be found online.
ZS01 protocol
Konami's "ZS01" security chip, used in ZI cartridges, is a pre-programmed PIC16 microcontroller that mostly replicates the X76F100's functionality, allowing the 573 to store up to 112 bytes of data protected by a 64-bit key. Unlike the X76F100, however, the ZS01 communicates with the 573 using encrypted packets and self-erases if too many attempts are made to tamper with the encryption.
A ZS01 transaction can be broken down into the following steps:
- The 573 prepares a 12-byte buffer to be sent to the ZS01. The first 2 bytes represent the command (read or write) and the address to read from or write to, respectively. Data is always read or written in 8 byte blocks, with some blocks being reserved for "special" purposes such as changing keys or reading out the DS2401.
- If the command is a write command the next 8 bytes are populated with the payload, in some cases encrypted with the ZS01's "data key" (different for each game). For read commands the 573 populates them with a random 64-bit nonce derived from RTC time, which will then be used by the ZS01 as a key to encrypt the response. This was probably meant as a way to prevent the replay attacks the X76F041 and X76F100 were vulnerable to.
- A (non-standard) CRC16 of the 10 bytes generated so far is calculated and stored in the last 2 bytes of the buffer. All 12 bytes are then encrypted using a 64-bit "command key", which seems to be identical across all ZS01 games.
- The encrypted packet is sent to the ZS01. If the CRC16 is correct after decryption the ZS01 will reply with an I2C ACK, otherwise it will ignore the packet and decrement its remaining attempts counter.
- The 573 proceeds to read 12 bytes from the ZS01 and decrypt them using the nonce it generated earlier. For write commands, the nonce provided in the last read command issued is reused by the ZS01.
- The CRC16 of the response's first 10 bytes is calculated and compared against the one received in the last 2 bytes; if it matches, the response is considered valid. The first byte will be zero if the command was executed successfully by the ZS01. The second byte seems to be a "seed" of sorts used in the encryption algorithm. The remaining 8 bytes contain the requested payload for read commands.
External modules
Over the 573's lifetime Konami introduced several add-ons that extended its functionality. Unlike the I/O boards, these were external to the 573 unit and usually optional, although some later games started to require them in order to boot. Not much is currently known about any of these.
- PS1 controller/memory card adapter: sits between the 573 and any panel mounted memory card (and sometimes controller) ports. It has an internal Toshiba TMPR3904 CPU that handles communication with the cards and connects to the 573 via the JVS bus.
- e-Amusement network unit (used by later GFDM games): connects to the 573 through PCMCIA, using a cable that ends in a dummy card. Once again it has its own processor - a Toshiba TMPR3927 running at 133 MHz with 8 MB of RAM, far more powerful than the 573 itself - as well as an internal 2.5-inch IDE drive and a PCI Ethernet chip. It seems to run a proprietary kernel provided by Toshiba known as UDEOS.
- Multi-session unit (used by some Bemani games): it has yet another TMPR3927, an FPGA and 4 (!) MPEG decoder chips. It comes with 3 or 4 daughterboards installed, each of which hosts a stereo I2S DAC and has RCA jacks for audio input and output. The box also has its own CD drive and power supply. Its purpose is to enable "session mode", which allows for the same song to be played on multiple games at the same time, with the box playing the backing track and routing audio between the cabinets. It connects to each cabinet's 573 using RS-232, through the "network" port on the security cartridge.
- Master calendar: this was a JVS device used by Konami to program security cartridges at the factory. All games that use a security cartridge search the JVS bus on startup and enter a "factory test" mode if a device identifying as a master calendar is connected. The game will then proceed to initialize the cartridge after an authentication handshake with the master calendar. Even though nothing is known about the actual hardware Konami used, this device has been successfully replicated using an Arduino (see the links section).
Connectors
This is (a good approximation of) what the front panel of a 573 looks like:
_________________________________________________ [3]
| .-----------------------. o------------o \
| | CD drive [1] | | Sub-panel | |
| |_______________________| | [2] | |
| o------------o |
| [_________JAMMA_________] * DIP JVS VGA RCA ... |
+------------[4]--------------[5]-[6]---[7]---[8]-+
- ATAPI CD drive: a standard 5.25-inch unit held in place by a bracket mounted to the upper half of the case. Gray case variants usually came with a removable plate covering the drive cutout, while black/blue models have a front panel that blocks access to the eject button for whatever reason.
- Sub-panels: the gray variant of the case has a cutout for a plate to hold additional I/O connectors here. Different games have different plates, see the game-specific information section for details on which connectors are broken out for each game. There is another sub-panel cutout on the back of the 573 as well, used by some I/O boards to expose additional ports.
- Security cartridge: cartridges are inserted into a slot on the 573's right side and locked in place by plastic tabs. Hotplugging cartridges while the system is powered on will result in permanent damage to the cartridge, the 573 or both due to ESD (this has been proven to happen).
- JAMMA: this is a standard PCB edge connector used in arcade systems, carrying 5V and 12V power rails, analog RGB video, a mono speaker output (wired to the left channel of the built-in amp, see below) and button and coin inputs. The 573 doesn't use the negative 5V rail.
- DIP switches: a set of four DIP switches for quick game configuration. The first three are used by some games (and can be freely used by homebrew) while the last one is reserved by the BIOS and used to select whether to boot from the CD or from the internal flash.
- JVS "USB" port: as already mentioned this is not an actual USB port but rather a serial bus which can be used to connect peripherals and external I/O boards. As the underlying protocol is RS-485, multiple devices can be daisy chained.
- "VGA" and RCA outputs: these are also mandated by the JVS specification and are useful for hooking the system up for testing without needing a JAMMA "supergun" or similar adapter. Note that the VGA connector does not output standard VGA with separate h-sync and v-sync but 15 kHz (240p/480i) RGB with c-sync only. The signal levels are also higher than allowed by the VGA specification, since they are still meant to drive a JAMMA CRT monitor. An upscaler such as the GBS8200 (which has a VGA input that supports 15 kHz and c-sync) might be required to connect the 573 to an LCD monitor, although some monitors with VGA input are known to accept 15 kHz and may work with a direct connection.
- Speaker outputs: the 573 has a built-in 15W amplifier, which can be used for either mono output (via the speaker pins on the JAMMA connector) or for stereo through this 4-pin connector. Bemani cabs do not use this output, relying on a more powerful external amp plugged into the RCA jacks instead.
BIOS
The 573's BIOS is based on a slightly modified version of Sony's standard PS1 kernel, plus a custom shell executable that replaces the Sony one. The kernel identifies itself as "Konami OS by T.H." and seems to have been used across all Konami PS1-based arcade boards. The main difference from the PS1 kernel is that most CD drive APIs and the ISO9660 filesystem driver have been removed. Other than that there are no significant changes (e.g. controller and memory card drivers are still present and functional, even though the controller port was never used).
Revisions
There seem to be at least three different versions of the BIOS:
Chip marking | MAME ROM | SHA-1 | Used by |
---|---|---|---|
700A01 |
700a01.22g |
e1284add4aaddd5337bd7f4e27614460d52b5b48 |
Most games |
700A01 |
700a01,gchgchmp.22g |
9aab8c637dd2be84d79007e52f108abe92bf29dd |
Gachagachamp |
700A01 |
Unknown (undumped, see below) | ||
700B01 |
700b01.22g |
a2421d0a494892c0e71003c96995ce8f945064dd |
Dancing Stage EuroMIX 2 |
700A01 is the most common version. The only differences between the two known
variants of it are minor code improvements in the shell, with the kernel being
identical. There reportedly is a third variant that shipped on systems that
came with the H8/3644 microcontroller unpopulated (presumably it would not
check for it on startup), however no evidence of its existence has ever been
found. Old versions of MAME also used to reference a ROM named 700_a01.22g
,
but it seems to be the same as 700a01,gchgchmp.22g
.
700B01 shares the same kernel, but its shell is an entirely different beast. It is split up into two separate executables, one in charge of running self-tests and the other actually handling the boot sequence. The exact practical differences other than the UI/font and some bugfixes in the tests are currently unknown, but the 700B01 shell seems to be more advanced than the 700A01 one from a cursory glance at the code.
Boot sequence
Both the 700A01 and 700B01 shells are far simpler than their PS1 counterparts.
Once launched by the kernel, they start by configuring the bus (by writing
0x24173f47
to the EXP1 configuration register) and proceed to run a hardware
self-test. The outcome of all tests is displayed on screen, with the following
chips being listed:
22G
: BIOS ROM (the shell and kernel are verified against a hardcoded checksum)16H
,16G
,14H
,14G
: main RAM (first row of chips)12H
,12G
,9H
,9G
: main RAM (second row of chips)4L
,4P
: VRAM (framebuffers are temporarily overwritten with pseudorandom noise, the self-test screen is redrawn afterwards)10Q
: SPU RAM18E
: H8/3644 microcontrollerCDR
: ATAPI CD drive
NOTE: the 700A01 shell does not actually test 4P
! It only tests the first
megabyte of VRAM and always reports 4P
as working due to a bug, which was
fixed in 700B01. A side effect of this is that the 700A01 BIOS will run and
pass all RAM and ROM checks in a regular PS1 emulator (as long as the emulator
is set up for 4 or 8 MB main RAM). The ROM checksum test fails on emulators
that patch the kernel on-the-fly to enable TTY output, such as DuckStation.
If any of these checks fails the shell locks up, shows a blinking "HARDWARE ERROR... RESET" prompt and stops resetting the watchdog after a few seconds, causing the 573 to reboot. Otherwise the shell attempts to load an executable from four different sources, in the following order:
- PCMCIA flash card in slot 2 (if inserted and DIP switch 4 is on)
- PCMCIA flash card in slot 1 (if inserted and DIP switch 4 is on)
- Internal flash (if DIP switch 4 is on)
PSX.EXE
in the root directory of the CD
Like Sony's shell, the 573 shell's ISO9660 filesystem driver does not support any extension, nor does it support non-8.3 file names. It also only allocates 2 KB for the path table, so the number of directories on the disc must be kept to a minimum to prevent the shell from crashing.
Unlike a regular PS1, the 573 ignores SYSTEM.CNF
completely even if present
on the disc. Homebrew discs can take advantage of this behavior to provide
separate PS1 and 573 executables on the same disc. All official discs use Mode
1 sectors, unlike PS1 discs, but the 573 can also read Mode 2 Form 1 sectors
without issues since the BIOS only requests the 2048-byte data area from the
ATAPI drive.
If DIP switch 4 is on, the shell expects to find an executable at offset 0x24
on either the built-in flash or one of the two flash cards, preceded by a CRC32
of it at offset 0x20
. The CRC32 is not calculated on the whole executable,
instead it is only calculated on bytes from the executable whose offsets are a
power of 2 (i.e. on bytes 0, 1, 2, 4, 8 and so on). The CRC variant used is the
Ethernet/"zlib" one, with polynomial 0x04c11db7
. The check is implemented in
the shell as follows:
#define EXE_CRC32 ((const uint32_t *) 0x1f000020)
#define EXE_DATA ((const uint8_t *) 0x1f000024)
const uint32_t crc32_table[256] = { /* ... */ };
uint32_t crc = 0xffffffff;
for (size_t i = 0; i < exe_size; i <<= 1)
crc = (crc >> 8) ^ crc32_table[(crc & 0xff) ^ EXE_DATA[i]];
if ((~crc) == *EXE_CRC32)
load_exe((void *) EXE_DATA);
DIP switch 4 can be turned off to force the shell to ignore any executables on the flash. This is used when upgrading cabinets to a new game to run the installer from the new CD, rather than the currently installed game from flash.
Accidental DVD support
Even though neither the 573 nor its BIOS were designed with support for DVDs in
mind, it is possible to boot from a DVD (assuming the installed drive is a DVD
drive in the first place) thanks to the fact that the ATAPI command used by the
BIOS to read data sectors also works on DVDs. In order for this to work, the
DVD must be formatted as ISO9660 (not UDF) with no extensions, as if it were a
CD, and must of course contain a PSX.EXE
file in the root directory.
This accidental capability was greatly abused by bootleg "superdiscs" (nothing to do with the SNES CD attachment!) that bundled multiple games on a single DVD and allowed the user to pick a game to install. Each game on these discs was patched to load its files from a subdirectory rather than the root of the disc, basically "namespacing" the assets. Obviously games that make use of CD audio can't be put on a DVD, so superdiscs were limited to games that used the digital I/O board for MP3 playback.
Homebrew games willing to sacrifice PS1 compatibility and CD-DA support can be distributed on a DVD. In that case the game's disc image shall be an .iso file with 2048-byte sectors, rather than the typical .bin and .cue pair for PS1 or PS1/573 hybrid games with Mode 2 sectors.
BIOS "modchips"
It is not uncommon to find "modchipped" 573 units out in the wild. These "modchips" (sometimes more properly called "mod boards") were bundled back in the day alongside bootleg game discs and are nothing more than a simple PCB that plugs in place of the BIOS ROM (which happens to be the only chip that comes socketed from the factory) on the motherboard. They were apparently required to "skip the anti-piracy checks in the BIOS" and allow the 573 to read burned discs.
Of course, since the 573 BIOS does no copy protection checks whatsoever, these claims were misleading. The actual purpose of these boards was not to tamper with the BIOS, but rather to piggyback on the system bus and provide a few rudimentary challenge-response authentication registers as a way for bootleg executables to verify that they were running on a modded 573. In other words the "modchips" were actually the bootleggers' implementation of a security cartridge, meant to stop people from simply burning copies of bootleg discs and force them to buy the discs with their respective "modchips" from whoever produced them instead. Oh the irony.
Although the added circuitry will not create any issues with official or
homebrew games, most of these boards also ship with a modified version of the
700A01 BIOS altered to load a differently named executable from the disc rather
than PSX.EXE
. The following names have been found so far (more might exist):
QSY.DXD
SSW.BXF
TSV.AXG
Homebrew games should thus place multiple copies of the boot executable on the disc to improve compatibility with "modchipped" systems. An interesting side note is that, for any of these names, summing the ASCII codes of each character will always yield the same result. Presumably bootleggers were unable to find the code in charge of BIOS ROM checksum validation and and found it easier to just turn the string into random nonsense whose checksum collided with the original one...
Game-specific information
Sub-panels
Black/blue case models, most commonly used in Fisherman's Bait and in a few non-Bemani games that do not require I/O boards, have no sub-panel cutouts and instead expose some of the built-in ports through a handful of connectors:
- Power: a hefty 2x4 Molex connector for powering the board, wired to the motherboard's power connector.
- Option 1: DE9 connector providing 4 analog inputs, wired to the
ANALOG
connector on the motherboard. These inputs seem to go directly into the 573's ADC chip with no protection whatsoever. - Option 2: DE9 connector providing 6 button (digital) inputs, wired to the
EXT-IN
connector on the motherboard. 4 of these inputs are also broken out to the JAMMA connector (see the pinouts section for details). - Reel connector (back side): 3x3 Molex connector wired to the fishing controls I/O board. The cutout seems to actually be only present on systems that came with Fisherman's Bait.
Gray case models that came with Dance Dance Revolution, regardless of whether they contain an analog or digital I/O board, have 4 connectors mounted to the front sub-panel which break out the board's light outputs:
- 1P (10-pin white, only 7 pins used): connects to the left stage and controls arrow lights. Two of the signals are additionally misused as a bitbanged SPI-like bus for communication with the pad.
- 2P (10-pin orange, only 7 pins used): same as above for the right stage.
- Unlabeled (10-pin red, only 7 pins used): connects to cabinet button and marquee lights.
- Unlabeled (6-pin white, only 2 pins used): goes to the inverter that drives the neon rings around the speakers.
There are several other sub-panel variants which are currently undocumented.
DDR light mapping
Dance Dance Revolution cabinets (standard 2-player ones, not Solo) have lights wired up to the analog or digital I/O board as follows:
Output | Connected to |
---|---|
0 | Player 1 up arrow |
1 | Player 1 left arrow |
2 | Player 1 right arrow |
3 | Player 1 down arrow |
4 | Data to player 1 stage I/O |
5-6 | Unused |
7 | Clock to player 1 stage I/O |
8 | Player 2 up arrow |
9 | Player 2 left arrow |
10 | Player 2 right arrow |
11 | Player 2 down arrow |
12 | Data to player 2 stage I/O |
13-14 | Unused |
15 | Clock to player 2 stage I/O |
16 | Unused |
17 | Player 1 buttons |
18 | Player 2 buttons |
19 | Unused |
20 | Bottom right marquee light |
21 | Bottom left marquee light |
22 | Top left marquee light |
23 | Top right marquee light |
24-27 | Unused |
28 | Speaker neon (digital I/O) |
29 | Unused |
30 | Speaker neon (analog I/O) |
31 | Unused |
Light outputs 4, 7, 12 and 15 do not actually control any lamps, but are used to communicate with each stage's I/O board. See below for details.
DDR stage I/O board
In Dance Dance Revolution cabinets, the sensors in each stage's arrow panels are not connected directly to the 573 but go through a board commonly known as the "stage I/O". This board, based on a Xilinx XC9536 CPLD, has two purposes: allowing the 573 to check the status of a specific pressure sensor (each panel has 4 sensors, one along each edge) and ensuring DDR games can only be played with an actual stage, rather than just a joystick or buttons wired up to the 573's JAMMA connector. Konami kept using the same board long after the 573 was discontinued, with the last game to use it being DDR X/X2.
Each stage's board communicates with the 573 over 6 wires, of which 4 are the up/down/left/right signals going to the JAMMA connector and 2 are light outputs from the I/O board being misused as data and clock lines (see above). The board initially asserts the right and up signals and waits for the 573 to issue an initialization command by bitbanging it over the light outputs. Received bits are acknowledged by the board by echoing them on the right signal and toggling the up signal.
Once initialization is done the board goes into passthrough mode, asserting the up/down/left/right signals whenever any of the respective arrow panels' sensors are pressed. The 573 can issue another command to retrieve the status of each sensor separately, which is then sent by the board in serialized form over the right and up signals. DDR games only use this command to display sensor status in the operator menu, no commands are sent to the board during actual gameplay.
The initialization protocol is currently unknown. The protocol used after initialization is partially known (see links) but needs to be verified and documented properly.
DrumMania light mapping
First-generation DrumMania cabinets (unofficially called "1st Mix") have lights wired up to the I/O board as follows:
Output | Connected to |
---|---|
0-15 | Unused |
16 | Hi-hat |
17 | High tom |
18 | Low tom |
19 | Snare |
20 | Cymbal |
21 | Start button |
22 | Select button |
23-26 | Unused |
27 | Bottom neon |
28-29 | Unused |
30 | Spotlight |
31 | Top neon |
The wiring was changed in 2nd Mix and later cabinets, which use the following mapping instead:
Output | Connected to |
---|---|
0 | Hi-hat |
1 | High tom |
2 | Low tom |
3 | Snare |
4-7 | Unused |
8 | Spotlight |
9 | Top neon |
10 | Unused |
11 | Bottom neon |
12 | Cymbal |
13 | Start button |
14 | Select button |
15-31 | Unused |
Misc. notes
Homebrew guidelines
It is relatively easy to develop homebrew games that can run on both a System 573 and a regular PlayStation 1, or to port existing PS1 homebrew to the 573. Nevertheless, there are some significant differences between the two systems and a game meant to run on both shall avoid using any feature that is only available on one. "Hybrid" PS1/573 games shall adhere to the following guidelines:
- Do not use the extra RAM. With the exception of development kits and modified units, consoles always have 2 MB of main RAM and 1 MB of VRAM. The additional RAM on the 573 might still be useful for 573-specific purposes such as FAT filesystem handling if an IDE hard drive is used.
- Do not use XA-ADPCM. XA is not supported by any ATAPI drive. CD-DA is supported by both the PS1 CD drive and ATAPI drives, however it will not work out-of-the-box on a 573 fitted with a digital I/O board as the 4-pin CD audio cable will not be plugged into the drive. Homebrew games that use CD-DA should display a splash screen showing how to unplug the cable from the I/O board and plug it into the drive (which is a quick reversible modification). SPU audio streaming can replace XA and will work on both platforms.
- Have separate executables for PS1 and 573. Since the PS1 BIOS parses
SYSTEM.CNF
while the 573 BIOS ignores it, a disc can have two different executables, one namedPSX.EXE
(which will be launched on a 573) and the other (which will run on a PS1) referenced bySYSTEM.CNF
. This makes it easier to have two separate builds of the game rather than having to detect system type at runtime. - Do not rely on the RTC. Most 573 boards have a dead RTC battery by now. As the battery is sealed inside the RTC it is basically impossible to replace without replacing the entire chip, which is something not all 573 owners can do. RTC RAM is additionally used by some games to store security-related data and shall not be used for saving.
- Implement an operator/settings menu. Among other things, the menu should allow the user to adjust the SPU's master volume, enable or disable the 573's built-in amplifier (which has no physical volume controls), test cabinet lights and eject the CD (as some cases hide the drive's eject button behind a small hole or make it difficult to access otherwise).
Known working replacement drives
This is an incomplete list of drives that are known to work (or to be incompatible) with Konami's ATAPI driver, used by both the BIOS and games. Note that CD-DA support is problematic due to the way Konami's code reads the disc's table of contents. Thus, very few drives are confirmed to work with games that use CD-DA (i.e. pretty much all games that don't use the digital I/O board).
Manufacturer | Model | BIOS | CD-DA | Notes |
---|---|---|---|---|
ASUSTeK | DVD-E616P3 | Yes | Unknown | |
Compaq | 179137-701 | Yes | Yes | |
Creative | CD4832E | Yes | No | |
Hitachi | CDR-7930 | Yes | No | |
LG | GCR-8523B | Yes | Unknown | |
LG | GDR-8163B | Yes | Yes | |
LG | GDR-8164B | Yes | Yes | |
LG | GH22NP20 | Yes | Unknown | |
Lite-On | LH-18A1H | Yes | Yes | |
Lite-On | LTD-163 | Yes | Unknown | |
Lite-On | LTD-165H | Yes | Unknown | |
Lite-On | LTR-40125S | Yes | Unknown | |
Lite-On | XJ-HD166S | Yes | Unknown | |
Matsushita | CR-583 | Yes | Yes | Stock drive |
Matsushita | CR-587 | Yes | Yes | Stock drive, can't read CD-R |
Matsushita | CR-589B | Yes | Yes | Stock drive |
Matsushita | SR8589B | Yes | Unknown | |
Mitsumi | CRMC-FX4830T | Yes | Unknown | |
NEC | CDR-1900A | Yes | Unknown | |
NEC | ND-2510A | No | ||
Panasonic | CR-594C | Yes | Unknown | |
Sony | DRU-510A | Yes | Unknown | |
Sony | DRU-810A | Yes | Unknown | |
TDK | AI-481648B | Yes | Unknown | |
TEAC | CD-W552E | Yes | Unknown | |
Toshiba | XM-5702B | Yes | Unknown | |
Toshiba | XM-6102B | Yes | No | Has issues with homebrew |
Pinouts
Analog input port (ANALOG
, CN3
)
The inputs are wired directly to the 573's built-in ADC, so they can only accept voltages in 0-5V range. This connector is mostly useful for wiring up potentiometers and similar resistive analog controls.
Pin | Name | Dir |
---|---|---|
1 | 5V |
|
2 | 5V |
|
3 | 5V |
|
4 | 5V |
|
5 | CH0 |
R |
6 | GND |
|
7 | CH1 |
R |
8 | CH2 |
R |
9 | CH3 |
R |
10 | GND |
Digital output port (EXT-OUT
, CN4
)
Pin | Name | Dir |
---|---|---|
1 | 5V |
|
2 | 5V |
|
3 | OUT7 |
W |
4 | OUT6 |
W |
5 | OUT5 |
W |
6 | OUT4 |
W |
7 | OUT3 |
W |
8 | OUT2 |
W |
9 | OUT1 |
W |
10 | OUT0 |
W |
11 | GND |
|
12 | GND |
Digital input port (EXT-IN
, CN5
)
Unlike EXT-OUT
, this port is not a separate input port. It piggybacks on the
JAMMA button inputs instead, exposing the button 4 and 5 pins for both players
as well as a sixth button input which is not available on the JAMMA connector.
Pin | Name | Dir | JAMMA |
---|---|---|---|
1 | 5V |
||
2 | 5V |
||
3 | P1_B4 |
R | 25 |
4 | P1_B5 |
R | 26 |
5 | P1_B6 |
R | - |
6 | GND |
||
7 | P2_B4 |
R | c |
8 | P2_B5 |
R | d |
9 | P2_B6 |
R | - |
10 | GND |
Main I/O board connector (CN10
)
The pinout of this connector is currently unknown.
Secondary I/O board connector (CN21
)
This connector exposes the SPI bus pins normally used for controllers and memory cards, which go unused on the 573 as no known I/O board ever used this connector.
Pin | Name | Dir | Pin | Name | Dir |
---|---|---|---|---|---|
A1 | A8 |
W | B1 | A9 |
W |
A2 | A10 |
W | B2 | A11 |
W |
A3 | A16 |
W | B3 | A17 |
W |
A4 | A18 |
W | B4 | A19 |
W |
A5 | GND |
B5 | ? |
||
A6 | GND |
B6 | ? |
||
A7 | GND |
B7 | GND |
||
A8 | GND |
B8 | DOTCK |
W | |
A9 | GND |
B9 | GND |
||
A10 | GND |
B10 | /ACK |
R | |
A11 | GND |
B11 | /JOY2 |
W | |
A12 | GND |
B12 | /JOY1 |
W | |
A13 | GND |
B13 | MISO |
R | |
A14 | GND |
B14 | MOSI |
W | |
A15 | GND |
B15 | SCK |
W |
Security cartridge slot (CN14
)
Pin | Name | Dir | Notes | Pin | Name | Dir | Notes |
---|---|---|---|---|---|---|---|
1 | GND |
23 | GND |
||||
2 | GND |
24 | GND |
||||
3 | /DSR |
R | Usually shorted to ground | 25 | EXCLK |
W | 7.3728 MHz clock (also goes into H8) |
4 | NC |
May have been DTR at some point | 26 | GND |
|||
5 | TX |
W | 27 | DSIG |
W | Goes high when 573 updates D0-D7 |
|
6 | RX |
R | 28 | SDA |
RW | Only bidirectional pin | |
7 | /RESET |
System reset (from watchdog) | 29 | /IREQ |
R | Sets ISIG when pulsed low |
|
8 | GND |
30 | /DACK |
R | Clears DSIG when pulsed low |
||
9 | GND |
31 | ISIG |
R | Goes low when 573 reads I0-I7 |
||
10 | - | Key (missing pin) | 32 | - | Key (missing pin) | ||
11 | ? |
Not connected? | 33 | I7 |
R | ||
12 | ? |
Not connected? | 34 | I6 |
R | ||
13 | D7 |
W | 35 | I5 |
R | ||
14 | D6 |
W | 36 | I4 |
R | ||
15 | D5 |
W | 37 | I3 |
R | ||
16 | D4 |
W | 38 | I2 |
R | ||
17 | D3 |
W | 39 | I1 |
R | ||
18 | D2 |
W | 40 | I0 |
R | ||
19 | D1 |
W | 41 | 5V |
|||
20 | D0 |
W | 42 | 5V |
|||
21 | 5V |
43 | /RTS |
W | Shorted to /CTS on some cartridges |
||
22 | 5V |
44 | /CTS |
R | Shorted to /RTS on some cartridges |
Serial port (CN24
, unpopulated)
Only present on later revisions of the main board. It exposes the exact same serial port signals as the security cartridge slot.
Pin | Name | Dir | Cart |
---|---|---|---|
1 | TX |
W | 5 |
2 | RX |
R | 6 |
3 | GND |
||
4 | GND |
||
5 | /RTS |
W | 43 |
6 | /CTS |
R | 44 |
I2S digital audio output (CN19
, unpopulated)
The pinout of this connector is currently unknown.
H8/3644 microcontroller pin mapping
Pin | H8 GPIO | Dir | Connected to | Usage |
---|---|---|---|---|
11 | P9_0 |
R | Unused | |
12 | P9_1-4 |
W | I/O ASIC | Status output bus |
16 | IRQ0 |
R | Unused | |
17-24 | P6_0-7 |
W | I/O ASIC | 16-bit JVS output bus (low byte?) |
25-32 | P5_0-7 |
W | I/O ASIC | 16-bit JVS output bus (high byte?) |
34 | P7_3 |
R | Unknown | |
35 | P7_4 |
R | Unknown | |
36 | P7_5 |
R | Unused | |
37 | P7_6 |
R | Unused | |
38 | P7_7 |
R | Unused | |
39-46 | P8_0-7 |
R | System bus (via latch) | 16-bit JVS write bus (low byte) |
47 | P2_0 |
W | Unknown | |
48 | P2_1/RX |
R | RS485 transceiver | JVS serial port receive |
49 | P2_2/TX |
W | RS485 transceiver | JVS serial port transmit |
50 | P3_2 |
R | Unused | |
51 | P3_1 |
R | Unused | |
52 | P3_0 |
R | Unused | |
53 | P1_0 |
W | Unknown | |
54 | P1_4 |
W | Unknown | |
55 | P1_5 |
R | Unused | |
56 | P1_6 |
R | Unused | |
57 | P1_7 |
R | Unused | |
59-2 | PB_7-0 |
R | System bus (via latch) | 16-bit JVS write bus (high byte) |
Credits, sources and links
This document is the result of a joint effort consisting of months if not years of original research, brought to you by:
- spicyjpeg (documentation writing, hardware test coding)
- Naoki Saito (hardware reverse engineering, schematic tracing, tests)
- smf (initial reverse engineering and implementation of the 573 MAME driver)
- Grandstand (tests with security cartridges and ATAPI drives)
- Shiz (security cartridge details)
Traced schematics, datasheets and additional resources are available in Naoki's 573 repo. Shiz also maintains a documentation repo for several arcade systems including the 573.
In addition to original research, some information has been aggregated from the following sources:
- System 573 MAME driver
- windyfairy/987123879113's MAME fork and gobbletools
- ATAPI specification (revision 2.6, January 1996)
- M48T58, ADC0834, X76F041 and X76F100 datasheets
- DDR stage I/O protocol notes
- List of working ATAPI drives
- "The Almost Definitive Guide to Session Mode Linking"
- Japanese page about drummania (has network adapter and multisession unit pictures)
- Light output for Salary Man Champ and Hyper Bishi Bashi Champ
- system573_tool (possibly the first ever homebrew app for the 573)
- Arduino-based master calendar clone
- Z-I-v forum post with security cartridge info
Huge thanks to the Rhythm Game Cabs Discord server and everyone who provided valuable information about the 573!