Charles MacDonald's Home Page

News (12/31/13)

Looks like I'd better make an update in before the year is over.

FD1089 dumping

The FD1089 key tool has been updated with a faster and more accurate method for generating keys from raw table dumps. Now it supports non-standard key data, such as the kind extracted from a FD1089 with a dead battery.

I also had a chance to rewrite the control software for the 68K analyzer board and optimize the dumping functions. It can extract a complete FD1089 table set in a few hours instead of several days. I've added framework for analyzing 68K behavior at a bus cycle or clock cycle level, which I used to look into a quirk of the FD1094 with more detail.

Back when the inital FD1094 research was being done I noticed the FC2-0 pins didn't seem to behave normally, but didn't have a way to examine this closely. These pins are used to indicate if a memory access is for program code or data. It turns out the FD1094 drives these low at all time (which is an undefined state) and only asserts them to indicate an interrupt acknowledge cycle. This makes it harder to track what the CPU is doing. It's not really a factor in terms of emulation or extracting table data, but it's an interesting security measure added to the hardware to make things challenging for bootleggers.

Old News (7/14/13)

I've been working on a few projects this month and now I'm shifting focus to work on some different things, so I wanted to do a quick update with the status of my efforts so far.

Data East 146 chip

Thanks to The Dumping Union I was able to purchase a "Super Shanghai Dragon's Eye" PCB. The board was designed by Data East for Hot-B and is mostly identical to other Data East boards of the same time period. This board needed PAL dumps and had some emulation problems in MAME prompting further investigation into the 146 protection chip. I made a few modifications to the board for finer control of the 146 and have been developing and testing a lot of trojan programs to figure out how the chip works.

I haven't gotten around to adding my findings to MAME and I won't have time to do so for a while, so I've decided to put up the relevant documentation. It's mostly complete and should be able to augment the existing 146 emulation to help Super Shanghai and other games.

I'd really like to do more work with the other Data East protection chips because they seem very similar to the 146. If anyone can help out with providing any of the 68000-based games that use these chips (such as Robocop 2, Rohga, etc.) maybe we can complete the emulation for them as well.

New PAL dumper

I've finished a new PAL dumper design. Many ideas from the previous 68000-based prototype have been refined and implemented in the new one, which had design goals of lowering cost and simplifying assembly.

Adding a proper ZIF socket and a software controlled power supply makes it easy to swap out chips when dumping, and allowed me to dump a box of 60 PALs in about an hour. The control software has more exhaustive tests to identify and confirm registered devices so you can easily tell how GAL chips are programmed and how they should be dumped.

This version supports 20 and 24-pin combinatorial devices and dumping of 20-pin registered devices. I've finished the new combinatorial dump analyzer, and am working on adding more devices to the registered dumping software. Then I can start work on the analysis program to convert registered dumps back into human-readable logic which should be quite a challenge. Even if that proves too troublesome, we still have a way to preserve all the data in registered PALs now, and the analysis software can follow at a later time.

Old News (6/16/13)

I've updated the Sega System 24 hardware notes with some new findings and corrections to the previous version.

Old News (6/12/13)

PSX memory card research

I've been doing some research on PSX third-party memory cards to find out why they have compatibility issues with the PS2 and PS2 slim consoles.

Card overview

A typical memory card consists of flash memory and a microcontroller that transfers data to and from the system. Cards have a fixed capacity of 128K which is divided into 16 blocks of 8K each. One block is reserved by the system, leaving 15 blocks left for game saves. As the storage size is fixed, the system doesn't understand cards that have more or less memory available.

The PSX CPU has one serial channel that goes to both ports 1 and 2, where each port has a joystick connector and memory card connector. Each port also has a unique control line that indicates if data on that channel is for the joystick or memory card. This means both joystick data and memory card data are present on the same bus.

The memory card and joystick connectors provide 3.3V for power and 8V for auxilliary power. The latter was used to power the rumble motors in Dual Shock controllers, but was never used by any official Sony memory card products.

Third party memory cards

These cards use standard flash memory (29EE010,020, AT45DB081A) and a often a PIC microcontroller (PIC16C64). Many of then use 5V parts directly connected to the 3.3V serial bus of the memory card port. To power these parts, the 8V auxilliary supply is used by a regulator that produces 5V for the rest of the hardware. Some cards use dedicated regulators like a 78L05, others used discrete ones like a transistor-zener regulator or just a zener diode. Some of the cards with low pin-count MCUs also include 74HC165 shift registers to speed up the parallel flash memory to serial conversion, or use serial flash memory instead.

Banked memory cards

A solution to the 128K size limit was to use larger flash memory and segment it into banks of 128K, where each bank appears to the system as a unique memory card. Physical switches on the card allow the user to select which bank is currently being used. Each time you change banks, the microcontroller in the card simulates a card removal and re-insertion event which notifies the system that a new card (bank) is present. To tell the user what bank is in use, some cards used a series of LEDs (one per bank), a 7-segment LED display, or a 7-segment LCD display.

Bank selection

Later card designs took advantage of the fact that the memory card and joystick share the same bus. The microcontroller would snoop the bus activity when the memory card was not being accessed and look for button combinations being made with the PSX controller. This allowed the microcontroller to switch banks in response to joystick input (typically Select plus L1 or R1 to decrement/increment banks) rather than needing a switch on the card itself.

This snooping function seems to only be designed for standard PSX controllers. If you use a PS2 Dual Shock controller, for example, you have to put it in digital mode for the memory card to detect button presses.

The PS2 replaced the old shared joystick/memory card interface with dedicated buses for each memory card and joystick port. This means there is no joystick data on the memory card port, and the joystick snooping function will not work. I don't think there are any trivial fixes for this problem, so cards that use the controller exclusively for changing banks will always remain in the last selected bank on the PS2.

PS2 slim memory card incompatability

A subtle change was made to the PS2 slim hardware that made many third-party memory cards inoperable. The 8V supply was removed from the memory card port only (not the joystick port) and replaced with an output that is 0V when the system is in PS2 mode (while booting, in the memory card browser, or when playing a PS2 game) and is 3.3V when playing a PS1 game. This causes all memory cards that use 5V parts to fail as the input voltage to the regulator is now too low to produce the proper 5V output.

The switching action also causes problems with cards that use the 8V line to power their LED or LCD displays, even if the rest of the card operates at 3.3V and is functioning correctly. These displays will remain blank in the memory card browser which makes managing PSX game saves more troublesome.

Thankfully there's a simple fix for this. The 8V supply is still present on the joystick ports and all you have to do is route pin 3 of the memory card connector to it, and disconnect the switched 0V/3.3V supply. Users may be reluctant to modify the PS2 slim console, and it seems like third-party accessory manufacturers were aware of this problem and provided their own workaround as follows.

A few third-party PS2 slim multitap devices make this correction and allow incompatible PSX memory cards to work again. There are also PS2 to PS2 slim multitap converters that make the same change. Not all third-party multitaps do this, and official Sony multitaps do not. Regardless you can still modify a multitap much more easily than you could the PS2 slim system directly.

One particular third-party multitap I tried ("4 Player Multi Tap PXII Compatible") had this design change and allowed the third-party cards to work. It also had an adjustable plug to work with both the original PS2 and PS2 slim, though the build quality is quite poor. Probably an ideal solution would be to buy an official Sony multitap and then modify it.

Compressed memory cards

Compressed memory cards are notorious for failing. After examining how they work, I can see why this is the case. A typical compressed memory card has two flash chips; 128K of primary storage and 512K or more of secondary storage. The primary storage is used exactly like it would be for a regular memory card. The secondary storage holds compressed 128K banks. The compression is done in software (by a PIC) and is likely something very simple like run length encoding that can be done in real time.

The unreliability comes form how the primary and secondary storage are used when you change banks. The microcontroller performs several steps during a bank change:

  1. Erase several sectors from secondary storage to make room for the current bank.
  2. Read all of primary storage and write it, compressed, to secondary storage.
  3. Erase all of primary storage.
  4. Decompress data from the newly selected bank and write it to primary storage.
Not only does this make changing banks take a significant amount of time, but it puts a tremendous amount of wear on both the primary and secondary flash memories. About the only thing you can do to minimize wear is to switch banks as infrequently as possible.

Flash memory has an endurance rating to specify how many times it can be erased and reprogrammed before data can no longer be reliably stored. I found that older flash parts from the late 90s and early 2000s had real-world endurances were much lower than stated, and as the wear increased, the memory took significantly longer to erase and reprogram. Sometimes several retries were needed before the changes would take hold.

So on paper the scheme seems like it should work if the chips really could meet their rated endurance, but I believe that in practice the heavy wear was making the chips fail much sooner than anticipated. This is what probably gave compressed memory cards such a poor reputation. Needless to say modern flash is much more robust with higher endurances so this isn't a problem anymore.

Old News (4/6/13)

I've been working on a System 24 project and decided to update the old hardware documentation. Almost everything has been tested that I can think of, including some unused features that games don't utilize. There's still a bit more work to do regarding wait states and rendering timings.

The V-Sync diagram shows how the composite sync output has the horizontal sync pulses inverted during the V-Sync pulse. The scanline timing diagram shows the timing relationships between different events in units of pixels. If possible, I'll try to get more updates done this year.