Konami1 CPU to 6809 Adapter?

DarrenF

Well-known member
Joined
Jan 7, 2011
Messages
5,855
Reaction score
526
Location
Florida
So has anyone ever tried to make an adapter to use a regular 6809 in place of a KONAMI1 CPU?

It appears that MAME has a function to decode the EPROM, so it should be pretty straightforward to generate a decrypted set...

The pinout for the Konami1 is well documented...

So it seems it's mainly just a matter of making a 40pin-to-42pin adapter to cross-wire the CPU.

(Or is there a cheap and plentiful supply of Konami1's that I'm missing?)
 
Please have a look at the schematics of konami super basketball. You can see the connection for a normal 6809e and in parallel a konami-1. If you do use the 6809e setup you have to put in an unencrypted roms set ....
 
Creating a decrypted set is not exactly straightforward.... Only opcodes are encrypted, so you need to distinguish between code and data, which is not always easy. It can be difficult to determine all the data blocks. See Tim's Crazy Climber hacking for a similar encryption example.
 
Creating a decrypted set is not exactly straightforward.... Only opcodes are encrypted, so you need to distinguish between code and data, which is not always easy. It can be difficult to determine all the data blocks. See Tim's Crazy Climber hacking for a similar encryption example.

Seems to me like it is fairly straightforward for the Konami1 CPU. MAME doesn't have any seperate CPU emulation for it. It simply decrypts and emulates it as a standard 6809. Check out "konami1.c" in the mame source. For example, run gyruss ("mame gyruss -debug"), run to next CPU (F6), which you'll see is just an 6809, decrypted. Simply export ("save filename,0xe000,0x2000") and you've got a copy of the decrypted ROM, which should run on a standard 6809. Now it's just a case of making a little PCB to adapt the pinouts from Konami1 to standard 6809. I'm starting to learn EAGLE so I can do just that...

Yes, I was working on a SBB, which was layed out to be populated with either a standard 6809 or a Konami1 when I thought of this; and there was a decrypted set used for the standard 6809 versions. I was thinking more for other games which were not designed to accept anything but a Konami1.

Did a search, looks like these are the games that used the subject CPU: Circus Charlie, Finalizer, Gyruss, Hypersports, Jailbreak, Juno First, Megazone, Roc-n-Rope, Super Basketball, and Track & Field.
 
Last edited:
Trust me, it's not that simple. I did a score save for Juno First (and worked on others, like MegaZone). Only the opcodes are encrypted. When MAME needs to execute an instruction it uses the decrypted value for the opcode. But for all other reads (including the data of the instruction) it uses the raw data.
 
If only the opcodes are encrypted, then surely the other data would be identical in both the encrypted and decrypted code?

The point is you can't just decrypt every byte, as the data is not encrypted to begin with (so "decrypting" it would corrupt it). Figuring out what is code and what is data is not always simple... they are often tightly mixed. It's doable, but far from trivial. And there's always the possibility you missed something.
If you read through Tim's Crazy Climber writeup maybe it'll make more sense.
 
I understand that, what I don't understand is why what DarrenF suggested wouldn't work. Alternatively you could rip the decryption routine out of the MAME driver and make a standalone decryption tool from it.
 
I understand that, what I don't understand is why what DarrenF suggested wouldn't work. Alternatively you could rip the decryption routine out of the MAME driver and make a standalone decryption tool from it.

MAME doesn't figure out what is code and what is data ahead of time. It keeps two copies; the original (partially encrypted) ROMs and a copy that is blindly decrypted (every byte treated as if it were an opcode). When it is executing an instruction it takes the opcode from the decrypted copy and its operand is read from the original. Any read operations of the ROM area also have to come from the original.
 
MAME doesn't figure out what is code and what is data ahead of time. It keeps two copies; the original (partially encrypted) ROMs and a copy that is blindly decrypted (every byte treated as if it were an opcode). When it is executing an instruction it takes the opcode from the decrypted copy and its operand is read from the original. Any read operations of the ROM area also have to come from the original.

OK, thanks for clearing that up, Matt. I didn't notice the discrepancy between the code in the debugger and the memory bytes shown off to the right... and it wasn't immediately obvious to me from glancing at the driver how/where it handles opcode reads different from other memory reads. In any case, I see now that it's not trivial.

A quick look at Gyruss, though, makes it appear that e000-efff is mostly (all?) data, and f000- is mostly code...

I guess I'll shelve this until I end up with a KONAMI1 CPU PCB that needs fixing...

PS--I didn't realize you dealt with the encrypted Konami1 opcodes in your Juno First HSS kit... Impressive.
 
Last edited:
For Gyruss, the Konami1 is just the slave CPU (the main CPU is a Z80). The slave CPU just has one ROM (with not too much in it). That may be a fairly easy one to figure out. Good one to start with anyway.
 
Back
Top Bottom