What's new

[SOLVED] Difficulties with suicided X-Men vs Street Fighter US board converted to multi.

That board doesn't need the 4K7 resistor. I have a working -7 B board with a multi kit in it and it doesn't need the resistor. But my board has EXC5 in place.

That EMI filter allow the battery backed part of the board receive power from the battery or from the 5V supply diodes which bypass the battery when the board is running. You can safely short circuit the two border pins, leaving the middle one (gnd) unconnected.
 
Using a MAC to load your cards causes all sorts of troubles with these kits because of the garbage files MACs add.

I'm well aware of those files, and have taken precautions. Linux/Unix/Mac admin of a decade and a half. This is the first time I've seen this sort of trouble though. I don't suppose your magic board has a serial port or jtag or some other magic where I could see sort of debug output? I saw the pin header that is vacant at the top and thought to probe for TTL serial, but I've been really sick and not up to messing with it much today. I don't know how raw your code is for that board, whether you're using libraries to access the filesystem or what. The only reason I can think of those dotfiles causing trouble for anyone is if you are loading whatever is on the card in some sort of sequential matter rather than by filename or by crc. Then again, look at Mr. Fancypants Numbski sitting over here talking like he knows what you're up to here at all. :P

Seriously though, it's like a tiny android you have sitting on here with it's tendrils leached into the CPS2.
 
Be nice. Network engineer first, perl and javascript coder second, electronics comes in a solid 16th or so. The things I do for the love of fighting games.
No misrespect mate. We all have our areas of expertise.
 
That board doesn't need the 4K7 resistor. I have a working -7 B board with a multi kit in it and it doesn't need the resistor. But my board has EXC5 in place.

That EMI filter allow the battery backed part of the board receive power from the battery or from the 5V supply diodes which bypass the battery when the board is running. You can safely short circuit the two border pins, leaving the middle one (gnd) unconnected.

Thanks for the head's up. EXC5 is destroyed on my board. Half needle-nose plyers, half Deadpool "STUPID! ...worth it." Only not-so-worth-it if I further trashed my ability to boot this thing.
 
Seriously though, it's like a tiny android you have sitting on here with it's tendrils leached into the CPS2.
You mean this?
http://i.stack.imgur.com/vrgHm.jpg

About Mac computers, It's not sequential, it uses some libraries available by the manufacturer of the ARM and although I have patched them as much as I could, there are still sometimes, with some SD Cards, some issues with Macs.
 
I saw a post where Mitsu comments about people destroying that part to allow the board to become bootable.

That should not be done. There's no need to destroy any parts of the board for whatever reason.

Shorting CCI near D5 by the battery with a flat screwdriver head should be enough for everyone. As long there's no hardware faults.
 
That board doesn't need the 4K7 resistor. I have a working -7 B board with a multi kit in it and it doesn't need the resistor. But my board has EXC5 in place.

That EMI filter allow the battery backed part of the board receive power from the battery or from the 5V supply diodes which bypass the battery when the board is running. You can safely short circuit the two border pins, leaving the middle one (gnd) unconnected.
Thanks for the head's up. EXC5 is destroyed on my board. Half needle-nose plyers, half Deadpool "STUPID! ...worth it." Only not-so-worth-it if I further trashed my ability to boot this thing.
Seriously if fixing that EXC5 doesn't work, reach out to Mitsu, it will save you a lot of headaches.
 
I will try formatting my 4GB sandisk class 4 on Windows tonight when my wife gets home (work laptop FTW!) and give that a go, along with cleaning up EXC5. If I am still in the same place, I can resign myself to sending it off I guess.

With all due respect to you guys - sorry I wasn't around for whatever it is that Raz did, but this piece of hardware (working or not) is a stroke of genius in design alone. Holy crap.

...and yes, EXACTLY like a facehugger.
 
I saw a post where Mitsu comments about people destroying that part to allow the board to become bootable.

That should not be done. There's no need to destroy any parts of the board for whatever reason.

Shorting CCI near D5 by the battery with a flat screwdriver head should be enough for everyone. As long there's no hardware faults.

If at any point that becomes a real problem for me, I think I'd put a momentary pushbutton someplace across those points and place the button someplace impossible to press on accident, but easy to press on purpose.
 
sorry I wasn't around for whatever it is that Raz did,
Every time someone comes up with something that has potential to hurt his profit margins he comes with some kind of plot to annoy.

In our case, we took knowledge he willingly shared at the CPS2 Shock website and applied on the decryption of CPS2 ROMs. Then we released ROMs that had no visual signs of being tampered with.

He puts code of his own on the games to then be allowed to claim ownership over the solution of reviving dead boards. Was an attempt at achieving some sort of monopoly.

When CPS2 Multi released he felt threatened again and tried everything he could to discredit the hardware. That's the reason why the CPS2 tester was updated with some weird performance counter. Which would in theory allow him to point fingers claiming it's not accurately playing the games.
 
When CPS2 Multi released he felt threatened again and tried everything he could to discredit the hardware. That's the reason why the CPS2 tester was updated with some weird performance counter. Which would in theory allow him to point fingers claiming it's not accurately playing the games.
I did tests with the multikit and the performance counter rom on my CPS2, and found that if the board is fed with just 5V it starts working slower after some time. Just feeding it with 5.08V at the JAMMA edge solves the problem on my board.
 
I saw a post where Mitsu comments about people destroying that part to allow the board to become bootable.
Hey, hey, hey. I never said destroyed. I said removed. lol And I have never personally done it but others have said they have as to not need to open the case to short EXC5. Seems to be working for them. Like I said, I have never needed to though.
 
I destroyed. Only the legs remain - and a few bits of dust.

Also - that sounds EXACTLY like the Raz of old. WTF - so 2000 up until your kit, and he still behaves like that. Yikes.
 
I saw a post where Mitsu comments about people destroying that part to allow the board to become bootable.
Hey, hey, hey. I never said destroyed. I said removed. lol And I have never personally done it but others have said they have as to not need to open the case to short EXC5. Seems to be working for them. Like I said, I have never needed to though.
That may have come from me. I got super frustrated with some of my boards resuiciding often and desoldered the components on EXC1,2,3,4,5 during testing. Having EXC2,3,4 removed seemed to cause various issues like crashing or failing to boot, so I soldered those back in. Leaving EXC1 and EXC5 desoldered I haven't had any further issues with non battery decrypted boards suiciding again.
 
It's obvious that your board has other issues, though. At the key programming pin header, four of the pins are inputs and each one has a pull up resistor in it. If a pull up resistor is faulty the board can pick up EMI from nearby sources and acknowledge it as input, making it memorize a invalid/corrupted encryption key, which in turn would prevent the board from booting a decrypted ROM.

So you shorting the caps would remove that spurious key programming making it work again.

So, FYI, holding the board in RESET is how the board is put on key programming mode. And the CPS2 MULTI holds the board in RESET while it is programming the flashes on the kit.
 
Yeah it definitely is related to it thinking an encryption key is present, because leaving the board alone for a few days would temporarily resolve the issue, just as would shorting EXC1,5.

Not sure why it affects some boards and not others though.
 
Hey Mitsurugi - if I wind up sending this to you, were you the one saying you were sitting on a stack of A-Boards? Sounds like you don't have much faith in mine, so I need to be looking at options.
 
It's obvious that your board has other issues, though. At the key programming pin header, four of the pins are inputs and each one has a pull up resistor in it. If a pull up resistor is faulty the board can pick up EMI from nearby sources and acknowledge it as input, making it memorize a invalid/corrupted encryption key, which in turn would prevent the board from booting a decrypted ROM.

So you shorting the caps would remove that spurious key programming making it work again.

So, FYI, holding the board in RESET is how the board is put on key programming mode. And the CPS2 MULTI holds the board in RESET while it is programming the flashes on the kit.
I had the same problem with decrypted (Avalaunch) sets on regular B boards (no multi) and saw reports that others had seen the same thing on phoenix sets, having to bridge EXC5 from time to time. So it doesn't seem to be related specifically to the multi, but yeah I suppose it could be some sort of common hardware issue with CPS2 boards.
 
Just as an FYI, still the same issue after formattin on Windows. Behaves exactly the same way. Every game I load up draws a different on-screen pattern, but no sounds and no signs of a proper boot. I guess I need to swap PMs with Mitsurugi-W.
 
Back
Top