tendril
Well-known member
Yeah, the FD1089B key is available, it's how MAME decrypts it to be played.
So to decrypt it to work on a regular 68000 the key is still needed, but that's not all.
The encrypted CPU uses the key in different ways if the CPU is reading an instruction (opcode) or data. When Sega created the ROMs they have a mask that specifies what each byte of the ROM should be encoded as (opcode or data).
To create a decrypted version of these ROMs that would run on a regular CPU you need the same mask to know which of the two decryption processes to follow. You can use MAME to help make this mask - because you could log what bytes are read as opcodes and what bytes are used as data as you play the game. But to be 100% - you have to make sure every possible instruction path is followed. Otherwise you have a chance of ending up with an incorrect mask that would crash the game if it read an instruction that had been decrypted as data.
Because knowing if the game has ran every instruction path is difficult/effectively impossible, you have to finish up the mask by hand by examining the disassembly and checking if it could ever branch to a data segment.
I might be making this sound more complex than it is - for someone familiar with 68000 code and MAME it might be 2-3 hours work. (But still - pain in the ass)
So to decrypt it to work on a regular 68000 the key is still needed, but that's not all.
The encrypted CPU uses the key in different ways if the CPU is reading an instruction (opcode) or data. When Sega created the ROMs they have a mask that specifies what each byte of the ROM should be encoded as (opcode or data).
To create a decrypted version of these ROMs that would run on a regular CPU you need the same mask to know which of the two decryption processes to follow. You can use MAME to help make this mask - because you could log what bytes are read as opcodes and what bytes are used as data as you play the game. But to be 100% - you have to make sure every possible instruction path is followed. Otherwise you have a chance of ending up with an incorrect mask that would crash the game if it read an instruction that had been decrypted as data.
Because knowing if the game has ran every instruction path is difficult/effectively impossible, you have to finish up the mask by hand by examining the disassembly and checking if it could ever branch to a data segment.
I might be making this sound more complex than it is - for someone familiar with 68000 code and MAME it might be 2-3 hours work. (But still - pain in the ass)

