← back to the Capcom custom chip sheet (85605-A-2 1/1)

The clean board — PAL16L8 on the PCB itself

set 2 hardware, set 3 ROMs · no riser — the decryptor is designed into the board
What the original chip does. Capcom's DIP48 at 10M sits between the program ROM and the Z80's data bus. On opcode fetches only (it watches M1/SYNC) it swaps the two 3-bit groups of the byte, leaving bits 0 and 4 alone:
decrypted = (src & 0x11) | ((src & 0xE0) >> 4) | ((src & 0x0E) << 4)

   bit   7  6  5  4  3  2  1  0
   from  3  2  1  4  7  6  5  0        (bits 0 and 4 stay put)
Ordinary data reads pass through untouched. The permutation is its own inverse, so the same wiring works in both directions — which is exactly why a bootlegger can replace a custom LSI with a handful of TTL.

What is actually on the board

This board has no riser. The bootlegger redrew the PCB with the decryptor designed in: the silkscreen itself reads PAL16L8, an AMPAL16L8NC sits in it, with LS08 directly above and LS245 above that, all a few millimetres from the Z80. That trio — PAL16L8 + 74LS245 + 74LS08 — is the architecture MAME documents for commandob2, and it is the variant whose PAL was dumped, so the equations below describe this board directly rather than by analogy.

Two facts about this board, and they disagree about which MAME set it is. Its hardware is set 2 (on-board PAL + '245 + '08). Its ROM contents match set 3 (commandob3). Bootleggers mixed board runs and ROM sets freely, so rather than force it into one label this page describes it as what it is: the clean board.
THE CLEAN BOARD - PAL16L8 ON THE PCB ITSELF (set 2 hardware, set 3 ROMs) no riser: silkscreened PAL16L8 + 74LS245 + 74LS08 sit next to the Z80 on the main board COMMANDO 85605-A-2 CUSTOM CHIP REPLACEMENT the clean board (reverse-engineered) reconstructed - not a Capcom drawing MEMORY SIDE CPU SIDE 9M 2 x 27128 stacked 11 D0 12 D1 13 D2 15 D3 16 D4 17 D5 18 D6 19 D7 11M Z80 14 D0' 15 D1' 12 D2' 8 D3' 7 D4' 9 D5' 10 D6' 13 D7' D0 direct - never swapped D4 direct - never swapped PAL16L8 AMPAL16L8NC straight through 1 19 2 18 3 17 5 15 6 14 7 13 not an opcode fetch: unchanged 74LS245 cross-wired (bidir) 3 17 4 16 5 15 7 13 8 12 9 11 read path DURING an opcode fetch -> the B-side wiring swaps the groups D1 <-> D5 D2 <-> D6 D3 <-> D7 CONTROL 9 /M1 10 /MREQ 8 -> PAL 4 6N/'08 12 ROM /CE 13 /RD 11 -> PAL 9 '08 5 /M1 6 -> PAL 8 11J/'14 PAL 11 <- Z80 /WR (pin 22) and -> '245 pin 1 (DIR) PAL 12 -> '245 pin 19 (~OE) one bidirectional '245 covers BOTH the swapped read path and the write direction - no '244 needed. decoded from the dumped fuse map (set 2 PAL): OE(D1'..D7') = P8 * P9 * P11 Dn' = Dn (a plain buffer) /OEbuf = /( P4*P9*( /P8 + /P11 ) )

How it works

The PAL turns out to be a plain tri-state buffer — every output is its own input (D1'=D1, D2'=D2…). It does not do the swap. The scramble is in the '245's cross-wiring; the PAL just picks which buffer drives the CPU bus:

pin 19 (D1')  OE = P8*P9*P11   out = P1       pin 15 (D5')  OE = P8*P9*P11   out = P5
pin 18 (D2')  OE = P8*P9*P11   out = P2       pin 14 (D6')  OE = P8*P9*P11   out = P6
pin 17 (D3')  OE = P8*P9*P11   out = P3       pin 13 (D7')  OE = P8*P9*P11   out = P7

pin 12 (/OE of the '245)  =  /( P4*P9*/P11  +  P4*/P8*P9 )
pin 16 (not connected)    =  /( P4*/P8*P9*/P11 )
CycleP8 (/M1)P11 (/WR)Who drivesResult
Normal data readhighhighPAL enabledunchanged
Opcode fetchlowhigh'245 enabledgroups swapped
Writehighlow'245, DIR = /WRCPU data out to memory

Note the economy against the dirty board: because the '245 is bidirectional, one chip covers both the swapped read path and the write direction. The dirty board's '367 only goes one way, so it needs a '244 alongside. Same PAL, same trick, one chip fewer.

The stacked ROMs are not the decryptor

Two D27128s are piggybacked in the ROM socket with a wire running from the LS08 to a lifted pin. That looks like a decryption trick — and it is a real one — but not here. The two devices hold the two address halves of the same program, byte for byte:

lower (bottom) ROM  ==  cm04.9m[0x0000:0x4000]     0 bytes differ    CRC DF8F4E9A
upper (top)    ROM  ==  cm04.9m[0x4000:0x8000]     0 bytes differ    CRC ACA99905

They are an ordinary 27256 substitute, the wire carrying the A14-derived select that picks between them. Their contents are the plain encrypted program — descrambling is the PAL's job. The dirty board makes the point by contrast: it has a genuine AM27256DC in that socket and no stack at all.

Byte 0 of the bottom ROM reads 3E raw (3E 04 32 00 E0… = LD A,4 / LD (E000),A at the reset vector), so this board's decryptor passes the first opcode fetch through untouched, exactly as Capcom's chip did. Spare images for both halves live in MAME/Extracted/.

Provenance

photographed The on-board PAL16L8 (silkscreened), the LS245/LS08 above it, and the piggybacked ROM pair with its select wire.
measured PAL equations from the dumped set-2 device (CRC BDBCAF02), the same architecture as this board; the 9M stack proven an address split by byte comparison against cm04.9m.
deduced The '245 B-side cross-wiring — undocumented, but forced by the logic: the PAL path is straight and bits 0/4 bypass, so the swap can only live there. Likewise the exact '08/'14 gate inputs, which MAME records only as feeding PAL pins 4, 8 and 9.


Commando reverse-engineering project · generated by Web/gen_variants.py