Mega Force PCB?
- Thread starter big10p
- Start date
I'll check. What was causing it?
Yes, I understand it's active low. Did you find what was causing it on your board?
This repair was for a 3 board set starforce with an encrypted cpu .At location J5 (74ls02)the wait signal comes from pin 10 and this was low,pin 9 was floating.
Traced pin 9 to a 74ls74 at location L4 where pin 9 output was floating,replaced ls74 and game booted and program was running but with corrupted graphics which I’m still trying to fix.
pull the cpu out of its socket and bend the pin 24 upwards so it does not go back into socket and tie this to +5v using a 1k resistor and see if it boots.
Traced pin 9 to a 74ls74 at location L4 where pin 9 output was floating,replaced ls74 and game booted and program was running but with corrupted graphics which I’m still trying to fix.
pull the cpu out of its socket and bend the pin 24 upwards so it does not go back into socket and tie this to +5v using a 1k resistor and see if it boots.
Thanks for the info. I'll give that a try. 👍
Yes, I'm thinking more and more this board is a complete dud. I will probably end up replacing so much stuff, it'll be a Trigger's Broom by the time it's working. Lol
In anticipation of the work ram being duff (since all other SRAM was dead), I've bought some 6116 replacements. I guess these are the 2 on the left of the Z80 that I need to look at?
I guess with no working CPU it's going to be difficult to tell if they're faulty? I will probably pull them anyway and socket a couple of new 6116s.
I'll need to buy some. Think there's a few more Fujitsu ICs on this board. Should I replace all Fujitsu chips as a matter of course, or just certain types? I've heard they're prone to fail.
favouredson
Super Star
- Credits
- 1,253CR
People should stop obsessing about Fujitsu ICs.
Yes, they had a period where their ICs were frequently sub-standard, but not all Fujitsu ICs produced during this time were dodgy.
Focus on actually finding the real faulty IC(s) rather than automatically suspecting any and every Fujitsu IC on a PCB.
I have numerous PCBs with Fujitsu ICs and, shockingly, they still work 40+ years later.
Of all the ICs I have replaced over the years Fujitsu account for no more than 10% of the total.
Remember, these items were not designed to last for the length of time they have, so be thankful that they still work at all...
Yes, they had a period where their ICs were frequently sub-standard, but not all Fujitsu ICs produced during this time were dodgy.
Focus on actually finding the real faulty IC(s) rather than automatically suspecting any and every Fujitsu IC on a PCB.
I have numerous PCBs with Fujitsu ICs and, shockingly, they still work 40+ years later.
Of all the ICs I have replaced over the years Fujitsu account for no more than 10% of the total.
Remember, these items were not designed to last for the length of time they have, so be thankful that they still work at all...
I agree with that. It's not always fujitsu.
But I've fixed a few PCBs simply by piggybacking fujitsus because when they fail they fail open so a piggyback works.
It's not a technical method of diagnosing issues but I just want to get a board working so I always start with the simple things.
But I've fixed a few PCBs simply by piggybacking fujitsus because when they fail they fail open so a piggyback works.
It's not a technical method of diagnosing issues but I just want to get a board working so I always start with the simple things.
Still working my way through this, tracing back to find why the watchdog counter isn't getting reset.
Having to trace back through a load of ICs has been tying my brain in knots, but I've found it stems from an ls139 (dual 2-to-4 line decoder/demux) that seems to be used for memory addressing.
A certain output on one decoder needs to get pulled low regularly, in order to reset the watchdog counter, but never does, because the enable pins (active low) for both decoders on the chip are being held high by the output of a couple of OR gates on a HC32. This causes all decoder outputs to be held high, despite activity on the input pins.
This HC32 and another one connected to it are both faulty, but looking at the way they connect to the ls139, I can't see how they can enable the decoders even when working. Anyway, I'll give my old brain a rest and replace them both, then continue the adventure...
Having to trace back through a load of ICs has been tying my brain in knots, but I've found it stems from an ls139 (dual 2-to-4 line decoder/demux) that seems to be used for memory addressing.
A certain output on one decoder needs to get pulled low regularly, in order to reset the watchdog counter, but never does, because the enable pins (active low) for both decoders on the chip are being held high by the output of a couple of OR gates on a HC32. This causes all decoder outputs to be held high, despite activity on the input pins.
This HC32 and another one connected to it are both faulty, but looking at the way they connect to the ls139, I can't see how they can enable the decoders even when working. Anyway, I'll give my old brain a rest and replace them both, then continue the adventure...
Retroman839
Senior Member
What’s the method to tie a resistor
To a chip leg ( pin 9 on the cpu)?
Thnx
Just small crock clips ?
Can you recommended some clips
To a chip leg ( pin 9 on the cpu)?
Thnx
Just small crock clips ?
Can you recommended some clips
I was pulling the WAIT pin high on a Z80 which is pin 24. The only things I had to hand were these croc leads and a clip. I'm sure there's something more suitable out there.