Any PGM Conversion info out there?

[Nebula]

PAL labels are in tact, and look original. DH U1 and DH U7. Here are the images from my boardset, I can work on pulling/dumping pals, but it'll probably be this weekend before I can devote much time to it. Also these we're just quick cell photos prior to dumping, I can get more detailed ones or trace out connections with my meter if needed.

GFX board seems to be from:
- IGS PCB NO-0213 (GFX) - Knights of Valour Plus
and PRG board from:
- IGS PCB NO-0179 (PRG) - Killing Blade

I wonder why they are not using GFX board from Killing blade... what would be different from it?

 

[twistedsymphony]

I wonder why they are not using GFX board from Killing blade... what would be different from it?

I don't know but I have a bad feeling we'll have to map out the whole damn thing if we want to figure out why

Honestly the KB GFX board holds the right amount of data, so I think it's mostly a matter of the logic ICs lining up properly, we can probably "make it work" it's just a matter of mapping it all out and seeing what's different and then seeing how much modification is required.

 

[Fluffy]

I wonder why they are not using GFX board from Killing blade... what would be different from it?

I don't think the GFX board has to match up, as long as it has the right minimum number of ROM footprints. It depends on where they get the boards from, if they are recycling broken cartridges it could be that they use up whatever is working.

 

[twistedsymphony]

I don't think the GFX board has to match up, as long as it has the right minimum number of ROM footprints

There definitely are some differences between the boards. If you're using a KOV2 GFX board for conversion then you need to modify the logic IC attached to the sound ROM. If you're using a KOVSH GFX board then no modification is necessary.

BOTH games have the necessary footprints.

so if you want it to work the GFX board has to match up... or you have to MAKE it match up.

 

[neofrank]

Thought clearer PCB scans might help, so I did these on a flatbed scanner of both boards front and back with the chips removed.

If anyone has dumping info on these PALS (if they are needed) and can point me in the right direction on some info, I have little to no experience with programming/reading them. U7 appears to be a 16V8 (which appears to read and gives me some varying data in L002048 and L002112) and U1 a LV22V10 (I am getting straight 1s on a read attempt with it)

ESPGaluda PCB Images

 

[xodaraP]

The factory PALs will have had the security bit flipped so they won't be readable without techniques that very few people know and those that do tend to keep it to themselves

But I think @twistedsymphony confirmed the ROMs are the same as what we've seen previously and it sounds like the PALs are factory as well or if they are new, have been protected as well

Scans of the boards will be fantastic, thank you very much for your help, hopefully we'll spot something we missed

 

[twistedsymphony]

I think at this point I'm pretty well convinced that the U1 PAL is custom.

@neofrank and @EVAWINGZERO both sent me some high resolution photos and I don't see any indication of additional jumper wires or trace cuts.

HOWEVER I noticed that while one of them has the "DH U1" label on the U1 pal the other has a "DH U8" label... I've tried swapping in the U8 PAL into the U1 slot just for shits and (unsurprisingly) it doesn't work.... so I'm inclined to believe that these are re-written and one of them happened to simply rewrite the U8 PAL for use in U1 since it needs to be pulled anyway.

 

[xodaraP]

Given they're PALs and not GALs I thought they were write once chips, could be they're repurposing the stickers to make it look more original

Interesting, unfortunately that means we need to get the PAL dump

 

[Fluffy]

It is one of those "it depends" things. GALs are erasable and re-programmable. But I think there are PALs where the fuses are stored in flash memory as well.
Of course without looking at the actual device type and datasheet you can't tell if it isn't some special case.

 

[xodaraP]

U7 appears to be a 16V8 (which appears to read and gives me some varying data in L002048 and L002112)

Someone with more knowledge than me on PALs will need to answer this, but is it possible the reason there's varying data in this area because someone has used a programmer to modify an existing bit on the PAL?

Since its fuses it obviously can't change that bit but maybe is caused a variation?

@neofrank any chance you can post up a dump of that 16V8?

 

[Asure]

Any software out there will generally write them in one go, from top to bottom of fusemap.

GALs were made for this and can simply be erased and rewritten. If any bootleggers needed to mod a PAL they simply cut traces or rewire it so the function becomes inverted or not AND or NOR or whatever

So, chances the PAL was rewritten are so super low that i don't think it's what happened.

 

[twistedsymphony]

I have 2 more "shots in the dark" on this Killing Blade conversion before I throw in the towel

@EVAWINGZERO and @neofrank if you could confirm for me:

1. are any of the PINS on either of the PAL chips are cut off, or folded under the chip? neofrank you pulled the chips when you did your scan so I would think you should already know this off the top of your head.

2. The two diodes that were added on the top right. the joint in the middle of them... is that also soldered to a VIA? Could either of you check with a multi meter to confirm continuity or no continuity from this joint to this this via (in the pic below)

Like I said this is a total shot in the dark, but maybe they're pulling a sneeky one by using the voltage divider as a way to tie a line high that also disables the ASIC circuit or something...

I can't for the life of me see any other PCB modifications in these pics and the PALs DO look original, even if the labels don't make sense.

 

[Nebula]

Little offtopic about lastly discussed about kb conversions:

Some people are complaining about espgaluda cartridges have graphic errors on stage 4:

Seen on “Japanese Candy cabinets... “ FB group (I cannot share the link and paste here...)

 

[twistedsymphony]

Some people are complaining about espgaluda cartridges have graphic errors on stage 4:

the background ROM is the second ROM on the PGM PCB, usually a SMD.

I've played through my Sheep Nova converted KOV2 cart to the end and didn't notice anything.

One thing I did notice on those KB conversions though, is that they're adding a jumper to cut the capacity of that ROM in half, I haven't seen this on any other conversion (it could just be the model of the IC they're using). Also, the KB PRG PCBs don't have a built in voltage regulator, so they're using a crappy diode voltage divider... either one of these could be leading to this issue.

or, it could just be a cold solder joint on a higher address line that doesn't come into effect until the higher levels.

is this ONE person reporting this issue, or multiple people reporting the same issue?

 

[Nebula]

Yes, I have been a bit alarmist ... it has only happened to one afaik, so it is probably a defect simply in that cartridge, as you said.

 

[oneleaf86]

I've had issues with backgrounds before which were remedied by reflowing the solder on the SMD ROMS. One thing I've noticed on every single Espgaluda conversion I've tested (around 6-7) is that some boss explosion animations glitch out. To rule out some variables I've tested the cart on various PGM Motherboards, Cabinets and Superguns which all exhibited the same behavior.

It's not completely consistent though, I can do a full play through only seeing it once or it could show up more frequently.

 

[neofrank]

1. are any of the PINS on either of the PAL chips are cut off, or folded under the chip? neofrank you pulled the chips when you did your scan so I would think you should already know this off the top of your head.

Both PALS were complete and no bent pins, I looked over the sockets and didn't see any additional bodge wires / cut traces under the chips either.

I don't have the cart with me now, but tonight I can check continuity with that via.

 

[twistedsymphony]

One thing I've noticed on every single Espgaluda conversion I've tested (around 6-7) is that some boss explosion animations glitch out. To rule out some variables I've tested the cart on various PGM Motherboards, Cabinets and Superguns which all exhibited the same behavior.

It's not completely consistent though, I can do a full play through only seeing it once or it could show up more frequently.

what do you mean by "glitch out" as in the sprites look incorrect or the explosion animation is incorrect?

I'd be curious to know what the actual extent of the Program ROM modification is on these I know the BIOS is appended to it and the encryption has been changed, but it'd be nice to know if that's it or if there are other modifications that have been made.

 

[twistedsymphony]

Both PALS were complete and no bent pins, I looked over the sockets and didn't see any additional bodge wires / cut traces under the chips either.

that's what I suspected, but thank you for the confirmation.

 

[oneleaf86]

One thing I've noticed on every single Espgaluda conversion I've tested (around 6-7) is that some boss explosion animations glitch out. To rule out some variables I've tested the cart on various PGM Motherboards, Cabinets and Superguns which all exhibited the same behavior.

It's not completely consistent though, I can do a full play through only seeing it once or it could show up more frequently.

what do you mean by "glitch out" as in the sprites look incorrect or the explosion animation is incorrect?
I'd be curious to know what the actual extent of the Program ROM modification is on these I know the BIOS is appended to it and the encryption has been changed, but it'd be nice to know if that's it or if there are other modifications that have been made.

When the boss explosion animation starts, sometimes a part of the animation changes for a split second into a black and white glitchy mess. Hard to explain and even harder to capture an image of.