AppIe IIGS logic board troubleshooting #2

[groink]

I have another Apple IIGS logic board, ROM01. Very clean board - no corrosion on the top or bottom. None of the chips appear to have any corrosion. Battery has been removed. No cards installed.

All power lines are there. No short-to-ground going on. Power supply is good. 65C816 is a good CPU, as it works fine in my other ROM01 boards. ROM - also good and tested on other boards.

On with the bad board. Powering it on, it displays these pink boxes, with some green stripes here and there.

First I test the CPU... Using a logic probe, the CPU resets on pin 40, and the address and data lines appear to be good (LO/HI at different speeds.) Although the CPU is a good part, upon power on, pin 38 is stuck on LO.

On a working IIGS ROM01, upon power on, pin 38 switches between HI and LO, and once the "check startup device" appears, pin 38 is permanently on HI. Nothing really documents the function of pin 38 other than the following I found:

38 M/X "Memory and Index lines" (Output). Tells you if the Accumulator (M) and Index Flags (X) are set -- like E, this gives you information about which mode the processor is in. Most people don't care, and it's hard to think of some real-world use for this pin anyway. -- Leave unconnected.


Again, the broken board is stuck on LO at pine 38. Reading the schematics, pin 38 is not connected to anything. Reading around the web, pin 38 is normally not used, and in many applications, they suggest no connecting it to anything. But still, M/X may be telling me something about the state of the CPU at such an early stage of booting.

 

[cruff]

That sounds like the processor either stopped running or is stuck in a loop where the instructions that are executing do not change the state of the M and X flags. Have you verified that the ROM and RAM are good?

 

[groink]

That sounds like the processor either stopped running or is stuck in a loop where the instructions that are executing do not change the state of the M and X flags. Have you verified that the ROM and RAM are good?

ROM is good. I've already tested the ROM in another logic board, and ran the diags on it. RAM is the next thing I'll have to test. I do have some extra DRAM from a previous repair. Does the piggyback trick on the DRAMs also work on the IIGS boards?

 

[groink]

I think I've found the answer to my question about using the piggyback method for testing DRAMs. This method will only work if the CAS circuitry on the DRAM is faulty. If CAS was indeed not working on the soldered-on DRAM, then piggyback would work as the piggyback chip will receive the CAS signal and therefore would take over that spot of the logic board. But if the soldered-on DRAM is functioning but one of the address or data pins are not working, then piggyback would not work because you'd then have two chips receiving the same CAS signal, and that would confuse the heck out of the logic board.

Looks like the only true way to test RAM on this board is to unsolder/socket each of the four chips until I find the bad one.

 

[groink]

Some progress, if you want to call it that....

I went full-on and removed all four DRAMs, installed sockets, and tested all the pins along with the schematics. Leaving out the DRAMs for now, M/X is still LO with just the CPU and ROM. But when I also remove the ROM, M/X is HI, although, during the RESET phase, M/X doesn't switch HI-to-LO-to-HI like a functional board would do. I added back just the DRAMs, and M/X remains HI. So M/X freezes at LO only when the ROM is installed.

Again, I'm positive that the ROM is good, and I've already tested the ROM and CPU together on another board and they work. So I believe that the bootstrap loader off the ROM is causing the CPU to freeze up. But because CPU and ROM are good, I'm now leaning towards management of the ROM during the bootstrap cycle.

Reviewing the schematic, the ROM is managed by UK5, UJ5, and UI5 - all of them are 74HCT245 parts. They are SMDs on the logic board, so I can't exactly easily pull them and test. Fortunately, I have an adapter to turn the SMD into a thru-hole package, a hot air station, and the TL866II Plus. So in the coming days, I'll test all three 74HCT245's. I've already tested the address and data lines from the ROM to the 74HCT245's, and resistance is very low, so I'm confident the connections are good and there's no short-to-ground going on. Can't say the same for the 245's internally at this stage.