What's new
By:
Filters

CPS1 Board Reset Loop on Bootup Diagnostic

ShootTheCore

ShootTheCore

Legendary
Joined
Jan 20, 2016
Messages
3,169
Reaction score
6,276
Location
Utah USA
I just received a CPS1 Street Fighter 2 CD board that I plan on converting over to Daimakamura. I want to make sure it works 100% before starting the conversion obviously. When I power it up right now, it runs through the list of bootup diagnostics, but right after finishing the Work RAM test, it reboots and does it again. Any ideas? I've tried seperating the A, B, and C boards, inspecting them for bent or missing pins, and then fitting them all back together with no difference in behavior.

Photo Feb 14, 10 36 38 PM.jpg
 
Either the test is failing but you get to see no message, or the code crashes right afterwards.
In either case the first step should be that of identifying which board is defective (if any). Do you have other A or B boards to try with?
 
I don't have any other A or B boards on hand yet, but I will in a couple of days.

The seller told me that he tested it successfully immediately before shipping it. He suggested to both check for proper voltages and to check the kick harness connection.

I'll try both of his suggestions when I get home later tonight, but I've successfully run five other arcade boards with the current power supply settings, and I didn't have a kick harness plugged in at all last night. I have a multimeter - where's the best place on the board to check for proper voltage?
 
I found an article on the Arcade Otaku wiki that mentions measuring voltage across a 74 series logic chip on the board. I'm measuring 5.01V on the B board, and 4.99V on the C board, so that sounds within spec to me. I don't have a kickharness yet, so I can't try that to see if it'll make a difference. Seems to me that the board should still boot up even without a kickharness installed.

I've also found that if I let the board boot cycle for a minute that it eventually fails the SCR RAM 3 test. Odd that it takes a full minute of tests to get there, but that might be the smoking gun nevertheless.

At this point, I'm going to wait until my second CPS 1 kit shows up so I can test the individual boards of this kit to narrow it down.
 
An update: my second CPS1 kit showed up, and using the parts from it, I narrowed the culprit on this first kit down to the B board. I pulled the B Board ROMs one by one and verified the checksums on them against MAME. I got a bad read on ROM 18, so I was initially excited that I had found my troublemaker. But after replacing 18 with a new, correct EPROM the symptoms are unchanged - it still reboots immediately after the startup diagnostic.

At this point, I know it's the B board, and I know that all of the ROMs are correct. Thoughts on what to try next?

Unless someone suggests otherwise, my thoughts are:

1) Check that the socketed PAL chips match MAME. I'm not sure how to get them to read though. I've set my Wellon VP-390 to a GAL16V8 chip, but it just reads zeroes out from the chip. Any suggestions here?

2) Check for a broken circuit. The board looks pretty clean, and I've given things a quick once-over under the microscope and not seen any obvious broken traces. I haven't yet done the "deep dive" of checking each trace for continuity with the multi-meter.

I just received a logic probe and digital oscilloscope in the mail, so I might look for floating pins on the ROMs next as well. I'm new to using both, but a glitching board is a great motivator for learning!

Thank you for any help or suggestions.
 
Since you know how to dump roms, and you look very determined in solving this issue, you might find the following useful:

1) The datasheet of the GAL16V8 is here. Now that GAL has internal latches which make it impossible to dump, but if it has been dumped for MAME then chances are the register inside the GAL is actually not used. Therefore you can build yourself an adapter which patches all input pins to address lines and all output pins to data lines. Once this is done, you can dump it like a normal EPROM. Your programmer will generate on the address lines all the possible input combinations and will read the outputs on the data bus. The challenge will actually be that of finding out which I/O pins of the GAL are configured as input and which as output. But for this, using the scope, you can just pull the GAL off the circuit and check which traces going to I/O pins are floating.
Then again, since GAL16V8 devices are still easy enough to find, you might want to just use the dump you found, program yourself one with your Wellon and be done with it.

2) With regard to the ROMs you might want to first isolate the program ROMs from the rest (which should be easy, due to the amount of information provided by MAME) and then check that each and every address line, data line and control line is doing what it should do (change state), which means it is properly connected.

3) I am not a CPS1 expert, therefore I'm not sure to what extent can the C board affect the boot process, but I do know that C boards contain the DRM of the game. You might want to check if its battery is dead (provided it has one) and maybe try and swap it out with another identical one just to rule it out. AFAIK, when the C board is dead you should get a black screen (that is no boot tests).

If anything fails you can still try and replace the few TTL ics on the B board one by one.
 
Good advice all around Asayuki - thank you. I can rule out the C board because it tests correctly on my second kit (both kits are the same game with the same model C board). I didn't know that GALs aren't normally dumpable without a special adapter like ROMs - that's helpful to know. For now, swapping the TTLs between the B boards seems like the next easiest step to try before digging in with the logic probe.
 
ShootTheCore said:
Good advice all around Asayuki - thank you. I can rule out the C board because it tests correctly on my second kit (both kits are the same game with the same model C board). I didn't know that GALs aren't normally dumpable without a special adapter like ROMs - that's helpful to know. For now, swapping the TTLs between the B boards seems like the next easiest step to try before digging in with the logic probe.
Click to expand...
Remember: this method of dumping PALs in general (and GALs which are designed to be compatible with them) is useful if and only if the PAL/GAL has no register inside or the register isn't used. If the register is used, then there is no way to make sense of the output data.
 
The CPS1 PALs are encrypted so there's no way to verify they're good other than replacing them with a GAL16V8, there is only 1 PAL on the CPS1 B board and it's used for tile mapping, if it was dead your game would boot but you'd have 1cm blocks all over your screen.

Check your B board for broken traces
 
I'm pleased to report that I now have a completely operational CPS B board. I went broken trace hunting and finally stumbled onto this guy right here:


IMG_1396.JPG

I checked the trace for continuity with the multi-meter and there wasn't any connection. One patch later and here we are:

IMG_1398.JPG

Shout out to Asayuki and xodaraP for the patience and helpful advice. Thanks guys!
 
I'm glad you found that little bugger.
Well done, man! :)
 
You must log in or register to reply here.
Back
Top