Possible improvement on CPS1 Openkey for fixing issue

Hi. Today I'm going to investigate a possible solution to an issue I have detected, and I want to share my thoughts.

I have a Daimakaimura board with broken C board (B-01 chip), so I have tested the Openkey with a B-21 programmable chip.
I have detected a small issue. With this game, there is a little probability (on first boot) it'll show me black screen with music on background.

This exact situation occurs when you power on the game without a C board or with a C board without codes. I have been thinking and this is because there is the possibility of, depending on the power supply, the game tries to boot just before the injection ends (or even boots in the middle of the injection causing bad graphics, I have experienced also that).

When this occurs, I just simply reboot the game (the codes can be inside the B-21 chip many minutes), and It boots perfectly.

So, my suggestion is to use one available pin on the ATtiny404 to throw a reset pulse on pin 103 of the B-21. I have not tested it yet, but this would do a general reset of the game just like CPS2 openkey does, and guarantee a 100% boot up success.

Alright. Pin 103 of the B-21 chip isn't in charge of the general reset signal of the board. I'll continue the search

perhaps instead of trying to control the reset, use the reset line as a signal for when to trigger programming?

ack said:

perhaps instead of trying to control the reset, use the reset line as a signal for when to trigger programming?

Click to expand...

I'm trying to figure how to make this, believe me. I don't know where is global reset pin on C board with the schematics

P.D.: also with one of my cabinets. Perfect 5V on C board and a Cadillacs and Dinosaurs. The same as Daimakaimura, so the culprit is the timing of its power supply. Definitely is necessary to establish a reset of the game after injecting

Tried something at first, but bot cigar. I modified the code for using pin 7 of ATtiny404 to throw a LOW signal, and cabling it to the reset pin in A board like Darksoft's multi does.

Inside the code, I make a first delay(500), and put the game in hold with LOW. The ATtiny404 makes the injection and deactivates, so no more LOW signal. The game boots, but the same issue ends happening.

With a Willow injecting B-03 codes, there is a possibility of seeing bad graphics on boot, with my fix and with the original code. I must continue investigating.

The first thing it comes to my mind probably is the extremely high speed of injecting the codes in the ATtiny. With normal arduino and battery, it takes a few seconds to program the game for keeping the nomal clock timmings. Maybe with the reset signal implementation, we could use the original injection of arduino the seconds it needs and reset the game.

EDIT: I have seen on Undamned's Infinikey also occurs this issue. See the last seconds and the bad graphics on various boots. That's not bad contact pins, it's the probability of not injecting good I said earlier in the thread.


I'm going to investigate the original injection with Arduino but ported on ATtiny404. I can test this issue perfectly

I think the general problem is what is being programmed to the B-21 chip. It contains details on where a number of different registers are located in its memory map. This would be stuff like palette/layer/priorities ctrl registers. However when a game first boots these are some of the registers its going to want to write to early on. If the B-21 hasn't been programmed by then, those register writes will just be lost.

ack said:

I think the general problem is what is being programmed to the B-21 chip. It contains details on where a number of different registers are located in its memory map. This would be stuff like palette/layer/priorities ctrl registers. However when a game first boots these are some of the registers its going to want to write to early on. If the B-21 hasn't been programmed by then, those register writes will just be lost.

Click to expand...

Thanks to the reset signal I have seen this is not the real issue. It's the injection itself. In many tries the CPS1 has reset itself and it has ended in black screen or bad graphics.

The ArcadeHacker's Arduino Desuicider code is more slow because it adapts to the clock timmings in the injection. I know without a reset signal, this process has to be real quick, but with this reset signal maybe we can use the Arduino Desuicider on each power up.

This thursday also tried my Cadillacs and Dinosaurs with Infinikey on a Blast City, and with 20 power on tries, only 2 booted well. I'm not telling you this code is bad, not like that, it's the correct injection timming I guess. Without a reset signal I understand this have to be done quick, but I think the injection could be improved.

You are thinking of wiring the openkey to the RESET signal on the A board?

I'm curious what you mean by this "ArcadeHacker's Arduino Desuicider code is more slow because it adapts to the clock timmings in the injection".

In what way do you see the injection being improved? I don't think it could be done any faster since the code is directly writing to the port registers.

ack said:

You are thinking of wiring the openkey to the RESET signal on the A board?

I'm curious what you mean by this "ArcadeHacker's Arduino Desuicider code is more slow because it adapts to the clock timmings in the injection".

In what way do you see the injection being improved? I don't think it could be done any faster since the code is directly writing to the port registers.

Click to expand...

ArcadeHacker made by reverse engineering the method of unlocking/injecting the code years ago, and Infinikey is based in it. I'm saying that maybe the timmings it uses are better. I'm trying to port his code to ATiny404 and make it work and see what happens. It's only a test.

And yeah, I'm using the digital pin 2 (pin 7) of ATtiny404 to throw a LOW pulse for holding the CPS1 while injects.

My code is based on his work too. The issue isn't getting the code injected right? its that the code injection isnt complete before the game starts.

Do you have these same issues on your other cabinet? I seem to recall it was only your blast city that was giving you grief with openkey-cps2.

ack said:

My code is based on his work too. The issue isn't getting the code injected right? its that the code injection isnt complete before the game starts.

Do you have these same issues on your other cabinet? I seem to recall it was only your blast city that was giving you grief with openkey-cps2.

Click to expand...

There are no delays between instructions. It's the fact here.

The problem happens with a few power supplies of mine and a local test I made on thursday on a Blast City also, and depending of the game codes.

Adding code level delay() wasn't needed when I was developing/testing/scoping it. The amount of time it takes the ATtiny to change a pin between high/low state is a long enough.

This bad boot thing is related to the game. In my case I have detected this issue on Daimakaimura (B-01), Willow (B-03) and Cadillacs (B-21 custom codes).

In resume, I am having a probability of bad booting / bad graphics on power up with these games + the fact of not booting at all on Blast City cabinets in almost all power ons.

Well, after 3 days of active tests (trying delays, combinations...), I can conclude my thoughts. First of all, many thanks to @ack for the great work he made with Openkey family. Studying his code has proven worth the time.

For the people don't know, with games like Daimakaimura and Willow (B-01 and B-03 codes), there was the probability of having bad graphics on boot. As the next images:




After so much time investigating this issue, I have discovered it's a voltage issue. If in the B-21 section doesn't arrive exact +5V, the codes will be written bad in a high probability. I have been doing groups of 20 power ons with each game with different jamma supplies (with more or less cable lengths). So this way, ack's code doesn't need any improvement.

However, the error of not booting CPS1 games with no test screen like Cadillacs and Dinosaurs on Blast City cabinets isn't solved yet. The place with 3 different Blast City cabinets where I can test the following solution is 150km away, so I must test it the next weekend.

In resume, Cadillacs and Dinosaurs is a game which hasn't a test screen on boot. Only jumps to title an revision number. Blast City power supplies has proven been a pain in the ass with CPS2 openkey (but that thing was solved). This game concretely throws a black screen on almost all the boot ups, so the ATtiny404 is working well. I think this is a problem of milliseconds difference between A board boot up and code injection.

The temporal solution has been to add a few lines on ack's code for using digital pin 2 of ATtiny404 (pin 7) for throwing a low pulse to the reset pin on A board. This change in the code doesn't affect if you want to use the reset signal or not, it's the same as ack's.

In my case I have used a arduino dupont male-female 40cm cable cut in half for easily disconect this solution eventually. As I say, if this reset signal works properly, I would suggest to switch to my modified code if I can confirm it.

I have attached a capture in the files for seeing the few changes in the code.

Thanks for taking the time to look into the issue and trying to debug. Its always a good thing for people in our small community to learn how things work and try to make them better for everyone.

For cps 1.5 games they have a check early on where the main cpu will sit in a loop waiting for the kabuki cpu to write a specific byte to a memory location in their shared ram. So if the kabuki cpu isnt working it will cause a black screen. Maybe a extra startup delay is needed when programming the kabuki cpu like was required to get the openkey-cps2 working on the blast city?

ack said:

Thanks for taking the time to look into the issue and trying to debug. Its always a good thing for people in our small community to learn how things work and try to make them better for everyone.

For cps 1.5 games they have a check early on where the main cpu will sit in a loop waiting for the kabuki cpu to write a specific byte to a memory location in their shared ram. So if the kabuki cpu isnt working it will cause a black screen. Maybe a extra startup delay is needed when programming the kabuki cpu like was required to get the openkey-cps2 working on the blast city?

Click to expand...

My pleasure sir.

The kabuki works good, that's for sure. So until I can't make further debug tasks on those cabinets, we will not know what's happening.

I have made the tests with Blast City cabinets. The reset signal implementation isn't useful at all. The problem of random black screen on boot-up is B-21 power up related. So, in Blast City cabinets, Infinikey CPS1 works worse than any other power supply. There is no more improvements can be made for this system.

AND YES, I CAN CONCLUDE BLAST CITY POWER SUPPLIES ARE SHIT. My original Night Slashers board freezes and even doesn't boot on that damn cabinet. Really dissapointing, SEGA