Saturday, 12 October 2019

Deconstructing Sega's System 16 Security - Part 1

Sega's System 16 was a new arcade platform introduced in 1986 as a successor to the earlier 8 bit Z80 designs Sega System 1 and System 2. The new system brought in many system upgrades including 16 bit Motorola 68000 CPUs and pioneering security.

Above all System 16 was one of Sega's most successful games platform seeing the release of countless epic games that form part of our collective childhood memories. Among my favorites titles are Shinobi, Golden Axe, Outrun, or Michael Jackson's Moonwalker to name a few, I bet you have yours too.

The platform got subsequent updates and revisions introducing improvements to base specs and integration of chips. The initial System 16A was released in 1986 followed soon by the more common System 16B in 1987, a later revision known as System 18 was introduced in 1989. Specs for all three revisions are as follows:

System 16A specifications

Main CPU: Motorola 68000 or Hitachi FD1089/FD1094 security modules @ 10 MHz
Memory: 16kB + 2 kB
Sound CPU: NEC uPD780C-1 (Zilog Z80) @ 4 MHz
FM synthesis sound chip: Yamaha YM2151 @ 4 MHz (8 FM synthesis channels)
PCM sound chip: NEC uPD7751@ 6 MHz
ADPCM channels: 3
Audio bit depth: 8-bit
Custom GPU chipset: 315-5011 sprite line comparator, 315-5012 sprite generator, 2× 315-5049 tilemap chips, 315-5107 & 315-5108 display timers, 315-5143 & 315-5144 sprite chips, 315-5149 video mixer
Performance: 12.5874 MHz sprite line buffer render clock, 6.2937 MHz sprite line buffer scan/erase & pixel clock
Display resolution: 320×224 to 342×262 (horizontal), 224×320 to 262×342 (vertical), progressive scan
Color palette: 98,304
Colors on screen: 4096 (unique colors) to 6144 (with shadow & highlight)
Graphical planes and sprite capabilities: 2 tile layers (row & column scrolling, 8×8 tiles), 1 text layer, 1 sprite layer. Dual line buffers, double buffering, 128 on-screen sprites, 800 sprite pixels (800.75 sprite processing ticks) per scanline, 100 sprites per scanline, 16 colors per sprite, 8 to 256 width, 8 to 256 height

Fantasy Zone System 16(A) motherboard

Note: a few of the initial System 16 games were released in what's know as Pre-System 16 hardware, this rare system looks pretty much like modified a System1 / 2 pcb.

Alien Syndrome. Pre-System 16 motherboard

System 16B specifications

Sound upgrades
Sound CPU: Zilog Z80 @ 5 MHz or NEC MC-8123 security module
PCM sound chip: NEC uPD7759 ADPCM Decoder @ 640 kHz
ADPCM channels: 8
Audio bit depth: 9-bit
Other features: 8 kHz sampling rate, up to 128 KB audio ROM and 256 samples

Video upgrades
GPU chipset: 315-5196 sprite generator, 315-5197 tilemap generator, 315-5213 sprite chip, 315-5248 & 315-5250 math chips
Sprite capabilities: Sprite-scaling

Wonder Boy III Monster Lair. System 16(B) motherboard

System 18 specifications

Sound upgrades
Sound CPU: Zilog Z80 @ 8 MHz
Sound chip: 2 × Yamaha YM3438 @ 8 MHz + Ricoh RF5c68 @ 10 MHz (8-channel PCM chip, remarked as Sega Custom 315)

Video upgrades
Graphics chips: Sega System 16B chipset, Yamaha YM7101 VDP
Colors on screen: 4096 (unique colors) to 8384 (with shadow & highlight)
Graphical planes and sprite capabilities: 4 tile layers, 1 text layer, 1 sprite layer with hardware sprite zooming, translucent shadows, sprites of any height and length.

Michael Jackson's Moonwalker. System 18 motherboard

Sega meets Hitachi

With the introduction of System 16, selected games replaced the main system 68000 CPU with secretive Hitachi branded device modules, these modules were Hitachi FD1089 revisions A and B, and a more commonly found Hitachi FD1094.

Pictured a couple of HITACHI modules used in Sega System 16 game boards

Most modules feature a sticker with a seven-digit code unique per game title and region. For arcade operators or collectors trying to replace these modules with a regular 68000 CPU or a different Hitachi module, this would result in a non-working game. A battery inside also plays a fatal role, losing its power renders the module unusable.

In combination with encrypted roms the modules provided Sega with a way to control piracy and stop unauthorized board conversions (when a game base system is reused for a different game).

Sega's work with Hitachi was no coincidence, at the time probably no other company in Japan would have the expertise, technology, and rights to be able to produce custom 68000 based modules. Early on Hitachi helped Motorola, the company behind the 68000 CPU, overcome critical manufacturing challenges and achieve repeatable production of the new CPU. In exchange Hitachi was allowed to second source 68000 CPUs under the Hitachi brand.

Hitachi's work with customer modules was not limited to Sega game systems, different modules for different customers were also produced over the years. Here's a few examples found on the net:

FD1095 a custom module close numbered to Sega's FD1094, its purpose or nature is unknown

Several HITACH FD modules found online

Some of these modules can be bought online at present time, in fact, IC supplier Kynix has an active listing selling Sega's FD1094 stock, to verify the validity of the listing I purchased a lot which turned to be right. The modules seem to be refurbished as some of them still contain valid game data and are visibly used.

FD1094 modules purchased from Kynix

Inside the modules

Over the next posts we will discuss the internals of the FD1089 and FD1094 modules, reveal their construction and facts of interest.

Stay tuned.

Sunday, 11 August 2019

Calling all Sony BVM 14F1 & 20F1 owners: Your CRT could be at risk of software death

The three chips pictured below found in the BC slot1 board contain key software at risk of preservation unless we act today.

IC3 is a 2mbit flash and contains the cpu code, according to the manufacturer datasheet it has a data retention guarantee of 10 years. IC107/108 are 256kbit eproms containing key system signals, their data inside will last 30-40 years depending on conditions.

If you would like to help preserve these please dump/read these chips and provide me a copy along with your CRT monitor model and year, BC board revision code, and software revision (menu->status). If you don't have a chip reader you can buy the inexpensive TL866II Plus from Ebay, IC3 will dump as AM28F020, and IC107/108 as any 27C256 eprom variant.

My monitor is a 20F1E from 2002, BC board rev A-1135-825-B, software rev 1.40. I have uploaded a copy of the content of my chips here:

UPDATE 8/13: Now moved to Github:

Thanks for collaborating in preserving such fantastic monitors.

Tuesday, 11 December 2018

Capcom CPS1 B21 chips in the wild

Do you own any Capcom CPS1 games with a dead or faulty graphics chip? UTsource is holding onto a large new original stock of B21 chips aka DL-0921. According to the listing the stock is at least 86000 units, enough supply for several lifetimes I guess.

To validate the listing I bought a couple of samples and the thing seems definitely real.

NOS Capcom B21 chips as purchased from UTsource.

Saturday, 8 December 2018

Sega System 16 / 18 / 24 / X Security Programming Guide

Dear all, after some lengthy testing we are happy to release full details on the security programing of the Hitachi FD1089 / FD1094 cpus used in Sega's System 16 / 18 / 24 / X motherboards.

This guide is the result of several years of work by a small group of arcade enthusiasts to unravel the secrets of the security implementation found in one of the most loved and popular arcade game platforms. Thanks to this work it is now possible to fully preserve most Sega 16 bit systems enabled with security as fully working unmodified originals.

Unlike previous projects this time we recommend the usage of a dedicated pcb to interface with the chips due to the high pin count involved in the programming.

Additional details of the inner workings of Sega's FD security modules will be published over time in this blog. Work on the earlier MC 8 bit modules used in some System 1 / 2 boards and sound of Sega 16 is still in progress and will be published when completed. 

Thanks to everyone who has helped make this a reality including all kind donors and testers.

Sega Hitachi FD1089 / FD1094 Security Programming Guide

This document will guide you through the basics of preparing your setup and testing the a clean desuicide method on any known Sega 16 / 18 / 24 / X board revisions using Hitachi FD1089 or FD1094 modules. You can find a pdf copy of this guide and code on the following link:

What's needed

Arduino programmer hardware

  • Soldering iron and solder


Assembling and preparing your Arduino programmer

This step is pretty straight forward, solder all the pin headers to your programmer pcb as well as the IC 64pin socket. The fully assembled pcb looks like this:

After the pcb shield is ready just sandwich it together with your Arduino Mega 2650.

Download and install software for your OS from
Select the right arduino board type before connecting your arduino to your computer. Tools -> Board -> Mega 2560.

Connect the Arduino to your computer by plugin the USB cable and choose the correct serial port in Tools -> Port. 

Open the ArcadeHacker Sega FD1094 or FD1089 .ino file in the Arduino environment. Compile and Upload the sketch to the Arduino unit.

Open the Arduino IDE serial monitor found in Tools -> Serial Monitor. Configure the two settings found in the lower right part of the serial monitor window as follows: Carriage Return and 115200 bauds. 

Close and open the serial monitor, you should now see the following text on screen. If this is the case you have successfully setup and configured your Arduino programmer. 

Programming security keys

Look inside the Arduino FD1089 or FD1094 code for the game you intend to program the encryption keys into the FD chip and uncomment the desired line of code. Only one game can be uncommented at any time, don't forget to comment the default blank game setting at the beginning of the list.

If the above was done correctly you should now compile and upload the program to your Arduino without problems. Once the upload process is finished open the serial monitor found in Tools. The program prompt should display the game you have configured. 

For this example we have selected "eswat" a System 16 game using the Hitachi FD1094 security module "317-0160". FD1094 security modules can be repurposed for any game and it is not required that a label in the cpu module matches the intended game security key to be programmed. This will not be the case with FD1089 modules as two different encryption schemes exist (FD1089A & FD1089B): A variants of the chip are only compatible with games roms for other A variants, and B variants for B games only.

Having inserted the module in the socket we can proceed to program the security keys by typing w and pressing enter. Make sure you replace the module battery if necessary before attempting a key load, a new battery will last at least 20-30 years so don't expect to have to repeat this often. Once the process finishes you can disconnect the Arduino module from your computer and remove the cpu module.

If you would like to verify that the contents of the cpu match the intended configuration loaded in your programmer you can perform a verification by typing v and pressing enter. This verification compares a 1 bit parity per byte calculated internally by the security module against the encryption configuration in your Arduino. 

WARNING: This verification procedure is 100% safe in FD1094 modules. Unfortunately this is not the case with FD1089 modules as the verification will delete the data inside your module, please do not attempt verification with any valuable FD1089 modules especially if currently undumped or not preserved in Mame. 

Final words

This is all there is to preserving your Sega FD1089 / FD1094 modules as working units, we hope this milestone will help you and the rest of the arcade community preserve your loved games as originals and stop the general discarding of Sega Hitachi modules. 

As mentioned in the opening of this post, a number of follow up articles in this blog will reveal the inner workings and curiosities of these artfully crafted security modules. 

Happy preservation. 

Tuesday, 5 June 2018

Sega System 16 Security Reverse Engineering

Dear all,

I'm glad to announce the successful reverse engineering of Sega's System 16 cpu security modules. This development will enable collectors worldwide preserving hardware unmodified, and stop the general discarding of Hitachi FD modules.

The project is right now involving external testers so expect further details and full disclosure over the coming weeks.


Project credits: Eduardo Cruz, Rockman (Pere ViciƩn), Digshadow, with support from Shinichiro Baba, Ricardo Fernandez-Vega, Andrew Welburn and other kind donators.

Wednesday, 30 May 2018

A Journey Into Capcom's CPS2 Silicon - Part 3

Welcome to the third and last post in the Capcom CPS-2 reverse engineering series, if you missed any of the previous post you can find them here:

Hunting Capcom's Secrets

For many years, finding how and where did Capcom hid away its security implementation has been a pending critical task for the arcade community. CPS2 systems running out of battery were rendered useless forcing collectors worldwide to perform board conversions or let go of their favorite games. 

Typical CPS2 3.6 volts battery made by Hitachi Maxell Ltd in Japan

The battery featured in CPS2 systems is found on the top B board, and it powers a grid that reaches all of the B board customs chips while the board is at rest. During normal operation battery drain is stopped and regular voltage is supplied.

Thanks to Capcom's friendly implementation, battery replacing is a relative safe operation as one is able to switch such battery without fearing instant game death. A capacitor found next to the battery is able to keep things running for a good few minutes until a fresh replacement is soldered. 

Battery voltage measured before distribution to one of the CPS2 custom chips

This grid and the fact Capcom pushes battery power to all custom chips in the board is a deliberate smoke and mirrors exercise in an attempt to deter any curious parties by multiplying the number of possible target chips. 

Earlier security implementations by Capcom such as Kabuki or CPS1 lack this grid scheme and just feature a direct correspondence between the battery and security chip target using it. 

Pulling the string

A clue as to where CPS2 systems hid security came with the introduction of B board revision 5 (93646B-5), from this revision on a little JST NH 6 pin connector was added featuring a number of known and unknown pcb signals. 

Previous to board revision 5 these signals have been found to exist at one of the large base connectors, more specifically base connector CN2.

CN9 as found in CPS2 B board revisions 5 and up

CN2 base connector at a CPS2 B board revion 4

Why would Capcom move these signals into an simpler and more readily accesible connector? If you think in terms of producing, distributing and maintaining tens of thousands of game boards, the move speaks loud of operational and logistics convenience.  Ever scalable, simpler and less expensive processes is a top of mind item for past and present organizations worldwide.

Still a relevant question remained over time: What was behind connector CN9? No game or board feature was known to make any use of it, even worst, any adventurous individuals messing around would quickly find out that playing with this connector ended up mysteriously killing the game. A clear indication about this connector being somehow related to the security implementation of the CPS2 system.

Behind CN9

A quick analysis of CN9 revealed the following findings:

Looking at the list above, pins 1, 5 & 6 carry well known signals involved in the most basic life elements of a game pcb: VCC & GND (Power), and /Reset. Without these it is materially impossible for a game to operate, therefore very relevant signals. 

The remaining pins 2, 3 & 4 don't seem to be driven as no signal is present during operation, most likely inputs with their purpose being unknown. Following the traces for these pins we quickly find them leading onto the adjacent custom chip DL-1827, and no where else. 

Eureka? Time to find out what's behind this IC.

CN9 pins 2, 3, & 4 interface with DL-1827 pins 131, 132 and 69

Inside Capcom's DL-1827

Microscope inspection of DL-1827 revealed a made to order gate array chip manufactured by Fujitsu, more specifically a CG24 series gate array model 692 built on a 0.8 micron CMOS process technology. More information on these chips and gate array technology available on the previous series post. 

Manufacturer marks inside Capcom DL-1827 

Further inspection of the chip logic revealed a shocking finding: DL-1827 is a mere middle-man making no use of such signals. In essence the chip verifies that the board is powered up and drives a passthrough for connector CN9 signals #2, #3 & #4 among several other. The target of such signals entering and exiting DL-1827 is revealed to be the adjacent chip DL-1525.

DL-1827 acts as a passthrough of CN9 signals onto chip DL-1525

The following chart below summarizes how CN9 signals travel until reaching out its destination at chip DL-1525. The analysis discovered that Capcom intentionally used chip DL-1827 to hide away the real security target in CPS2 systems.

CN9 signal journey summary

Inside Capcom's DL-1525

As discussed in the previous post, DL-1525 hosts inside a massive die measuring around 7x7mm in size featuring a majestic Motorola 68000 megacell core surrounded by a vast 3-layer gate array. Inside of this sea of gates one area in particular hosts a large section of memory registers used to store some configuration settings and the game encryption keys. 

A total of 158 bits (1 bit per memory register) are chained together in a serial train to compose the memory block used as part of these settings found in CPS2 security.

DL-1525 Motorola H4C057 class gate array, memory dedicated array area highlighted.

A closer look of the area shows the structures identified as memory registers.

Group of gate array memory registers highlighted in purple and green.

Below, verification of such structures in the simulator reveals the memory registers as D type flip-flops. Top right of the image: 20x chip gate array area capture of a flip-flop memory register.
Top left and bottom images: logic simulation for verification purposes.

CPS2 DL-1525 gate array D type flip flop overview and simulation

Example of how one of the CN9 signals enters the DL-1525 chip: Bottom left in yellow CN9 #3 enters DL-1525 through pin 9 and is driven through a buffer for signal amplification purposes. After that the signal goes straight into the first memory register enable input, then connected to the rest of registers as a series of chains.

Overview of CN9 #3 signal entering DL-1525 through pin 9

Structure of the memory

The 158 bits used in CPS2 security configurations are structured in 4 differentiated blocks. One of them is dedicated to configuration settings while another three contain specific encryption information such as the pair of encryption keys.

From the outside configurations are stored in the chip via serial a protocol in bit reverse order, while the system inside access the information in full parallel mode (all bits at once).

Example CPS2 internal configuration for the game sfz2alh 

As displayed above a number of bits in the first block are of unknown purpose, from here i'd like to invite any brave readers to venture in finding their exact use and functionality.

All information regarding how to write CPS2 security configurations can be found here.

Closing words

Working on unraveling the mysteries behind the CPS2 security implementation has been an amazing challenge and journey for me. I'd like to thank every person that has participated, helped or backed the project in any way, specially to those deeply involved: Artemio Urbina, Ian Court and Digshadow.

The arcade legacy still has a great number of preservation challenges waiting to be addressed that will keep us entertained for while. I look forward to share new and exciting projects with you in the near future.


Sunday, 4 March 2018

Is Your Gaming CRT Exposing You to X-Rays?

Motivated by this discussion at UKVAC I decided to run a little experiment to find out if your typical gaming CRT leaks any measurable X-rays. Tan while having fun? Let's find out.

Test Setup 

My setup involved testing three tubes in my collection used from time to time for testing arcade pcbs, retro consoles, as well as micro computers. I believe these models are also commonly found among the gaming community and they should be somehow representative.

In front of each tube an X-ray sensor is placed at different distances: 3cm, 30cm, 60cm. X-ray activity is sampled during 180 seconds during each run, then compared against ambient readings (tube turned off).

Initially the X-ray sensor is left to warm up for a good 10 minutes to obtain constant ambient reads.


Sony BVM-20F1E

Toshiba A68 CRT (NANAO MS9) on a New Astro City cab

The Results

I'm afraid to break the news but... there's no such thing as a free tan while retro gaming. At no time any of the tubes tested presented any abnormal sensor reads indicating the presence of X-rays. To put things into perspective I have included a table below comparing the different scenarios together with reads of the sensor exposed to radiation from a controlled x-ray source.

I'm no expert on this matter, but even if the energies inside the tube are high enough to produce X-rays, the glass in your CRT has lead in it to block those from reaching you. Perhaps someone with enough expertise could confirm these assumptions.

Happy safe gaming.