What's new
This is excellent information, thank you for sharing. So if I understand you're speculating that the CPLD on the adapter board is simply responding to commands from the mobo as another device on the IDE, and not a MitM?

Are these CPLDs Dumped/Reversed? Do we have the ability to re-create these CPLDs?
 
unless something changed,
there are no pld dumps related to KI, no schems and mame does not support the conversion kit other than having the rom/drive dumps.
i think it's low priority for them as the game is playable via the dedicated set. :(
 
This is excellent information, thank you for sharing. So if I understand you're speculating that the CPLD on the adapter board is simply responding to commands from the mobo as another device on the IDE, and not a MitM?

Are these CPLDs Dumped/Reversed? Do we have the ability to re-create these CPLDs?
I have it dumped and cloned that pcb but it cost me a fortune
 
The biggest issue I’ve had in making this kit are the knockoff parts I’m getting won’t work or program correctly . I’ve successfully programmed 4 of these(the U1 from the adapter PCB) , tried to migrate the code to a newer device with no luck .
 
i dont think it's passive, i suspect it's translating some drive commands - look at the mame source.
what country are you in?
i'd like to draw a schematic of one of these boards.
MAME doesn't support the conversion, and AFAIK, doesn't have any technical information about the conversion. MAME supports the dedicated version, which as I mentioned, I believe swaps some address mappings (but no additional IDE stuff). I assume the KI2 conversion ROM has the original address mappings, but now has additional IDE checks.

I'm in the USA... if you want to draw schematics of the board, I think the spreadsheet I posted would be nearly sufficient. There's also one 10K pullup resistor on IDE pin 39, and a few bypass caps. The CPLD is an Altera EPM7032LC44-15T. Of course all the magic happens inside the CPLD, so cloning the board itself doesn't really get you anything without knowing how the CPLD works.

This is excellent information, thank you for sharing. So if I understand you're speculating that the CPLD on the adapter board is simply responding to commands from the mobo as another device on the IDE, and not a MitM?

Are these CPLDs Dumped/Reversed? Do we have the ability to re-create these CPLDs?
Yes, take a look at the spreadsheet and you can see that the conversion board simply passes the IDE signals through (like a cable), and the CPLD just hangs off some of the pins (similar to how two hard drives hang off the same IDE cable). Pins would have to pass through the CPLD in order to change data/addresses/etc. to/from the HDD.

I’ll have to give this a shot, I have a conversion board somewhere around here. You’re the man now @DogP
Be sure to post if you find anything... good luck!

other than having the rom/drive dumps.
Just to clarify, the HDD is the same between the dedicated and conversion... only the boot ROM changed.

DogP
 
The biggest issue I’ve had in making this kit are the knockoff parts I’m getting won’t work or program correctly . I’ve successfully programmed 4 of these(the U1 from the adapter PCB) , tried to migrate the code to a newer device with no luck .
It seems like eliminating the conversion adapter would be the easiest (and cleanest/cheapest)... an hour or two with MAME would probably tell you whether it's easy, and if that goes well, a few more hours would probably have it done.

DogP
 
EA2BD494-B4A2-470C-8FDC-BA7E29495985.jpeg

Neat!
 
lets see your source patches so we can try :)
I'll post once I've got it emulated "properly"... right now I just have a patch that works, but I don't think is how the hardware actually works. Since the dedicated KI2 already works, it only makes sense to emulate the protection if done accurately, so I'm going to hook up the logic analyzer and watch the data on the real hardware to make sure I know exactly what it's doing. Early AM meetings all week are cutting into my fun time though. :(

But yes, the CPLD looks to be a register accessible as an IDE slave.

DogP
 
OK, I think I got this figured out... slightly more complex than I expected. I ended up writing several test ROMs (MIPS assembly, ugh) to put it through a bunch of well defined states while watching the data on the logic analyzer, rather than just watching the random data presented by the game PCB. They were also kinda tricky since the protection to allow the game to boot was slightly different than the protection to start a game (I thought I knew how it worked, then when starting a game, it'd say "Time Out" and go to the continue screen).

The CPLD sits on the bus and works when the host selects the IDE slave device (/CS0=0, /CS1=1, A2=1, A1=1, A0=0). This is the IDE head and device select register... when bit 4=1, the slave device is selected, and the lower 4 bits are the head number. Of course this isn't actually a real IDE device, but since the IDE hard drive (master) sees that the host is communicating with a slave, it stays off the bus and ignores this data.

The gist of the protection is that there's two 4-bit registers and a 4-bit counter. Writing to the device with D6 high stores the lower 4 bits (head number) in an internal register. Writing to the device with D6 low stores the lower 4 bits in another internal register, and also increments a 4-bit counter. Reading the device returns the value of the counter XOR register 1 XOR register 2. Reading doesn't change any data.

I attached my updated MAME source file (rename to .cpp) in case anyone wants to try it (or understands C++ code better than my English description above ;) ). I'll do a pull request for this eventually.

Oh, and I found an error in my adapter spreadsheet (one data line was wrong), so I fixed it and edited my old post.

A side note to all of this... it should be VERY easy to bypass the protection altogether with a minor ROM mod. The one complication is that the code looks to be decompressed from ROM into RAM at startup, then runs from RAM. So, I could figure out the (de)compression scheme, or probably much easier to add a few instructions to simply modify the data in RAM after the data is decompressed.

Let me know if you try any of this out, or need any clarification on it.

DogP
 

Attachments

  • IMG_2907.JPG
    IMG_2907.JPG
    225.6 KB · Views: 177
  • kinst.txt
    40.3 KB · Views: 150
Last edited:
so as the ide is syncronous and does not have to be lightning fast, i'm thinking "BluePill" :D
 
A side note to all of this... it should be VERY easy to bypass the protection altogether with a minor ROM mod. The one complication is that the code looks to be decompressed from ROM into RAM at startup, then runs from RAM. So, I could figure out the (de)compression scheme, or probably much easier to add a few instructions to simply modify the data in RAM after the data is decompressed.
Here's an IPS patch for that simple mod I was describing. You'll want to patch the KI2 conversion Any IDE ROM. This should run KI2 on a KI1 PCB w/o the conversion board. Of course it should make building a multi KI/KI2 much easier as well.

I tested it and it seems to work, though I'll admit that I pretty much suck at the game, plus my JAMMA testbench doesn't have a full set of KI controls, so it's not very easy to play. So, if anyone tries it out and does a complete playthrough... please report back. I see one additional piece of code that looks similar to the protection code, but putting a breakpoint in MAME, I never see it execute. Maybe it's one last booby trap that only happens after a certain point, or maybe it isn't this at all. I left it alone, as I don't like changing code unless I know what it does.

Also, I updated the MAME source in my post above to make it more accurate (when the CPLD is read, the upper bits are set according to the last write - though the software just masks them off anyway, so it's functionally the same).

I'm sure the next question will be about running KI on a dedicated KI2 PCB (or dedicated KI2 ROMs on a KI PCB). This becomes trickier, because the CPLD on the motherboard (U96) changes some address mappings. So, you'd need to go through the ROM and manually swap all of them. From the MAME source:
Code:
read: $80 on ki2 = $90 on ki
read: $88 on ki2 = $a0 on ki
write: $80 on ki2 = $90 on ki
write: $90 on ki2 = $88 on ki
write: $98 on ki2 = $80 on ki
write: $a0 on ki2 = $98 on ki
These are memory mapped to offset $10000000 (i.e. "read: $80" is a read of $10000080). You could try to exercise all the code, log all accesses, then swap them as necessary. But as I mentioned before, the code is decompressed from ROM into RAM, so you'd either need to decompress, patch, recompress... or manually patch all locations after decompression. Probably not difficult, but tedious.

DogP
 

Attachments

  • ki2_conv_anyide_secbypass.zip
    216 bytes · Views: 231
so next question:
is the data loaded from the drive by track/sector, or is there a filesystem and filenames?
because it would be interesting to get away with one drive for all the data!
 
It looks to be a raw access kinda thing. I was thinking the same thing about getting both on the same drive, but I think it'd be a matter of concatenating the raw disk images and putting an offset in everywhere in the code that accesses the disk. So again, probably very tedious. ;)

DogP
 
Here's an IPS patch for that simple mod I was describing. You'll want to patch the KI2 conversion Any IDE ROM. This should run KI2 on a KI1 PCB w/o the conversion board. Of course it should make building a multi KI/KI2 much easier as well.

I tested it and it seems to work, though I'll admit that I pretty much suck at the game, plus my JAMMA testbench doesn't have a full set of KI controls, so it's not very easy to play. So, if anyone tries it out and does a complete playthrough... please report back. I see one additional piece of code that looks similar to the protection code, but putting a breakpoint in MAME, I never see it execute. Maybe it's one last booby trap that only happens after a certain point, or maybe it isn't this at all. I left it alone, as I don't like changing code unless I know what it does.

Also, I updated the MAME source in my post above to make it more accurate (when the CPLD is read, the upper bits are set according to the last write - though the software just masks them off anyway, so it's functionally the same).

I'm sure the next question will be about running KI on a dedicated KI2 PCB (or dedicated KI2 ROMs on a KI PCB). This becomes trickier, because the CPLD on the motherboard (U96) changes some address mappings. So, you'd need to go through the ROM and manually swap all of them. From the MAME source:
Code:
read: $80 on ki2 = $90 on ki
read: $88 on ki2 = $a0 on ki
write: $80 on ki2 = $90 on ki
write: $90 on ki2 = $88 on ki
write: $98 on ki2 = $80 on ki
write: $a0 on ki2 = $98 on ki
These are memory mapped to offset $10000000 (i.e. "read: $80" is a read of $10000080). You could try to exercise all the code, log all accesses, then swap them as necessary. But as I mentioned before, the code is decompressed from ROM into RAM, so you'd either need to decompress, patch, recompress... or manually patch all locations after decompression. Probably not difficult, but tedious.

DogP
Thanks for sharing, I tried it (patched the KI2 conversion anyide rom) but it doesnt work. When powering the pcb it goes to the test menu and I cant select anything, its frozen there.
I tried on 4-5 good working KI1 pcbs and all have and same problem with your patched code.

Works perfectly using one of my conversions adapters.
 

Attachments

  • IMG_9424.JPG
    IMG_9424.JPG
    155 KB · Views: 169
  • IMG_9427.JPG
    IMG_9427.JPG
    293.8 KB · Views: 159
  • IMG_9429.JPG
    IMG_9429.JPG
    236.4 KB · Views: 159
Back
Top