Old News (10/12)

Getting a bunch of PCBs to work with in the next few weeks: three CPS-2 'B' boards (more on those next update), Shanghai for HD63484 tests, and a Quartet 2 board for my Sega addiction.. err, collection.

I'll continue my CPS-2 research once the other games arrive. One of them has no battery so I can skip the annoying encryption and run tests directly, which will be a huge convenience. I think right now all the useful data that can be extracted from xmcota and pzloop2j has been obtained.

I acquired a Virtua Fighter boardset a while ago and am tracing out the board connections to figure out how everything works. Eventually I'd like to get my own code running on the system to investigate TGP functions and to document the Model 1 hardware, but in the meantime just figuring out the organization of everything is important. I ended up removing the V60 from a spare System 32 board to figure out the pin assignments for the QFP-variety V60 within a reasonable time frame, necessary for Model 1 work. The board is still functional, just needs a CPU now. :)

I adapted my System 32 software and USB loader program for the System Multi 32 and have been doing some preliminary tests on the system. It's a bit awkward swapping the JAMMA harness between both edge connectors to check the output of one screen or the other. The V70 is a lot faster than the V60 at just 4 MHz more, I think the 32-bit data bus helps a lot.

Old News (9/30)

I've been doing some research on the CPS-2 hardware in the last few months, starting as soon as the System 32 work was put on hold. I'll give a basic overview of the encryption, however I should point out I'm just elaborating on the findings that Razoola originally made, which are at CPS-2 Shock. As you can imagine the results of his prior experiments have been absolutely essential to this project.

The CPS-2 hardware uses a custom 68000 CPU running at 16MHz, though the effective speed is lower due to video DMA. Out of the 16MB address range, the lower 4MB is allocated for ROMs storing program code and data. The first 1MB of this area is where decryption is enabled, though the exact boundary under the 4MB point may change from game to game.

In addition to the address range check, there is a timer that expires after a certain amount of time has passed. When this happens, decryption is turned off and the 68K will execute code exactly as it is read from memory. A sequence of one or more specific instructions, changing on a per-game basis, will reset the timer and enable encryption again. The timer can be restarted after any duration from when it has expired.

The decryption logic uses bits A16 through A1 of the 68K address bus, meaning the encryption wraps every 128K. For each encrypted word at a given address there is exactly one unique output; in contrast to the FD1094 there are no disabled opcodes or 'blanked' data that resolve to the same decrypted value. Data read from the supervisor or user code space is decrypted (e.g. opcodes and operands) and data from the supervisor or user data space is not.

The size of a complete set of decrypted data for one game quite large, totalling 8GB - it takes forever to dump. There are no duplicate tables within a game's table set or between sets for different games, though I've only examined tables dumped from the two 'B' boards I have.

I've discussed analysis of the table data with a few other people and so far the encryption seems to be pretty tough to solve. As a result, I think progress will depend on additional help. If you have skill in this type of thing (strong mathematics background and familiarity with encryption) and would like to lend a hand, then please get in contact with me.

Working with the CPS-2 hardware has been challenging due to the large amount of custom parts involved. I designed a communications board with a USB adapter, DTACK generator, and interface to the CPS-2 video and peripheral bus to run software on it, as well as several adapters to replace the 16V8 GALs with more capable 22V10 GALs that have their own shared I/O bus.

Small update for some common questions:

• The two games I've dumped are xmcota and pzloop2j, which are both already emulated in MAME.

• The ETA for a complete table dump (65,536 files) is 9 hours, and it's fully automated. Sometimes the system locks up randomly and has to be reset which slows things down, this occured quite a lot for pzloop2j and not at all for xmcota. They have different types of B boards, perhaps that has something to do with it.

• Many people are suggesting to look at Street Fighter Zero and it's variants, as well as Rockman which had a less common CPS-2 release but is very similar to the CPS-1 version. The only thing that would be really useful is to find two games that are encrypted with the same or similar keys, so unless Rockman has an identical key as another game it's not that useful. I would be interested in getting data out of another variant of xmcota.

• The tables have been compared by 32-bit CRC, and apart from some cases where two very different files had the same CRC, there are no duplicates. If this isn't the best way to do it, I'm open to suggestions. Likewise they do not compress at all.

Old News (6/24)

I've been making a lot of progress with the System 32 hardware. Most everything has been documented at this point, currently I'm working on the mixer chip. It's responsible for combining all the display layers (five tilemaps, a bitmap, and sprites) based on priority and applying special effects such as blurring and alpha blending. I've also looked at the random number generator, which I'll discuss here.

The random number generator is a 16-bit register mapped throughout the $D80000-$DFFFFF range. Writing to it sets the seed value. It is clocked asynchronously rather than by access from the V60, so continually reading it does not produce an exact dump of the values it generates. Furthermore things like the V60's prefetch queue make it difficult to synchronize the CPU with running instruction sequences, so even the same code that reads the random number generator several times will have slightly different values depending on how quickly the V60 processes it.

For example, you could assume the mov.d (64-bit) and mov.w (32-bit) transfer instructions issue four or two back-to-back memory read bus cycles, respectively. If the random number generator was clocked at a slower rate, mov.d would capture more data than mov.w does when they are used repeatedly to dump the output. However the data read does not resemble any part of the data captured using mov.w, meaning that the random number generator is updated faster than the V60 can access in a best case situation.

One possible solution would be to cut the trace to the clock input (there are two of them, 16 and 8 MHz) on the custom chip that contains the random number generator hardware and connect it to a spare I/O port pin, allowing it to be manually clocked through software. I had done a similar thing on System 24 to determine how the timers were implemented, so it can work in the right circumstances. But the same chip also controls many other aspects of the hardware and this might prevent the system from running. It would only work if one of the clock inputs was used for non-critical functions as well as the random number generator. I've got two spare boards and may try this eventually.

Perhaps it is possible to determine how the random numbers are generated without having a sample of every possible state. I wouldn't mind hearing from people with some experience on this subject.

Old News (6/15)

Time for an update. I had some computer problems and decided to upgrade, which introduced more problems. But everything is up and running now.

I've been using Aaron's V60 assembler to develop test programs for the Sega System 32 platform. The video hardware seems to be a precursor of what's in the Sega Saturn's VDP1/2 chips, which makes it interesting to study but also quite complex. Thankfully I've done a lot of work with the Saturn in the past.

I picked up some related PCBs as well; two DBZ V.R.V.S boards (I can confirm that it is a terrible game, ironically these were conversions from Arabian Fight and Dark Edge) and I'm expecting a System Multi 32 "Title Fight" board to arrive soon.

For the latter I'm going to need an EPROM eraser to test my programs, can anyone recommend a good (cheap) model? Some of the ones I've seen are very expensive and are almost half the cost of an EPROM emulator which would be a better purchase.

Hopefully I'll get back to doing more regular updates, I've made a lot of progress with some of my other projects over the past few months as well.

News (2/20)

The PCBs for my PC Engine development board arrived last week and I've been working on debugging them since. Most of the problems seemed to be about how the HuC6280 handles a bus transaction when reading or writing memory, it's not nearly as simple as the patents would lead you to believe. The glue logic was implemented on a GAL22V10, which was a good choice as I've been reprogramming it a lot to tweak the design.

Once the hardware bugs are resolved, I'm hoping to do some serious work on TGEmu and my PC Engine documentation. I may release the design to the public domain if there is sufficient interest, though it's not that much cheaper compared to Tototek's PCE-PRO 32M Flash Cart. But a DIY project is always rewarding, I was pretty excited when I had Blazing Lazers running for the first time. :)

Old News (2/15)

Here's Alien Syndrome (FD1089A, 317-0033) decrypted and running:

Thanks to Steve Ellenoff for lending the Alien Syndrome CPU. Another great Sega arcade game that had a decent port on the Master System and Game Gear as well.

I also fixed a minor hardware problem with my System 24 mainboard and was able to correctly dump the table set from Super Hang-On.

Old News (1/31)

Recently the FD1089 CPUs for Enduro Racer and Super Hang-On were sent to me for dumping, from Thierry and Gerald. The table extracting software is standardized at this point so processing Enduro Racer was a snap, but for some reason I cannot get a full set of tables from Super Hang-On.

I decided to pick up a Super Hang-On boardset for doing more tests. It did not come with the original cabinet wiring or a manual, so I'm looking for sources on the connector pin assignments or possibly any leftover wiring from a Super Hang-On or Out Run cabinet. Some of the wiring diagrams from an Out Run manual match Super Hang-On, but the video board is different so it may not be 100% compatible.

I bought a Sega System 32 PCB and did some work reverse engineering the security board. It has a V25 CPU that uses a lookup table to substitute opcodes, and the address lines to the program ROM are swapped around. I figured out the address bus connections and got enough of the lookup table data determined for the security program to run in a stand-alone emulator.

Haze kindly added it to MAME, now Golden Axe II's protection is emulated instead of simulated. This was done just for the documentation aspect of MAME; the previous simulation code did the exact same thing. Gameplay is unaffected but the emulation is more complete than before.

I've been finalizing the design for a TurboGrafx-16 / PC Engine development board. It provides a USB interface to a PC to transfer programs, has 512K of flash memory, and 512K of NVRAM. The addressing decoding is flexible so programs can be stored in either or both memories, and "split" HuCard images can be executed out of NVRAM (up to 256K+256K max). I built a simpler prototype on a breadboard that worked fine, the next step is to get some PCBs manufactured after the board layout is verified.