Trying some board debugging

[InfiniteTape]

Inspired by watching too many Adrian and Noel videos, I'm trying my hand at board-level repair of a TI. It's the typical black screen and tone failure mode.

 

An area I've honed in on is the GROM data bus after the 74LS245. I've removed all the GROMs and the 9918, but when I look at D0 on the output of the 245 and the GROM sockets, I get sloped triangle waves at different amplitudes instead of the square waves on the input side. Has anyone seen this before? Any advice on telling if it's the 245, 373, or 244 that's causing it, or if I'm totally on the wrong track?

[GDMike]

Cool. This would be nice to know what we should be seeing, then I'd be better at using my scope to track down issues on my my machine.

But first I need to identify if my ps is functioning before I do that. I've tried 2 different ps and get different types of black screen. It get a no response on one totally black and a gray on the other...I have to start way back to the PS first, as I'm thinking one of the PS actually killed the MB.

Good luck I'll be watching this.

[InfiniteTape]

9 minutes ago, GDMike said:

Cool. This would be nice to know what we should be seeing, then I'd be better at using my scope to track down issues on my my machine.

But first I need to identify if my ps is functioning before I do that. I've tried 2 different ps and get different types of black screen. It get a no response on one totally black and a gray on the other...I have to start way back to the PS first, as I'm thinking one of the PS actually killed the MB.

Good luck I'll be watching this.

I'll post some pics of what I'm seeing later tonight. I was suspicious at first of the 5V rail only reading 4.2V, but I tried swapping in a supply outputting 5V and didn't get a change in behavior. I went ahead and ordered some replacement scratchpad RAM chips, but the more I poked around, the less convinced I was that was the problem.

[GDMike]

8 minutes ago, InfiniteTape said:

I'll post some pics of what I'm seeing later tonight. I was suspicious at first of the 5V rail only reading 4.2V, but I tried swapping in a supply outputting 5V and didn't get a change in behavior. I went ahead and ordered some replacement scratchpad RAM chips, but the more I poked around, the less convinced I was that was the problem.

I think, from what I've heard anyway, was a no on beep was ROM issues.??. As it can't find the code in the first place.

Edited September 10, 2022 by GDMike

[InfiniteTape]

Here is U614, 74LS245, pin 9. This is the side that starts at pin 41 of the 9900. It looks like what I expected.

Here is pin 11, which is the output D0 line that goes to the GROMs, sound chip, cartridge port, and expansion port. To me, this looks like what people in YouTube videos call a bus conflict, hence my suspicion of the logic chips leading to the GROMs. However, I haven't dug into one of my working consoles to compare.

 

[+Ksarul]

If you pull a copy of the original 99/4 troubleshooting manual from WHT, I believe it has a lot of relevant signals shown in it--even though it was for the 99/4. The troubleshooting tree isn't half bad either. Note, the manual is in two parts.

[speccery]

8 hours ago, InfiniteTape said:

Here is pin 11, which is the output D0 line that goes to the GROMs, sound chip, cartridge port, and expansion port. To me, this looks like what people in YouTube videos call a bus conflict, hence my suspicion of the logic chips leading to the GROMs. However, I haven't dug into one of my working consoles to compare.

 

I can look at this in the evening if I have time. I just designed a GROM replacement board which I got properly working yesterday, I will be opening its own thread for that when I have time . My TI is wide open at the moment due to that work, so easy to measure.

 

I'm not sure your picture displays a bus conflict. If the only activity which was done during the capture on the 8-bit bus is reading of GROMs, this could be ok - need to compare to a working TI though. The GROMs have weak drivers and they leave their outputs floating after the bus cycle is over (i.e. GROM CS goes back high). If nothing else is being read on the 8-bit bus then no device would actively be pushing the signal anywhere. It would be interesting to look at this if you would also include the GROM chip select signal on another channel.

 

My understanding is that a common failure point are the 4116 video RAM chips, if you have the F18A board you could plug that in to see if it fixes the issue as it incorporates its own VRAM.

 

I should mention that I did contribute a little to Noel's video by doing some comparison measurements for him. In his case one of the issues was a blown up ROM chip if I recall correctly.

Edited September 12, 2022 by speccery

[InfiniteTape]

23 hours ago, Ksarul said:

If you pull a copy of the original 99/4 troubleshooting manual from WHT, I believe it has a lot of relevant signals shown in it--even though it was for the 99/4. The troubleshooting tree isn't half bad either. Note, the manual is in two parts.

I'd been using the tree in the 1983 manual, but thanks for the pointer to the 99/4 manual with the signals. In both trees, I get stuck in a loop where it has me remove the groms and sound chip, replace them one-by-one, then loops back to the top of the page. Hmmm...

[InfiniteTape]

16 hours ago, speccery said:

I can look at this in the evening if I have time. I just designed a GROM replacement board which I got properly working yesterday, I will be opening its own thread for that when I have time . My TI is wide open at the moment due to that work, so easy to measure.

 

I'm not sure your picture displays a bus conflict. If the only activity which was done during the capture on the 8-bit bus is reading of GROMs, this could be ok - need to compare to a working TI though. The GROMs have weak drivers and they leave their outputs floating after the bus cycle is over (i.e. GROM CS goes back high). If nothing else is being read on the 8-bit bus then no device would actively be pushing the signal anywhere. It would be interesting to look at this if you would also include the GROM chip select signal on another channel.

 

My understanding is that a common failure point are the 4116 video RAM chips, if you have the F18A board you could plug that in to see if it fixes the issue as it incorporates its own VRAM.

 

I should mention that I did contribute a little to Noel's video by doing some comparison measurements for him. In his case one of the issues was a blown up ROM chip if I recall correctly.

I'm attempting to get that 2 channel shot. It's being finicky. Might need to come at it again tomorrow.

 

I did swap in an F18A, but I get the "waiting for VDP data" screen, so I don't think I'm getting to the 9918 initialization part of the startup sequence.

[speccery]

@InfiniteTape Here is an example I took on my system. It's a working setup, working with my new TI-GROMmy board which replaces the GROMs. Not ideal for the pictures, but I think it serves as comparison material for you.

 

The yellow signal is GROM chip select. The cyan is channel 2 which is D0, pin 8 in the GROM socket. Same as in your measurements. The trigger is /CS going low. You can see that my GROM replacement is ready with the read operation in about 5 microseconds (2us per div) and driving the data bit high. I'm using a 5V tolerant microcontroller pin, but the MCU is running from a 3.3V power supply, so the high level is at around 3V.

 

I suppose the point in this picture is that if you look at what happens outside of the time period where /CS is low, the signals are all over the place, and the waveforms are similar to what you had.

Here is another capture. Since  here D0 is high at about 4.5 volts, it must be a write cycle coming from the CPU as in my setup the MCU cannot drive a signal higher than 3.3 volts. This would be part of the address setup (which requires two cycles). Also here we see weird waveforms outside of the /CS low.

[Geoff Oltmans]

I noticed on my board that the GROM data bus was not very square looking, but worked. You do need to have one of the three GROMs installed otherwise the system won't boot though... the other two are for TI BASIC and are not necessary to boot up.

[InfiniteTape]

Well, what I was able to determine last night is that the GROM select is never being pulled down. When I can get back to this on Sunday, I'll start tracing my way back, but it's going to be a learning process through all the logic chips. At least I'm picking up another console on Saturday so I can do comparison testing without disturbing my daily driver.

[InfiniteTape]

Finally got back to the bench. I decided to look closer to the CPU, so I walked through the address lines. Line A8 (CPU pin 16) looks like this at everywhere along its path.

I did pick up another working console last weekend, and this is what A8 should look like.

Pondering my next step. A8 connects to the CPU, RAM, ROM, GROM Port, IO Port, and U509, so plenty of points of failure.

[Duewester]

On 9/24/2022 at 6:43 PM, InfiniteTape said:

Finally got back to the bench. I decided to look closer to the CPU, so I walked through the address lines. Line A8 (CPU pin 16) looks like this at everywhere along its path.

I did pick up another working console last weekend, and this is what A8 should look like.

Pondering my next step. A8 connects to the CPU, RAM, ROM, GROM Port, IO Port, and U509, so plenty of points of failure.

@InfiniteTape  Oh wow. I just happen to be doing the very same thing about the very same issue. I'm not at my desk so I don't have my screen shot collection available, but I started off with a dead system and a working system to compare to. 

I'm using an inexpensive Hantek digital scope/meter/signal generator and my signals don't look near as good as yours. I did see that D0 changed from a nice clean square wave right in line with the timing cycle to a garbled looking almost sin wave looking thing. I unsoldered chips down the line believing one of them was trashing the signal only to finally compare to my working machine and finding those same conditions.🤔 I have not looked at the Address lines because I didn't think there would be any meaningful signal there until later in the boot sequence.

I do see that the black screen will become a blurry lined dark blue screen after a minute or two. It doesn't change any of my signals though. 

Once the hurricane gets through with me I intend to look at the timing circuits. My interpretation is that PH1-PH4 should look the same but out of phase. My working machine shows them that way but, my bad machine shows PH3 and PH4 different all together.

I'm starting to run out of dip sockets because every chip I take out, I socket it back in.

I await your results and hopefully getting my dead machine working.

[Duewester]

Well, I get nothing out of the A0 etc pins of the processor.

Checking the frequency of the two clocks, I get a real low P-P on the bad board Vid in (Pins 39-40). On the Good board I get real High P-P values on Pins 39-40.

Does the F18 board have it's own clock crystal or does it depend on the onboard clock? I ask because I tried using an F18A to bypass any Video Processor problems and it didn't seem to work.

Edited October 3, 2022 by Duewester

[Duewester]

I think I answered my own question. The F18 uses the board clock. That's why it doesn't get past the F18 boot screen.

Or........

It's not dependent and it's waiting on the 9900 for instructions it's not getting. 

I'm starting to to confuse myself.🤐

[+arcadeshopper]

16 hours ago, Duewester said:

Well, I get nothing out of the A0 etc pins of the processor.

Checking the frequency of the two clocks, I get a real low P-P on the bad board Vid in (Pins 39-40). On the Good board I get real High P-P values on Pins 39-40.

Does the F18 board have it's own clock crystal or does it depend on the onboard clock? I ask because I tried using an F18A to bypass any Video Processor problems and it didn't seem to work.

@matthew180

[matthew180]

The 9918A is typically asynchronous to the host computer, thus the F18A is also asynchronous.  The 9918A looks like an asynchronous RAM (albeit a 1-byte RAM) to the host CPU.  The MODE, #CSR, and #CSW inputs to the 9918A drive all the activity to the chip.

 

The ~10.738MHz crystal used by the 9918A is for its internal video clocking and state machine, and it *is* possible to drive the host computer from the CPUCLK output of the 9918A (the SpectraVideo328, and a few other computers actually do this).  If the host computer uses the CPUCLK output from the 9918A, or derives its clock from the 10.738MHz crystal that is used by the 9918A, then technically the 9918A and host system would be synchronous (but offers no advantage), but the data interface between the host CPU and 9918A is still controlled by the MODE, #CSR, and #CSW inputs.

 

To be clear, the 99/4A does *not* share a clock with the 9918A, other that using the GROMCLK output from the 9918A.  Thus, if the sound chip is making *any* sound at all, you know the 9918A is generating the GROMCLK.

 

When the F18A is used to replace a 9918A-family VDP, it does not use the 10.8768MHz crystal on the host board, nor the legacy VRAM.  If the F18A is getting +5V and the reset pin is not low (the system is not stuck in reset), it will generate output video.  If the host computer is not working or communicating with the F18A, this is the case where you will typically see the "green screen", as it has come to be known, or the newer (since V1.8, IIRC) F18A version screen.

 

With the 9918A, the power-on reset state for all VDP-registers are zero, which is not useful since that means the screen is blank, 4K is selected, interrupts are disabled, and all VDP tables are located at the same memory location.  This leads to a 99/4A with a blank screen and the sound chip has not been reset (it will be full on making sound), an has come to be known as a "screaming banshee".

 

In this state it looks like the 9918A is having the problem, and is not a useful state for troubleshooting.

 

The power-on state of the F18A purposefully deviates from the 9918A.  The default power-on state for the F18A is active video, 16K, the VDP registers set to sensible values, and VRAM loaded with a valid font in the pattern table, valid data in the color table, and a default name table that displays one of the screens below (depending on your firmware version).

 

This can help you troubleshoot a system, since if you see one of these screens, you know the +5V is good, the system is not in reset, and the problem is with the communication to the host computer.  If the system uses the GROMCLK (like the 99/4A does), and the sound chip is "screaming", then you know the host CPU did not even execute enough start-up instructions to silence the sound chip.

 

You can check the CPUCLK(38) and GROMCLK(37) pins for ~3.58MHz and ~447.443KHz, respectively.  Check that #RESET(34) is high.  You can also monitor the MODE(13), #CSW(14), and #CSR(15) pins for activity.  Without #CSR or #CSW going low (both being low at the same time is an illegal state), the 9918A will not do anything.

 

 

 

[GDMike]

Sweet 

[Duewester]

It's gonna take some time for me to digest this.

[GDMike]

You probably want to throw everything on a large whiteboard.

[Duewester]

Well, my digestive system is in overload but, I ordered a couple of Processors and went ahead and removed mine and installed socket strips.

I also replaced the crystal with a 10.00 one that I had.

Same results as before, just takes a little longer to manifest. I ordered two of the proper 10.73863 crystal from different vendors just in case.

Now it's a waiting game. Processor comes from China, crystals from Mouser and Digikey.

In the meantime, update my spreadsheet and docx and peruse for additional wisdom from the 99ers.

On 9/13/2022 at 9:51 AM, speccery said:

Here is an example I took on my system. It's a working setup, working with my new TI-GROMmy board which replaces the GROMs. Not ideal for the pictures, but I think it serves as comparison material for you.

@speccery I'm interested in your grom replacement setup. How can I get one for testing or otherwise contribute to your research and development.

@matthew180 Thank you so much for all your insight into this project.

@GDMike I use a spreadsheet and/or docx for my whiteboarding and yes a large one is nice.

@InfiniteTape Thank you for breaking the ice on this project.

[Stuart]

On 10/10/2022 at 7:00 PM, Duewester said:

Well, my digestive system is in overload but, I ordered a couple of Processors and went ahead and removed mine and installed socket strips.

I also replaced the crystal with a 10.00 one that I had.

Same results as before, just takes a little longer to manifest. I ordered two of the proper 10.73863 crystal from different vendors just in case.

Are you sure you're not getting your clocks and crystals mixed up? Processor clock is from a 12 MHz crystal (48 MHz on early models) that feeds the TIM9904 4-phase clock generator. 10.7...MHz crystal is for the VDP - has to be the exact frequency for the video signal to be correct ... replacing it with an odd 10MHz crystal from the spares box will prove nothing.

 

If two phases of the 4-phase processor clock are suspect, I'd replace the TIM9904 and see if that helps. Careful what you buy ... lots of dodgy 9904's out there.

Edited October 11, 2022 by Stuart

[Duewester]

My bad. I should have made myself more clear (assumed people would know that 10.xxxxx crystal was for VDP). I went down this road when I thought the F18 used the VDP crystal. I've been educated since then. I only have the one F18 so, I'm reluctant to mess with it much. It works like a champ in my good 99 so I'll leave it be. The 12MHz crystal seems fine and operates with a good p-p signal. The reason I got led down the 10.xxx road was that it had a very low p-p (even for 5v).

 

2 hours ago, Stuart said:

If two phases of the 4-phase processor clock are suspect, I'd replace the TIM9904 and see if that helps. Careful what you buy ... lots of dodgy 9904's out there.

I've swapped all my socketed chips from a good 99 and they don't make any difference to the bad 99. I don't like to put suspect bad chips in my good 99 but since all my swap chips still worked when I returned them to the good 99, my belief is that there is little wrong with the bad 99 chips.

 

I've been going through John Guions' checklist.

[InfiniteTape]

@Duewester, glad you're chipping away at it. Life's gotten a bit busy here, so I haven't gotten to spend the in-depth time on investigation that I wanted. I tried installing just GROM 0 from a working TI, but that didn't change behavior. I also tried piggybacking different 6810 chips to see if that might help diagnose a scratchpad ram problem, and that didn't work either. (Both were shots in the dark.)