konami573-security-io

name: konami573-security-io description: "Konami System 573: security cartridges (install, game, network), external modules (multisession/PCMCIA/HDD), BIOS, bootleg mod boards, game-specific technical notes, PCB pinouts. Use when working with System 573 security, BIOS, or game-specific details."

Security cartridges

Most System 573 games use cartridges that plug into the slot on the right side of the main board as an anti-piracy measure and/or to add game specific I/O functionality (particularly for games that do not otherwise require any I/O board). Cartridges typically contain a password protected EEPROM, used to store game and installation information, and in some cases a DS2401 unique serial number chip.

• Electrical interface
• Cartridge EEPROM types
• EEPROM-less cartridge variants
• X76F041 cartridge variants
• ZS01 cartridge variants
• Cartridge identifiers

Electrical interface

All communication with the cartridge is performed through the following means:

• an 8-bit parallel input port (I0-I7), readable via register 0x1f400004;
• a latched 8-bit parallel output port (D0-D7), controlled by register 0x1f6a0000;
• a single tristate I/O pin (IO0), which can be either configured as a floating input or set to output the same logic level as D0 through register 0x1f500000;
• the CPU's SIO1 interface (TX, RX, /RTS, /CTS, /DTR, /DSR);
• four bus handshaking lines (IRDY, DRDY, /IREQ, /DACK).

As all EEPROMs used in cartridges have an I2C interface rather than a parallel one, IO0 is used in combination with individual bits of the parallel I/O ports to bitbang I2C. The SIO1 interface either goes unused or is translated to RS-232 voltage levels and broken out to a connector on the cartridge.

See the pinouts section for more information on the security cartridge slot.

Handshaking lines

The cartridge slot carries two status lines unofficially known as IRDY and DRDY plus two inputs named /IREQ and /DACK, probably meant for synchronization with cartridges that would actually use D0-D7 and I0-I7 as a parallel data bus rather than to bitbang serial protocols. No currently known cartridge uses these pins.

DRDY 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 IRDY to go high until the 573 accesses the input port. The 573 can read the status of IRDY (as well as DRDY) through the Konami ASIC and wait for it to be set before reading the next byte.

The cartridge I/O ports can basically be thought of as a single-byte FIFO, with DRDY being the "TX buffer full" flag and IRDY the "RX buffer not empty" flag. The handshaking lines are implemented using a handful of 74LS74 flip flops.

NOTE: the JVS MCU also has its own handshaking lines, JVSIRDY and JVSDRDY, which are actually used and work in pretty much the same way. See the JVS interface section for more information on communicating with the MCU.

Note about RTS/CTS

The PS1 CPU's SIO1 UART has hardware flow control and will not transmit data until CTS is asserted. In order to get around this most cartridges tie CTS to RTS, allowing it to be controlled in software. Cartridges that use the serial port (i.e. ones with a network port) have the pins tied together on the PCB, while other cartridge types usually break them out to a shorted 2-pin jumper.

Some earlier games that do not use SIO1 for networking purposes redirect their debug logging output to it (by calling the AddSIO() function provided by the Sony SDK) if CTS and RTS are shorted on startup. On later 573 motherboard revisions, the SIO1 pins are additionally broken out to a separate connector (CN24) and made accessible even when a cartridge without a network port is inserted.

Cartridge EEPROM types

Konami's security cartridge driver supports the following EEPROMs:

NOTE: Konami seems to have never manufactured X76F100 cartridges, however most games that expect an X76F041 can also use the X76F100 interchangeably. ZS01 support was only added in later versions of the driver.

ZS01 protocol

The "ZS01" EEPROM (also known as "NS2K001") is actually a 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 password. Unlike the X76F041 and X76F100, which use plaintext commands, all communication with the ZS01 is obfuscated using a rudimentary scrambling algorithm. A CRC16 is attached to each packet and used to detect attempts to tamper with the obfuscation. Attempting to send too many requests with an invalid CRC16 will cause the ZS01 to self-erase and reset the password.

A ZS01 transaction can be broken down into the following steps:

1. The 573 prepares a 12-byte packet to be sent to the ZS01, containing a command, address and payload:

   Bytes	Description
   0	Command flags
   1	Address bits 0-7
   2-9	Payload (data for writes, response key for reads)
   10-11	CRC16 of bytes 0-9, big endian

   The first byte is a 3-bit bitfield encoding the command and access type:

   Bits	Description
   0	Command (0 = write/erase, 1 = read)
   1	Address bit 8 (unused, should be 0)
   2	Access type (0 = unprivileged, 1 = privileged)
   3-7	Unused? (should be 0)

   The access type bit specifies whether the command is privileged. Privileged commands require the ZS01's current password, while unprivileged commands do not.

   The address must be one of the following values:

   Address	Length	Privileged	Description
   0x00-0x03	32 bytes	No	Unprivileged data area
   0x04-0x0e	80 bytes	Yes	Privileged data area
   0xfc	8 bytes	No	Internal ZS01 serial number
   0xfd	8 bytes	No	External DS2401 serial number
   0xfd	8 bytes	Yes	Erases data area when written (write-only)
   0xfe	8 bytes	Yes	Configuration registers
   0xff	8 bytes	Yes	New password (write-only)

   Data is always read or written in aligned 8 byte blocks. Unprivileged areas can be read using either a privileged or unprivileged read command, but writing to them still requires a privileged write command.

2. If the command is a read command, a random 8-byte "response key" is generated (typically as an MD5 hash of the current time from the RTC) and written to the payload field; the ZS01 will later use it to encrypt the returned data as a replay attack prevention measure. For write commands, the payload field is populated with the 8 bytes to be written.

3. A CRC16 is calculated over the first 10 bytes of the packet and stored in the last 2 bytes in big endian format. The CRC is computed as follows:

   #define ZS01_CRC16_POLYNOMIAL 0x1021
   
   uint16_t zs01_crc16(const uint8_t *data, size_t length) {
       uint16_t crc = 0xffff;
   
       for (; length; length--) {
           crc ^= *(data++) << 8;
   
           for (int bit = 8; bit; bit--) {
               uint16_t temp = crc;
   
               crc <<= 1;
               if (temp & (1 << 15))
                   crc ^= ZS01_CRC16_POLYNOMIAL;
           }
       }
   
       return (~crc) & 0xffff;
   }
   

4. If the command is privileged, the 573 scrambles the payload field with the chip's currently set password, using the following algorithm:

   // Note that this state is preserved across calls to zs01_scramble_payload()
   // and must be updated when a response is received (see step 8).
   uint8_t zs01_scrambler_state = 0;
   
   void zs01_scramble_payload(
       uint8_t *output, const uint8_t *input, size_t length,
       const uint8_t *password
   ) {
       for (; length; length--) {
           int value = *(input++) ^ zs01_scrambler_state;
           value     = (value + password[0]) & 0xff;
   
           for (int i = 1; i < 8; i++) {
               int add   = password[i] & 0x1f;
               int shift = password[i] >> 5;
   
               int shifted = value << shift;
               shifted    |= value >> (8 - shift);
               shifted    &= 0xff;
   
               value = (shifted + add) & 0xff;
           }
   
           zs01_scrambler_state = value;
           *(output++)          = value;
       }
   }
   

   The CRC16 is not updated to reflect the new data. This step is skipped for unprivileged read commands.

5. All 12 bytes of the packet are scrambled with a fixed "command key", using the following algorithm:

   static const uint8_t ZS01_COMMAND_ADD[]   = { 237, 8, 16, 11, 6, 4, 8, 30 };
   static const uint8_t ZS01_COMMAND_SHIFT[] = {   0, 3,  2,  2, 6, 2, 2,  1 };
   
   void zs01_scramble_packet(
       uint8_t *output, const uint8_t *input, size_t length
   ) {
       // Unlike zs01_scramble_payload(), this state is *not* preserved across
       // calls.
       uint8_t state = 0xff;
   
       output += length;
       input  += length;
   
       for (; length; length--) {
           int value = *(--input) ^ state;
           value     = (value + ZS01_COMMAND_ADD[0]) & 0xff;
   
           for (int i = 1; i < 8; i++) {
               int shifted = value << ZS01_COMMAND_SHIFT[i];
               shifted    |= value >> (8 - ZS01_COMMAND_SHIFT[i]);
               shifted    &= 0xff;
   
               value = (shifted + ZS01_COMMAND_ADD[i]) & 0xff;
           }
   
           state       = value;
           *(--output) = value;
       }
   }
   

6. The scrambled packet is sent to the ZS01, which will respond to the first 11 bytes immediately with an I2C ACK and to the last byte with an ACK after a short delay. The 573 then proceeds to read 12 bytes from the ZS01, issuing an I2C ACK for each byte received up until the last one.

7. The 573 uses the response key generated in step 2 to unscramble the packet returned by the ZS01. The unscrambling algorithm is the same one used in step 5, applied in reverse:

   void zs01_unscramble_packet(
       uint8_t *output, const uint8_t *input, size_t length,
       const uint8_t *response_key
   ) {
       uint8_t state = 0xff;
   
       output += length;
       input  += length;
   
       for (; length; length--) {
           int value      = *(--input);
           int last_state = state;
           state          = value;
   
           for (int i = 1; i < 8; i++) {
               int add   = response_key[i] & 0x1f;
               int shift = response_key[i] >> 5;
   
               int subtracted = (value - add) & 0xff;
   
               value  = subtracted >> shift;
               value |= subtracted << (8 - shift);
               value &= 0xff;
           }
   
           value       = (value - response_key[0]) & 0xff;
           *(--output) = value ^ last_state;
       }
   }
   

   For write commands, the response key required to unscramble the packet is the one sent as part of the last read command issued. For read commands, the ZS01 may either use the key provided in the payload field or the one from the last read command issued; Konami's code tries unscrambling responses with both.

8. The unscrambled packet will contain the following fields:

   Bytes	Description
   0	Status code (0 = success, 1-5 = error)
   1	New payload scrambler state
   2-9	Payload (empty for writes, data for reads)
   10-11	CRC16 of bytes 0-9, big endian

   The 573 proceeds to compute the CRC16 of the first 10 bytes. If it does not match the one in the packet, it will try unscrambling the packet with a different response key (see step 7) before giving up. Otherwise, the global zs01_scrambler_state variable from step 4 is set to the value of byte 1, regardless of whether the status code is zero or not.

   The exact meaning of non-zero status codes is currently unknown.

EEPROM-less cartridge variants

Hyper Bishi Bashi Champ 3-player cartridge (GX700-PWB(E))

This is the only known cartridge type that has no EEPROM (although the PCB does have an unpopulated X76F041 footprint). It has no plastic case, as it's meant to be enclosed in the same case as the 573 itself. It has open-drain outputs for driving up to 12 lights, arranged as 3 banks of 4 outputs each (one bank for each player's buttons), plus an RS-232 transceiver for SIO1. The following pins are used:

This cartridge has three connectors:

• CN2 (5-pin): RS-232 port. Note that this port is not electrically isolated and shares its ground with the 573, unlike all other cartridges with an RS-232 connector.
• CN3 (16-pin): breaks out the light outputs and the incoming 12V supply from CN4.
• CN4 (4-pin): 12V power input, connected through a short cable to CN17 on the 573 main board.

X76F041 cartridge variants

All X76F041 cartridges use the following pins:

X76F041 cartridges equipped with a DS2401 additionally use the following pins:

Generic cartridge (GX700-PWB(D))

Rectangular cartridge used by the earliest 573 games and as a separate installation key for some later games. Contains only the X76F041 EEPROM and no DS2401, but the PCB has an unpopulated footprint for an unknown 64-pin TQFP part.

Generic cartridge with DS2401 (GX894-PWB(D))

Rectangular cartridge similar to GX700-PWB(D) but equipped with a DS2401. The PCB has two unpopulated SOIC footprints, one of which may possibly be for an X76F100 or another I2C EEPROM.

Early serial port cartridge (GX896-PWB(A)A)

Seems to be an older variant of the more common GX883-PWB(D) cartridge, with the same ports but no DS2401. As with the 3-player Bishi Bashi cartridge, it has no case and is instead meant to sit inside the 573's own case.

This cartridge has two connectors:

• CN2 (5-pin): electrically isolated RS-232 port. The transceiver is powered by an isolated DC-DC module and all signals going from/to the 573 are optoisolated.
• CN3 (6-pin): three 5V logic level signals, used in some cabinets to control lights or the speaker amplifier.

Serial port cartridge with DS2401 (GX883-PWB(D))

T-shaped cartridge with a DS2401, a "network" (RS-232) port and a "control" or "amp box" port, commonly used by pre-ZS01 Bemani games. Uses the following pins:

This cartridge has two connectors:

• Network (5-pin, unlabeled on PCB): electrically isolated RS-232 port. The transceiver is powered by an isolated DC-DC module and all signals going from/to the 573 are optoisolated.
• Control/amp box (6-pin, unlabeled on PCB): three 5V logic level signals, used in some cabinets to control lights or the speaker amplifier.

PunchMania cartridge (GX700-PWB(J))

T-shaped cartridge used only by PunchMania/Fighting Mania series. Contains an X76F041, a DS2401 and an ADC0838 used to measure up to 8 analog inputs. The ADC uses the following pins:

This cartridge has two connectors:

• Unknown (12-pin): analog input connector. As with the ADC built into the 573 motherboard there seems to be no protection on the inputs, so only voltages in 0-5V range are accepted.
• CN4 (10-pin): unknown purpose. Seems to be always unpopulated.

Hyper Bishi Bashi Champ 2-player cartridge (PWB0000068819)

T-shaped cartridge with open-drain outputs for driving up to 8 lights, arranged as 2 banks of 4 outputs each. Unlike the GX700-PWB(E) 3-player variant, it has an X76F041 (but no DS2401), lacks the RS-232 port and does not seem to be designed to be mounted inside the 573. The latches driving the light outputs use the following pins:

This cartridge has two connectors:

• CN2 (16-pin): breaks out the light outputs and the incoming 12V supply from CN3.
• CN3 (4-pin): 12V power input, presumably connected to the power supply externally (i.e. not through the main board).

Salary Man Champ cartridge (PWB0000088954)

T-shaped cartridge with open-drain outputs for driving up to 8 lights (although only 6 outputs seem to be populated). Contains an X76F041, a DS2401 and two 4094 shift registers, presumably chained. The shift registers use the following pins:

This cartridge has two connectors:

• Unlabeled (16-pin): breaks out the light outputs and the incoming 12V supply.
• Unlabeled (4-pin): 12V power input, presumably connected to the power supply externally (i.e. not through the main board).

ZS01 cartridge variants

All ZS01 cartridges use the following pins:

All cartridges are fitted with a DS2401, however it is connected to a GPIO pin on the ZS01 rather than being directly exposed to the 573. The ZS01 additionally provides its own unique serial number, which seems to be unused by games.

Serial port cartridge (GE949-PWB(D)A)

ZS01 variant of the GX883-PWB(D) cartridge. Uses the following pins:

This cartridge has two connectors:

• Network (5-pin, unlabeled on PCB): electrically isolated RS-232 port. The transceiver is powered by an isolated DC-DC module and all signals going from/to the 573 are optoisolated.
• Control/amp box (6-pin, unlabeled on PCB): three 5V logic level signals, used in some cabinets to control lights or the speaker amplifier.

Stripped down serial port cartridge (GE949-PWB(D)B)

T-shaped cartridge that uses the same PCB as GE949-PWB(D)A but only has the ZS01, DS2401 and supporting parts are populated. Used by games that do not need the RS-232 interface.

Cartridge identifiers

Most games use the security cartride's EEPROM to store, among other data such as the game code and region, a set of up to four 8-byte identifiers.

SID (silicon/serial ID?)

The serial number of the cartridge's DS2401, always present in cartridges that have one. As per the 1-wire specification it has the following format:

The CRC is computed as follows:

#define DS2401_CRC8_POLYNOMIAL 0x8c

uint8_t ds2401_crc8(const uint8_t *data, size_t length) {
    uint8_t crc = 0;

    for (; length; length--) {
        uint8_t value = *(data++);

        for (int bit = 8; bit; bit--) {
            uint8_t temp = crc ^ value;

            value >>= 1;
            crc   >>= 1;
            if (temp & 1)
                crc ^= DS2401_CRC8_POLYNOMIAL;
        }
    }

    return crc & 0xff;
}

Refer to the DS2401 datasheet and Maxim 1-wire documentation for more details.

TID (trace ID)

Seems to be a cartridge-type-agnostic serial number. On cartridges without a DS2401 the trace ID is assigned by Konami at manufacture time (see the master calendar section) and has the following format:

On cartridges with a DS2401 the trace ID is instead derived from the SID:

The hash is calculated over bytes 1-6 of the SID (excluding the family code and CRC8) using the following algorithm:

// Note that some games set this to 14 instead of 16.
#define TRACE_ID_HASH_BIT_WIDTH 16

uint16_t trace_id_hash(const uint8_t *data, size_t length) {
    uint16_t hash = 0;

    for (size_t i = 0; i < (length * 8); i += 8) {
        uint8_t value = *(data++);

        for (size_t j = i; j < (i + 8); j++, value >>= 1) {
            if (value & 1)
                hash ^= 1 << (j % TRACE_ID_HASH_BIT_WIDTH);
        }
    }

    return hash;
}

MID (medium ID?)

Seems to be some kind of cartridge type flag, possibly indicating whether the cartridge shall be used during or after game installation, or if it was used when performing a game upgrade and shall no longer be usable to run the game it initially shipped with.

NOTE: 00 00 00 00 00 00 00 00 seems to be a valid MID value, despite having an otherwise invalid checksum, and to have a different meaning from 00 00 00 00 00 00 00 ff.

XID (external ID?)

The serial number of the digital I/O board's DS2401, written to the cartridge during installation by most games that use it in order to prevent reinstallation on a different system. Has the same format as the SID. On a cartridge that has not yet been paired to a 573 the XID is set to 00 00 00 00 00 00 00 00.

When finishing installation or attempting to use a cartridge with a mismatching XID the game will display the digital I/O board's serial number as an 8-digit value (XXXX-YYYY), generated as follows:

// Some games seem to only use the lower 32 bits of the DS2401's serial number,
// while others use all 48 bits.
size_t xid_to_string_32(char *output, const uint8_t *xid) {
    uint32_t value = 0
        | (xid[1] <<  0)
        | (xid[2] <<  8)
        | (xid[3] << 16)
        | (xid[4] << 24);

    int high = (value / 10000) % 10000;
    int low  = value % 10000;

    return sprintf(output, "%04d-%04d", high, low);
}

size_t xid_to_string_48(char *output, const uint8_t *xid) {
    uint64_t value = 0
        | (xid[1] <<  0)
        | (xid[2] <<  8)
        | (xid[3] << 16)
        | (xid[4] << 24)
        | (xid[5] << 32)
        | (xid[6] << 40);

    int high = (int) ((value / 10000) % 10000);
    int low  = (int) (value % 10000);

    return sprintf(output, "%04d-%04d", high, low);
}

Cartridges for games that use the digital I/O board typically come with a blank label onto which the 8-digit ID can be written by the operator, to help keep track of which cartridge goes into which system after installation.

Note that games that use other I/O boards with a DS2401, such as Kick & Kick and DDR Karaoke Mix, do not seem to write those boards' serial numbers to the cartridge; they are stored in the internal flash memory instead.

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 not always mandatory. Not much is currently known about any of these.

Relay board (GN845-PWB(A))

A relatively simple lamp driver board, controlled by the optoisolated outputs from the analog or digital I/O board. Commonly mounted in a metal box alongside audio amplifier boards in most cabinets.

DDR stage I/O board (GN845-PWB(B))

Sits between the 573 and the sensors in each stage's arrow panels in Dance Dance Revolution cabinets. It is based on a Xilinx XC9536 CPLD and allows the 573 to check the status of a specific pressure sensor (each panel has 4 sensors, one along each edge), in addition to 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 (PC based).

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.

PS1 controller and memory card adapter (GE885-PWB(A))

A ridiculously overengineered JVS board providing support for accessing PS1 controllers and memory cards plugged into ports on the front of the cabinet. Contains a Toshiba TMPR3904 CPU, a Xilinx XCS10XL Spartan-XL FPGA, 512 KB of RAM and a 512 KB boot ROM; the ROM is only a small bootloader and the actual firmware is downloaded from the 573 into RAM. There are also two connectors for security dongles. Returns the following JVS identifier string:

KONAMI CO.,LTD.;White I/O;Ver1.0;White I/O PCB

Memory card support became common in later Bemani games, allowing players to save their scores and play custom charts. GuitarFreaks is the only game known to support external controllers through this board.

PunchMania 2 PCMCIA splitter (PWB0000085445)

Combines two 32 MB PCMCIA flash cards into the same address space, allowing them to be accessed as if they were a single 64 MB card. Connects to the 573 through a cable that plugs into a passive PCMCIA slot adapter. Only used by PunchMania 2.

e-Amusement network unit (PWB0000100991)

Used by some Bemani games, in particular later GuitarFreaks and DrumMania releases. Provides networking functionality (DHCP and TCP/UDP sockets) as well as a 10 or 20 GB IDE hard drive for storage of downloaded content. The module contains a Toshiba TMPR3927 CPU, a Xilinx XC2S100 Spartan-2 FPGA, 16 MB of RAM, a 512 KB boot ROM and a DP83815 PCI Ethernet MAC. As with the controller and memory card adapter, the bulk of the firmware seems to be loaded from the 573. Connects through PCMCIA slot 2, using the same cable and adapter as the PunchMania PCMCIA splitter.

Multisession unit (GXA25-PWB(A))

A fairly large box containing a Toshiba TMPR3927 CPU, a Xilinx XC2S200 Spartan-2 FPGA and four (!) hardware MP3 decoders. It comes with up to four daughterboards installed, each of which hosts a stereo DAC and has RCA jacks for audio input and output plus a mini-DIN connector for RS-232 communication with a cabinet. The box also has its own ATAPI CD-ROM drive and power supply.

Its purpose is to enable "session mode" in later Bemani games, which allows for the same song to be played on multiple games at the same time with the box playing the backing tracks and routing audio between the machines. It connects to each cabinet's 573 using RS-232, through the "network" port on the security cartridge.

Master calendar

A JVS device used internally by Konami to initialize motherboards and security cartridges during manufacturing. The exact hardware Konami used is unknown, but the protocol can be inferred from game code. All games search the JVS bus on startup and enter a "factory test" mode if any device with the following identifier string is present:

KONAMI CO.,LTD.;Master Calendar;<any value>;<any value>

The game will then proceed to request the current date, time, game and region information from the master calendar, initialize the RTC and program the security cartridge. The master calendar also returns a unique trace ID (see the cartridge data formats section) for each 573, used for identification purposes on cartridges that lack a DS2401.

0x70: Get date and time

0x71: Get game region or initialization data

0x7c, 0x7f, 0x00: Get trace ID "main" serial number

0x7c, 0x80, 0x00: Get trace ID "sub" serial number

0x7d, 0x80, 0x10: Get next ID

0x7e: Set DS2401 identifiers

0x7f: Unknown

0xf0: Reset master calendar

BIOS

The System 573 BIOS is based on a slightly modified version of Sony's standard PS1 kernel, plus a custom shell executable.

• Shell revisions
• Kernel differences
• Boot sequence
• Command-line arguments
• JVS MCU test sequence
• DVD-ROM support
• Scrapped CF card support

Shell revisions

There seem to be either three or four different versions of the BIOS, all of which share the same kernel but feature different shells:

700A01 is the earliest and most common version. The only difference between the two known variants of it is that they were linked to slightly different Sony SDK releases; Konami's own code is identical across the two. There reportedly is a third variant that shipped on systems that came with the JVS MCU unpopulated (presumably it would skip the check for it), however no evidence of its existence has ever been found. The shell is stored in ROM in both variants at 0xbfc40000, in the form of a standard PS1 executable (including the header) that gets loaded at 0x803c0000 by the kernel.

700B01 has a more complicated structure: it is split up into two separate executables, one (at 0xbfc28000, loaded at 0x80010000) in charge of running the self-test sequence and the other (at 0xbfc60000, loaded at 0x80380000) handling CD-ROM or flash booting. The overall coding style suggests that it was developed alongside the installers/launchers used by later Bemani games, but dropped as the main feature it would have introduced over the 700A01 shell - CF card support - was broken due to a PCB wiring mistake.

Kernel differences

The kernel in both the 700A01 and 700B01 shells identifies itself as Konami OS by T.H. with a 1995-09-01 build date. All other Konami PS1-based arcade boards, with the exception of the Twinkle System, use a kernel with the same identifier and date (but potentially different code). The kernels used by other manufacturers' arcade boards also contain the same T.H. initials, possibly hinting at the fact there was a single Sony employee in charge of providing customized kernels to all arcade system manufacturers.

While the 573's kernel is functionally identical to its retail counterpart (aside from its lack of support for the PS1's CD-ROM drive), several parts of it have been slightly tweaked to account for the hardware:

• Most CD-ROM APIs and the ISO9660 filesystem driver seem to have been purged.
• The code to parse SYSTEM.CNF and launch the boot executable from the CD-ROM has been made inaccessible. The shell handles executable loading and booting on its own, without ever returning to the kernel.
• The kernel initializes the EXP1 region and clears the watchdog periodically while booting. It does not keep clearing it in the background (e.g. from the exception handler) once the shell is loaded.
• 700B01 performs a "memory initialization" sequence that fills various RAM areas with pseudorandom values (possibly for heap debugging purposes), showing c1 through c7 on the debugging board's 7-segment display in the process.
• 700B01 reads register 0x1f40000e to determine which RAM footprints on the board are populated, then configures the main RAM controller accordingly.
• The GPU is reset and a series of color bars is displayed while the shell is being relocated to RAM. This feature is also present in other non-retail kernels such as the DTL-H2000's.
• The shell is launched through a stub that contains a Lisenced by Sony Computer Entertainment Inc.(SCEI) [sic] string, validated by the kernel in a similar (but not identical) way to PS1 expansion port ROMs.

Boot sequence

All variants of the shell are far simpler than their PS1 counterparts, as they lack any kind of UI (aside from a non-interactive status screen) and have no copy protection or anti-piracy checks of any kind. Once loaded by the kernel, they start by initializing the system bus and proceed to run a hardware self-test. The outcome of all checks is displayed on screen, with the following ones being performed:

• 22G: BIOS ROM integrity check. A checksum is computed and verified against the one present in the ROM at 0xbfc7fffc-0xbfc7ffff;
• 16H, 16G, 14H, 14G: main RAM read/write test (first row of chips on the board, closest to the CPU);
• 12H, 12G, 9H, 9G: main RAM read/write test (second row of chips on the board, closest to the JAMMA connector);
• 4L, 4P: VRAM read/write test. This causes the 573 to briefly display random pixels as framebuffers are overwritten during the check;
• 10Q: SPU RAM read/write test;
• 18E: JVS MCU reset and status check;
• CDR: ATAPI CD-ROM drive initialization and executable loading.

NOTE: 700A01 shells do not actually test 4P! The GPU starts up in 1 MB VRAM mode by default and the shell does not enable the chip select for the second bank, so the first VRAM chip is tested twice instead. This bug was fixed in the 700B01 shell, which initializes the GPU correctly.

If any check fails the shell locks up, shows a blinking "HARDWARE ERROR... RESET" prompt and stops clearing the watchdog after a few seconds, causing the 573 to reboot. Otherwise, the state of DIP switch 4 is checked and 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 memory (if DIP switch 4 is on);
• PSX.EXE in the root directory of the disc inserted in the CD-ROM drive. The drive is only initialized after booting from flash or PCMCIA fails or if DIP switch 4 is off, thus the shell will not error out if a drive is not connected but a boot executable is present on the flash. Note that the drive must be set up as an IDE primary/master device using the appropriate jumpers.

As with Sony's PS1 shell, the 573 shell's ISO9660 filesystem driver only implements a minimal subset of the specification and may not properly support non-8.3 file names. It also only allocates 2 KB for the disc's path table, so the total number of directories on the disc must be kept to a minimum in order to prevent the shell from crashing. Unlike the PS1, however, the 573 ignores SYSTEM.CNF completely regardless of whether or not it is present on the disc; the shell is hardcoded to always load PSX.EXE. Homebrew discs can take advantage of this behavior to provide separate PS1 and 573 executables instead of detecting the system type at runtime.

If DIP switch 4 is on, the shell expects to find a standard PS1 executable (including the full 2048-byte header) at offset 0x24 on either the built-in flash memory or one of the two PCMCIA flash cards, preceded by a CRC32 checksum of it at offset 0x20. The CRC is stored in little endian format and is not calculated on the whole executable, but rather only on bytes whose offsets are a power of two (i.e. on bytes at 0x24 + 0, 0x24 + 1, 0x24 + 2, 0x24 + 4 and so on). The check is implemented as follows:

#define EXE_CRC32_POLYNOMIAL 0xedb88320 // 0x04c11db7 bit-reversed

uint32_t exe_crc32(const uint8_t *data, size_t length) {
    size_t   offset = 0;
    uint32_t crc    = 0xffffffff;

    while (offset < length) {
        crc ^= data[offset];

        for (int bit = 8; bit; bit--) {
            uint16_t temp = crc;

            crc >>= 1;
            if (temp & 1)
                crc ^= EXE_CRC32_POLYNOMIAL;
        }

        if (offset)
            offset <<= 1;
        else
            offset = 1;
    }

    return ~crc;
}

#define DIP_SWITCH_PTR    ((const uint32_t *) 0x1f400004)
#define EXE_CRC32_PTR     ((const uint32_t *) 0x1f000020)
#define EXE_HEADER_PTR    ((const uint8_t  *) 0x1f000024)
// Offset of the "text section size" field within the executable header
#define EXE_TEXT_SIZE_PTR ((const uint32_t *) 0x1f000040)

bool is_exe_valid(void) {
    if (*DIP_SWITCH_PTR & (1 << 3)) // 1 = DIP switch off
        return false;
    if (memcmp(EXE_HEADER_PTR, "PS-X EXE", 8))
        return false;

    // BUG: the actual size of the executable including the header is
    // (2048 + *EXE_TEXT_SIZE_PTR), however neither the 700A01 nor 700B01 shells
    // take this into account and instead end up ignoring the executable's last
    // 2048 bytes.
    uint32_t crc = exe_crc32(EXE_HEADER_PTR, *EXE_TEXT_SIZE_PTR);

    return (crc == *EXE_DATA_PTR);
}

Installing a new game usually involves inserting the installation disc and turning off DIP switch 4 in order to prevent the shell from booting the game currently installed on the internal flash.

Command-line arguments

PS1 executables are generally launched with CPU registers $a0 and $a1 set to zero, in order to make sure programs that interpret them as argc and argv respectively will not crash by trying to parse invalid data. The 700A01 shell follows this convention.

The 700B01 shell, however, does pass two arguments to the executable it loads. $a0 is thus set to 2, while $a1 is set to point to an array containing pointers to the following strings:

• boot.rom=700B01
• boot.from=<device>, where <device> is one of the following:
  • flash.0 (internal flash memory)
  • flash.1 (PCMCIA flash card in slot 1)
  • flash.2 (PCMCIA flash card in slot 2)
  • ata.2 (CF card in slot 2)
  • cdrom

The launchers used by later Bemani games use these arguments if present to determine where to load the main game executable from, and fall back to autodetecting the game's installation location otherwise.

JVS MCU test sequence

The JVS MCU check is implemented in a different way between the two shell revisions. While the 700A01 shell simply resets the MCU and validates the status and error codes, the 700B01 self-test sequence performs 35 (!) different checks, each validating the codes returned under different conditions. The following tests are done:

1. Reset MCU, clear JVSIRDY, ensure that:
   • status code = 0
   • error code = 3
   • JVSIRDY = 0
   • JVSDRDY = 0
   • incoming JVS data = 0x0000
2. Reset MCU, write valid dummy packet header (0x00e0), ensure that:
   • status code = 2
   • error code = 3
3. Reset MCU, write invalid dummy packet header (0x001f), ensure that:
   • status code = 2
   • error code = 2
4. Reset MCU, write 16 dummy packets (0x1fe0, 0x0004, 1 << i, checksum), for each packet ensure that:
   • status code = 1
   • error code = 3
5. Reset MCU, write 16 dummy packets (same as above) with an invalid checksum, for each packet ensure that:
   • status code = 1
   • error code = 1

It is currently unclear if any data is actually sent to the JVS bus during step 4, as the shell may reset the MCU it before it starts sending the packet.

DVD-ROM support

Even though neither of the shell versions was explicitly designed with DVD-ROM support in mind, it is possible to run games from a DVD-ROM thanks to the fact that the ATAPI commands used by the shell and games to read sectors from the disc are medium-agnostic. Games that rely on CD-DA playback obviously cannot be put on a DVD, however all other games (including ones that rely on the digital I/O board for MP3 playback) will work as long as the disc is formatted as if it were a typical 573 CD-ROM (ISO9660 with no extensions, no UDF, 8.3 file names and a path table smaller than 2 KB).

NOTE: due to ATAPI incompatibility issues only a very limited number of DVD-ROM drives will actually be recognized and work properly with the shells and games. This is unrelated to the DVD format itself and is purely due to the fact that, unlike CD-ROM drives, most DVD drives were manufactured after the ATAPI specification got updated in a way that broke the 573's compatibility.

This accidental capability was greatly abused by bootleg Bemani "superdiscs" that bundled multiple games on a single DVD-ROM and shipped with a modified installation menu, allowing the user to pick which game to install. Each game on a superdisc is patched to load its files from a subdirectory rather than from the DVD's root.

Homebrew 573 software can be distributed as an ISO9660 image larger than 650 MB meant to be burned to a DVD-R, if sacrificing PS1 compatibility and CD-DA support is an option. In such case the image shall be distributed as an .iso file with 2048-byte sectors, rather than the typical .bin and .cue file pair used for PS1 games with 2352-byte Mode 2 sectors.

Scrapped CF card support

In addition to booting from "linear" memory mapped PCMCIA flash cards, the 700B01 shell features a driver for CF cards and a FAT filesystem parser that allows it to mount a CF card inserted in PCMCIA slot 2 (via a passive CF-to-PCMCIA adapter), search for a flash card image file and interpret its contents as if it were an actual flash card, loading the executable directly from it. Or at least, that would allow it to do so, had Konami not screwed up the wiring of the PCMCIA slots.

CF cards can operate in three different interfacing modes: memory mapped, I/O mapped and IDE compatibility mode. On the 573 only memory mapped mode is accessible as the other modes require usage of I/O chip select pins that are not connected. This mode, however, requires the host to issue 8-bit writes to the card's 16-bit bus through the use of individual chip select lines for each byte (/CE1 and /CE2). While the PS1's CPU does have separate lower (/WR0) and upper (/WR1) byte write strobes that could have been easily adapted to the appropriate signals, Konami decided to cut this specific corner and shorted /CE1 and /CE2 on each PCMCIA slot together, making it impossible to issue a single-byte write.

NOTE: later revisions of the 573 main board seem to have unpopulated jumpers next to the PCMCIA slots that can be used to rewire the chip select signals. It is currently unclear if these jumpers are actually sufficient to enable CF card booting without any additional hardware or BIOS modifications.

Bootleg mod boards

It is not uncommon to find 573s fitted with a bootleg BIOS "mod board" in place of the stock 700A01 or 700B01 mask ROM. These boards used to be bundled alongside bootleg game CD-ROMs and were apparently required in order to bypass the "anti-piracy checks" in Konami's BIOS.

Of course, since neither version of the shell has any such checks, the claims were completely 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 crude authentication mechanism to the bootleg game, allowing it to verify that it was indeed running on a 573 equipped with an appropriate mod board. In other words, mod boards were actually the bootleggers' implementation of Konami's security cartridge system, meant to prevent people from simply burning copies of a bootleg CD-ROM and forcing them to buy bootleg kits from whoever produced them instead. Oh the irony.

The added authentication circuitry will not create any issues with official nor homebrew software, however most of these boards feature an additional party trick: the shell executable is altered to load a differently named executable, making bootleg discs unable to boot on a stock 573 and vice versa. The following names have been found so far in modified BIOS ROMs:

• QSY.DXD
• SSW.BXF
• TSV.AXG
• GSE.NXX
• NSE.GXX

The following names have been found on unofficial game discs, but are not confirmed to have ever been used in modified BIOS ROMs:

• OSE.FXX
• QSU.DXH
• QSX.DXE
• QSZ.DXC
• RSU.CXH
• RSV.CXG
• RSW.CXF
• RSZ.CXC
• SSX.BXE
• SSY.BXD
• TSW.AXF
• TSX.AXE
• TSY.AXD
• TSZ.AXC

Homebrew software should thus place multiple copies of the boot executable on the CD-ROM to ensure any BIOS, modded or not, can successfully load it. 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 found it easier to just turn the string into random nonsense whose checksum collided with the original one.

DDRTURBO mod board

Board required by and specific to the DDR Extreme PLUS hack. Unlike all other currently known boards, this one actually adds new functionality to the system: the ability to speed up MP3 playback... by taking the place of the 29.45 MHz main oscillator on the digital I/O board, which is desoldered and replaced with a bodge wire. It features three crystal oscillators supplying the following clocks:

• 29.5 MHz (0.16% faster than stock, referred to as "Normal Speed" in Extreme PLUS)
• 33 MHz (12.05% faster than stock, referred to as "Speed up 10%" in Extreme PLUS)
• 36 MHz (22.24% faster than stock, referred to as "Speed up 20%" in Extreme PLUS)

The board listens for reads from the upper half of BIOS ROM (0xbfc40000-0xbfc7ffff) and latches bits 5-6 of the byte read to determine which clock to output to the digital I/O board:

NOTE: kernel code execution while the game is running will not affect the clock as the kernel is contained entirely within the ROM's first half. The second half is in fact only accessed on startup when relocating the shell executable to RAM and computing the ROM checksum.

In order to switch clocks, Extreme PLUS always reads from one of the following addresses:

The board's EPROM holds a copy of the 700A01 BIOS with the last byte of the checksum at 0xbfc7ffff modified from 0xf9 to 0x39. Extreme PLUS uses this change to detect the mod board and will refuse to run if it is not present. The padding byte at 0xbfc7fffb is also changed from 0xff to 0x3f in order for the contents of the ROM to match the new checksum.

Game-specific information

Black case I/O connectors

Fisherman's Bait and a few other non-Bemani games use a 573 housed in a black case with blue front and back panels. Unlike the gray metal cases used by other games, this case model has no cutouts for removable front and back panels that hold game-specific connectors and instead has a fixed set of ports exposed:

• Power: 2x4 Molex connector that can be used as a power input or output, wired to CN17.
• Option 1: DE9 connector providing four analog inputs, wired to CN3 on the main board.
• Option 2: DE9 connector providing six button (digital) inputs, of which four are also exposed on the JAMMA connector. Wired to CN5 on the motherboard.
• Reel connector (back side): 3x3 Molex connector wired to the GE765-PWB(B)A fishing controller I/O board. Probably missing on systems that that did not come with Fisherman's Bait.

DDR I/O connectors

Dance Dance Revolution uses a 573 enclosed in a gray metal case, with either an analog or digital I/O board installed. The front panel has a cutout covered by a metal plate, which in turn holds the following connectors:

• 1P (10-pin white, only 7 pins used): connects to the left stage and controls arrow lights, in addition to being used for bitbanged communication with the stage PCB. Wired to light bank A on the I/O board.
• 2P (10-pin orange, only 7 pins used): same as above for the right stage. Wired to light bank B on the I/O board.
• Unlabeled (10-pin red, only 7 pins used): connects to cabinet button and marquee lights. Wired to light bank C.
• Unlabeled (6-pin white, only 2 pins used): controls the inverter that drives the neon rings around the speakers. Wired to light bank D.

The back panel has a similar cutout, covered by a plate with holes for the digital I/O board's RCA networking jacks.

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:

Light outputs A4, A5, B4 and B5 do not actually control any lamps, but are used to communicate with each stage's I/O board. See the external modules section for more details.

DDR Solo input and light mapping

Dance Dance Revolution Solo cabinets, unlike 2-player cabinets, do not use a stage I/O board to multiplex the sensors as each arrow panel only has 2 sensors (rather than 4). Each sensor is instead wired directly to the JAMMA connector, making use of most of the available inputs.

The light mapping is currently unknown. Solo cabinets have less lights compared to their 2-player counterparts (e.g. arrow panel lamps are missing).

DrumMania light mapping

First-generation DrumMania cabinets have lights wired up to the I/O board as follows:

The wiring was changed in later cabinets, which use the following mapping instead:

Notes

• Hard-to-install games
• Homebrew guidelines
• Missing support for PAL mode
• Flash chips and PCMCIA cards
• Known working replacement PCMCIA cards
• Known working replacement drives
• Bemani launcher error and status codes

Hard-to-install games

While the vast majority of 573 games can be trivially installed by inserting the respective game disc (or sometimes a separate install disc) and a new security cartridge, there are a few ones that require more complex installation procedures:

• Games without a CD-ROM: for what should be obvious reasons, such games cannot be installed without either using homebrew flashing tools or injecting a flash image into another game's CD-ROM installer. Konami's "official" installation method was to boot the flash image from a PCMCIA card, which the game will detect and copy over to the internal flash.
• Hyper Bishi Bashi Champ, Handle/Steering Champ: RTC RAM is employed as a "suicide battery" of sorts by pre-populating it with a header and other data at the factory. If any of the data is corrupted or missing, the game will display "HARDWARE UNMATCHED" and refuse to boot any further.
• Dance Dance Revolution (JAB version): also checks RTC RAM and will not boot if its header is missing from the first 32 bytes (subsequent data can be uninitialized and will be rebuilt automatically if needed). Additionally, even though the game requires a CD-ROM, its disc only contains CD-DA tracks and lacks an installer or flash image, requiring the same workarounds as CD-ROM-less games in order to install it.
• Dance Dance Revolution 4thMIX PLUS and PLUS Solo: as this game is an upgrade to DDR 4thMIX, the installer will refuse to proceed unless 4thMIX's header is present in the first 32 bytes of RTC RAM. This check is only performed during installation; the game itself will rebuild the entire contents of the RTC if the header is invalid.
• Dancing Stage feat. Dreams Come True (both analog I/O and digital I/O versions): notorious for requiring a lot of juggling with security cartridges. The installer prompts for a cartridge from a previous game that is allowed to be upgraded, which will be invalidated and made unusable as part of the installation process.

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 named PSX.EXE (which will be launched on a 573) and the other (which will run on a PS1) referenced by SYSTEM.CNF. This makes it easier to have two separate builds of the game rather than having to detect system type at runtime. Additional copies of PSX.EXE with the file names commonly used by BIOS mod boards (QSY.DXD, TSV.AXG and so on) shall also be present.
• 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).

Missing support for PAL mode

The 573 only supports 60 Hz mode (i.e. "NTSC", even though the video DAC has no composite or S-video output so no color modulation is involved). Attempting to switch the GPU into 50 Hz PAL mode using the GP1(0x08) command will result in a crash, as only the NTSC clock input pin is wired up.

Support for 50 Hz can be added back by shorting pins 192 and 196 on the GPU (which will give "PAL-on-NTSC" timings) or by connecting pin 192 to an external oscillator tuned to generate a PAL clock. See the timings section of the GPU page for more details.

Flash chips and PCMCIA cards

The PCMCIA flash cards required by most 573 games are "linear" (memory mapped) cards consisting of one or more parallel flash memory chips wired directly to the bus, rather than CF or ATA-compatible cards. As neither linear cards nor parallel flash command sets are fully standardized, working with these cards may be difficult without some prior knowledge.

There are two main variants of such cards:

• 8-bit: these contain one or more pairs of flash chips with an 8-bit data bus each. Each pair has one chip wired to the lower byte of the data bus and the other wired to the upper byte. Commands must thus be issued to both chips at once by repeating the command byte (e.g. writing 0x9090 to issue the 0x90 JEDEC ID command). Issuing 8-bit writes to a single chip is not supported on the 573 due to the way chip select lines are wired up; see the BIOS CF card support section for more details.
• 16-bit: these contain flash chips with a native 16-bit bus. The chips are simply mapped next to each other within the card's address space.

Konami's flash driver only supports 8-bit cards that use one of the following chips:

Most games, including the launchers used by later Bemani games, will check the JEDEC IDs of the cards' chips on startup and reject any unsupported chip, even if valid game data is otherwise present on the card. This makes it impossible to manually install a game onto an unsupported card (e.g. through homebrew tools) without also patching the launcher in order to skip the check.

The 573 main board seems to always be fitted with either MBM29F016A or LH28F016S chips. The internal flash memory is accessed using the same driver as the flash cards and has the same caveats (having to issue commands to two chips at once and so on).

Known working replacement PCMCIA cards

This is an incomplete list of PCMCIA flash cards that are known to work, or not to work, with Konami's flash driver. Due to the JEDEC ID checks, only cards that contain flash chips listed in the previous section will work.

Note that most of these cards have identical labels and can typically only be told apart from the model number printed on the bottom side or one of the edges.

IMPORTANT: the model numbers on Centennial cards seem to be inconsistent and not necessarily related to which flash chips the card is fitted with. As such buying these cards for use with 573 games is strongly discouraged, even though some of them are known to use parts compatible with Konami's driver.

Known working replacement drives

This is an incomplete list of drives that are known to work, or to be incompatible, with the ATAPI driver Konami used in the BIOS shell and games. The driver was likely written using an old version of the ATAPI specification as a reference; CD-ROM drives manufactured in the late 1990s and very early 2000s have a higher chance of being compatible than drives manufactured later, possibly due to changes introduced in later revisions of the ATAPI specification that broke the assumptions Konami's driver makes.

CD-DA playback is particularly problematic as Konami's code seems to be unable to handle the subtle implementation differences across different drives. To add insult to injury, some of the few drives that do work have bugs in their subchannel handling that result in incorrect playback status data being reported to the 573, completely breaking pre-digital-I/O Bemani titles that rely heavily on audio timing.

NOTE: Konami shipped some units with a Toshiba XM-7002B laptop drive and a passive adapter board (GX874-PWB(B)) to break out the drive's signals to a regular 40-pin IDE connector. Laptop drives were also used by Konami in the GXA25-PWB(A) multisession unit.

Bemani launcher error and status codes

The installers and launchers used by Bemani titles that require the digital I/O board have an extensive error and status reporting system. Launcher messages are easily recognizable as they are always displayed in a blue window and have a 3-digit status code, however Japanese versions of the games will show them in Japanese with no way to switch language (short of patching the launcher; all launcher variants contain both English and Japanese strings).

Below is a list of all messages from launcher version 1.95 in both English and Japanese, along with the respective status codes and indices in the launcher's internal message array.

Boot is not available from this device.
DEVICE=%s1

このデバイスからのブートはできません.
DEVICE=%s1

Digital Sound PCB intialization failed.

デジタルサウンド基板の初期化に失敗しました.

Digital Sound PCB ROM error.

デジタルサウンド基板ROMエラー.

CD-ROM initialization failed.

CD-ROMドライブの初期化に失敗しました.

File system mounting failed.
Please check that correct CD-ROM is in use.

ファイルシステムのマウントに失敗しました.
CD-ROMが間違っていないか確認してください.

File system mounting failed.
Please check that correct CD-ROM is in use.

ファイルシステムのマウントに失敗しました.
CD-ROMが間違っていないか確認してください.

File system mounting failed.
Please check that correct CD-ROM is in use.

ファイルシステムのマウントに失敗しました.
CD-ROMが間違っていないか確認してください.

File system mounting failed.
Please check that correct CD-ROM is in use.

ファイルシステムのマウントに失敗しました.
CD-ROMが間違っていないか確認してください.

File system mounting failed.
Please check that correct CD-ROM is in use.

ファイルシステムのマウントに失敗しました.
CD-ROMが間違っていないか確認してください.

Disc device initialization failed.

ディスクデバイスの初期化に失敗しました.

You are using an incorrect CD-ROM.
Replace CD-ROM to %s1 and
turn on the main power.

CD-ROMが違います.
CD-ROMを%s1に交換し,電源を
入れ直してください.

Disc device initialization failed.

ディスクデバイスの初期化に失敗しました.

Disc device initialization failed.

ディスクデバイスの初期化に失敗しました.

Config file error.
FILE=%s1
ERROR=%d2, LINE=%d3, COLUMN=%d4

コンフィグファイルエラー.
FILE=%s1
ERROR=%d2, LINE=%d3, COLUMN=%d4

You are using an incorrect CD-ROM.
Replace CD-ROM to %s1 and
turn on the main power.

CD-ROMが違います.
CD-ROMを%s1に交換し,電源を
入れ直してください.

Cassette is not installed.
Turn off the main power and install the
correct cassette then turn the power on.

カセットがセットされていません.
電源を切り,正しいカセットをセットして
再度電源を入れてください.

Cassette error. (%d1)
Cassette does not match this game.
Check if the cassette is for this
game (%s2)
Refer to manual for more information.

カセットエラー (%d1)
ゲームとカセットが対応していません.
カセットがこのゲーム(%s2)用のものか
確認してください.
詳しくは取り扱い説明書を参照してください.

Boot is not available from this device.
DEVICE=%s1

このデバイスからゲームのブートはできません.
DEVICE=%s1

Cassette error (%d1)

カセットエラー (%d1)

Master Calendar network error.

マスターカレンダー通信エラー.

Master Calendar network error.

マスターカレンダー通信エラー.

Master Calendar network error.

マスターカレンダー通信エラー.

Installation boot device error.
Installation cassette is inserted.
Turn off the power.  Before turning the
power on:  1. Change the cassette to the
Operating Cassette to enter the game or
2. Set DIP-SW4 to "OFF" to install.

インストールブートデバイスエラー.
インストールカセットがセットされています.
電源を切り,ゲームを行うには運用カセットに
交換, インストールするにはDIP-SW4をOFFに
し,再度電源を入れてください.

Installation Cassette does not correspond
to the machine.
Please use Installation Cassette marked
%s1 for installation.

インストールカセットと本体との対応がとれて
いません. 認証番号%s1が記入された
インストールカセットを用いてインストール
してください.

Cassette error (%d1)

カセットエラー (%d1)

This cassette is used to convert another
game. This can not be used as an operating
cassette.

このカセットはいちど次機種への
コンバージョンに使用されたものです.
運用カセットとして使用することはできません.

Cassette error (%d1)

カセットエラー (%d1)

File not found.
FILE=%s1

ファイルが見つかりません.
FILE=%s1

File reading error.
FILE=%s1

ファイルリードエラー.
FILE=%s1

File not found.
FILE=%s1

ファイルが見つかりません.
FILE=%s1

File reading error.
FILE=%s1

ファイルリードエラー.
FILE=%s1

File reading error.
FILE=%s1

ファイルリードエラー.
FILE=%s1

File reading error.
FILE=%s1

ファイルリードエラー.
FILE=%s1

File data error.
FILE=%s1

ファイルデータエラー.
FILE=%s1

File data error.
FILE=%s1

ファイルデータエラー.
FILE=%s1

Turn off the power and check if the Flash
Card is inserted properly.
Please turn the power on after checking.
DEVICE=%s1

電源を切り, フラッシュカードが正しくセット
されているか確認してください. 準備が整って
から再び電源を入れてください.
DEVICE=%s1

Checksum error.  If you have the latest
CD-ROM, please replace.  Turn off the
power and insert installation cassette.
Set DIP-SW4 to "OFF", then turn on the
power and reinstall CD-ROM.

チェックサムエラー. 最新のCD-ROMがあれば,
それに交換してください. 電源を切り,インス
トールカセットに交換,DIP-SW4をOFFにして
電源を入れ,再インストールしてください.

Area specification error.
Only area specification below is available.
 %s1
Check the DIP-SW of Master Calendar.

仕向地指定エラー.
本タイトルは次の仕向地のみ指定できます.
 %s1
マスターカレンダーのDIP-SWを確認して
ください.

Cassette initialization error.
The cassette is already initialized as
Operating Cassette (%s1)
Reinitialization can not be completed.

カセット初期化エラー.
カセットはすでに運用カセット(%s1)
として初期化されています.
再初期化はできません.

Cassette initialization error.
The cassette is already initialized as
Installation Cassette (%s1)
Reinitialization can not be completed.

カセット初期化エラー.
カセットはすでにインストールカセット
(%s1)として初期化されています.
再初期化はできません.

File not found.
FILE=%s1

ファイルが見つかりません.
FILE=%s1

Turn off the power and check if the Flash
Card is inserted properly.
Please turn the power on after checking.
DEVICE=%s1

電源を切り, フラッシュカードが正しくセット
されているか確認してください. 準備が整って
から再び電源を入れてください.
DEVICE=%s1

Installation failed. (%d1)

インストールに失敗しました (%d1)

Assertion failed.
FILE=%s1
LINE=%d2

アサーションフェイル.
FILE=%s1
LINE=%d2

Argument buffer overflow.

引数バッファオーバーフロー.

File not found.
FILE=%s1

ファイルが見つかりません.
FILE=%s1

File data error.
FILE=%s1

ファイルデータエラー.
FILE=%s1

File reading error.
FILE=%s1

ファイルリードエラー.
FILE=%s1

Security Chip error. (%d1)
This Security Chip was initialized for
another title.

セキュリティチップエラー.(%d1)
このセキュリティチップは他のタイトル用に
初期化されています.

CD-ROM drive error

CD-ROMドライブエラー.

RTC error

RTCエラー.

Specification selection error
Only specification below can be
selected for this title.
 %s1
Check the DIP-SW of machine.

商品仕様指定エラー.
本タイトルは次の商品仕様のみ指定できます.
 %s1
本体のDIP-SWを確認してください.

Operating Cassette is not corresponding
with the machine.  Turn off the power and
replace it with Operating Cassette
No.%s1 then reboot.

運用カセットと本体との対応がとれていません.
電源を切り,認証番号%s1が記入された
運用カセットに交換して再起動してください.

Incorrect cassette installed.

不当なカセットです.

Security Chip initialization failed. (%d1)

セキュリティチップ初期化エラー. (%d1)

Cannot use this security cassette
as Installation Cassette.

このセキュリティカセットはインストール
カセットとして使用することはできません.

Cannot use this security cassette
as Installation Cassette.

このセキュリティカセットはインストール
カセットとして使用することはできません.

This version cannot initialize a cassette.
Please replace CD-ROM to %s1
for initialize, and turn off the power.
Set DIP-SW4 to "OFF", then turn on
the power.

このバージョンはカセットを初期化できません.
初期化するにはCD-ROMを%s1に
交換して電源を切り,DIP-SW4をOFFにして
再起動してください.

You are using an incorrect CD-ROM.
Replace CD-ROM to %s1 and
turn on the main power.

CD-ROMが違います.
CD-ROMを%s1に交換し,電源を
入れ直してください.

Cannot use this security cassette.

このセキュリティカセットは使用できません.

Cannot use this security cassette.

このセキュリティカセットは使用できません.

Cassette is not corresponding with the
machine.  Turn off the power and
replace it with Cassette No.%s1
then reboot.

カセットと本体との対応がとれていません.
電源を切り,認証番号%s1が記入された
カセットに交換して再起動してください.

Cassette is not corresponding with the
machine.  Turn off the power and
replace it with Cassette No.%s1
then reboot.

カセットと本体との対応がとれていません.
電源を切り,認証番号%s1が記入された
カセットに交換して再起動してください.

Checksum error.
If you have the latest CD-ROM, please
replace.  Turn off the power and set
DIP-SW4 to "OFF", then turn on
the power and reinstall CD-ROM.

チェックサムエラー.
最新のCD-ROMがあればそれに交換してください.
電源を切ってDIP-SW4をOFFにしたあと,
電源を入れて再インストールしてください.

This cassette is used to convert another
game. This can not be used to this game.

このカセットは次機種へのコンバージョンに
使用されたものです.
この機種で再び使用することはできません.

Boot is not available from this device.
DEVICE=%s1

このデバイスからゲームのブートはできません.
DEVICE=%s1

You are using an incorrect CD-ROM.
Replace CD-ROM to %s1 and
turn on the main power.

CD-ROMが違います.
CD-ROMを%s1に交換し,電源を
入れ直してください.

File system mounting failed.
Please check that correct CD-ROM is in use.

ファイルシステムのマウントに失敗しました.
CD-ROMが間違っていないか確認してください.

File system mounting failed.
Please check that correct CD-ROM is in use.

ファイルシステムのマウントに失敗しました.
CD-ROMが間違っていないか確認してください.

Installation boot device error.
Please turn off the power for installation,
and set DIP-SW4 to "OFF", then turn on
the power.

インストールブートデバイスエラー.
インストールするには電源を切り,DIP-SW4を
OFFにして再起動してください.

CD-ROM drive error

CD-ROMドライブエラー.

CD-ROM drive version update failed. (%d1)
Please call a dealer near you.

CD-ROMドライブのバージョンアップに失敗
しました. (%d1)
最寄りのサービスセンターにお問い合わせ
下さい.

Cassette error (%d1)

カセットエラー (%d1)

You are using the cassette of another
cabinet. Please use the correct cassette.
Please see details in operator's manual.

異なる本体向けのカセットを使用しています.
正しい本体との組み合わせで使用してください.
詳しくは取り扱い説明書を参照してください.

You are using the cassette of another
cabinet. Please use the correct cassette.
Please see details in operator's manual.

異なる本体向けのカセットを使用しています.
正しい本体との組み合わせで使用してください.
詳しくは取り扱い説明書を参照してください.

You are using unknown cabinet.
Check all connectors.
Please see details in operator's manual.

不明な本体を使用しています.
各コネクタが外れていないか確認してください.
詳しくは取り扱い説明書を参照してください.

You are using unknown cabinet.
Check all connectors.
Please see details in operator's manual.

不明な本体を使用しています.
各コネクタが外れていないか確認してください.
詳しくは取り扱い説明書を参照してください.

Non-applicable game installed.
To install this game,
 %s1
shall be installed first.

異なるゲームがインストールされています.
このゲームをインストールするにはあらかじめ
 %s1
がインストールされている必要があります.

This software is for the e-Amusement
system.
The game will only work on the e-Amusement
cabinet.

このゲームソフトはe-Amusement(レンタル)用
ソフトです.
e-Amusement用筐体でのみ動作します.

This software is not for the e-Amusement
system.
The game doesn't work on the e-Amusement
cabinet.

このゲームソフトはe-Amusement(レンタル)用
ソフトではありません.
e-Amusement用筐体では動作しません.

Non-applicable game installed.
To install this game,
 %s1
shall be installed first.

異なるゲームがインストールされています.
このゲームをインストールするにはあらかじめ
 %s1
がインストールされている必要があります.

Cassette initialization error.
The cassette is already initialized as
%s1
Reinitialization can not be completed.

カセット初期化エラー.
カセットはすでに%s1として初期化
されています. 再初期化はできません.

Cassette initialization error.
The cassette is already initialized as
%s1
Reinitialization can not be completed.

カセット初期化エラー.
カセットはすでに%s1として初期化
されています. 再初期化はできません.

Cassette initialization error.
The cassette is already initialized as
%s1
Reinitialization can not be completed.

カセット初期化エラー.
カセットはすでに%s1として初期化
されています. 再初期化はできません.

Installation completed.
Please write down the No.%s2
on cassette and machine.  Turn off the
power and replace cassette to
%s1 then turn on the power.

インストール完了.
カセットと本体に認証番号%s2を記入
してください.電源を切ってカセットを
%s1に交換し,再度電源を入れて
ください.

Installation complete.  Please write down
the No.%s3 on cassette and machine.
Replace CD-ROM to %s1 and turn off
the power then replace cassette to
%s2.  Set DIP-SW4 to "ON",
then turn on the power.

インストール完了. カセットと本体に認証番号
%s3を記入してください.
CD-ROMを%s1に交換して電源を切り,
カセットを%s2に交換し,
DIP-SW4をONにして再度電源を入れてください.

Operating cassette initialized.
The cassette was initialized as Operating
Cassette (%s1)

運用カセット初期化完了.
カセットを運用カセット(%s1)として
初期化しました.

Installation cassette initialized.
The cassette was initialized as
Installation Cassette (%s1)

インストールカセット初期化完了.
カセットをインストールカセット(%s1)
として初期化しました.

Initialized Operating Cassette
The cassette is already initialized as
Operating Cassette (%s1)
Reinitialization is not necessary.

初期化済み運用カセット.
カセットはすでに運用カセット(%s1)
として初期化されています. 
再初期化の必要はありません.

Initialized Installation Cassette
The cassette is already initialized as
Installation Cassette (%s1)
Reinitialization is not necessary.

初期化済みインストールカセット.
カセットはすでにインストールカセット
(%s1)として初期化されています.
再初期化の必要はありません.

Installation completed.
Please write down the No.%s2
on cassette and machine.  Turn off the
power and replace cassette to
%s1 then turn on the power.

インストール完了.
カセットと本体に認証番号%s2を記入
してください.電源を切ってカセットを
%s1に交換し,再度電源を入れて
ください.

Installation complete.  Please write down
the No.%s3 on cassette and machine.
Replace CD-ROM to %s1 and turn off
the power then replace cassette to
%s2.  Set DIP-SW4 to "ON",
then turn on the power.

インストール完了. カセットと本体に認証番号
%s3を記入してください.
CD-ROMを%s1に交換して電源を切り,
カセットを%s2に交換し,
DIP-SW4をONにして再度電源を入れてください.

Installation completed.
Please write down the No.%s1
on cassette and machine.
Turn off the power, then reboot.

インストール完了.
カセットと本体に認証番号%s1を記入
してください.
電源を切って再起動してください.

Installation complete.
Please write down the No.%s2
on cassette and machine.
Replace CD-ROM to %s1 and turn off
the power.
Set DIP-SW4 to "ON", then reboot.

インストール完了.
カセットと本体に認証番号%s2を
記入してください.
CD-ROMを%s1に交換して電源を切り,
DIP-SW4をONにして再起動してください.

Security cassette initialized.
The cassette was initialized for
%s1.

セキュリティカセット初期化完了.
カセットを%s1に初期化しました.

Initialized Security Cassette
The cassette is already initialized for
%s1.
Reinitialization is not necessary.

初期化済みセキュリティカセット.
カセットはすでに%s1に初期化
されています. 再初期化の必要はありません.

SERVICE button is pressed.
To force installation, turn off the power,
change the cassette to the Installation
Cassette, and turn on the power with
pressing SERVICE switch.

サービスボタンが押されています.
強制インストールを行うには電源を切り,
インストールカセットに交換して, サービス
ボタンを押しながら電源を入れてください.

CD-ROM drive version update in progress.
Please do not shut off power.
This will take a few moments.

現在CD-ROMドライブのバージョンアップを
実行しています.
電源を切らずにそのままお待ち下さい.

CD-ROM drive version update completed.

CD-ROMドライブのバージョンアップが完了
しました.

Starting CD-ROM drive version update.
Please do not turn off the power while
updating.
Press TEST button to begin updating.

CD-ROMドライブのバージョンアップを行います.
バージョンアップ中は絶対に電源を切らないで
下さい.
テストボタンを押すとバージョンアップを開始
します.

Cleared RTC-RAM.
At Game Demo screen, press the test button
for the Test Mode and re-do the settings.

Press the Test Button for the next screen.

RTC-RAMをクリアしました.
ゲームデモが始まったらテストボタンを押して
テストモードに入り設定をやり直してください.

テストボタンを押すと次に進みます.

Pinouts

• Main board pinouts (GX700-PWB(A))
• Analog I/O board pinouts (GX700-PWB(F))
• Digital I/O board pinouts (GX894-PWB(B)A)
• Security cartridge pinouts

Main board pinouts (GX700-PWB(A))

Analog input port (ANALOG, CN3)

The inputs are wired directly to the 573's built-in ADC with no protection, so they can only accept voltages in 0-5V range. This connector is usually used for potentiometers and similar resistive analog controls.

Digital output port (EXT-OUT, CN4)

Unlike the light output ports on most I/O boards, these are unisolated 5V logic level outputs.

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. All inputs have a pullup resistor to 5V.

Content truncated for page performance. Open the source repository for the full SKILL.md file.