Old News (12/29)

Here's Action Fighter (FD1089A, 317-0018) decrypted and running:

Thanks to Thierry (aka ShinobiZ) for lending the Action Figher CPU and providing the ROM set.

The sprites and tilemaps are still a little off, but that's an issue with the video emulation (I re-used the Dunk Shot emulator for testing) and not related to the decrypted ROMs. I'm sure it will look fine in MAME. :)

This game was very difficult to patch in order to dump data, because it's startup routine locks up the System 24 board. I got around this by disconnecting the high order address lines and pulling them low so addresses accessed by the FD1089 were always from a fixed 64K segment of RAM. This prevented it interfering with the rest of the system, and allowed testing of different instructions sequences until the right one was found.

Old News (12/11)

Got Dunk Shot fixed, works fine now:

The weird thing is that it's a System 16B game but the video hardware seems to be a little different.

I developed a utility to encrypt a test program for direct use on the Dunk Shot FD1089A, and have confirmed that it cannot execute unencrypted code. So patching the original game code on a per-game basis to extract data seems to still be necessary, at least for the time being. This makes the process more difficult but certainly not impossible.

Old News (12/05)

Here's Dunk Shot (System 16B, 317-0022) decrypted and running:

Thanks to Dave Widel for donating the CPU, and ShinobiZ & COY for providing the original and bootleg Dunk Shot ROM sets.

This is the first FD1089A game that has been decrypted. While it it's encryption method is less complex, finding the right place to insert your own decryption routine is extremely difficult. This is because all data as well as code is encrypted (no vector table changes, hard to know where code starts/stops) and there are no direct instructions, which was the most important finding that led to the FD1094 being figured out. As eight of every 16 bits are encrypted, you have a 50/50 chance of identifying code sequences, which improves as the size of the search data increases.

A disappointing aspect of the FD1094 is that you cannot easily restore a non-working game. It's possible to manually put together an unencrypted ROM set from the original data and several decrypted program ROM images (one for each state used), but it is difficult to be 100% sure the result is correct and these kinds of hacks are frowned upon.

Luckily this is not the case with the FD1089A. While opcodes and data are encrypted, there is no state mechanism so the decrypted data is just two copies of the program ROM image, one decrypted as code, and the other as data. You could write these to a larger ROM and have the 68000 FC0 pin drive the high order address line to select the decrypted opcodes or decrypted data portion.

What remains to be seen is how difficult it is to decrypt other FD1089A based games. I was able to make progress with Dunk Shot because I had a bootleg set and could get an idea of the what the game code did, so it could be patched. For a game with no bootleg it's trickier since you can only make guesses about the game's program flow, what instructions are used at which addresses, etc.

If anyone would want to donate FD1089A / FD1089B CPUs for testing and possible decryption, please get in touch. I only have Dunk Shot (my Enduro Racer CPU is dead) and may be getting an Aurail CPU soon, but that's it.

I'll work on getting better screenshots, not sure what the game is up to currently.

Old News (12/03)

Thanks to everyone who helped identify the parts I needed assistance with. Mostly all PROMs, go figure.

It's still in an early stage, but here are my hardware notes for the Sega "X-Board" hardware:

• loftech.txt

Progress on the FD1089A/B is on hold at the moment, as I'm waiting for more CPUs to run tests on. Not a problem, just need to determine what the common points are between games rather than what's specific to Dunk Shot.

Old News (11/12)

I've been examining a board which appears to implement the FD1089A workings using regular TTL parts and some programmable logic. It's pretty old (1985) and finding information for some of the components has been difficult. If anyone can help out, I'm looking for information (datasheets, primarily pin assignments) for the following parts:

• Harwin M3-7643B-5 / Intersil M37643B
• Harwin M3-7649-5 / Intersil M37649
• Fujitsu MB7142E
• Toshiba TMM24128AP (just a 128Kx8 EPROM, need a pinout though)

Old News (10/29)

I've been able to decrypt a large portion of the game "Dunk Shot" which uses a FD1089A. It turns out the program ROMs from the bootleg dump (used as a reference to locate code in the encrypted ROMs) weren't completely bad, the decrypted data and opcodes are stored separately and in unusual locations within each ROM. There should probably be more data (about 1/3 of the original content is accounted for) but it was more than enough to get started with.

The FD1089A is fairly interesting: both code and data are encrypted, and a wider range of address bits seem to be used for the decryption (compare to FD1094 where the encryption 'wrapped' on 16K boundaries). Everything from the program space is encrypted identically, so using an instruction with a PC-relative EA mode allows you to read the PC/SP vectors, game code, interrupt handler code, etc. Thankfully no 'states' this time to deal with, as the FD1089A is very different from the FD1094.

One problem with encrypted code and data is that it's harder to determine where sections of code start and end. Also there are no 'direct' opcodes so it isn't easy to program the FD1089A at all. An advantage with Dunk Shot (and possibly other games) is that only bits $FC48 of each word are encrypted, the remaining bits are unmodified. So you can search for a sequence of data and get fairly good matches, the longer the search data is the more accurate the results are. For example longer instructions like 'move.l #imm32, $mem.w' are easier to find, and from there the unencrypted bits of the opcode can be changed to modify the EA mode to something more desirable. There's plenty of work left to be done, but some initial progress has been made.

Old News (10/21)

Should be a lot of FD1094's coming in the next week or two, that will make up for the lack of updates. I've still been doing plenty of tests with the FD1094 and dumping table data in the meantime, which is useful but not exactly worth discussing.

I ran some tests on the System 24 hardware to see how CPU performance is affected when one CPU accesses memory or a device on the other one's bus. The memory space is divided between the two CPUs as follows:

    Memory          Description     CPU
    000000-07FFFF : /ROM            A
    080000-0FFFFF : CPU A RAM       A
    100000-1FFFFF : /ROM            A
    200000-3FFFFF : /VRAM           B
    400000-5FFFFF : /COLOR          B
    600000-7FFFFF : /OBJ            B
    800000-9FFFFF : /I/O            A
    A00000-AFFFFF : /INTC           A
    B00000-BFFFFF : /EXCS0          A
    C00000-CFFFFF : /EXCS1          A
    D00000-DFFFFF : /EXCS2          A
    E00000-EFFFFF : Unused          x
    F00000-F7FFFF : CPU B RAM       B
    F80000-FFFFFF : CPU A RAM       A

The CPU that is waiting can resume operation as soon as the other CPU is no longer accessing memory. Even a slow instruction that takes many cycles to finish like 'mulu.w #$5555, (a0)' will only access memory twice, allowing the other CPU will run at full speed most of the time.

The worst case scenario is when TAS is used, which forces an interlocked read-modify-write cycle that will keep control of the bus for the entire duration of the instruction. In this case the other CPU will run at about half speed (5 MHz).

In practice the design works pretty well; CPU A would manage inputs, the disk drive, YM2151, and the timer-driven DAC. CPU B would manage tilemaps, sprites, and the palette and mixer chip registers. The only time any performance hit would occur is when CPU B had to access it's interrupt control registers (doesn't happen often) or when either CPU writes to RAM to communicate with the other one.

One other note is that if either CPU accesses a region of memory where DTACK won't be asserted, such as $E00000-$EFFFFF, both of them lock up.

I'm looking for datasheets for the ARM2 or ARM3 CPU (any clone parts too, not necessarily the ones made by VLSI), specifically anything that has pin assignments. I've already looked through the available ARM7TDMI and ARM610 documents.

Old News (10/10)

I've put up a page about the status of dumped and decrypted FD1094-based games, which you can view here:

FD1094 Status Page

Check it out and decide if you can help out with this project. I'll try to assemble a list of CPUs that are needed next.

News (10/09)

Here's Wonderboy III - Monster Lair (System 16B, 317-0085) decrypted and running:

Thanks to Thierry (aka ShinobiZ) for donating the Wonderboy III CPU and ROM board.

This version of the game runs on the original type of ROM board. It has a warning screen and a simpler test mode, so perhaps this is the older version of the two. I think now all varities of this game have been accounted for.

I recently had the chance to examine a program code dump from the 8751 used in Moonwalker. I couldn't find any good 8051 disassemblers, so I wrote my own. For those that are interested, here are the files:

• mcs51d-win.zip Windows binary
• mcs51d-src.zip Source code

Previous update:

Here's Flash Point (System 16B, 317-0127) decrypted and running:

Thanks to Thierry (aka ShinobiZ) for donating the Flash Point CPU and ROM board.

An enhanced Tetris clone, with familiar Sega elements like Fantasy Zone themed backgrounds and Flicky making a brief appearance. No label on this FD1094, the EPROMs used are EPR-12590B and EPR-12591B (note the 'B' suffix); can anyone verify which FD1094 corresponds to this set?

Previous update:

Here's E-Swat (System 16B, 317-0130) decrypted and running:

Thanks to Dave Widel for donating the FD1094, and zozo for dumping the program ROMs.

For those of you that are wondering, many Sega games had several revisions, each encrypted differently. There are two varieties of E-Swat, a whole bunch of Golden Axe's, etc. It's pretty much the same as the 317-0129 version I decrypted earlier, I would assume with some minor tweaks like bugfixes. Then again the CPU part numbers have no correlation to the release date of a particular game, so this could possibly be an older version.

I've been getting a lot of questions about decrypting System 24 games. I can't do this until I have a valid disk dump (or physical disk to try dumping) and a matching FD1094. I am using a System 24 board in this process, but that in itself doesn't make it possible to decrypt a particular System 24 game without the corresponding program code and CPU. Hope that's not too confusing. :)

Old News (10/06)

Here's Sonic Boom (System 16B, 317-0053) decrypted and running:

Thanks to Thierry (aka ShinobiZ) for donating the Sonic Boom CPU and ROM board.

A unique aspect of this game is that it only has one decryption state used in-game, apart from the vector fetch state. No compare instructions are issued, and the interrupt state is identical to the reset state. All of the exception handling code used for debugging is present in unencrypted 68000 code, though it's certainly for the development hardware as it writes to ROM often. So there is no way to get the FD1094 to execute unencrypted code, despite what this game seems to say.

Regarding screenshots: when I run out of things to dump or decrypt I'll fix the rendering code. ;)

The Sega USB link PCBs arrived yesterday, and work fine. There's a compatibility problem with System 18, apparently the 68000 cannot reliably execute code out of RAM in the old or new type of System 18 boards. This is probably due to the restrictive way in which the VDP controls the 68000 bus, which also competes for access from the 315-5360. The USB loader in ROM provides an interface so the PC can read/write memory, which provides a working if cumbersome way to test the hardware. I've been poking around the custom chip registers used on the Clutch Hitter / D.D. Crew ROM board this way to understand how it works.

Also picked up a Mega Play PCB, which is a very cool piece of hardware. I've traced out half of the PALs and will probably document the system after all this FD1094 stuff is over. It won't play Genesis/MegaDrive cartridges (I took the risk and checked :) and attempting to do so will not cause any damage. The BIOS isn't much fun by itself, so I need to locate some Mega Play carts now.

News (10/05)

Thanks to Dave Widel for donating the FD1094 used by this game.

Apart from some priority errors in the emulator it runs fine. Sprite banking is implemented in an odd way, I'll be getting a WB3 ROM board to soon to verify.

The last 'trick' used is to allow nested interrupts after changing the state within an interrupt. When an interrupt occurs, the interrupt state is selected (state $0300FFFF set earlier in the ISR is discarded) and the saved state from the original interrupt ($0071FFFF) is restored when RTE executes.

Given all that, it seems the state management works as follows: The FD1094 has an internal flag to signify interrupt occurance, and some kind of storage to retain one state. When an interrupt occurs, the interrupt state is selected and the flag is examined. If the flag is clear (no previous interrupts) the current state is saved, otherwise the saved state remains unchanged. When an RTE is used, the saved state is restored if the flag is set, otherwise no state change occurs.

Previously

Leave it to a 3rd-party game to try something really bizarre with the FD1094. Wonderboy 3 will do the following:

• Change a few states and run in $0071FFFF for the rest of the game.
• An interrupt occurs, automatically saving the current state and switching to the interrupt state.
• In the interrupt handler, change state with a new type of argument: $0300FFFF.
  This state is ONLY valid if the state outside of the IRQ handler was $0071FFFF.
  Otherwise the following code is decrypted incorrectly
• End with an RTE, which restores the state to $0071FFFF, not $0300FFFF.

This proves several things: state values other than $00xxFFFF are valid, state changes within the interrupt state will work, and RTE only restores the state used prior to an interrupt occuring.

What I find interesting is that the interrupt handler code is encrypted properly for the reset state, but the decryption logic knows to check the previous (post-interrupt, maybe a value temporarily stored in the FD1094) state when a compare instruction occurs, rather than the current one.

On the whole most Sega games are well behaved and don't do anything weird like this. After figuring this one out, I'm hoping to not come across any others. :)

Old News (10/04)

Here's Alien Storm (System 18, 317-0146) decrypted and running:

I'd like to thank Dave Widel for generously donating several FD1094's, which made decrypting this game possible.

This is the 2-player version of Alien Storm. One of my favorite games, and it's great to have it properly emulated at long last. It passes all the ROM/RAM checks and seems to be working 100%, with some emulator related graphics problems aside.

I'm looking for information about the System 16B version of Golden Axe, using a FD1094 with part number 317-0122. If someone can provide a description or scans of the ROM board, please get in touch.

Old News (09/30)

Here's Clutch Hitter (System 18, 317-0176) decrypted and running:

All the sprite garbage is from the protection chip for the same reasons described earlier. This was the biggest game dumped so far, it only used two states so getting it finished was pretty easy.

With Clutch Hitter done, I have decrypted all the games in my collection at this point. Next up is the System 16A version of Tetris which should arrive in a few weeks.

In the meantime I'll try to get the emulation fixed up and investigate the protection chip more.

News (09/30)

Here's E-Swat (System 16B, 317-0129) decrypted and running:

D.D. Crew pipes nearly all of the video data through the protection chip, so the game looks terrible even though it's running correctly. It also gets the address of some tables through the chip, which come out wrong and cause problems. The protection chip is programmable and has 16 registers that are updated during V-Blank, so it's not exactly simple. Given all that I figured I'd work on E-Swat in the meantime.

E-Swat has simpler protections, it uses the multiplier chip on the ROM board frequently and does some odd stuff with the compare chip, putting in opcodes like NOP, RTE, and examining the result. The emulator needs some sprite/tilemap fixes to get it looking correct, but it's basically playable.

The same technique used with D.D. Crew was applied to E-Swat. The game uses five states and doesn't do anything terribly complex regarding state changes. I was concerned as this game uses compare instructions normally, showing that a specific encoding of the operand is what triggers a state change. Otherwise the instruction can be used normally. Some of the protection checks are patched out at the moment, I need to run some more tests on the compare chip registers to see what kind of results E-Swat is expecting.

Old News (09/30)

Here's D.D. Crew (System 18, 317-0186) decrypted and running:

The graphics problems are an emulator issue, and not decryption related. This game has a custom chip on the ROM board that adds a layer of abstraction to the regular sprite and tile banking controls. It may also be used for accessing program ROM contents with data shuffled around as a form of protection. The VDP seems to be heavily used, getting that hooked up will probably make for more interesting screenshots.

I think this is why the bootleg D.D. Crew board had such a poor looking title screen, because the bootleggers just left out the VDP chip rather than copy it which would be a fairly difficult task. I'd bet the bootleg version of Alien Storm has no background graphics in the first person shooting stages for the same reason, even though the VDP setup code is still present.

I tackled this game in a completely different way compared to what was done with Tetris. Instead of putting fragments of encrypted code together, I decrypted the entire ROM in each state that the game used. The 68000 emulator was modified to keep track of the decryption state and switch decrypted ROM images as needed. If a state is ever selected that has no corresponding table, the emulator exits gracefully and tells me what to dump next. Because the game actually works, this shows that current assumptions about how the decryption state is managed are correct.

The upshot of this method is that you no longer have to identify all of the executable code in a game, just the states that are used. This can be determined by running the game in an emulator in the reset state, and dumping more data each time an unknown state comes up. D.D. Crew only uses 6 or so states, so analyzing disassemblies was all that was needed.

I'll try to get the graphics fixed soon. The banking/protection chip will hopefully not be a problem, I have several System 18 boards with the same part and can run tests on it. But that will have to happen later, right now all the System 24 stuff is hooked up and I'd rather focus on that.

Old News (09/28)

I finally got around to investigating the Tetris ROM check failure. It was a bug in the ROM loading in my emulator, thankfully. So there is no issue of the program code being able to examine itself, or anything else like that. As far as I can tell the decrypted version of Tetris now works 100%.

The 'junk' data at 3F0-3FB in the original encrypted ROM is a series of word-sized checksum results for the even and odd bytes of each word in a 256K block, with up to 768K being able to be tested. I've seen other games that have similar information there, now it's purpose is known. The bootleg version will always fail the ROM test as the checksums were not updated for the patched program. This may be the same reason why other bootlegs like shdancbl have ROM test problems as well.

Old News (09/25)

Sorry for the lack of updates, with the Tetris CPU battery dying I needed to dump table sets before the data was gone. Takes forever to do. Due to the large size (~600MB compressed, 5GB uncompressed) I can't really make these available for other people to look for patterns, etc. I'll try to think of a solution, though with the battery issues the validity of the table data is in question.

I found a dead FD1094 from Alien Storm to run tests on. It actually still works, most of the direct opcodes are available. I would assume they are decrypted in a fixed way, whereas the other values use the internal RAM as part of the decryption. Because of the corrupt RAM contents, there are only two types of tables I've seen before, instead of unique ones at every address.

I wrote a new, reasonably fast version of the table dumping software. It works entirely using direct opcodes with no reliance on encrypted data, so you can start dumping tables from any FD1094 without modifying the software. It also only resets the FD1094 once and doesn't rely on double exceptions to halt it, as it's been theorized that resets or other unusual behavior may cause additional drain on the battery, possibly as a tamper-proofing feature. A 16K block is provided for any state initialization (compare instructions or to enter an interrupt) so data from any state can be retrieved. It's been optimized as much as I can and the time it takes to dump tables is fixed regardless of the amount of state setup code.

I will be releasing a software package with documentation for how to build the Sega board <> PC link, which I have simplified into a USB-based two chip design. It's easy to make, cheap, and all you need is a device programmer to burn some EPROMs and a PLD. I'll be including the decryption programs and other code for System 24 software development. When I have the time, I'd like to write some example programs for System 16/18/C2/Mega Play as well, to go along with the System 24 stuff.

Update: Won a System 16 A-type Tetris board off eBay, I will be certain to replace the battery ASAP when it arrives. Should be interesting to compare tables to those dumped from the System 16B version.

For those of you who have the preliminary schematic of the Sega USB link board, there is an error in the wiring. Contact me for more information.

Old News (09/21)

I think I found the answer for why there's a single incorrectly decrypted word in Tetris, it looks like the battery is failing. I redumped some tables and noticed a few of the values came out as $FFFF that shouldn't. I tried putting the CPU back in the original Tetris board, and it doesn't work. At least this explains the results I was seeing and means the decryption technique was correct.

On the other hand, I was able to decrypt virtually all of the original ROM at the time, and can fill in any potentially incorrect spots using the bootleg. And I do have other working CPUs to continue experimenting with, so that's not a problem. Tetris was just convenient because it was such a small game and had a simplistic use of changing states.

Because the direct opcodes are always decrypted in the same way, I've found they can be use to set the initial PC and SP values. There's a chance this might allow test code to be executed on a dead FD1094 as there would be no reliance on the initial PC and SP values being decrypted correctly. It would only work based on the assumption that the direct opcodes are decrypted in a fixed way and the other encrypted values are decrypted using the internal data table.

That said, if anybody has a dead FD1094 module they'd like to donate, I'm certainly interested. :)

Further tests show there is only one state used for autovector interrupts. The level 1,3,4,5 interrupts all use the same state for decryption. I can't trigger level 6,7 interrupts on the System 24 board but I would imagine they work in the same way, and once I brush up on the YM2151 timers a little more I can try level 2 interrupts as well.

Only the RTE instruction will resume the previous state. Manually exiting the interrupt handler (e.g. move.w (a7)+, sr; rts;) doesn't revert states. If an RTE is executed when not in the interrupt state, it does nothing. This is true even if you change states with cmpi.l beforehand, RTE will not disturb the currently selected state. While in the interrupt state, if you cause a TRAP and RTE from that, the pre-interrupt state is reverted to, making the interrupt handler code invalid. In fact if you then RTE to exit the interrupt handler, you'll still be in the pre-interrupt state as the 2nd RTE does nothing. So it looks like there is only one level of state information that can be stored. I still need to check nested interrupts and executing cmpi.l's while in the interrupt state.

There was an error in the direct4.txt list, the last value isn't a direct opcode and should not have been included. While trying to determine the error, I noticed something very interesting. Here is a list of all encrypted inputs that decrypt to $FFFF.

• ffff.txt

There are two forms an opcode can have to specify a PC-relative EA mode:

    xxxx xxxxx xxxx xxxx : $003A - EA mode is (disp16, PC) 
    xxxx xxxxx xxxx xxxx : $003B - EA mode is (disp8, PC, Xn)

I've put up a Sega WIP page with most of the previous information in an easier to access format. New stuff includes some more data tables and general information updates.

An interesting problem came up; the Tetris ROM check fails. In theory the program can only read from the data space, and the data space is mapped to the unmodified original ROMs, so the check should pass. Perhaps there is a way for it to read from the program space after all, but that's just a guess. I'm currently trying to pick apart the ROM test routine to see what's going on.

The source of the failure may be from a single word which was decrypted as $FFFF but should be $0004 according to the bootleg. This word is in the middle of properly decrypted code so it's not a state issue.

I've been working on E-Swat and so far the techniques used for Tetris are giving good results. The game switches states normally, but also uses "CMPI.L #$imm32, d0" in a regular way to control program flow. I think only a specific encoding of the operand is what triggers a change, the games I've observed use it with an operand of #$00xxFFFF exclusively when the intent is to switch states. I guess it makes sense, so the functionality of the instruction isn't lost. Hopefully this won't manifest into anything too weird, I'd like to think the state issue is understood at this point.

Because removing/inserting the FD1094 is such a nerve-wracking procedure, I'm interested in finding a 64-pin ZIF socket. I've seen the green 3M/Textool ones, but they have larger rectangular pins that will not fit into a standard size socket. If anybody has some leads on distributors or where such a part is available, I'd like to know.

I've gotten some very generous offers of donating/loaning CPU modules. For now I just want to work with the games I have, but I certainly appreciate the support.

Redumped the tile ROMs from my Tetris board, here are correct screenshots:

I've been getting some requests to decrypt games. I can only decrypt games I have the CPU modules for, which are Tetris, E-Swat, Clutch Hitter, and D.D. Crew. And I already know I'l be looking at E-Swat or D.D. Crew next. :)

Some people want to know if getting the games decrypted will allow non-working protected boards to be fixed. In short, yes. The decrypted data is smaller or equal to the original ROM size, but is separate and would need to be merged in with the data portions of the original ROM. This could be done by playing the game in an emulator and automatically putting the pieces together. You'd have to play the game enough to ensure all data was accessed.

A hardware solution would be to have a plug-in board for the 68000 slot, with a regular 68000, decrypted code ROMs, and some logic to select the original set or decrypted ROMs based on the 68000's function code pins. This could probably be done very cheaply too, though across different Sega board types the 68000 is always in a different position with clearance issues around it, so a one-size-fits-all PCB layout might be tricky to design.

Ignore the tile/sprite display problem, I wanted to get the screenshots up ASAP rather than debug the emulator.

Images removed.

So here's Tetris, now decrypted, and seemingly works fine. The game cycles through a demo and the title sequence repeatedly without anything weird happening. The bad graphics are an emulator problem and has nothing to do with the game itself.

Putting the little pieces of decrypted code together is extremely tedious even for a small game like Tetris. Thank goodness I like Sega games enough to actually do this kind of work. The bit about trigging an interrupt to enter the new decryption state works and getting the VBlank interrupt handler code wasn't a problem.

My intention is to clean up my emu for further validation of Tetris (get the inputs working so I can actually play it, for starters) or possibly get the game running in MAME if that's doable without too much trouble. And pick another game to decrypt. :)

I'd like to thank smf, Razoola, Jonathan Wilson, zozo, and Chris Hardy for sharing information, ideas, and test suggestions.

An interesting problem has come up. I have been able to decrypt all of Tetris except for the V-Blank interrupt handler. Apparently the CPU has a state change when an interrupt occurs, and I'd imagine it restores the previous state afterwards. The interrupt handler doesn't execute a compare instruction, and basically all of the data from the first MOVEM operand to the last MOVEM operand / RTE pair is invalid. It's not the same state as when the CPU resets, I checked. So perhaps there is a unique state specifically for interrupts.

This isn't as bad as it seems; I can trigger a V-Blank interrupt on the other CPU to force a state change. System 24 allows CPU A to change the IRQ enable mask for CPU B, and a table could be used to generate a 'stop #$2300' instruction to enable interrupts and keep CPU B busy while waiting for the interrupt to occur. Hopefully this will work, then I can try running the game in an emulator and verify the data is correct (the disassemblies are all valid so far).

The other thing which now seems obvious is that prior compare instructions do in fact have to be executed, because the instruction itself is encrypted and depends on the previous state. This wasn't difficult to implement, I changed the startup code to execute all of the compares in sequence before decrypting the test block of code.

Previous update:

Great news, I've been able to sucessfully decrypt any 16K block from D.D. Crew. It should be possible to decrypt the entire game at this point. Because D.D. Crew is so large, I'm going to work on Tetris first.

The argument to the compare instruction has an effect the decryption state for all following data. Most of it's 32 bits do something, though there are plenty of settings that give the same decrypted output. All you have to do is make the FD1094 execute compare instructions as they come up in the code, and the rest of the data can be decrypted. From what I've seen the result is not cumulative, so just need to run the last compare instruction instead of all prior ones.

The catch is that because the decryption state can be changed by the programmer at almost any point in the game's code, you have to trace through the code which is a tedious process. D.D. Crew changes the state a lot but only uses the same few arguments, so one solution would be to decrypt the entire ROM multiple times with different compares being used, and then patch together the correct parts. Tetris only changes the state four times in the startup code and doesn't do anything afterwards, making it a better choice to work with.

What's really exciting is, assuming no other problems arise, the technique I'm using is applicable to any FD1094 module. There is no restriction on the source ROM size or the memory map (none of the original code is executed except for the compares). The only work that needs to be done for each game is to get the initial PC (which can be automated) and determine which instruction changes the decryption state, but from what I've seen in other bootlegs it's always the same one.

But before I get ahead of myself, I'll try working with Tetris and D.D. Crew to be 100% sure.

Today I dumped about 512MB worth of tables for D.D Crew and was able to decrypt a reasonable portion of the startup code using a much smaller subset of that data. Here's the valid part before the decryption changes, the entry point is $408:

    NOP                                        ; 000400 4E 71 
    RTE                                        ; 000402 4E 73 
    NOP                                        ; 000404 4E 71 
    NOP                                        ; 000406 4E 71 
    MOVE     #$2700,SR                         ; 000408 46 FC 27 00 
    MOVEQ    #$00,D0                           ; 00040C 70 00 
    MOVEQ    #$00,D1                           ; 00040E 72 00 
    MOVEQ    #$00,D2                           ; 000410 74 00 
    MOVEQ    #$00,D3                           ; 000412 76 00 
    MOVEQ    #$00,D4                           ; 000414 78 00 
    MOVEQ    #$00,D5                           ; 000416 7A 00 
    MOVEQ    #$00,D6                           ; 000418 7C 00 
    MOVEQ    #$00,D7                           ; 00041A 7E 00 
    MOVEA.L  D0,A0                             ; 00041C 20 40 
    MOVEA.L  D0,A1                             ; 00041E 22 40 
    MOVEA.L  D0,A2                             ; 000420 24 40 
    MOVEA.L  D0,A3                             ; 000422 26 40 
    MOVEA.L  D0,A4                             ; 000424 28 40 
    MOVEA.L  D0,A5                             ; 000426 2A 40 
    MOVEA.L  D0,A6                             ; 000428 2C 40 
    MOVEA.L  #$00000000,A7                     ; 00042A 2E 7C 00 00 00 00 
    LEA      $00000AF4,A0                      ; 000430 41 F9 00 00 0A F4 
    MOVEA.L  #$00FE0020,A1                     ; 000436 22 7C 00 FE 00 20 
    MOVE.W   #$000F,D1                         ; 00043C 32 3C 00 0F 
    MOVE.B   (A0)+,D0                          ; 000440 10 18 
    MOVE.W   D0,(A1)+                          ; 000442 32 C0 
    DBF      D1,*-$0004     [00000440]         ; 000444 51 C9 FF FA 
    CLR.B    $FFFFC0FF                         ; 000448 42 39 FF FF C0 FF 
    NOP                                        ; 00044E 4E 71 
    NOP                                        ; 000450 4E 71 
    NOP                                        ; 000452 4E 71 
    CMPI.L   #$0091FFFF,D0                     ; 000454 0C 80 00 91 FF FF 
    MOVE     #$43AA,SR                         ; 00045A 46 FC 43 AA 

Also, comparisons between the Tetris CPU tests and D.D. Crew CPU show all the usual similarities; the direct opcodes are the same, PC relative instructions are missing, decryption repeats every 16K, etc. No surprises which is a good thing, I'd assume all other FD1094 CPUs work in the same way.

A new finding is that within a 16K block, certain addresses (no relation to each other, seems random) have the same table output. So you don't get completely unique tables for every address within a 16K block. In theory this means a smaller set of tables would be needed per block, but there doesn't seem to be any apparent way to tell which addresses will decrypt identically.

The D.D. Crew decryption was done using tables from $10000-$12000. The initial PC and SP don't come out correctly, even though they should work with table data from offsets $10000-$10007. At least determining the entry point is pretty easy to do, not being able to decrypt it (so far) will not be a problem for other games.

I got around to processing the table dumps from $4000-$409C, which represents a fairly large chunk of data to look for common points in. Here are lists of the 'direct' opcodes, these are the ones that always decrypt to the same value at any address, and can be used for limited programming of the FD1094.

• direct0.txt
• direct1.txt
• direct2.txt
• direct4.txt

I noticed something weird when examining the frequency of decrypted values used. Out of 79 tables, each value was used 79 times except for $FFFF which occured 400681 times, because multiple encrypted values decrypt to $FFFF. (Ignore what I said earlier about other values being like this, that was from results generated from a more limited data set) The odd thing is that only in the first table dumped, there was a set of decrypted output that didn't appear in any of the other ones. The instructions were in this group were seemingly all of the JMP, JSR, and branch (Bcc/DBcc) varieties and a few illegal instructions.

The dumping program would fill in earlier locations with a NOP to advance to the next address rather than TRAP to the test address, so I think this was a result of the code path being one particular way for the first table, and then all remaining tables had one or more NOPs executed beforehand. Going by the what I thought was invalid concept of a processor state being involved, this would show NOP (or maybe any of the direct opcodes) reset the state in a certain way. And that multiple NOPs didn't advance the state any further. Confusing, to say the least.

After some discussions with other people, I think the state concept isn't valid. Interrupts and program branching, such as loops, would modify the state unpredictably.

Another idea is that the prefetch queue contents could have an effect, which fits what I'm seeing better, though again interrupts would be an issue due to the prefetch queue being flushed and reloaded with different data. I had tried dumping several tables while modifying data after the test instruction and their contents were always identical.

As the front page is getting a little messy, a summary of the current findings is available here:

• summary.txt

In a way this puts things back at square one for figuring out exactly what's going on with the decrypted output changing, but at least some ideas can be ruled out.

I think the decryption logic maintains some kind of internal state which is modified as instructions are executed. I tried running the Tetris ROM through the CPU, decrypting a word from each location in the source ROM (from about $0412 to $6000), and examining the output. From the 'direct' opcodes I can see the proper data is coming through, but the opcodes for the encrypted data is all wrong. For example:

         bootleg    original   decrypted       instruction (bootleg)
    7fe: 30d9       a437       e142            move.w (a1)+, (a0)+  ; wrong
    800: 51c8 fff8  75ba 8b2a  e02a 8d5d       dbra d0, $7fa        ; wrong
    804: 4e75       0e75       4e75            rts                  ; correct
    806: 4e71       0e71       4e71            nop                  ; correct

    Bootleg (code moved around)

    414: 46fc 2700       move.w #$2700, sr
    418: 0c80 0052 ffff  cmpi.l #$52ffff, d0
    41e: 7000            moveq #$00, d0

    Original

    416: 06fc ff59
    41a: ef02 ef97 013b
    420: d32f

    Decrypted code

    416: 46fc 2700       move.w #$2700, sr          ; correct
    41a: 0c80 0052 ffff  cmpi.l #$52ffff, d0        ; correct
    420: c870 4761       and.w ($61, a0, d4.l), d4  ; wrong

The speed problem was fixed by a great idea from Phill. A TRAP instruction is put at the entry point, which goes to a PEA #$imm32 instruction to store decrypted immediate data to the stack. These are the 'direct' coded instructions that decrypt the same way at any address and regardless of the CPU state. The other vectors are set up to double-fault the CPU by causing two address errors, which keeps the CPU under control after executing the PEA. All of the startup code can be bypassed, so a complete table of data can be dumped in a few seconds instead of several minutes. At least it's easy to get table data from nearly any address now.

The other cool thing is that by halting the CPU this way, the initial PC of any FD1094 can be stacked and retrieved to give a starting point for patching, assuming the initial SP was also set up to a valid location. At some point I'll do this with E-Swat and D.D. Crew to make sure this works as expected.

So the question is, how much of the prior execution details are remembered? Probably not much. Chris Hardy kindly provided scans of two bootleg boards that implement the FD1094 decryption logic in TTL for Wonderboy 3. These have a 2K table of fixed data for the decryption hardware, and some latches and two flip-flops. The latches seemed to be more for the data table access, so that leaves 4 bits of 'state'. I'm not saying this is a fact, just a guess that fits what's currently known.

This finding also backs up the results of other tests I've done: for example any moderate patching of the startup code causes later encrypted code to come out wrong. Jumping to small encrypted code fragments in certain situations causes a lot of A-line, F-line, and illegal instruction exceptions. The decryption hardware is producing different results with the same inputs.

After hacking up the PC client software to automate downloads, I dumped tables from $4000 to $409C. It's about 3.7MB compressed, if there is any interest I will make it available.

At the very least it is nice to have a more solid idea of how the FD1094 works, even though this project hasn't resulted in any decrypted games yet. I'm open to any suggestions about how to proceed. :)

I've been getting some good tips and ideas from people. I modified the way data is captured using a shorter 'move.w #$imm, d0' instruction so data can be decrypted without needing tables for two adjacent words. Then a TRAP instruction can be placed after the test code to jump to a code fragment that stores D0 to memory. Currently the decrypting code works fairly well, and it takes about 5 minutes to get all the data from a single location. This is mainly because resetting the CPU makes it go through it's startup code each time before the first TRAP can be taken to the test code.

This allows data following the first decrypted location to be decrypted too, I've done about 8 sequential positions now. At some point I'll come up against the code fragments used to do the test write and result store, but I can relocate those in the earlier decrypted range of data. The real problem is time and storage; for the first issue I can try to automate the PC-hosted program to dump data, look up the opcode from the resulting table, and proceed with the next word. The table data should amount to 1GB (table size is 128K, 8K positions to test) which is too much for me to put at my website for interested parties. :)

Because the area being decrypted starts later in the ROM, you'd think the earlier data would be unrecoverable. But since the decryption wraps on 16K boundaries, I can just decrypt the first few hundred bytes of the next 16K to get the tables needed to decrypt the earlier parts. In theory, of course, as this is based on current assumptions.

Stability is an issue because the FD1094 thinks it's in a System 16 environment and tries to do things that don't agree with the System 24 hardware when booting up. This can cause lock-ups, which would interrupt the process if it could be automated.

On another subject, does anybody have a scan of the PCB for a Mega Play cartridge? I should be getting a Mega Play PCB soon but have no carts, and want to see what kind of differences there are between Mega Play and Genesis cartridges.

While comparing the Tetris data dumps, there appear to be a very specific group of values that are never generated as a result of the decryption function. These are all opcodes that access data with the PC relative addressing mode. Instructions like LEA and PEA aren't present because they only use the program counter to generate an effective address. Here's a list, probably not complete:

• output.txt

A majority of the values decrypted by the CPU have a unique output. The Tetris data shows that for the ones that don't, they nearly always map to $FFFF, $4E73, $0612, and $0404, and to a much lesser degree the values are in the 4xxx-6xxx range. It makes you wonder how (for example) an immediate operand can have all 64K possible values represented if the decrypted output has a smaller range than that.

I guess I'll keep working with Tetris, for the life of me I cannot get E-Swat to behave. The bootleg code is too out of sync with the original to get an idea of what's going on. I also have a CPU for D.D. Crew but I believe that game has no bootleg for a reference. It may be possible to get tables of data from a few more locations in Tetris, but I don't think I'll bother with that unless somebody makes a request.

With the PC link working on my System 24 board, I have been doing tests on the Hitachi FD1094 CPU that Tetris uses (the 315-0092) because there is a very similar bootleg to it. I can also try E-Swat, but those are the only CPU modules I own that also have bootlegs.

Tetris has the following instruction:

00005D0: 6945 BD0B 535B     move.w #$1111, $E0F6.w

Here is a table of the decrypted data:
Update: I've added data from several other addresses too. This gives a better example of which values are position-independant and which ones change based on their address. Also I byteswapped all the files to be LSB first. (the other one wasn't, oops)

• tetris-data2.zip (1.3MB)

The 5d2.tbl table above has all 64K values of the word at address $0005D2. The results are fascinating, for example many values like 0E71 are decrypted as 4E71, which was the correlation I discussed earlier between the 4xxx group of opcodes. Even more interesting, the decrypted data has a lot of duplicate results, such as many values being decrypted as $FFFF. I had assumed every input would have a unique output. Remember that the decryption hardware also takes the current address into account, so some of the values would be different for another address, except for the 'fixed' results like the 4xxx group.

Anyway, while it's not much, it's a first step to understanding how the FD1094 works. If anybody has some ideas for me to try, or notices anything interesting in the data, please let me know. I'll try to get some tables of data from other locations, though there are other experiments I want to run first.

One other point of interest: I tried relocating code fragments at different offsets and it turns out only bits 13-0 of the address are used when decrypting. Bits 23-14 are unused. So you can position the code at any 16K boundary and it will be decrypted in the same way.

This means the 5d2.tbl file of decrypted data can be used in other locations. For example, in Tetris again:

00045D2: 799D CE7F BF3F     cmpi.b #$1E ($51, a6)

00045D2: 0C2E 001E 0051     cmpi.b #$1E ($51, a6)

As part of getting my test programs working, I finished up a memory map for the System 24 hardware. There is some unusual behavior with the sprite RAM that I haven't looked into yet, so I haven't clarified that part. This is for CPU A:

 000000-03FFFF : ROM (256K)
 040000-07FFFF : ROM (mirror)
 080000-0BFFFF : CPU A work RAM (256K)
 0C0000-0FFFFF : CPU A work RAM (mirror)

 100000-13FFFF : ROM (mirror)
 140000-17FFFF : ROM (mirror)
 180000-1BFFFF : ROM (mirror)
 1C0000-1FFFFF : ROM (mirror)

 200000-20FFFF : Tilemap generator name table RAM (64K)
 210000-21FFFF : Tilemap generator name table RAM (mirror) (*1)
 220000-27FFFF : Unused (returns $FFFF), write-only registers are:
 240000.w      : Framebuffer read-out starting X position ($FFCE = Tilemap pixel 0)
 260000.w      : Framebuffer read-out starting Y position ($FBF0 = Tilemap line 0)
 270001.b      : Display mode (00=normal, 01=invalid) (*3)
 280000-29FFFF : Tilemap generator pattern RAM (128K)
 2A0000-2BFFFF : Tilemap generator pattern RAM (mirror)
 2C0000-2DFFFF : Tilemap generator pattern RAM (mirror) 
 2E0000-2FFFFF : Tilemap generator pattern RAM (mirror)
 300000-3FFFFF : Mirror of 200000-2FFFFF

 400000-403FFF : Color RAM (16K)
 404000-407FFF : Mixer chip registers
 408000-5FFFFF : Mirror of 400000-407FFF

 600000-6FFFFF : Object generator RAM (256K) (*2)
 700000-7FFFFF : Mirror of 600000-6FFFFF

 800000-9FFFFF : I/O chip

 A00000-AFFFFF : Interrupt controller and timer registers
 B00000-BFFFFF : /EXCS0 and /DTK0 area (Floppy disk controller board)
 C00000-CFFFFF : /EXCS1 and /DTK1 area (HotRod analog I/O board)
 D00000-DFFFFF : /EXCS2 and /DTK2 area (30-pin I/O expansion connector)
 E00000-EFFFFF : CPU hangs when accessing (no DTACK)

 F00000-F3FFFF : CPU B work RAM (256K)
 F40000-F7FFFF : CPU B work RAM (mirror)
 F80000-FBFFFF : CPU A work RAM (mirror)
 FC0000-FFFFFF : CPU A work RAM (mirror)

 Notes:

 1.) The schematics show an extra address bit is not used, so the tilemap
     generator can handle up to 128K of name table RAM depending on the
     implementation. For System 24, only 64K is available, mirrored twice.

 2.) The object generator supports 512K DRAM but only 256K is present.
     Reading 640000-67FFFF returns words from random addresses in the
     lower 64K of DRAM. Having sprites displayed from this area returns
     the same 'garbage' data. Writing to this area causes no data to
     be written to DRAM at any address.

 3.) The invalid display mode causes the display hardware to start a second
     frame within the first one. This cancels or prevents the framebuffer
     auto-erase from occuring at all. As a result, the portion of the
     framebuffer that is shown will accumulate all sprite data rendered in
     previous frames until the display mode is changed back to normal.

I've been taking care of a RSI over the past few weeks, which has really limited the amount of work I can do on my projects. I guess the last update to SMS Plus took it's toll on me. :)

So, I focused my efforts on something else: I finished the prototype of a PC communications card that fits into the 30-pin expansion connector found on many Sega arcade boards. The transfer rate is about 180K per second in either direction, which is perfectly adequate -- most of the boards I own have less than 64K of RAM for program storage anyway. The limiting factor is the how fast the 68000 (10 MHz in this case) can process data.

One experiment I tried was to have my System 16 emulator upload the video RAM contents to a Shinobi board during gameplay. There is quite a lot of flicker from the color and sprite RAM writes, and it doesn't run at full speed, but was nevertheless cool to watch. I think a better application in an emulator would be to have a hotkey that uploads the video state to the target hardware when pressed, so you can compare the software rendered display to what the real one should look like.

Now that the communication code is working fairly well on both ends, I'll see about adapting it to the System 18/24/C2 platforms. In theory, this will conveniently solve the problem of ROM swapping on the System 24 board (no more bent pins!) so I can get back to playing around with the FD1094 and disk controller again. I've been running low on working flash memory chips and didn't want to risk wasting any more.

Apart from just loading programs, the other nice aspect is that large amounts of data can be saved to disk instead of printed on the screen. This will be handy for testing the math chips that E-Swat uses. I'll share my findings later on.

I've completed a major update to SMS Plus. Here are the new files:

• sp-081404-dos.zip
• sp-081404-src.zip

 - Proper emulation of the Game Gear parallel and serial I/O hardware.
 - Codemasters mapper support.
 - PAL console support.
 - Improved memory management. (Space Gun works)
 - New SN76489 PSG emulator from Maxim.
 - New YM2413 FM emulator from MAME. EMU2413 is still available too.
 - Fixes to the rendering engine.
 - Support for the SMS 2 VDP extended display modes.
 - Many improvements to the VDP and I/O port management.
 - Tons of bugfixes and other minor improvements.

Some people have asked about getting the PC-Engine information page back up, I'll do this shortly. Currently I am rewriting TGEmu and updating my PCE documentation.

I found a few of my old notes and rewrote the Super NES 1024K HiROM devcart instructions. The new document is available in the SNES section.

Congratulations to whomever was visitor 200,000. :)

I've been restoring the console information links, and added a new GameCube section. There are still plenty of missing files in the other sections, but I'll finish the updates eventually. I won't be changing page names anytime soon, so those of you with direct page links can update them without worry.

I finally got around to rewriting the website to use PHP and CSS extensively. There's still more to do, so I'll be fixing links and adding more content later on.

I picked up some cool hardware recently: a Deniam Logic Pro 2 board, Namco Super World Court (NA-1) board, and will be getting a Taito Tetris (Sega-licensed) board this week. I've already documented most of the Deniam-16C hardware used in Logic Pro 2, and will release that information soon.

The best find was an Enduro Racer boardset; not only was it cheap and complete, but included the MCU daughterboard and the YM2151 type of sound hardware. I need to do some minor repair work on it first, but it should usable eventually. The MCU board is nearly identical to what the Pre-System 16 hardware uses, so building a compatible one may be possible.

I've found out something really interesting about the Hitachi FD1094 instruction encoding. In comparing the bootleg or unencrypted original versions of several games to their encrypted counterparts, I noticed a group of instructions have a similar encoding to the original 68000 opcodes, that are always encoded in the same way regardless of position. The operands are encrypted, however.

Normally instructions are encrypted based on their value and their address, so for example two ADDX.W instructions in sequence would have two very different opcodes. But in this case, a stream of identical opcodes have the same value.

The group seems to be most of the 68000 $4xxx ones, most notably LEA is absent. In the FD1094 they are replaced as $0xxx. Here's a partial list of the ones I've observed so far:

    nop
    rts
    rte
    pea     $nnnnnnn
    swap    dn
    stop    #$nnnn

    move.w  #$nnnn, sr
    move.w  #$nnnn, ccr

    not.b   dn
    not.w   dn

    tas.b   $nnnn.w
    tas.b   (an)
    tas.b   ($nnn, an)

    ext.w   dn
    ext.l   dn

    clr.b   dn
    clr.b   (an)
    clr.b   (an)+
    clr.b   $nnnn.w
    clr.b   ($nnnn, an)

    clr.w   dn
    clr.w   (an)
    clr.w   $nnnn.w
    clr.w   ($nnnn, an)

    clr.l   (an)
    clr.l   (an)+
    clr.l   $nnnn.w
    clr.l   ($nnnn, an)

    tst.b   dn
    tst.b   $nnnn.w
    tst.b   (an)
    tst.b   (an)+
    tst.b   ($nnnn, an)
    tst.b   ($nnnn, an, dn.w)
    tst.b   $nnnnnn

    tst.w   dn
    tst.w   $nnnn.w
    tst.w   ($nnnn, an)
    tst.w   $nnnnnn

    tst.l   dn
    tst.l   (an)
    tst.l   (an)+
    tst.l   ($nnnn, an)

    movem.w dn/an, -(a7)
    movem.w (a7)+, dn/an

    movem.l dn/an, -(a7)
    movem.l (a7)+, dn/an

    jmp     (an)
    jmp     ($nnnn, pc, d0.l)
    jmp     ($nnnn, a0, d0.w)
    jmp     $nnnnnn
    jmp     ($nnnn, pc)

    jsr     (an)
    jsr     $nnnnnn
    jsr     ($nnnn, an, dn.l)
    jsr     ($nnnn, pc)

So, 0E71 is NOP, 0238 is CLR.B $nnnn.W, etc. This encoding of instructions is consistant between all encrypted games that use the FD1904 that I have examined, which were incidentally all System 16 games.

This isn't a 100% complete list, it was generated using some statistical checking between several ROM sets with most of the results verified by hand. Most likely the addressing modes not shown are also valid, but it just depends on what each game uses. The other group are some $8xxx instructions are encoded as $1xxx:

    divu.w  #$nnnn, d0
    divu.w  ($nnnn, an, dn.w), dn
    divu.w  dn, dn
    divu.w  (an)+, dn

    divs.w  dn, dn

All of these instructions have no alternate encodings, and no encrypted instructions result in a value equal to any of opcodes for the above list.

I think this finding is significant in several ways:

• The possible result the encryption function has on an opcode is limited to not be any of the above ones. This reduces the possible one of 64K values an encrypted opcoded will have.
• The decryption feature is selectively enabled based on the opcode itself. For example, in the sequence 'nop; beq *; nop' it knows not to decrypt either NOP, but will decrypt BEQ and it's operand appropriately.
• There is now a valid set of instructions that can be used to program the CPU; though they are not very useful and the ones with encrypted opcodes are completely useless.

Here are some of the other results I've put together over the last few years:

• Executing code from higher addresses outside of the ROM space does not stop the CPU from trying to decrypt opcodes.
• Preceeding or following data next to an opcode does not affect how it is decrypted. (e.g., encryption works on a single 16-bit word unit, adjacent data has no effect)
• The unencrypted vector table entries can be modified to point to other locations within encrypted code with no undesired results.
• The high 8 bits of the vector address do nothing, just like a regular 68000.

I have a lot of ideas for experiments to try, but have very little free time nowadays, and development on the System 24 board is extremely tedious (it's used to change the FD1094 program code on the fly and monitor work RAM changes). I can see why the CPS2Shock team ended up using an EPROM emulator instead of prying out and re-inserting EPROMs every single time a program is tested.

I'll post more about this later on.

Here's a small Sega WIP update, adding ADPCM sound playback to the two Datsu bootleg games, shdancbl and tturfbl. This fixes most of the sound related issues for these two, although sample playback in-game for Tough Turf is still a little problematic. The sound test works find, oddly enough.

• Sega WIP

• SuperGrafx hardware notes
• Sega Saturn hardware notes
• Sega Saturn cartridge information

I've noticed the Space Harrier / Enduro Racer schematics document a very similar implementation of the MCU, but the scan that's currently available is too difficult to read. Are there any scans that include a more legible copy of sheet 1 of the CPU board diagram? This would save me a lot of trouble. :)

I recently figured out how to get around the MCU protection in Body Slam, so I can run my own software. By forcing an address error in the initialization routine, I can get my exception handler to run before the MCU checksums the code, and it seems to resume control afterwards instead of leaving the 68000 halted. I've been able to do some testing and have finished up the first version of my Sega Pre-System 16 documentation:

• Pre-System 16 Hardware Notes

I noticed the N7751 program in MAME is the same one from Monster Bash, which accesses some hardware specific to that game that isn't in the Pre-System 16 board. While it's entirely possible the same code was used elsewhere, I would like to confirm this.

My updates to MAME have been included in the 0.80u2 update, which is available here:

• Haze's MAME Page

Time for another Sega WIP update, most notably sound support has been added to the tturf, tturfu, tturfbl, fpointbl, and fpointbj drivers. The latter two have slightly different sound hardware and were previously using a ROM from the original game, not the actual bootleg one.

Further investigation into the similar tturfbl / shdancbl sound hardware leads me to think it does not have a DAC. The sample data is 4-bit, written in 8-bit units at a time, and it seems that an NMI is triggered after a sample data write to allow more data to be sent. Both games might use some kind of ADPCM chip, and this would explain why shdancbl can fit all of the PCM samples in a much smaller space. Currently FM sound is enabled, but samples are turned off in tturfbl, shdancbl.

• Sega WIP

Just for fun, I've been fixing up some of the Sega 16-bit game drivers in MAME. I've added a WIP page to show the progress being made, along with screenshots and updated source code.

• Sega WIP

If anyone has suggestions or bug reports, please let me know. I'm trying not to break anything in the process of updating the drivers. ;)

A while ago I had worked out some of the pin assignments for the program ROM board of a Neo Geo MVS cartridge. I haven't seen any information like this available before, so here's the current version of my notes:

• neopin.txt

It mainly covers the the connections used by the 68000 program ROMs, which was the part I was most interested in. Maybe I'll add some more details later.

After a long delay I've updated my Sega SC-3000H hardware notes. Apart from some of the unusual cartridge types and expansion hardware (SF-7000), nearly everything about the main system has been documented.

• sc3000h.txt

I recently picked up a multisync monitor and finally had a chance to test my Sega System 24 "Hot Rod" board after all these years. Much to my surprise it works flawlessly, I had originally gotten the board heavily used and untested for cheap, expecting it was probably broken (it certainly looked that way).

I modified the it to accept flash memory and have been running test programs, which has allowed me to fill in lots of missing information in my technical documentation and emulator. Development is a little tedious as the ROMs are physically close to each other and difficult to remove, maybe I can try using the disk drive instead.

I've been examining the Hi-Vision / 31KHz and PAL-specific display modes of the Sega Saturn. I'll write up some details on how they work and probably put up some accompanying test programs. Too bad no commercial software uses the exclusive monitor modes, it would be nice to see a game like Fighting Vipers or Virtua Fighter 2 utilizing a 704x480 progressive scan display.

Thanks to everyone who helped out with the Oki MSM5205 information. :)

I'm looking for datasheets for the Oki MSM5205 (an ADPCM chip used in many older arcade games) and the NEC uPD91061GD or any related parts. I've examined the MSM6585 documentation which is an improved version of the MSM5205, but I'm still curious about the original one. If anyone can help out, please get in contact.

I have made a replacement for the 315-5391 part used on the Sega System 18 mainboard (both versions) implemented in a GAL22V10. It has been tested and works fine on a Clutch Hitter board. Here is an archive with the JEDEC file and source, it's free for anyone to use and hopefully will help keep people's games up and running. :)

• s18ic80.zip