Please note that if anyone does use this info for their own CC emulator project I do ask that credit be given where credit is due. I'm not asking for any money, just to be acknowledged in the emulator credits. It was a LOT of work to crack this:- As for the decryption algorhythm, a few things; There are two sets of ROMS in the tant archive (Brian Peek's mirror). One is supposedly the genuine set, and the other a bootleg. The set I have on my boards seems to be a hybrid between the two. The program ROMS (7-11) are the same as the bootleg set and the others seem to be the same as the genuine set. The encryption on the bootleg set is different to the genuine set. The following description only applies to the bootleg program ROMs (Only the program ROMs are encrypted). If you look at ROM11 with a hex editor the first few bytes should be as follows if you have the right set:- FE FF FF EE 73 00 A0 96 AC 00 44 54 44 54 44 54 The encryption is quite sophisticated and cannot be decrypted without dissassembling the code, working out where the data tables are, and then reassembling. I actually had to write a special Z80 disassembler/unscrambler to do this (This was written on a C64 if you want the program). ***NOTE: Don't panic! A Z80 emulator program can be easily modified to decode the encrypted ROMs on the fly. Please don't ask me for decrypted versions of the ROMs. On the Z80 there is a pin called M1 or 'machine cycle one'. This pin indicates when the processor is doing the opcode fetch of an instruction execution. In other words, for an instruction like a Jump which consists of 3 bytes, the first byte is the opcode and the following two bytes are the address to jump to. The M1 pin will only be active while reading the first byte. The decryption is only applied when the M1 pin is active. in other words for a Z80 jump instruction:- ROM bytes xx 00 40 -----> would become C3 00 40 ;xx is encrypted byte. ^^ ^^ Note that the bytes containing the jump address stay the same. Similarly, for a two byte instruction, only the first byte will be encrypted, and of course all one byte instructions would be encrypted. What this means is that decryption cannot be applied to the whole file because all data reads are unencrypted. Just to make life a little more difficult, the encryption is different on odd and even addresses. The encryption involves scrambling bits 0,2,4,6 through a prom which is toggled by A0. The following index tables taken from my disassembler/unscrambler program decode the opcode bytes. Use evetab for even addresses and oddtab for odd addresses. The values in the tables are all decimal. For example for encrypted value of 1 on an even address you would read 84 (decimal). For an encrypted value of 4 on an odd address you would read 64 (decimal). evetab: db 65, 84, 70, 19, 81, 20, 2, 82 db 73, 92, 78, 27, 89, 28, 10, 90 db 5, 16, 67, 86, 1, 85, 6, 22 db 13, 24, 75, 94, 9, 93, 14, 30 db 97, 116, 102, 51, 113, 52, 34, 114 db 105, 124, 110, 59, 121, 60, 42, 122 db 37, 48, 99, 118, 33, 117, 38, 54 db 45, 56, 107, 126, 41, 125, 46, 62 db 68, 17, 23, 66, 0, 80, 83, 87 db 76, 25, 31, 74, 8, 88, 91, 95 db 21, 64, 7, 18, 4, 69, 3, 71 db 29, 72, 15, 26, 12, 77, 11, 79 db 100, 49, 55, 98, 32, 112, 115, 119 db 108, 57, 63, 106, 40, 120, 123, 127 db 53, 96, 39, 50, 36, 101, 35, 103 db 61, 104, 47, 58, 44, 109, 43, 111 db 148, 193, 135, 215, 129, 196, 130, 210 db 156, 201, 143, 223, 137, 204, 138, 218 db 132, 208, 147, 194, 209, 197, 214, 150 db 140, 216, 155, 202, 217, 205, 222, 158 db 180, 225, 167, 247, 161, 228, 162, 242 db 188, 233, 175, 255, 169, 236, 170, 250 db 164, 240, 179, 226, 241, 229, 246, 182 db 172, 248, 187, 234, 249, 237, 254, 190 db 145, 192, 199, 211, 212, 149, 146, 134 db 153, 200, 207, 219, 220, 157, 154, 142 db 144, 128, 198, 131, 213, 133, 195, 151 db 152, 136, 206, 139, 221, 141, 203, 159 db 177, 224, 231, 243, 244, 181, 178, 166 db 185, 232, 239, 251, 252, 189, 186, 174 db 176, 160, 230, 163, 245, 165, 227, 183 db 184, 168, 238, 171, 253, 173, 235, 191 oddtab: db 80, 17, 18, 82, 64, 85, 86, 87 db 88, 25, 26, 90, 72, 93, 94, 95 db 81, 20, 3, 70, 69, 4, 66, 6 db 89, 28, 11, 78, 77, 12, 74, 14 db 112, 49, 50, 114, 96, 117, 118, 119 db 120, 57, 58, 122, 104, 125, 126, 127 db 113, 52, 35, 102, 101, 36, 98, 38 db 121, 60, 43, 110, 109, 44, 106, 46 db 84, 21, 22, 19, 16, 5, 2, 67 db 92, 29, 30, 27, 24, 13, 10, 75 db 68, 1, 71, 23, 0, 65, 83, 7 db 76, 9, 79, 31, 8, 73, 91, 15 db 116, 53, 54, 51, 48, 37, 34, 99 db 124, 61, 62, 59, 56, 45, 42, 107 db 100, 33, 103, 55, 32, 97, 115, 39 db 108, 41, 111, 63, 40, 105, 123, 47 db 129, 133, 215, 210, 193, 197, 151, 146 db 137, 141, 223, 218, 201, 205, 159, 154 db 212, 208, 131, 134, 213, 144, 195, 198 db 220, 216, 139, 142, 221, 152, 203, 206 db 161, 165, 247, 242, 225, 229, 183, 178 db 169, 173, 255, 250, 233, 237, 191, 186 db 244, 240, 163, 166, 245, 176, 227, 230 db 252, 248, 171, 174, 253, 184, 235, 238 db 145, 149, 199, 194, 209, 148, 135, 130 db 153, 157, 207, 202, 217, 156, 143, 138 db 196, 192, 147, 150, 132, 128, 211, 214 db 204, 200, 155, 158, 140, 136, 219, 222 db 177, 181, 231, 226, 241, 180, 167, 162 db 185, 189, 239, 234, 249, 188, 175, 170 db 228, 224, 179, 182, 164, 160, 243, 246 db 236, 232, 187, 190, 172, 168, 251, 254 I have been thinking that it would be a fairly simple matter to use these tables in a Z80 emulator so that when it decodes the opcodes it uses the above tables to index the encrypted ROMs. This would allow an emulator to use the original encrypted ROM images. If anyone needs any other help regarding Crazy Climber please email. I have worked out most of the memory map and have a partly working CC reconstruction already. Lionel Theunissen (lionelth@ozemail.com.au)