What's new

ekorz

Multi Boyz 4 Pi
Legendary
Multi Boyz
Joined
Aug 21, 2016
Messages
5,187
Reaction score
7,770
Location
Boston, MA
To add to my Lucky Moron PCB Repair series, I decided to start this sub-chapter called Boot Camp. Previously I fixed things that were just sort of not-working, but now we'll really get into it where the board doesn't even boot. To add to the fun, I don't actually know what I'm doing and don't have the solution worked out just yet. So if you're new to this, enjoy my flailing and probable failure. If you're good at this, chime in and let me know if I'm on the right path. Remember I only have to be right once!

First up, my previously working Gundam EX Revue seta2 board. It booted. Now it don't boot. Lucky for me I have the same PCB running Guardians, so I can cheat a little.

1) Power. Check. Chips are getting lovely 5v.
2) Program Roms. Check. Verified with MAME I'm running this one
3) Work Ram, I didn't see anything immediately wrong with the LH52B26D-70LL when logic probing
4) Clock, clocking. My oscilloscope shows me a nice clean strong signal.
5) Reset. It's resetting(!) Reset on this Toshiba CPU is active low, and it bumps low every second or two....

Is that a watchdog? What a weird name. So it barks "reset" because something in the circuit is broken? Why even build that? My korean Guardians doesn't look like it has one, just saying... Anyway I wrote out a whole schematic - look at it really! It's dope! I also compared the inputs and outputs with my Guardians pcb. And I think I found something!

The reset signal seems to come from U23, 74LS161. That's a counting chip as far as I can tell. It gets a clock signal from a little loop between a 74HC14, a resistor, and a capacitor. How? No idea, but that little loop generates a clock-like signal. The chip counts based on that clock. It just counts and counts until something resets it, and if nothing resets it - it freaks out and pumps output signals (namely the one that is resetting the cpu). Normally there is a combination of a few signals that decide if the counter resets, but on my board all the other options are grounded (i.e. out of the equation). There's only one thing that sends a reset signal -- MR, pin 1, Master Reset.

On my working PCB I can see MR get pulled low periodically. On my non-working PCB, MR stays high. So the watchdog counter is never reset, and my pcb gets a jolt from it every time the counter fills up.

So, what generates the periodic reset signal, you might ask?

A GAL16V8 at U51 :(

Anyone got a dump? KA-101, might be used on some Guardians boards too, but sadly not mine.
 
Last edited:
...couldn't give up for the night and I just learned that the GAL takes a CLOCK signal also?! Who knew?

Updated Schematic: https://i.imgur.com/y6EVWLT.png

That clock signal comes from the CPU through a 74LS11, and the output from that does not look at all like a signal with 5v peaks. On my Guardians it certainly is. And the inputs from the cpu look similar.

So while I wait for someone to come up with a GAL dump I'm going to order a 74LS11 and replace that chip. Fingers crossed.
 
So, what generates the periodic reset signal, you might ask?



A GAL16V8 at U51 :(
Usually code writes to a dedicated port or address to kick the watchdog. I assume that GAL just decodes the address.

Of course if CPU crashes it never writes anything and watchdog kicks in.
 
Usually code writes to a dedicated port or address to kick the watchdog. I assume that GAL just decodes the address.
Of course if CPU crashes it never writes anything and watchdog kicks in.
I was looking for that sort of kick, but didn’t find one. Maybe as you say the cpu isn’t doing that job, but it is at least active and generating the signal that the 7411 should be passing to the GAL.

Would it be something a signal from RAM connecting to the 74161, one of its inputs? If this chip replacement doesn’t yield results, I may ask for some additional pointers on where that kick might be hiding...
 
Well, I replaced the 74LS11 with a known working one, and I still have a black screen / no boot. I must then assume that the CPU isn't generating the signal to kick the watchdog. I'd like to kick the watchdog myself at this point, it's being a jerk.

What's next in line? If the CPU isn't writing the signal, but the program roms are good (guess i can doublecheck those...) should I be looking more closely at the work ram? What would I be able to see in a probe/scope that would indicate an error, or should I just remove/test them?
 
Next stop... work ram? On my Guardians board the N341256P-20 ram shows activity reaching 5v peak on every address line. On my Gundam EX board there are a few lines that never oscillate peak to peak. A5, A7, A8, A9.

So what's wrong? I dunno! But that's not right!

Taking a look at two, say A8 and A9.
A8 in reset is 1.8v, then when it's supposed to be operating it's noise-like-signal between 0v and 0.2v.
A9 is the opposite, in reset it's 1.8v but when operating it's basically noise 5v +/- 0.2v.

On my working board both are held at 5v during reset. I'm using the reset button to do reset.

Both lines are connected to ROM address lines directly on one side. The ROMs are checked out.

On the other side, they're connected to... more logic chips.

Also, the CE pin is basically always high and the datasheet shows a line above CE, which I think means active low. So that's not right either. It should also oscillate. That ties to the CPU, looks like pin 76 CS1 (also active low).

Here I'm not sure how it all operates. But that probably won't stop me from shotgunning some chips anyway! So is the CE line not engaged by the CPU because of something workram/logic related? Or is it the reverse? Or both?

Stay tuned.
 
Last edited:
/CE for my program roms are also not firing on two of them (serves me right for assuming they were all connected). That circuit leads back to my good friend GAL at U51 too. Am I going in circles now?

Could use a dump for that chip to be sure! Sigh...
 
Here are the things that look wrong, and the state of affairs:

Work RAM /CE is fine. (incidentally connected to the other gal at U52)
Work RAM /CS goes to the CPU's CS1 line, and always stays high
2 Program ROM /CE always stays high and is connected to my good friend the GAL U51
Address lines on the RAM (that don't fluctuate) are connect to address lines on the Program ROMS, and also to a 74LS244 but are all inputs there

I desoldered the extra program ka-001-005.u77 even though it ran in mame without it. It verified fine unsurprisingly.
I desoldered and dumped my questionable GAL 51 so I could take a look at the brute-forced equations. They are very similar to the KA-201 dump I verified, so I'm thinking that this chip is actually fine.

Time to remove and replace the CPU because IDK what else to do really. And who doesn't love dealing with QFP100?! I wish I had a 100% way to tell it was a broken cpu for sure, but I got nothing else right now. Best I can tell, the CPU is supposed to be generating the /CS signal and it is not. I don't know where it's pulling that signal from or how it's computing it, or really the order of operations here between ram/rom/cpu but someone feel free to chime in before I perform the surgery :evil:
 
Last edited:
New cpu :thumbsup:
still broke :thumbdown:
 
Back
Top