So I swapped the plug on the chassis and bam the picture is right way up.
So onto playing the game.
When i first started playing it I played one game and it seemed normal, played to lvl 7 then died on springs
by climbing the second last ladder and got hit by a spring? not sure how but thats what seemed to happen.
after that i decided to stream with my sub optimal web cam, its blury but ill get another one soon and any suggestions are welcome. so i did this and came back and noticed the game had frozen,
I rebooted it and set up the stream.
http://www.twitch.tv/monstabonza/b/531698937so from here you can watch if you like at first it seemed normal then weird things started happening, at around 10min
I noticed that the girders above hammers were vanishing or becoming other things when hammers were taken. Then on the next pie stage, funny things started happening with kong, as the game goes on the pie factories get weirder and weirder. 23:11 in the video is a prime example.
Then at about 35:30 the game resets on the first death, after this there is still some funny sprites on the screen.
The next game it also reset 49:30 on my first death.
After this I played a game through to lvl 12 or 13, and not a thing i could notice at all went wrong, Besides things being different colour and a few sounds missing and being different, i could not in anyway distinguish anything different from crazy kong part II from mame by Falcon.
Now about the Pcb, it is a Crazy Climber PCB by Nichibutsu.
This game came out with with roms that were encrypted and had a module to read the information.
this was located where the z80 chip is on my board.
this module can be seen here
http://www.crazykong.com/pcbs/A%20-%20F/CrazyClimber.pcb_mini.jpgThis is about the module
Info taken from
http://www.arcadecollecting.com/crazy/cchack/That block is a custom CPU module that decrypts the code ROMs. The good news is that someone smarter than myself figured out the encryption table and the details are in MAME's Crazy Climber driver source code. The bad news is that they only encrypted opcodes and not data. This means we can't just use MAME to dump out the decrypted code and burn a set of EPROMs and install them on the board. The only way MAME knows what values are supposed to be opcodes and which are supposed to be data is to actually run the code. What they do is create a memory region that's twice as big as the code ROMs and fill one half with the decrypted data and the other half with untouched data. When MAME runs the game, if it's executing an opcode, it reads from the decrypted region and if it's reading data, it reads from the untouched data. In order for us to do the same, we'd have to burn a set of EPROMs that are twice the size of the original and connect the "M1" pin of the Z80 CPU to the highest address pin of each EPROM. This works because when the CPU is executing an opcode, the M1 pin will be "low" and when it is reading data, it will be "high" (or the other way around, I forget), so you use that to switch between the upper and lower halves of the data in the EPROMs.
Well, I didn't much like the idea of running wires all over my PCB. But, the only way to get a correctly decrypted set of ROMs the same size of the original would be to somehow play through the game and monitor what gets used as what. You could modify MAME to create a log file indicating what values were used as what. However, you'd need to play through the entire game,trying to get every last byte to be read to be 100% sure you've got the two regions merged correctly. This is near impossible to do by just playing through the game, since there will be bits you will miss no matter how many times you play. I got into a bit of discussion on this topic with David Widel, who had been trying this technique with some other games and couldn't get more than about 93% of a game's ROMs identified with this method. I had some ideas of my own on how to get 100% identification, so he sent me his modified version of MAME and I went to work on my favorite encrypted game... Crazy Climber.
There are two types of data that a given byte can be. The first type is data associated with an opcode.
Here is an example of the first type:
CA C9 0B -- jp z,$0BC9
CA is the opcode (jp z or jump if zero) and C9 0B is the data (the address to jump to, 0BC9).
The second data type is data that is read in chunks, like text strings, level layouts, etc.
After playing through the game a couple times to get a good sampling to work with, and looking at all the places that weren't getting executed, I noticed that all of the second data type in Crazy Climber was enclosed with a header and footer that was the same every time...
C7 FB [DATA] C7 F3.
Bingo! That meant that I would be able to identify every single byte in the game without playing it at all. However, I was actually kinda having fun figuring out how to get all the code in the game to execute, so I went ahead and went through all the code using my newfound information to accurately target the areas I needed to get executed, setting breakpoints at key locations and figuring out the conditions that would be required to run that chunk of code. It took about 8 more hours of fiddling to get to 100% identification. Along the way, I found almost all the interesting bits of code and memory locations that I'd need to twiddle to make my mods to the game to fix the interface flaws I felt it had. (Check out the bottom of the page for some of the interesting areas I found.) So, the result of this is we now have decrypted code that is easy (realatively speaking) to modify to our (well, at least to my) liking. The EPROMs with encrypted code can be replaced with EPROMs containing non-encrypted code and the funny green block can be replaced with a standard Z80 CPU. Sounds grand, but there's one problem... the socket the green block plugs into is not a standard CPU socket. In order to run unencrypted code on an original PCB, you will need to make an adapter.
So im assuming something like that was done but without the adapter,
Now for my speculations on this,
Falcon released CK part II mine says leisur , which i assume would be an easy hack being the same amount of characters
now in australia there is a company called Allied Leisure Industries.
Im going to go out on a limb and say someone there did it.
The question now becomes How they did it, Why they did it, and what id really like to know when they did it.
Again ill guess they maby they were going for a licence of the game?
Anyway thats a long enough post, If anyone has anything else to add feel free to chime in, especially if I have made any mistakes.
Next step is probably send it to one of you guys the get the roms dumped and find out whats going on in there nd get it Mamed.
Nick
