I've been working on my CPS2 setups over the past few days and I needed a quick way to desuicide a B board that I was swapping the roms on. I didn't know where my LCD shield and Arduino Uno that I usually use for desuiciding CPS2 B boards (I moved late last year and a lot of stuff is still in boxes) so I figured I'd just swap my multi onto this B board and write the key using the multi. Once I got the multi swapped to the new B board I noticed that the game that was already loaded on the multi booted to a solid color screen as if it didn't have it's key written. I went ahead and programmed the correct game that I was trying to convert the B board to and it also would not boot after programming, just a solid green screen. Very strange.
After this I moved the multi back over to it's original B board and found that it was behaving the same way there. At that point I went ahead and dug through some boxes until I found my Arduino Uno that I have set up for key writing, and I found that if I manually wrote the key for the currently loaded game It worked just fine, but if the multi tries to write the key the board suicides.
I probed around on the CN9 connector of the B board with my oscilloscope during the boot process and found that Setup 1 was briefly pulled high then low then high then low again. '
Setup 2 was pulled low then left high.
Data appears to be sending the key
And there is a clock signal, but it is only coming in at 1.2v peak to peak, which I'm assuming is the problem since the CPS2 security chip is probably expecting TTL clock input.
My multi is what I believe to be the first generation multi, although I'm not totally clear on how many revisions there have been. As far as I can tell the clock signal comes straight off of one of the legs of the ST microcontroller, so I don't think there could be a component failure between the key writing wires and the MCU. @Darksoft, @Mitsurugi-w , or anyone else who might have knowledge about this, what could be causing this and is there a solution? Much appreciated.
P.S. here is a video demonstrating the problem.
View: https://youtu.be/O65ei217gvM
After this I moved the multi back over to it's original B board and found that it was behaving the same way there. At that point I went ahead and dug through some boxes until I found my Arduino Uno that I have set up for key writing, and I found that if I manually wrote the key for the currently loaded game It worked just fine, but if the multi tries to write the key the board suicides.
I probed around on the CN9 connector of the B board with my oscilloscope during the boot process and found that Setup 1 was briefly pulled high then low then high then low again. '
Setup 2 was pulled low then left high.
Data appears to be sending the key
And there is a clock signal, but it is only coming in at 1.2v peak to peak, which I'm assuming is the problem since the CPS2 security chip is probably expecting TTL clock input.
My multi is what I believe to be the first generation multi, although I'm not totally clear on how many revisions there have been. As far as I can tell the clock signal comes straight off of one of the legs of the ST microcontroller, so I don't think there could be a component failure between the key writing wires and the MCU. @Darksoft, @Mitsurugi-w , or anyone else who might have knowledge about this, what could be causing this and is there a solution? Much appreciated.
P.S. here is a video demonstrating the problem.
Last edited: