TI-99/4 troubleshooting

[Hans23]

Hi,

 

I have a bunch of sick TI-99/4's on my bench and two of the three were satisfying repairs - One had a dead TIM 9904, the other had a dead capacitor in the RESET circuit.  The third one, however, is giving me more trouble.  Its TIM 9904 and CPU were toast to begin with, but even after swapping them out, the console still does not want to start.  It seems that it gets stuck very early in the initialization process:

 

 

(yellow is RAM CS, blue is ROM CS)

 

It seems that it is reading the reset vectors from ROM, tries to save the old WS pointer in the new workspace and then gets stuck.  I swapped out U608 (one of the two MC6810P's) because two of its data bus lines never transitioned during the brief period of life of the machine, but apparently that was just a coincidence and the problem is somewhere else.  Any suggestions what to try next?

 

Thanks!
Hans

[Duewester]

Swap the other 6810? Reseat the GROMS?

[Hans23]

I swapped the other 6810 and the GROMs, no change at all.  It seems that the system hangs very early in the initialization cycle.  I was under the belief that the CPU actually reads the reset vector and then stalls within the execution of the initial ROM code, but from looking at the trace, it seems more likely that it is not correctly reading from the ROM and then jumps into nirvana.  As both the RAM and ROM have been verified as working, and I also checked everything that is on the MSB side of the bus ('244 and 9918), it should be either something in the control logic or on the LSB side of the bus.  But maybe I'm misinterpreting the scope output still.  Any additional insight would be appreciated.

[Hans23]

I've removed everything but the ROMs and the RAMs from the data bus to see whether the machine gets any further in the reset initialization process, but it does not.  It seems to me that this only leaves the READY signal as being incorrectly combined, but maybe I'm missing something?

[Duewester]

I always fear that one of the (upper or lower) roms is gonna be bad. I don't have the skills - tools maybe - to program new eprom(s).

[atrax27407]

The code is available for both EVEN and ODD byte console ROMS. BTW, the 6810s can be substituted with TMS2532 EPROMs. I have both. 

[Hans23]

I've also successfully replaced 4A console ROMs with 2764 EPROMS on two sockets with the required rewiring applied.  I'm not sure how you'd replace the 6810 RAMs with EPROMs though.

[atrax27407]

They are direct pin-for-pin drop-ins.

[Geoff Oltmans]

ROM checksum good?

 

[Hans23]

As I mentioned, both the ROMs and the RAMs are good, I've verified them to work in another console.  I have looked at the READY signal now and as I suspected, it is stuck low when the machine freezes.  Unfortunately, it is generated by a whole bunch of combinatorial logic and flip-flops, making it really difficult for me to pinpoint exactly where things go wrong.  I might end up having to desolder and test all of the chips involved

[Hans23]

This is the part of the schematic in question:

[Hans23]

I may be missing something here:

 

It looks as if the D input of the flipflop (pin 2) is connected to another two gate inputs and nothing is driving this network?  Me not reading the schematic correctly or error in the schematic?

Edited June 22, 2023 by Hans23

[JasonACT]

Have you tried some of the other 99/4's GROMs you own in this machine?  The 99/4A's boot has about 12 instructions before it does the dummy GROM read...  looks like you might be getting that far.

[JasonACT]

In the 99/4A schematic, QC (pin 13) is connected to that network.

[Hans23]

3 minutes ago, JasonACT said:

In the 99/4A schematic, QC (pin 13) is connected to that network.

That makes sense, thanks for cross checking.

 

I've put in a set of known good GROMs and the behavior is the same.  If I start the machine without the GROMs installed, though, it does not hang, so it seems that the CRU interface is involved in the fault.

[JasonACT]

Have you run the logic analyser over the GROM select?  I don't have many more ideas on this, but if the circuit allowing the GROM ready to pass through is activated, but the GROM isn't activated, then that may lock it up.  From what you say, it is the GROM ready being low that's locking up the console.

[Hans23]

 

It was indeed the GROMs that locked up the machine, and I think that the reason for that is that the GROM clock is wonky - If I understand things correctly, it is generated by the TMS 9918 and should always be present on the clock input pin of the GROMs.  I did not see it, though, so I started poking around in the VDP area and found that once I probe one of the clock output pins of the VDP with the scope, the clock starts ticking, video output sync is generated and the CPU executes instructions.  Black screen, still but some progress at least.  I've exchanged the socket and tried a known good VDP, so I now believe the problem is somewhere around the passives and the crystal that create the VDP clock.  I'm a bit puzzled, however, that probing with my 10x oscilloscope probe makes the clock generator work, but I don't know much about electronics.

[Hans23]

I swapped out the VDP crystal and now the clock comes up and I reliably get a black screen.  Back to square one in fault finding, I guess

[Duewester]

@Hans23, your probe MAY be essentially grounding the signal. I used to work in plastics, we had an issue where a scanner would stop working half way through a job. It would miraculously start working when the operator gave it a push. Turns out that a ground wire was broken and the scanner built up a static charge sufficient to stop it working until the static was discharged by touching the scanner.

Long story short, look downline of the clock signal that the probe "touch" makes things happen (u607, u613, or other).

[Hans23]

OK, so after I replaced the '245 in the bus multiplexer which did not make good contact to the socket that I had installed, the black screen became a blue screen - I also saw the beep on the oscilloscope, telling me that the ROM initialized the sound chip.  The DRAMs were my next suspect, and I desoldered the one that got hotter than the others.  It tested bad, and I replaced it with a good one which changed the screen to be black with a blue border and some structure that resembled the startup screen.  No other chip got hotter than the others, so I decided to desolder all DRAMs and test them.  This was not a pretty operation due to the large ground planes and I'm not all that proud of my work, but it was necessary as all DRAM chips test bad.  I'm going to pause here to breathe some air, but I'm kind of hopeful that this console will be back operating eventually.

 

The dead CPU, 9904 and DRAMs lead me to believe in a power supply failure to have been the cause, but the dead VDP crystal does not fit that theory too well.  Anyway, thank you all for helping and rubber ducking, I would not have made it so far without you!

Edited June 22, 2023 by Hans23

[Hans23]

Here's the picture of the repaired PCB, back to life:

 

 

Red - Dead component replaced

Yellow - Chip desoldered, found to be OK

[Duewester]

On 6/23/2023 at 1:38 AM, Hans23 said:

Here's the picture of the repaired PCB, back to life:

 

 

Red - Dead component replaced

Yellow - Chip desoldered, found to be OK

Somewhere along the line I missed the fact that this one was a 99/4 and not a 4a.

That's a lot of red dots. Congratulations on returning a classic to service.