Pang 3 bootleg A/B chips on official h/w?

[rockbottom]

So i've got a fully working Pang 3 bootleg coming soon, there are several types, but it is this style:

It is identical except the A chip is the 27c634 instead of the Comco and the board is fully working.

I have 2 little projects in mind.

First is see if the A/B chips work as replacements on the original CPS1 hardware (i've read conflicting reports of this!)

Second is see if the board can be converted to run another game (gfx rom space will be the obvious hurdle, limiting to the smaller games).

Anyone tried anything like this?

I do like the look of this h/w, looks much closer to the original CPS1 than the ususal single board bootlegs.

I've noticed the power diodes around the A/B chips, as most here will know, this is a common (but somewhat dubious) bootlegger method of mixing 5 and 3.3v chips, perhaps the 27c63x chips are suppose to be 3.3v chips, could be a problem on official h/w...

 

[GadgetFreak]

All the Pang 3's I've had are the usual 3 board stack. So this board is a new one on me.
Not sure if you are aware of my Arcade Rom Patcher
It contains patches to generate rom/gal sets for 9 games to run on the 3 board stack version of Pang 3. The only one your board wouldn't be able to run would be Three Wonders as I had to use 4 x 16Mbit eproms for the GFX.

First up to point out is that the small square chip labelled MACH215 is almost certainly the protection chip which mixes up the main program rom data lines in a programmable way. For my 3 board conversions I removed this chip and then linked the second set of program rom data lines across to the first set. As you only have one pair of program roms sockets you would have to work out where to link the data lines.

The other thing you would need to find is the GAL (CP1B1F) that controls the GFX rom control / address lines as this will need replacing.

When I was first doing the conversions I did play around with encrypting the program roms so as to stop having the remove the MACH chip and do the patch wires. The problem was this induced extra delays which affected games like Strider.

Anyway, CPS1 games in my patcher are 1941, Ghouls & Ghosts, Mega Twins, Mercs, Nemo, Strider, Varth, Willow.

 

[rockbottom]

Thanks GadgetFreak, I am indeed aware of your tool, used it a few times in the past, excellent work

Regarding the board itself, I don't think it's super rare, i've seen a few for sale over the years but this is the first fully working example that's come along at a price i'm willing to pay.

Regarding the protection chip and mapper pal/gal, remains to be seen if they're same as the other variant or unique to this board. I'm quietly confident, this hardware does seem exact CPS1 condensed onto a single board unlike most common CPS1 bootlegs. We'll see...

Actually my biggest dilemma is whether to actually do this at all or rather just remove the A/B chips to see if they work on original Capcom hardware. If they do work that would actually be quite a big deal, especially the A chip, as there's currently no way to repair all those A boards that are dropping like flies.

Although I don't like sacrificing boards (even bootlegs) to repair others it would be nice to know if it's an option. Decisions, decisions...

 

[GadgetFreak]

Comparing the Program rom files with the Mame set should show if the protection chip is the same. Due to the lack of secondary program rom sockets the 8 data lines could be sorted using the pins on the Mach215 socket.

 

[rockbottom]

Received the board today, good condition and fully working. It's actually really good, much better than the typical single board bootlegs. Nice clean video and sync, nice sound, everything works properly in test menu, screen flip, memory test etc. Whoever made this thing obviously went all out to create an exact replica of the CPS1 hardware!

The A/B chips seem pin compatible (at least power + gnd are in right places), however the supply pins are fed through a power diode. That's a real bummer in terms of robbing the chips to fix original boards as it most likely means they're really 3.3v asics (common bootlegger method seen a lot with neogeo bootleg carts etc.)

In terms of PALs, there's a total of 8 (16v8) which matches the 5 on original A board and 3 on original Pang 3 B board. Protection chip is Mach215 same as original. Of course remains to be seen if they're programmed the same, most likely secured but perhaps bruteforcable.

That's all for now, next up is pull and read roms, see if they match pang3b in Mame...

 

[rockbottom]

The other thing you would need to find is the GAL (CP1B1F) that controls the GFX rom control / address lines as this will need replacing.

When you create your PAL equations, do you use pin 15? Looking at the equations for stock CP1B1F, it seems pin 15 is unused (and pin 16 is pass-through for pin 1).

On this board pin 15 is OE for both gfx roms, just the first minor difference I guess, probably more to come

 

[rockbottom]

Dumped some roms, the second encrypted program rom matches pang3r1 in Mame so good news there (encryption is the same), the first non-encrypted rom is unknown (not in Mame or FBN) but looks very close to pang3r1 also.

The pal is secured (as suspected

), have made a bruteforce dump but have yet to extract the equations.

Gfx matches official sets.

Sound.. todo...

 

[GadgetFreak]

When you create your PAL equations, do you use pin 15? Looking at the equations for stock CP1B1F, it seems pin 15 is unused (and pin 16 is pass-through for pin 1).

On this board pin 15 is OE for both gfx roms, just the first minor difference I guess, probably more to come

NO, on a standard Pang3 board pin 15 is OE and pin 16 is CE1 for the first pair of GFX rom sockets.
So not sure what equations you were looking at but it would look to me like the board could well match a stock Pang 3.

 

[rockbottom]

...not sure what equations you were looking at...

stock CP1B1F from Mame pang3 set. The issue was jedutil spits out:

o13 = i4 & /i11 +
i9 & i11
o13.oe = vcc

/o14 = /i9 & /i11
o14.oe = vcc

o15 =
o15.oe = vcc

o16 = i1
o16.oe = vcc

o17 =
o17.oe = vcc

o18 =
o18.oe = vcc

o19 =
o19.oe = vcc

so what are pins 15, 17, 18, 19 doing? I assumed in meant they're just not used but then with another tool found out pin 15 is b'0' (which makes more sense

) Just a jedutil issue I guess...

anyway confirmed the pal is the same, however pin 11 is used in the equations but is not connected to anything on this board. The device is atmel atf16v8b which does have pullups on inputs (not all pals do), so looks like bootleggers are relying on that pullup for correct operation, but my question is what function is pin 11 on stock pang3 board? Do you use it in your equations?

 

[rockbottom]

Another discovery, the clone B chip is a B17, not a B21

Looking at the code running in Mame, it's the pang3r1 set hacked to run on a B17 chip rather than the usual (for pang3) B21.

That's a bit of a disappointment, as it's fixed config and the only stock games that will run are a few versions of sf2ww.

Hopefully Arcade Rom Patcher "any-c" patches will work for those games it supports, assuming the clone B chip reports the id correctly (also assuming that's how any-c detects the B chip), doesn't appear to be any id checking code in the bootleg or stock pang3r1 so jury's still out on that.

Guess i'll have to burn some roms and see what happens...

 

[rockbottom]

Well no luck with this, tried a few any-c patched games and tried the decrypted
16 rom from Mame set pangb. Can't get anything to run, just black
screen.

@GadgetFreak, about this mod on the
stock Pang 3, it's just remove the Mach chip and link the 2 program rom
lines d0-d7? That's what i've done here, but i'm not sure what you're
getting at in your posts in this thread about soldering to the Mach etc.
My single pair of sockets is equivalent to 16 and 17 on stock board
afaik. Are the stock board unused sockets (12-15) used in your conversions?

...I did play around with encrypting the program roms so as to stop having the remove the MACH chip and do the patch wires...

Any chance you could share your encryption code

rockbottom2020-02-20 17:44:18

 

[GadgetFreak]

Your problem will be that you don't have a second pair of program rom sockets to link the data lines from as on an original Pang 3.
You will need to link 8 pairs of pins on the Mach215 socket. Do you have a standard Pang 3 board you can buzz them out on? If not I may get some time in the next few days.
Will need to dig out the source, but don't think its very user friendly, just a hack to do the job I needed.

 

[rockbottom]

No, don't have standard Pang 3 unfortunately.

I've buzzed the data lines, I have:

d8-15 common to both roms 16, 17 and the 68k

rom 16 d0-7 go rom -> mach -> 68k

rom 17 d0-7 go direct to 68k

that's all exactly as I would assume knowing (from mame) that only the low byte of rom 16 is encrypted.

I'm wondering now if they've used some spare pins on the mach for something else (20+ spares pins?) and by removing it i'm breaking that something.

But that said, I'm not clear on how the second pair of program rom sockets is involved. The only picture of the mod I could find (in the Arcade Rom Patcher thread) shows the roms in sockets 16 and 17 and d0-7 of those same sockets linked, which is exactly what I have done.

I'm also having a hellish time trying to reverse the decryption code in mame, so as to be able to encrypt other roms into Pang 3 format. (my brain wasn't built for crypto stuff

)

managed to reverse the decryption code, so can hopefully now encrypt any rom, will attempt some games with the mach in place and no wire mod...

rockbottom2020-02-21 02:59:16

 

[GadgetFreak]

Sorry, being stupid, it's been ages since I did these patches. You are correct in that linking D0-D7 from 16 to 17 is correct.
On a Pang 3 board you have to setup a port address to get the Mach215 setup so it requires code mods I think but my memory could be bad on this as well

A few things that come to mind are:
Have you found the correct GFX mapping GAL on the board CP1B1F.
The C chip may not have its ID setup correctly being a bootleg. I did leave a way to hardcode the C Chip in the routine with a single byte but its at a different offset for each game. If you tell me which game you want to try I can look up the location.
Generally though, even when the C chip is not being setup correctly you can still run the board. Often with a black screen but you would still be able to clock credits etc and hear the sounds after the initial boot delay.
GadgetFreak2020-02-21 11:50:27

 

[rockbottom]

Thanks GadgetFreak, this is turning into more of a pain than I thought it was going to be

nice to know the mod is correct, one thing I can check off the list

...On a Pang 3 board you have to setup a port address to get the Mach215 setup so it requires code mods...

oh crap, more fun and games

would be great if you could provide any specifics reguarding that.

Have you found the correct GFX mapping GAL on the board CP1B1F

yes, and dumped it, and confirmed it is same as original.

The C chip may not have its ID setup correctly being a bootleg

yes, that's another thing I still need to confirm

If you tell me which game you want to try I can look up the location

thanks, i'll shout if I need it

...Often with a black screen but you would still be able to clock credits etc and hear the sounds...

not sure if the board is running with no gfx or crashed, haven't yet socketed the sound roms so for any other game obviously the sound code and samples are wrong. I hoped even in that case there might be some activity (even if just random noise or wrong samples or whatever) to reveal the game is running, but nothing observed.

The weirdest thing i'm currently looking at is:

running decrypted rom 16 with no mach and wire mod, this should work fine and does in mame.

however, on the board, it gets a bit further than the any-c games, some gfx activity, then crashes with "credits: /2" displayed bottom right corner of the screen.

Can't see any obvious reason for this, I'm thinking perhaps the bootleggers have used some spare pins of the mach for some other task and by removing the chip I'm breaking that something, but that's pure speculation at this point. Another possibility is without the mach, introduces some subtle timing issue like you found with Strider.

Not actually sure now whether to proceed with decrypted rom/no mach/wire mod approach,

or (now that I can encrypt other roms) just stick with mach/no mod hardware... decisions to make

 

[rockbottom]

Made some progress, i've found ghoulsu with any-c patch and encrypted rom 16 will run with mach and no wire mod, but i'm getting some general weirdness, reboots, minor gfx problems, dips not working etc.

So a bit further forward, at least proves the bootleg B chip is reporting correct id.

 

[GadgetFreak]

Did a little digging back in my notes. The Pang3 boards have a 1024bit eeprom which appears at $80017A-$80017B. The strange thing is there is also a read from $80017A that occurs at the start of the VBlank interrupt code. I am fairly certain that without this regular read the Mach chip does strange stuff. Certainly when I was playing with encrypting Rom16 and leaving the Mach chip in I had this read in my code.
It is not connected with the read/write of the eeprom as it is disabled when this is done.

 

[rockbottom]

Oh I forgot all about this thread

I got other games running in the end, turned out there were a couple of minor faults on the board which bizarrely didn't affect Pang3 but did affect any other game I put on the board. I've actually turned the board into a rather crude homebrew multi-game with Ghouls 'n Ghosts, 3 Wonders, Final Fight and SF2 switchable.

I gave up on the Mach but have researched it's workings as much as possible. It does indeed require a "kick" every vblank else it seems to stop decrypting the code. As well as protection it also outputs 2 control signals which switch the eeprom in/out data onto the main 68k data bus which explains why decrypted Pang 3 doesn't run without the Mach as the eeprom read/write is also broken without it.

I've also dumped and reversed the other 2 PALs which reveal the encrypted/decrypted address ranges and the IO range which the Mach responds to. I won't post it all here but if anyone has any interest I can provide the details and a schematic.

Unfortunately I fell at the last hurdle, hoping to dump the Mach and somehow reverse it and reveal its secrets, I dug out my old early 90's era eprom programmer which supports the old Mach devices, built an adapter, fired up the old DOS 486 and of course.... damn thing is protected

Well, in hindsight I guess it would be too ironic if a protection chip was not itself protected

If anyone does have any kind of dump of this chip I would very much like it. Whilst searching I found a single reference on some old forum years ago of someone having it, then loosing it, then needing it, so asking if anyone else had it, but no replies. So maybe it is out there somewhere... perhaps

 

[GadgetFreak]

The eeprom is a serial device, not memory mapped, so I would imagine the Mach chip is just making the few signal connections much like it does with the lower 8 data bus lines.

 

[dankcomputing]

I have one of these and am trying to convert it to Varth. Every PAL on it I've tried to dump is protected, as is the mach. Are any of the dumps of the PALs submitted anywhere? Which one is the CP1B1F? Which ROMs are which on this board?

Currently I'm trying to remove the mach and just jumper it out. Really don't understand why the bootleggers spent the cash to reproduce the protection and didn't just patch it out entirely.

dankcomputing2021-11-09 21:19:25