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.

• System 24 hardware notes
• V-Sync timing diagram (PNG)
• Scanline timing diagram (PNG)
• Horizontal and vertical timings (ODS)

News (10/20/12)

Here's the current version of the fdtool program which is used to work with and manipulate FD1089 tables and key data:

• fdtool-102012.zip (Windows binary and source)

• Search through a table set to find a LCG seed that can generate the tables.
  If the tables are damaged or incomplete it can usually still derive a likely candidate for the seed, it just won't confirm it as being correct.
• Generate a key file from a LCG seed and list of encrypted code/data memory ranges.
  This is for building keys where we know the seed but haven't dumped it, so the encrypted code/data ranges have to be guessed.
• Generate a table set from a key file, mainly for validating keys.
• Turn a directory of old-format individual table files to a single file.

The dumping hardware design files and control program will get released next. I'm using it to get a better idea of how the 68000 runs on a cycle by cycle basis, but the hardware needs some slight modifications to fully enable this type of clock control. Once that's done and tested it will be ready for the public.

Old News (10/13)

I recently acquired some PCBs from Sega's "Caribbean Boule" (1991), a roulette game for eight players with electromechanical components. It's an interesting mix of old and new technology spread out over thirteen boards:

• Eight satellite boards that manage player inputs, audio, and drive their own medium resolution monitor.
• A video board which generates low-resolution video for a rear-projection television that all players can view.
• A game board that has a huge bank of TOSLINK fiber optic connectors and UARTs to network everything together.
• Three smaller PCBs to drive an operator's control panel, lamps, and relays.

The satellite boards are labeled "System M1" (1990) but have no relation to Model 1 in terms of having 3D capabilities:

• 315-5292 tilemap chip with 64K of video RAM and 512K of tile RAM.
• 315-5294 video mixing chip and 16K of color RAM.
• 315-5242 color encoder; outputs 5:5:5 RGB.
• 315-5296 programmable I/O chip (x2)
• 315-5338A I/O and serial comms chip.
• 68000 with 16K work RAM
• Z80 with 8K work RAM
• YM3438 FM sound chip

The design reminds me of Model 1 which came out a year later; the serial-to-memory I/O chip that I thought was introduced with Model 1 showed up here first and the old System 24 parts are re-used in a similar way. I always find these intermediate steps beteween hardware platforms intriguing and this board fills in some blanks for me.

The new I/O chip (315-5338A) has a pretty cool mode where it can be operated remotely over a serial connection. In Model 1 this was used on the main board, the chip communicated with the comms board and stuffed data into dual port RAM for the V60 to read, all without any CPU intervention. Here it is used in a similar way, controlling the 7-segment LED drivers and inputs on the operator's control panel PCB without needing a Z80 or other CPU/MCU to handle those tasks.

The game board is from 1989 and has no system designation. It looks a lot more like older Sega board designs compared to the satellite board:

• 68000 @ 12.5 MHz, 32K work RAM
• Z80, 8K work RAM
• YM2151 FM sound chip, uPD7759 ADPCM sound generator
• 315-5338A I/O and serial comms chip.
• Bank of 11 UARTs and TOSLINK connectors.
• 8255 PPI for I/O

The video board seems to not do much; hardly any of the sprite ROMs are populated. It uses the same communication board as other X-Board games. The sound hardware isn't used and no sample or Z80 ROMs are specified in the ROM list. Going by the diagrams it connects to a RGB to S-Video converter, as the projection monitor only has S-Video input. Throwing in an entire X-Board just to drive a standard resolution display seems like overkill, but it's the only thing with a fiber-optic comms board Sega made at the time.

Can we emulate this game? Well we still need the video board ROMs dumped, but perhaps communication can be faked so that the rest of the system works. Peformance should be an issue with 9 displays, 11 68Ks, and 17 Z80s. I can't even begin to imagine how incredibly costly this thing must have been when it was new. I guess there is good money in gambling games because it must have cost a small fortune.

The FD1089 work discussed earlier is nearly done. I finished a program that can search for LCG seeds and used it to generate a complete key for sjryuko, to replace the partial key we had in MAME. Together with the dumping circuit any FD1089 can be preserved now. There's a lot of partial dumps in MAME so if you can help out and loan a FD1089 to be read out, please get in touch.

Thanks to ShouTime we finally got Last Survivor dumped and emulated. It's a good reminder that there are still working FD1094 CPUs out there, and we do need to get them dumped as soon as possible. Between this and Bullet we have had good fortune finding rare games, so who knows, maybe we'll find Charon next.

While FD1094 dumping has been a plug-and-play affair, we've never had a good solution for the FD1089. We recently acquired a FD1089-based game to be redumped to complete the partial table set that's already in MAME. This was a good opportunity to approach the FD1089 again from a new perspective, given the last work I had done on it was back in 2005. Here's the dumping circuit I developed:

This is a variation of the custom Z80 dumping board I made for the Free Kick-type CPU modules. There's a lot more chips underneath the top PCB, and the empty sockets were for some alternate ideas that I ended up not needing to use.

The new automated dumping process works like this:

• Reset CPU 256 times and present each possible value for the low and high words of the PC vector, then force a bus error during the first instruction fetch. The decrypted PC is pushed to the stack and captured. This generates encryption tables for addresses 4,6 that can be used for 0,2 and 10 through 16, which is enough to encrypt our own PC, SP, and a short fragment of code.
  
  
• Cycle the stack pointer through all addresses and execute the instruction "MOVE.L (A7), (A7)". This allows two adjacent data words to be decrypted and captured, so tables for the entire data space can be dumped.
  
  
• Cycle the stack pointer through all addresses and execute "MOVE.L -$12(PC,A7.L), (A7)". This allows two adjacent program words to be decrypted and captured so the entire program space can be dumped.

Being able to control the 68000 at the bus-cycle level makes a lot of interesting behavior readily apparent. You can see the prefetch mechanism, including dummy fetches that result in unused data, and the out-of-order stack writes during exceptions. Plus a lot of invalid instruction encodings don't cause exceptions at all, which isn't what I expected. Rather than being useful undocumented instructions I think they are just aliases for other valid ones. Anyway it would be worthwhile to look into this further.

News (7/7)

Quite a lot of progress has been made with the Data East cassette system dumping efforts. Many different dongle types have been examined and supported, and currently all known dongle types can be dumped. Software has been developed to extract the PROM data out of dongle dumps and to perform detailed analysis of the decryption features of various dongles, and to determine internal jumper settings to see how a dongle is configured without even opening it up. A few games have been added to MAME recently and it's likely there will be more additions in the future, as we keep finding tapes and dongles to dump from generous donors.

Thanks to Guru I have a Bubble System board to work with, and I made an expansion card to run software other than the BIOS and provide USB communication to a PC. It also has a pass-through connector so the RAM cards that fit in the expansion port can still be used.

The Bubble System MCU controls the bubble memory, watchdog, and system reset functions. It seems to reset the system very aggressively and it has been hard to write software that keeps the MCU happy long enough to start reading sectors of bubble memory data. The board I have has some faults, so there could be a number of problems contributing to this behavior. Regardless, I've been able to run test programs on the Bubble System and probe the various memories, registers, and the bubble memory interface to learn more about how it works. I think it will definitely be possible to extract all the game data in time.

I've dumped an alternate version of Free Kick and Exciting Black Jack. Free Kick was an older version (1987.9) which the two bootlegs were derived from, so all known version of the game are now dumped. Exciting Black Jack utilized the custom CPU module in new ways that lead to the discovery of more memory mode quirks and an external memory mode select. I've updated my notes about it here:

• Security module notes

The Data East cassette system uses a security dongle that is unique to each game. This prevents operators from duplicating a game simply by copying the audio data from a game cassette to a blank tape. There are several types of basic dongle designs, and each one has data that is specific to a particular game.

A 6502 CPU runs the BIOS and software loaded off the tape. It can exchange command and data bytes from a 8041 MCU that controls the tape drive over a serial interface. The dongle sits between the 6502 and 8041 and can modify, replace, or pass data through unaltered during communication. A loaded program can also interrogate the dongle for additional data unrelated to the 8041 or tape contents.

I've made a circuit that mimics both the 6502 and 8041 interface so all aspects of the dongle can be observed. Because some dongles also have a reset generator inside them that intializes the internal state, the dongle reader has a software-controlled power supply to force a reset condition as needed.

It has been tested successfully with a so-called Type 3 dongle. This dongle has a normal operating mode and a "PROM mode" where a 4Kx8 PROM can be read out sequentially. After a reset, values written to the data and command registers and data read from the command register are not modified. Values read from the data register have bits 6 and 7 exchanged, and bit 0 is the latched value from the previous byte that was read.

The 8041 normally uses commands in the 00-7F range and ignores higher values. This allows 80-FF to be used to send commands to the dongle that will not trigger any action on the tape drive. For the Type 3 dongle, writing Cx (where bits 3-0 don't matter) enables PROM mode. Now, writing any value to the command register loads bits 12-8 of a 12-bit counter and bits 3-0 are reset to zero. Reading the command register returns a byte from the PROM at the current address, then the counter is incremented by one. The counters wrap from offset FFF to zero. In this way the loaded program can read out the entire PROM content.

Oddly enough the 8041 interface seems to be disabled in this mode. Writing to the data register or command register will tristate the data bus, causing the 8041 to latch an open-bus value. Likewise, reading the data register returns an open-bus value as well. There are no resistors on the BIO-8 board or in the Type 3 dongle to pull the data lines into a known state, so the actual value that is present will fluctuate.

Perhaps after receiving the Cx command the 8041 knows to ignore all future communciation with the 6502. Once the power has been cycled the system and dongle will reset and normal operation resumes, with the tape drive being accessible again. Once I get some other types of dongles to experiment with I'll post an update about how they work.

Old News (1/6)

I recently dumped the internal ROM for Wing's "7 Smash". The ROM was trojaned in a similar way to Pinkiri 8 and other Wing games that are now emulated in MAME.

This board uses a HD647180 MCU (in a huge 90-pin SDIP package) with 16K of internal ROM and up to 128K of external ROM. The external ROM contains program code so it isn't particularly hard to get control of the system by inserting your own software into the ROM once you've made a NOP sled or identified the entry points.

To get the internal ROM data out I used my 8-bit EPROM emulator which can also emulate RAMs. The two red wires in the picture are used to tap into the system reset signal from the MB3771 and part of the glue logic which generates a write strobe for memory locations. This allows the trojan program to write back into emulator memory to store data. Once it had copied the internal ROM to RAM (and generated a checksum) I just had to download the emulator RAM and that was it.

If any more of these games come up in the future it should be fairly easy to get them dumped.

Old News (1/1)

Here's some Saturn and PSX info:

• Saturn Game Shark schematic (BSch CE3)
• Saturn Game Shark schematic (PNG)
• PSX Game Shark schematic (BSch CE3)
• PSX Game Shark schematic (PNG)
• PSX Gold Finger schematic (BSch CE3)
• PSX Gold Finger schematic (PNG)
• PSX Gold Finger PAL equations (PLD)
• PSX Gold Finger hardware notes
• PSX parallel port pin assignments (PNG)
• ROM replacement for PSX cheat device

The ROM replacement is designed to be used with an EPROM emulator connected to the flash memory socket of a PSX Action Replay or similar device. It functions as a loader for a small (~32K) program appended to the ROM, which is copied to work RAM at $80010000 and executed as a subroutine. The appended program can return to the caller to continue with the BIOS boot process if necessary.

The AR and most clones use a 78L05 regulator which is not sufficient to power an EPROM emulator, I had to replace mine with a full-sized 7805. The cheaper variants just use a zener diode to knock down 7.5V to 5V and have no real regulator, so more changes will be necessary.

I've been having a lot of fun playing the fan-translated version of Persona 2: Innocent Sin. The people responsible did an incredible job hacking up the original game for the rest of us to enjoy, and it's thrilling to think they are working on Soul Hackers next:

• Persona 2: Innocent Sin translation
• Game Shark codes