Namco system 256

From Arcade Otaku Wiki
Jump to: navigation, search

Boot sequence

Not very verbose. At power up there are 7 beeps, followed by over a minute of nothing, a brief solid red screen, then a blue screen with a brief JVS test, a brief grey screen, then game startup.

Beep codes

  • 3 beeps, no (valid) memory card found


PS2 based system, in a compact sturdy metal enclosure that adds quite a bit of weight. Unlike the Taito Type X, it has no internal power supply. It is a JVS system, and I've tested it with 3 different IO boards with no issues - if you already have a JVS cab, you don't need the IO board that comes with the kit.

DIP switches

  • 1 off=Game mode, on=test mode
  • 2 off=3v video output, on=0.7v video output
  • 3 off=15khz video, on=31khz video
  • 4 off=composite sync, on=h/v sync

For use with a VGA (31k) monitor, use off,on,on,on

JVS Input

The system has two USB connectors, where one is JVS and the other is presumably USB.

The connector used for JVS input is the one next to the RCA audio connectors.

Case Fan

Nidec D06R-12TM 60x60x15mm 12v 2-wire fan. If it's really noisy, you should replace it - same size as many CPU cooling fans.


All standard JVS except for the power-entry, which is JST VH, part number VHR-6n. Pinout of the power is:

  • 1 - 5V
  • 2 - 5V
  • 3 - GND
  • 4 - GND
  • 5 - 12V
  • 6 - GND

The kit originally comes with a JVS power adapter (JST VH to JST-VL), part number 306-465.


Uses what is probably a bog standard IDE DVD drive. Guru has tested a bunch, personally I've tested the NEC 3500A dvd-recorder with no issue. The drive itself is not mounted directly with screws, and although it is pretty snug in the horizontal direction, not so in the depth direction. This is the reason many pictures shows the DVD drive pushed into the metal cage. This can easily be remedied by using a cut wine cork as a spacer.

Memory card details

The memory card holds the executable game file in a NAND flash chip, and also has a MagicGate protection IC. The MagicGate is different from the one used in PS2 memory cards, which is the reason you cannot PS2 card readers/writers.

The NAND flash chip is organized into:

  • 1024 Blocks
  • 16 Pages per block
  • 528 bytes pr page,consisting of
    • 256 bytes of the 1st half page
    • 256 bytes of the 2nd half page
    • 16 bytes spare

1024*16*528=8650752 bytes. This is the size a raw dump of the chip should have. The 16 bytes spare part of the page should be used for some kind of system level ECC/error correction algorithm. For the PS2/System246 this algorithm is Hamming.

Some dumps do not include the spare/ECC portion, as this is not seen by the host system (it is handled by the MCU on the memory card), or they include it in a separate file. These files will be 1024*16*512=8388608 bytes, and 1024*16*16=262144 respectively.

The different way to store dumps is very similar to the ISO vs RAW/BIN of optical discs.

NAND flash chips seen:

  • Samsung K9F6408UOA
  • Samsung K9F6408UOB
  • Samsung K9F6408UOC
  • Fujitsu MBM30LV0064
  • Toshiba TC58V64FT
  • Toshiba TC58V64AFT
  • Spansion S99-50146

To repair the flash in case of corruption, you can desolder/resolder the NAND flash and read/write it with a programmer. Wellon VP-490 programmer with Adapter WL-PSOP44-U001 is confirmed to access the chips correctly.

Generally the system accesses the contents of the NAND flash like this:

  • System256 -> MagicGate -> NAND flash

The MagicGate and contents of the flash are tied togheter, so it is generally not possible to to merely interchange NAND flashes between memory cards. However, the only thing that ties the MagicGate to the content of the flash is 32 bytes in the boot.bin file. If you have two MemoryCards for the same game, the only difference between those two will be 32 bytes in the boot.bin file. Thus, hex-comparing two 'identical' boot.bin files should not only reveal where 32 byte signature located, but also what it is for a given memory card.

listing/extracting files works great under linux, get the python source and run it from linux for zero issues:

This is the dump of SuperDragonBallZ

~/python NM00027.BIN ls
rwx--d----+----      33 2005-12-07 09:49:58 .
-wx--d----+--H-       0 2005-01-19 12:46:14 ..
rwx-f--8--+----   46912 2005-01-19 12:46:16 boot.bin
rwx-f--8--+----   86561 2005-01-19 12:46:17 ACLOAD
rwx-f--8--+----   91265 2005-01-19 12:46:19 IOPRP214A
rwx-f--8--+----      50 2005-01-19 12:46:19 title.txt
rwx-f--8--+---- 3686320 2005-12-07 09:49:24 DBALOAD
rwx-f--8--+----  105346 2005-12-07 09:49:26 DBAGAME
rwx-f--8--+----  126002 2005-12-07 09:49:27 FPGA
rwx-f--8--+----   32644 2005-12-07 09:49:29 JVFIRM
rwx-f--8--+----  261261 2005-12-07 09:49:31 IOPRP300A
rwx-f--8--+----   83725 2005-12-07 09:49:33 MCMANAC
rwx-f--8--+----    6509 2005-12-07 09:49:34 ACCORE
rwx-f--8--+----    2501 2005-12-07 09:49:34 ACFPGALD
rwx-f--8--+----   15874 2005-12-07 09:49:35 ACJVLD
rwx-f--8--+----    1745 2005-12-07 09:49:36 ACJV
rwx-f--8--+----    4901 2005-12-07 09:49:37 ACRAM
rwx-f--8--+----    1369 2005-12-07 09:49:38 ACSRAM
rwx-f--8--+----    2665 2005-12-07 09:49:39 ACMEM
rwx-f--8--+----    5997 2005-12-07 09:49:40 ACMEME
rwx-f--8--+----    2817 2005-12-07 09:49:41 ACTIMER
rwx-f--8--+----   11957 2005-12-07 09:49:42 ACATA
rwx-f--8--+----   36065 2005-12-07 09:49:43 ACCDVD
rwx-f--8--+----    6781 2005-12-07 09:49:44 ACCDVDE
rwx-f--8--+----    6501 2005-12-07 09:49:45 ACUART
rwx-f--8--+----   44869 2005-12-07 09:49:46 PADMAN
rwx-f--8--+----   10542 2005-12-07 09:49:47 MNCARDIF
rwx-f--8--+----   17067 2005-12-07 09:49:48 IOPMAIN
rwx-f--8--+----   28661 2005-12-07 09:49:49 LIBSD
rwx-f--8--+----   70925 2005-12-07 09:49:50 ACARKD_DVD
rwx-f--8--+----   76469 2005-12-07 09:49:52 CRI_ADXI
rwx-f--8--+----    1370 2005-12-07 09:49:53 INFODAT
rwx-f--8--+----  726162 2005-12-07 09:49:58 RAMDISK

Memory card pinout