What's new
By:
Filters

openkey kabuki project

ack

ack

Grand Master
Joined
Apr 21, 2018
Messages
404
Reaction score
814
Location
WA, USA
In May/June I got my hands on bunch mitchell boards that were in need of desuiciding.

IMG_0864.jpg


The plan was to put infinikeys in them can call it a day, but turns out there was no stock of infinikeys. Undamned hadn't logged into the forum since late last year, so seemed unlikely there was going to be new stock. At the time I didn't even consider trying to make my own and started looking at doing the dead battery society mod instead.

Mid-July I bought sbbros from a forum member that had an broken infinikey in it (ended up being a bad dip switch). Looking the infinikey over it was just a MCU and a dip switch for picking a game. I decided to read up on the process of how to reprogram and found Eduardo Cruz/Arcade Hacker awesome write up.

I initially built his out of socket arduino based programmer to confirm I was able to get reprogramming working at all. After that worked, I breadboarded up a attiny MCU and a dip chip test clip to work on programming the cpu on the fly when powering on the board.

IMG_0862.jpg


That plus writing the firmware for the attiny took about a day to get a working on a single game. The next day I added the dip switch to allowing picking games. This ended up being a pita. I thought I had some firmware bug as some games worked and others didn't. I eventually figure out the dip switch that I had pulled from a cps1 parts board had a bad switch on it. I also spent a far bit of time figuring out the timing of when the attiny should start programming after it gets power.

Up to this point these were all similar things I've done in the past on other projects, but I've never done anything related to creating a pcb. I spent a couple weekends learning up on kicad and all the different lingo related to having pcb's made. Got a very basic PCB made in early August.

first_rev.jpg


It worked, thankfully.

Continued learning more kicad and making numerous additional revisions. I'm currently at this

IMG_0859.jpg


For someone that mostly programs, 1-2 week turn around on being able to test a new pcbs is brutal. I burned almost a month going through a couple revs to get the solder jumpers to where they were easily jumped.

At this point I think I'm mostly done. My plan was to throw this up on github, but it feels like a bit of a gray area since its obviously looks pretty similar to the infinikey. So looking for a some feed back on that.

thanks
 
Nice, I love seeing people learning skills like this. Looks like a lot of fun, great job.

As for the ethics of it ... this is just my personal take: I haven't spoken to Undamned really in years, I don't know him well, but we've met and chatted. My sense is that if he was active nobody would even bother trying to step on his toes. But he's clearly feeling like he needs a break, and isn't around now. Not speaking for him at all, just my feeling that it's good to fill the vacuum for these kind of projects if the people who were doing them before step away. I don't think he would mind.

It's best for the community imo if projects that do things like keep old games alive also manage to stay alive.
 
I just asked him on Twitter. He actually responded a few days ago about his DB15 adapters and said they are still being made, but parts shortages are causing delays. I asked about this chip and the CPS 1.5 (of which I need 3!).

If he's still selling these, I'm not sure of the rules of this forum, since I think there is a rule against selling something already being made, but I agree, it's been a loooong time since they were out of stock. I think it wouldn't hurt, but since Undamned blazed the trail, I would buy his if he came back. If not, I'd be happy to take a few of these and then beg you to do a CPS 1.5 version! :)
 
XtraSmiley said:
I just asked him on Twitter. He actually responded a few days ago about his DB15 adapters and said they are still being made, but parts shortages are causing delays. I asked about this chip and the CPS 1.5 (of which I need 3!).

If he's still selling these, I'm not sure of the rules of this forum, since I think there is a rule against selling something already being made, but I agree, it's been a loooong time since they were out of stock. I think it wouldn't hurt, but since Undamned blazed the trail, I would buy his if he came back. If not, I'd be happy to take a few of these and then beg you to do a CPS 1.5 version! :)
Click to expand...
Yeah, I wouldn't have gone through the hassle of making it if they were still available. My original thought when seeing them all out of stock is he was just tired of making them. I don't believe there is any parts shortage on the parts needed for any of the infinikeys. I had thought the best course would be to ask if I and/or the community could buy out the infinikey designs and then he could open source them. However I didn't end up asking after seeing that he hadn't logged in since late last year. I'm still open to this idea as I think it would be better if there was only one solution that was easily available to everyone.

I actually started working on a cps1 programmer a little after I started on the kabuki one. I was going to need something so I could test openkey-kabuki on a cps 1.5 board. I was planning on making post in this thread later today/tomorrow about it.
 
ack said:
Yeah, I wouldn't have gone through the hassle of making it if they were still available. My original thought when seeing them all out of stock is he was just tired of making them. I don't believe there is any parts shortage on the parts needed for any of the infinikeys. I had thought the best course would be to ask if I and/or the community could buy out the infinikey designs and then he could open source them. However I didn't end up asking after seeing that he hadn't logged in since late last year. I'm still open to this idea as I think it would be better if there was only one solution that was easily available to everyone.

I actually started working on a cps1 programmer a little after I started on the kabuki one. I was going to need something so I could test openkey-kabuki on a cps 1.5 board. I was planning on making post in this thread later today/tomorrow about it.
Click to expand...
I'll post what/if he replies to me on Twitter.

If he hasn't logged in over a year and it's sold out everywhere (I though a store in Australia had 30+ still in stock though), then I see no issues either.

Hook it up brother. I support original creators and to hell with it, if he comes back, I'll buy 3 from him and 3 from you as back-ups. Now that is fair!
 
With the long down times between having new revisions of openkey-kabuki pcb, I decided to take a look at making a on the fly programmer for cps1. I was going to need something to test a cps 1.5 game with the openkey-kabuki so it made sense to try and make openkey-cps1. At the time I didn't have a cps 1.5 game but was looking for one.

I started out the same way I did with the kabuki, using ArcadeHackers out of band C board programmer. It worked as expected on a suicided capcom world I had.

I breadboarded stuff and started writing the firmware. I used the same ATtiny MCU and was able to reuse a lot of the code from openkey-kabuki. The initial breadboarding didn't work and after some debugging it turns out 2 of the 4 pins needed to do the programming are tied to ground on the B board. I ordered some short IDE/40pin extension cables and cut those 2 pins from the female side of the cable. This allowed programming to start working.

cps1_breadboard.jpg


At this point I started designing the board in kicad. This was a good step forward in learning as it required taking real world measurements of the locations/spacing of connectors and getting them into kicad. Plus a lot of practice running the 160+ traces.

First rev of the pcb ended up not working. After a bit of debugging I found I f'd up on the schematic. I accidentally mixed up those 2 pins that should have been disconnect from the B board with the 2 that shouldn't. 2 bodge wires and cut traces later, stuff was working. (pic is from after I had already stolen the MCU/dip switch for the next rev)

cps1_rev0.jpg


Fixed up that issue in schematic and added some silk screen, then ordered up a new rev.

While that rev was being made I got my hands on a punisher board. After reverting the dead battery society mod on it, I installed openkey-kabuki/cps1 and both were
working good. However I found out having the openkey-cps1 installed didn't allow the cover to close on the punisher board. The C board being shifted directly to the left caused it to conflict with a plastic standoff on the case.

I ended up taking a hacksaw to one of the first rev boards so it was possible test shifting the C board connectors down to see where best to place it. Once I figured that out I adjusted the pcb which required re-running all the traces. This puts me at the current revisions of

cps1_latest_rev_top.jpg
cps1_latest_rev_bottom.jpg


This new rev allows the punisher case to fully close, but its a tight fit height wise.

I still need to write up some docs, but once those are done I will looking at putting this up on github too
 
I can wholeheartedly agree @ack is an awesome person and a great contributor. He his helping me trouble shoot one more game in the list, then I hope he will update his GitHub with the newest results!

I'm so glad we all have an alternative for these items to save these old games!
 
Great write up and good methodical process. Proof of concept using a breadboard > prototype PCB (make any required changes) > finished board.
 
I'm back, with an openkey-cps2 board. I've been working on this on and off for the past couple months. The progression of board revisions

revisions.jpg


It was a slow process because when I started I only had 93646B-6 and 93646B-7 CPS2 revisions. This is reflected in my initial revision which only supported those.

Once I got my hands on a 93646B-4 board it led to the 2nd openkey-cps2 revision. At the time I did my best to verify that version should fit ok on the all-in-one CPS2 boards based on pictures. However I only focused on making sure the openkey board didnt interfere with the screw hole and the plastic dimm/simm connector. I didn't consider that the nub added for 93646B-4 support might stick out past the edge of all-in-one board, which it did :/

This led to the 3rd/current revision which shifted the nub closer to where the openkey board solders into the all-in-one cps2 board. This change also allowed me space to add in a UPDI programming header. The lack of one of them made it annoying to program the mcu in the first 2 revisions.

Here are some picks from it installed. Ignore the green arrows, I stole these from my install docs.

b_34_install2.jpg
b_67_installed.jpg
a_34_installed.jpg


Firmware was pretty straight forward, just writing out 20 bytes. There are a lot of games / keys, which made firmware size right at the 4k limit of the
ATiny404. I was a little worried about that initially, but was able to save about 800 bytes by making a lookup table for the first 6 bytes of each key. There ended up only being 10 unique combinations of those 6 bytes across all keys, which made the lookup table possible.

https://github.com/jwestfall69/openkey-cps2
 
This is some of the details related to openkey-kabuki having a compatibility issue with the older (uncommon?) cps 1.5 92636D-3 D board revision. Ultimately I suspect its not possible to program the kabuki at power-on with this D board revision.

I had a user contact me that their 3x Warriors of Fate USA boards were all giving "RAM ERROR" when using openkey-kabuki. I made a conversion of wofu with my punisher board and it worked fine. So wasn't sure what was going on.

I disassembled the wofu rom (tk2u_23c.8f) to see what can trigger a "RAM ERROR" thinking maybe (but unlikely) there was some issue with the all 3 of their A boards.


Code: 
; gfx ram
0761a: 7014                      moveq   #$14, D0
0761c: 720a                      moveq   #$a, D1
0761e: 207c 0090 0000            movea.l #$900000, A0            ; grx ram start
07624: 2248                      movea.l A0, A1
07626: d3fc 0002 fffe            adda.l  #$2fffe, A1             ; grx ram end
0762c: 45fa 0224                 lea     ($224,PC) ; ($7852), A2 ; "RAM ERROR" address location
07630: 4dfa 0006                 lea     ($6,PC) ; ($7638), A6   ; return address from branch
07634: 6000 0068                 bra     $769e                   ; test memory function

; work ram
07638: 7014                      moveq   #$14, D0
0763a: 720a                      moveq   #$a, D1
0763c: 207c 00ff 0000            movea.l #$ff0000, A0            ; ram start
07642: 2248                      movea.l A0, A1
07644: d3fc 0000 fffe            adda.l  #$fffe, A1              ; ram end
0764a: 45fa 0206                 lea     ($206,PC) ; ($7852), A2 ; "RAM ERROR" address location
0764e: 4dfa 0006                 lea     ($6,PC) ; ($7656), A6   ; return address from branch
07652: 6000 004a                 bra     $769e                   ; test memory function

; infinate loop looking for kabuki to have written 0x77 to shared ram at $f19ffe
; ie black screen if wrong kabuki key
07656: 3039 00f1 9ffe            move.w  $f19ffe.l, D0  ; part of upper shared ram between m68k and kabuki
0765c: 0c00 0077                 cmpi.b  #$77, D0
07660: 66f4                      bne     $7656

; test lower shared ram between m68k and kabuki
07662: 207c 00f1 8000            movea.l #$f18000, A0   ; lower shared ram between m68k and kabuki
07668: 303c 0ffe                 move.w  #$ffe, D0      ; number of words to test
0766c: 30bc ffff                 move.w  #$ffff, (A0)   ; write ffff
07670: 0c58 ffff                 cmpi.w  #-$1, (A0)+    ; read back
07674: 670e                      beq     $7684          ; if equ goto next address (dbra below)

07676: 7014                      moveq   #$14, D0       ; if not equ
07678: 720a                      moveq   #$a, D1
0767a: 247c 0000 7852            movea.l #$7852, A2     ; "RAM ERROR" address location
07680: 6000 0044                 bra     $76c6          ; print text and stall
07684: 51c8 ffe6                 dbra    D0, $766c      ; loop next address

; test memory function used by gfx/work ram, not really important
0769e: 2648                      movea.l A0, A3
076a0: 383c 0001                 move.w  #$1, D4
076a4: 7600                      moveq   #$0, D3
076a6: 2c3b 3028                 move.l  ($28,PC,D3.w), D6      ; test pattern?
076aa: 204b                      movea.l A3, A0
076ac: 2410                      move.l  (A0), D2
076ae: 2086                      move.l  D6, (A0)               ; write test pattern
076b0: 2a10                      move.l  (A0), D5               ; read back
076b2: bc85                      cmp.l   D5, D6                 ; compare
076b4: 6600 0010                 bne     $76c6                  ; if not equal print "RAM ERROR" text and stall
076b8: 20c2                      move.l  D2, (A0)+              ; next address to test
076ba: b1c9                      cmpa.l  A1, A0                 ; end of memory rang?
076bc: 63ee                      bls     $76ac
076be: 5843                      addq.w  #4, D3                 ; next pattern?
076c0: 51cc ffe4                 dbra    D4, $76a6
076c4: 4ed6                      jmp     (A6)

In summary
  1. test grx ram
  2. test work ram
  3. wait for kabuki to write 0x77 to a shared memory location
  4. test shared ram between main cpu/kabuki

So its possible "RAM ERROR" to be triggered by the shared ram between the main cpu and kabuki. I provided the user with programmer and we tried a number of different firmware to test out different timing thinking it could just be an issue with the kabuki writing to the shared ram while the main cpu was doing its shared ram test. None of these made a difference.

The user sold me one of the boards. Once arrived I confirmed I was getting the "RAM ERROR". (also a side note, sometimes you can get around the error by doing a very fast powercycle. Which is short enough the kabuki retains the key data, openkey itself doesn't power cycle, and the board reboots. The effect is openkey doesn't program and the kabuki uses the previously programmed key data and the game starts fine).

ram_error.jpg


I also confirmed that game worked fine with a battery backed kabuki that had been programmed by openkey. Turns out his wofu's all have 92636D-3 D boards, where my punisher/conversion has the 92636D-5 D board.

Next was to modify wofu code to identify which ram test was triggering the "RAM ERROR". This was done by making the gfx ram test print "M ERROR", work ram print "ERROR", and shared ram print "ROR". In the event there was some other code path I missed it would still print "RAM ERROR"

ror.jpg


That confirmed it was the shared ram. At this point I tried may different timing tweaks to the firmware. However making programming take longer doesn't seem like its going to help because of main cpu is waiting for the kabuki to write that 0x77 to shared ram before it will even start the shared ram test. So I focused on making the programming go faster, all the way to the point of removing all logic from the firmware and just long list of pin enable/disables.

openkey-kabuki-tk2-raw.ino

This version still results in "RAM ERROR". Additionally I've tried many other tweak in the firmware with no luck.

Up next was getting more info out of the main cpu about what it was actually seeing during the shared ram test error. I wrote some code to take control of the execution of the wofu rom right before its normal wait for 0x77 business to allow me to do that wait, run the ram test and print out the details. I slightly modified the test routine from the original to saves the read value to d1 so I could print it out.

Code: 
                movea.l #$f18000, a0    ; lower qsound shared ram block
                move.w  #$ffe, d0       ; number of words to test
        .loop_next_address:
                move.w  #$ffff, (a0)
                move.w  (a0)+, d1
                cmp.w   #-$1, d1
                beq     .address_good
                move.w  #$ffff, d0      ; expected value
                jsr     print_data_error

This resulted in

bad_cmp.jpg


wtf? expected and actual are the same (address is random within the shared ram range). I originally thought I had messed something up in my print_data_error code, but confirmed it was working correctly by feeding in manually set values.

This made me think there could be a dead output situation, where the main cpu trying to read from the shared ram but the ram (or maybe a bus transceiver) never
put anything on the data lines. On a 68k cpu this usually results in part of the next instruction being put into the register. However even if this was the case, its unclear to me how the cmp fails if d1 actually contains 0xffff.

To rule out this dead output idea I put a 'nop' between the move.w (read) and the cmp as this should cause a behavior change, hopefully with different 'actual' data.

Code: 
                movea.l #$f18000, a0    ; lower qsound shared ram block
                move.w  #$ffe, d0       ; number of words to test
        .loop_next_address:
                move.w  #$ffff, (a0)
                move.w  (a0)+, d1
                nop
                cmp.w   #-$1, d1
                beq     .address_good
                move.w  #$ffff, d0      ; expected value
                jsr     print_data_error

The added 'nop' resulted in a black screen instead (yawn). At this point I added some code that if the memory test passed it just printed "PASS" instead of giving control back to the game on the off chance the 'nop' fixed the issue but some other part of the game was causing the black screen. No change, black screen still. Adding a 'nop' shouldn't have this effect.

The only thing I can think of that would cause this black screen is an exception, so added some code to override bus/address/illegal instruction/divide by zero exceptions with my own code.

The result

exception.jpg


Its unclear to me why/how the PC is 0x0, but the 0xe687c address value is the location of that 'nop' instruction.

At this point I'm suspecting there is some design flaw with this older revision of the D board. Such that any delay in the kabuki starting is tickling this flaw and causing problems with the main cpu accessing the shared ram during its shared memory test.

Here is all the code/roms from the modified wofu if anyone wants to poke

openkey-kabuki-wofu-debug.zip

This "RAM ERROR" behavior on 92636D-3 seems to also effect inifinikey-kabuki as the one I have is doing it.
 
I was curious how the other cps 1.5 games using the 92636D-3 would/wouldn't work with openkey-kabuki. It was possible the when/how the other games checked the shared ram wouldn't cause a problem. But the all ended up having issues.

C&D = black screen
Punisher = black screen
Muscle Bomber Duo:
mbombrd.jpg


The "NG" on Duo has the same meaning as "RAM ERROR" on wof

Slam Masters:
slammastu.jpg

Far as I can tell this message will show up on slam masters for an F-line exeption which maybe an indication of an invalid instruction that's start with 1111 (binary).

The quick power-cycle trick noted in my previous post works for them all. Lastly they all boot fine with an battery backed kabuki programmed with openkey-kabuki.
 
Did some additional digging/debugging between the 2 D board revision and there seems to be a simple fix. Replace the D9K1 PAL found on 92636D-3 with D9K2 PAL found on 92636D-5.

The original D9K1 PAL would enabled 3x 74LS245s that handle passing data/address lines to/from the main cpu to the kabuki data/address bus whenever the kabuki enabled BUSACK.

The updated D9K2 PAL adds additional restricts on enabling those 74LS245s. For example one of them disables the 74LS245s if the main cpu is no longer accessing the shared memory address range.

So its likely with the original version those 74LS245s were just being enabled for to long and could cause problems.
 
You must log in or register to reply here.
Back
Top