Interesting pirate PCB

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderators: B00daW, Moderators

Post Reply
User avatar
Fisher
Posts: 1114
Joined: Sat Jul 04, 2015 9:58 am
Location: -29.794229 -55.795374

Interesting pirate PCB

Post by Fisher » Mon Sep 21, 2020 2:43 pm

Hi.
I've got an pirate The Punisher cartridge wich the PCB uses what seems to be a OR gate with a resistor and a diode, plus a PPU A12 deglitch capacitor printed on board.

The OR gate works fine, no doubts, but any chances of this "printed capacitor" to work fine?
Probably I can just figure it out by trying, but I would like to know what do you guys think.

Thanks in advance.
Attachments
Assembled game
Assembled game
Components side
Components side
Solder side
Solder side

User avatar
Jeroen
Posts: 1044
Joined: Tue Jul 03, 2007 1:49 pm

Re: Interesting pirate PCB

Post by Jeroen » Mon Sep 21, 2020 2:52 pm

Any "plates" with distance between them will act as a capacitor. So it'll be a small value, but yes those tracks will act as a capacitor. (And it probably doesn't have to be a very large value if it's just smoothing out fast transients.)

edit: Note that if you want to try this yourself. I recommend against it. Capacitors are essentially free and you'll get more consistent behavior out of anything you produce this way.

edit2: looks like the pirates also populated it with a real cap instead of the traces? It might have been an experiment they tried. Maybe they couldn't get the value large enough to work.

lidnariq
Posts: 9796
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Interesting pirate PCB

Post by lidnariq » Mon Sep 21, 2020 2:57 pm

Fisher wrote:
Mon Sep 21, 2020 2:43 pm
The OR gate works fine, no doubts, but any chances of this "printed capacitor" to work fine?
Work fine, yes. Be any significant amount of capacitance? Not so much.

Assuming that's a 1oz pour (34 µm thick), 10 thou (250µm) trace spacing, and 600 thou (15mm) long bits, that capacitor is has a cross-sectional area of 34µm·14·15mm = 7 (mm^2). The resulting capacitor should have a capacitance of ε·area÷separation, where ε is the average of FR4's and air's permittivies. This works out to about 1 pF...

User avatar
Fisher
Posts: 1114
Joined: Sat Jul 04, 2015 9:58 am
Location: -29.794229 -55.795374

Re: Interesting pirate PCB

Post by Fisher » Mon Sep 21, 2020 3:28 pm

Jeroen wrote:
Mon Sep 21, 2020 2:52 pm
looks like the pirates also populated it with a real cap instead of the traces? It might have been an experiment they tried. Maybe they couldn't get the value large enough to work.
It was me who put both capacitors when I was trying to fix the game, since it crashed and the HUD jumped a lot.
The jumping HUD was fixed with the capacitor, but the game still crashes a lot.
I just learned about the one on the PCB after I disassembled it for better cleaning.

I'll try to dump it to test if these problems are caused by some modification made by the pirates.
lidnariq wrote:
Mon Sep 21, 2020 2:57 pm
Assuming that's a 1oz pour (34 µm thick), 10 thou (250µm) trace spacing, and 600 thou (15mm) long bits, that capacitor is has a cross-sectional area of 34µm·14·15mm = 7 (mm^2). The resulting capacitor should have a capacitance of ε·area÷separation, where ε is the average of FR4's and air's permittivies. This works out to about 1 pF...
Yeah, a lot less than the 120pf needed for a proper deglitch.
I think I'll stay with the capacitor I've put on it before.

Thanks for the info.

krzysiobal
Posts: 793
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland

Re: Interesting pirate PCB

Post by krzysiobal » Tue Sep 22, 2020 12:24 am

As expected, such PCB like this one (glob MMC3 + two DIP28 mask-roms) havs some shuffled lines for anty-copy (this time:
MMC3-PRG-A15 -> PRG-ROM-A16
MMC3-PRG-A16 -> PRG-ROM-A15

MMC3-CHR-A15 -> CHR-ROM-A16
MMC3-CHR-A16 -> CHR-ROM-A15

Other than that, MMC3 pinout matchesy the AX5202P (except the non-used pins)
Image Image Image

User avatar
Fisher
Posts: 1114
Joined: Sat Jul 04, 2015 9:58 am
Location: -29.794229 -55.795374

Re: Interesting pirate PCB

Post by Fisher » Tue Sep 22, 2020 3:57 pm

krzysiobal wrote:
Tue Sep 22, 2020 12:24 am
As expected, such PCB like this one (glob MMC3 + two DIP28 mask-roms) havs some shuffled lines for anty-copy (this time:
MMC3-PRG-A15 -> PRG-ROM-A16
MMC3-PRG-A16 -> PRG-ROM-A15

MMC3-CHR-A15 -> CHR-ROM-A16
MMC3-CHR-A16 -> CHR-ROM-A15
Great!
That explains why I'm having trouble.
That swapped A15 and A16 are really driving me nuts!
Thanks for the information, I'll try to rebuild it with another flashrom.

User avatar
Ben Boldt
Posts: 612
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: Interesting pirate PCB

Post by Ben Boldt » Wed Sep 23, 2020 2:38 pm

Do you know, with SRAM, you can put address lines and data lines in any order? :) ALWAYS you see special routing to keep them correct, nobody must realize it.

User avatar
Fisher
Posts: 1114
Joined: Sat Jul 04, 2015 9:58 am
Location: -29.794229 -55.795374

Re: Interesting pirate PCB

Post by Fisher » Wed Sep 23, 2020 4:29 pm

Ben Boldt wrote:
Wed Sep 23, 2020 2:38 pm
Do you know, with SRAM, you can put address lines and data lines in any order? :) ALWAYS you see special routing to keep them correct, nobody must realize it.
That's great!
I think these pirates had figured it out back on the day.
They even "swapbinned" the PRG! :-D
https://drive.google.com/file/d/0B0OtMD ... sp=sharing
https://drive.google.com/file/d/0B0OtMD ... sp=sharing

After unswapping the ROMs, they seem to be mostly the same as the original.
There's only small copyright logos removed from the CHR.
I'm sharing the IPS, not sure if a ROM like this already exists.
Pirate Punisher.ips
(40 Bytes) Downloaded 33 times

User avatar
aquasnake
Posts: 134
Joined: Fri Sep 13, 2019 11:22 pm

Re: Interesting pirate PCB

Post by aquasnake » Thu Sep 24, 2020 11:09 am

Ben Boldt wrote:
Wed Sep 23, 2020 2:38 pm
Do you know, with SRAM, you can put address lines and data lines in any order? :) ALWAYS you see special routing to keep them correct, nobody must realize it.
not really, some kinds of MCP have 2 dies inside, and the highest address actually is the driving pin of CS.
the CS pin's input delay is much larger than other address pins', had better use for the highest address control(ram banking), not suitable for the lower address pins(random accessing)

User avatar
Ben Boldt
Posts: 612
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: Interesting pirate PCB

Post by Ben Boldt » Thu Sep 24, 2020 4:56 pm

aquasnake wrote:
Thu Sep 24, 2020 11:09 am
not really, some kinds of MCP have 2 dies inside, and the highest address actually is the driving pin of CS.
the CS pin's input delay is much larger than other address pins', had better use for the highest address control(ram banking), not suitable for the lower address pins(random accessing)
That is an interesting point I had not thought about, or even considered that RAMs might have multiple dies inside. I don't see the problem though, how is that different than using the real CS? Code mostly runs from ROM and will be toggling back and forth with the CS's constantly anyway.

lidnariq
Posts: 9796
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Interesting pirate PCB

Post by lidnariq » Thu Sep 24, 2020 5:00 pm

I've definitely heard of Flash (and RAM-and-something-nonvolatile) that worked that way, but I haven't yet heard of RAMs that had two dice and a demux.

User avatar
Fisher
Posts: 1114
Joined: Sat Jul 04, 2015 9:58 am
Location: -29.794229 -55.795374

Re: Interesting pirate PCB

Post by Fisher » Mon Sep 28, 2020 6:35 pm

That's interesting.
I also figured out that the ROMs are fine.
The problem probably is caused by the weird PCB design with some short edge contacts and even some holes that I think are too close to them.
There are some contacts that doesn't connect properly, causing weird bugs on the games.

I tried Shadow of the Ninja, and it froze at the title screen, rarely going to the history.
Mighty Final Fight usually showed a black screen, some times going to the "licensed by nintendo" screen others it even started but suddenly had bugged graphics and soon froze.
Some clones are a lot more susceptible to these glitches, probably because the difference of the cartridge connectors.

The pin that I think that is most critical is the M2 signal.
Looks like poor contact in there can make the game randomly freeze.
Is this assumption correct?

User avatar
aquasnake
Posts: 134
Joined: Fri Sep 13, 2019 11:22 pm

Re: Interesting pirate PCB

Post by aquasnake » Sun Oct 18, 2020 11:08 pm

Ben Boldt wrote:
Thu Sep 24, 2020 4:56 pm
aquasnake wrote:
Thu Sep 24, 2020 11:09 am
not really, some kinds of MCP have 2 dies inside, and the highest address actually is the driving pin of CS.
the CS pin's input delay is much larger than other address pins', had better use for the highest address control(ram banking), not suitable for the lower address pins(random accessing)
That is an interesting point I had not thought about, or even considered that RAMs might have multiple dies inside. I don't see the problem though, how is that different than using the real CS? Code mostly runs from ROM and will be toggling back and forth with the CS's constantly anyway.
By switching two SRAMs according to address, we need to use an additional multiplexer. By decoding the highest address, two CS are generated. In the total access speed, the delay of a multiplexer will be added. In this way, due to timing constraints, the original SRAM speed may not meet the system requirements. Or a higher bandwidth multiplexer is needed to reduce latency.

On the other hand, the frequency of the input signal of the multiplexer determines the stability of the output line. The higher the input signal frequency is, the greater the leakage current of the device is, and the more unstable the output jitter is. Generally, the change rate of upper addresses is lower than that of lower addresses, so it is recommended to keep the highest address (1 bit) in order, and the other addresses can be disordered.

The above is only my personal opinion. In most cases (256K bit SRAM), there is no problem in randomly staggering address lines or data lines.

Post Reply