Sunday 30 November 2014

Capcom Kabuki CPU - Part 1

Welcome to the second post in the Kabuki series of articles analyzing this security cpu in detail. If you haven't you can read the previous post here.

Who made Kabuki?

Kabuki was manufactured by VLSI Technology Inc, also known as VLSI or VTI, a company which designed and manufactured custom and semi-custom ICs. 

I assume their company name originated from the term "Very Large Scale Integration", a term referring to design and fab processes for the integration of hundreds of thousands of transistors into an IC.

According to Wikipedia, VLSI was an important pioneer in the electronic design automation (EDA) industry. It offered a sophisticated package of tools, originally based on the 'lambda-based' design style. VLSI no longer trades as it got acquired in by Philips in 1999.


During my investigation and using social networks I did reach out to several ex-employees, and was lucky to make contact with a person who ran operations within VSLI at the time Kabuki got manufactured (1987/88).

This person confirmed that the company had a Z80 product in their portfolio and remembered the company had designed and manufactured ICs for several Japanese game vendors. He referred to their Z80 as a "megacell" family product.


Cells and Megacells

One of the two popular design processes for semi-custom chips is known as cell technology. Back in the 80s VSLI Technology Inc became one of the early vendors of cell based semi-customs.

Think of cell based design as the way of defining primitive logic functions (AND, OR, XOR....) into a library for reusing and combining as many times as required in different designs via CAD design tools.

A standard cell NAND gate


According to VTI documentation from 1986, "Megacells" consisted in far more complex products than standard cells, just imagine a whole chip or controller design converted into cell format for combined usage with other cells.



The VTI Z80 product was one of those megacells available as part of the VMC10 and VMC100 Series, 2-Micron and 1.5 Micron Advanced Megacell Family:

Portion extracted from a 1988 VTI megacell catalog

Besides Kabuki, VTI did more semi-custom Z80 products for other companies, here's an example of one found inside a music instrument, the SCI Multi-Trak:

VTI Z80 semi-custom. Photos taken from www.tauntek.com/SCIMultitrak.htm


Kabuki CPU vs the standard Z80

Kabuki's main difference to any standard cpu is the lack of Dynamic Memory (DRAM) refresh. Standard Z80 cpus feature DRAM refresh on pin 28 that helps using dynamic memories with the same ease as static memories.

Dynamic memories consist of tiny capacitors requiring constant refreshing in order to preserve memory contents. The Z80 helped overcome this problem by offering an integrated memory refresh facility that simplified designs and reduced overall cost by requiring far less external circuitry.

Instead of featuring a memory refresh service, Kabuki uses pin number 28 as a power supply input directly related to its security features. Losing power on this input causes a loss of internal data inside the chip and bricks your game.


What this also means is that Kabuki cannot be used in systems that feature dynamic memories, at least not without the aid of external circuitry. 

One particular interesting behavior of Kabuki is that leaving pin 28 low or unconnected turns it into a standard Z80 cpu. A clear indication that whoever designed Kabuki wanted it to also be useful as a regular cpu.

Designing and manufacturing your own customized cpu is a very expensive business,  having the option to reuse Kabuki as standard Z80 stock could have made complete financial sense to Capcom back then. 

We now know Kabuki has physical differences, but what about at code level? Is Kabuki a fully compatible Z80 class cpu? 


Z80 Compatibility

Wondering how compatible Kabuki is, I hooked it into my old Amstrad CPC 6128 (uses a z80 too) and turned it on without any surprises. The computer worked and seemed to do its job without any issues.

Next was running Zexall, a powerful application commonly used by developers of Z80 emulators to test for emulation compatibility issues. Zexall is a great program that runs all posible Z80 instructions and reports any issues found. 



No surprises here either, running the Z80 Exerciser for several hours revealed no issues whatsoever. To all effects, at code level Kabuki is a fully compatible Z80 cpu. 



How Kabuki works

Thanks to the great work done by the Icer Addis and later the Mame team, Kabuki's encryption scheme is known and all games successfully emulated. It works by performing a series of bit operations consisting of bit swaps, bit rotations and xors.

The exact method as described by the mame driver:

"The base operation is a bit swap which affects couples of adjacent bits.
Each of the 4 couples may or may not be swapped, depending on the address of
the byte and on whether it is an opcode or data.
bitswap -> ROL -> bitswap -> XOR with a key -> ROL -> bitswap -> ROL -> bitswap
- if the byte is an opcode, add addr_key to the address
- if the byte is data, XOR the address with 1FC0, add 1, and then add addr_key"

The keys involved in the process are as follows and each game has a different key set:
  • For example, decode keys used by Pang:
    • Bitswap key #1 0x01234567
    • Bitswap key #2 0x76543210
    • Address key 0x6548
    • XOR key 0x24

Putting Kabuki under the logic analyzer revealed that at a physically level Kabuki must see or control at least the following cpu lines:

  • All data inputs, D0 through D7
    • Needed in order to see and decode data.
  • All address lines, A0 through A15.
    • Each byte decodes differently depending on the address.
  • The RFSH "refresh" line
    • Used as power input to maintain internal memory contents. When low makes Kabuki behave as a standard Z80.
  • The M1 line
    • Necessary in order to know when an op code or data is fetched. Kabuki decodes Op code bytes differently than Data bytes.
  • The RD "read" line
    • Needed to know when data read operations occur. Kabuki does not interfere with write operations, only decodes, does not encode.
  • The IORQ or MEMREQ line
    • Kabuki must know when IO operations occur as it does not interfere with IO reads or writes.


Kabuki being analyzed with a multi channel logic analyzer

The important questions

Question #1
What happens after Kabuki has lost power and its memory contents gone? After all memory is memory and it must return to a known state.  Do all decoding keys go back to 00? or perhaps FF? 

Question #2
How did Capcom program Kabuki? It's obvious that someone had to program each cpu during game manufacturing. 

Did they use an external programer attached to each cpu? This approach would require special logic inside the cpu and the manufacturing additional hardware (programming devices).

Did they use a special rom containing programing code?  This approach sounds the easiest from a manufacturing point of view, plug a rom, power the board and done, the cpu has been programmed. 

This last method would also imply a lot of complex custom cpu logic (eg: instruction decoding etc...) and use unused Z80 opcodes, we already know Kabuki is full Z80 compatible.

Question #3
Is it even possible to reprogram it? Some security ICs feature physical protections such as security fuses burned after programing. 


This is all for this week, thanks for reading and stay tuned for the my next post: A software attack on Kabuki.

Sunday 23 November 2014

Capcom Kabuki CPU - Intro

What do games such as Pang, Cadillacs and Dinosaurs or Block Block have in common?



Yes, they are all Capcom titles, but what i'm referring to is this thing:

The Capcom Kabuki Z80 CPU

Manufactured by VSLI Technology Inc, the Kabuki is a security enabled Z80 cpu used extensively by Capcom during the late 80s and early 90s.

Kabuki uses a custom crypto implementation involving an internal memory with a set of decryption keys in combination with external encrypted roms. A 3.6v external battery keeps those keys from being lost when the game isn't being powered

The obvious issue here: lose the power source and you will lose your game. 

Why did Capcom produce and use Kabuki? The one and only reason was to combat bootleggers, a widespread business practice back then that saw countless game titles being copied and produced by alternative companies without any rights or payments going back to the original manufacturers.

The security feature in Kabuki presumably tried to make things difficult for bootleggers in order to avoid open and simple copies of games from being produced.  

But did Kabuki accomplish its mission? 

This is a question that's hard to answer since there's known copies of most if not all Kabuki powered titles, therefore one could say in full confidence that Kabuki did not fully prevent game copies from happening, but probably helped reduce the amount of companies and/or individuals able to produce them.

The effectiveness of Kabuki as a business investment is probably a retrospective financial question that needs to be made to Capcom itself.  For us, the collectors and researchers in the post arcade business era, Kabuki represents the two sides of a coin, a very important piece in the arcade history that we need to preserve, but also a limitation to overcome in order to preserve fully working game titles today.

According to the Mame team this is the list of Capcom games known to use Kabuki:

Adventure Quiz 2 Hatena ? no Dai-Bouken  
Ashita Tenki ni Naare    
Block Block                            
Buster Bros
Cadillacs and Dinosaurs           
Capcom Baseball   
Capcom World              
Dokaben   
Dokaben 2
Mahjong Gakuen 2 Gakuen-chou no Fukushuu 
Pang 
Poker Ladies  
Pomping World 
Punisher                           
Quiz Sangokushi             
Quiz Tonosama no Yabou   
Slam Masters     
Super Buster Bros 
Super Marukin-Ban   
Super Pang (Japan) 
Super Pang (World)
Warriors of Fate                   
           
All these games use Kabuki as the main game cpu except for Cadillacs and Dinosaurs, Punisher, Slam Masters, and Warriors of Fate. These four titles use Kabuki only as the sound cpu in Capcom's patented Q-Sound technology. 

This blog post is the first one in a series of Kabuki articles that will analyze this security cpu in full detail, and share my research work and findings that successfully allowed me to reverse engineer this cpu and bring any dead Kabuki games back to life unmodified. 

What this means to you and the rest of the arcade community is full preservation of all Kabuki powered games as fully working factory originals.

You can read the next articles in the series here:




  • Part 1
  • Part 2
  • Part 3
  • Part 4
  • Part 5

  • Thursday 6 November 2014

    Hello World

    Welcome to Arcade Hacker, a personal blog about my experiences, research and curiosities on arcade gaming.

    Just like many of you, arcade games were an integral part of my early years and marked my childhood in many unforgettable ways.

    As an adult I continued the enjoyment thanks to the incredible work done by the Mame team, and by early 2014 got my hands on my first real arcade game pcb, my all time favorite Taito's Bubble Bobble. Many more game pcbs followed as well as endless learning and research about the arcade hardware and software world in general.

    Thanks for ready and I hope you enjoy my articles.

    Eduardo.