The “bus bars” are also distributed decoupling caps! This makes sense if you look at their construction; you’ve got a metal strip on one side of an insulator, and another on the other side, and encased in an insulating sleeve. Two conductors separated by an insulator (dielectric) = capacitor. And this capacitance is distributed along the length of the bus bar, instead of having discrete decoupling caps like you would find in an Apple ][ or C64, for example.
Welp you are right about this. I doubt tho that this would totally render the system to constantly fail. My guess would be that the capacitance that's missing here is maybe in the range of picofarads...I know, a TI is not an Amiga, but I know that Amigas (my field of expertise) are running fine even with a lot of bulk capacity missing as long as the PSU is stable. Same goes for 64s.
My first thought is that if one of those bus bars was faulty, perhaps the others are too. It's worth checking, I'd say. If some of the circuits aren't getting clean power, they just won't work. Your main problem is that it "just won't work."
Those power buss bars are designed to replace wires/traces and bypass capacitors. When laying out pcb you need large power traces and when other traces cross over/under them noise is injected into the. The bus/cap bars allowed very low impedance power distribution and the sandwich makes a capacitor tamping down noise
That's interesting. It would be why they were ran in vertical alignment, to get them away from other traces. It might be needful to fabricate a new buss bar using solid core wire so that it will stand in proper alignment to the board?
You say it's addressing the peripherical expansion area. I'd imagine there's a "hook" to allow certain expansions to tie in early in the boot process. I'm thinking the computer is getting a bad signal from the expansion port that sending it into that loop waiting for something that never comes ready.
Setting a problem child aside can be extremely useful. You can think yourself into a corner, and taking a break can give you fresh insight and new paths to try. Good luck!
Also worth noting that some replacement logic will not be fast enough when used with other types. IE: mixing TTL and CMOS chips even when they state they are compatible. Try to always go with what the original was.
TMX9918 instead of TMS9918? Interesting - it might be an engineering prototype instead of a commercial part. Those strips were a reasonable alternative to 4 layer PCBs at the time, which were far more expensive than 2 layer boards. They not only deliver power but also act as decoupling capacitors, so replacing them with thick wires might make the supply a little more noisy but that shouldn't be a problem.
An important note about the 74LS138… The 3to8 decoder also has 3 enable pins. Two are active low and one is active high. If these are not set correctly the outputs of the 138s outputs will all stay high regardless of the address input pins. So check the enable pins 4,5,6
i know this is going to be a bit of work but... 1) deep clean the board, its a LOT easier to see if anything is wrong when the board isnt covered in dust and grime 2) re flow all the solder that you havent done already. ive seen joints that look good but werent making a stable connection due to both vibration and age. 3) use your logic analyzer and a camera in slow mo to record the boot up of the known good machine and the dead one so maybe you can get an idea where its hanging up at.
Seems like you got close to it at 7:36. Why didn't you drill down there? If good logic is coming in thru 1,2,&3 and output is always high, look at the other pins and signals to/from that chip. Also, beware of "if I can't fix it, I can fix it so it can't be fixed". (grin). Finally, cat update?
I’m familiar with the ‘138… I use it on my NABU expansion boards. It won’t do anything unless all three of the gate lines are in the correct configuration - you need to look at both the address lines and the gate lines.
The inputs to the 'LS138 but the outputs were not changing. Either the '138 is bad or something is pulling on the lines and preventing them from changing. To decide which is going on you need to bend the output pins slightly to allow you to put the chip back in the socket but the output pins will be out in the open. You can then check the outputs of the '138 to see if they are changing as the inputs change. If you can get a program listing of the ROM(s) you can use the logic have a logic analyzer to watch the boot up sequence and see how far it gets by comparing what you see on the LA vs what you expect it to do based on the listing of the ROM. Good luck with breathing life back in to the system.
I'm going with this. "New parts" doesn't mean "good parts", so replacements can't be assumed to be working. The fact that the line is high all the time makes kevin's suggestion a good way to check if the line is pulled high past the 138, perhaps a shorted trace somewhere.
I have found those chips marked "E4" are of inferior quality and/or counterfeit. Even though some of them work, I NEVER use them anymore. So, he may have actually installed a problem early on when he changed out the LS138's. I consider the E4 labeled LS138's to be an unnecessary variable, and would replace them with genuine LS138's with a date code before the year 2010.
The only thing that comes to my mind is using multimeter beep and logic analyser to check the traces, and compare the boot sequences between the good and the bad system, to see what went wrong
8:51 - The clue is the way address line A13 randomly goes high causing address to flip between 0194 and 2194 and back again, or between 0192 and 2192 etc. I would scope the a13 line to see if it is a genuine clean pulse or noise. Suspect a faulty ic is causing it but tracing which one will take a while as you would need to isolate each in turn.
You can probably find a strong clue to finding the fault (potential fault) in the addresses the machine is getting stuck on. It very probably isn't/wasn't the CPU though unless its a far more subtle fault. Should also be focusing on the rest of the glue logic in the address bus or looking for a short trace in that area. Can you pull the chip select wires down for instance? Computer repair can be real torture sometimes.. Especially when the final answer turns out to be something obvious.
@@monad_tcp yes you're right. I believe it's a non maskable interrupt problem or one of the signal requirements of the cpu aren't being met. Either way, this should be an easy fix if he stops throwing parts at the problem.
I have a stock of 40-pin sockets. Your CPU is a whopping 64 pins. I probably would have made the mistake of trying to use those round pin headers too. Seeing you using the HP logic analyzer brings back fond memories of working at GE in the 1980's.
That's indeed a lot of mess in that system, I admire how you Keri on with this project. It fills me with determination. Tek AN/USM-425 "G.I. Scope"? Beauty!
If I remember correct, the "paper" power bus bars also had distributed capacitance to enhance power noise filtering. Haven't touch similar board design in 40 years so I am not sure any more. Adding all the sockets is well worth the effort. Thanks for the explanation and troubleshooting process.
A few other people have already mentioned it, you need to 'scope the power on each power domain/chip to make sure it's clean and those bus bars are doing their job of delivering *enough* power cleanly.
I have been at that point and wired up a logic analyzer to all address lines, read and write strobes, data lines and trigger by coming out of reset. You see the each instruction executed and compare that to a ROM listing. The first deviation gives you a clue where to look. It takes hours to set up and debug, but it does deliver answers and at this point a few more hours won't really make anything worse.
May have been mentioned above, but since it is executing SOME code, you could make a simple ROM and boot from that. Start with a NOP loop. Then add progressively more functionality. Such as memory or IO reads/ that should wiggle the chip selects. Then observe with logic analyzer. I’m not familiar with that CPU, but what you saw where it was going between something like 0094 and 2094 for one clock: that could be normal if the cpu multiplexes an address line for status or something. You’d need to look closely at the timing diagrams on the data sheet. An example of similar behavior is the Z80 if you only read sequential addresses, the logic analyzer will capture other addresses interleaved with the real ones because of the built in memory refresh logic. Anyway goal would be to observe the addr, data, and control lines going thru the correct sequence and matching the timing diagrams when it’s executing the extremely simple loop of a single operation.
You mentioned 'rust' on the barn find. I'd check for open circuit inputs on the logic gates. Just scan down each of the ICs with a scope, look for a floating level like 1.5v or so which is what TTL floats to (it will see it as a 1 input though).
18:18 You forgot to show how you checked not only the A, B and C inputs (pins 1, 2 and 3), to confirm that the '138 was receiving something to demux, but also the enable pins /G2A, /G2B and G1 (pins 4, 5 and 6) to show that at some point the selected output was actually enabled.
I feel your pain.... I had a piece of equipment that the 5v rail would every intermittently put 7.5v "AC" on to the rails as the low voltage regulator would for some unknown reason fail to regulate. I had check the rails...all good ... its just some time later that I happened to just check them again that I thought I saw a glitch....and so much patience later..BANG, I caught it.....rude words were spoken loudly. And it STILL did not work....more rude words. I eventually tracked it down to a header connector where one pin was not locked in fully and again would intermittently connect or not and I only found it because the signal I was looking at was easier to grab off that pin rather than shift the scope over to the other side of this machine to look at it on the board it originated from and I notice the pin moved.....MORE rude words...followed by VERY rude words when it all worked flawlessly afterwards .
I am learning a lot about troubleshooting. I am also reminded of the most important lesson in technical work -- know when to ask for help. Keep up the great work. I really like your presentation style. Looking forward to seeing the process of picking your way through the main board logic next time you are feeling ambitious 🙂
LOL... sometimes you just have to shelf it. I am working on a powered three way speaker with an interesting fault... I keep finding new problems as I chase the issue and replace components. I have a number of days to put it aside while more output ic's arrive from China. I will, "put it in the corner and let it think about what it has done wrong"
Using a logic analyser is overkill. Start with the basics by checking the penny logic. For you, as a starting point, check the 74LS138 with its Y0-Y7 outputs disconnected from the PCB. If the outputs are working in this state look downstream else look upstream.
First place to look in old electronic equipment is the electrolytic capacitors, especially the lower values (e.g. 47 μF). It may not seem "logical" in digital equipment, but years of practical experience should not be ignored readily.
I know you want the 99/4 because it is the "more pure" version, the "more rare" version, like a rare post stamp, but there is a reason they discarded the 99/4 and replaced it with the A revision... ;)
I'm late to the party, but I thought one way to test high-impedance outputs would be to monitor the chip-select, output-enable, and output bits with a scope. Then place a 1k resistor from the data bit under test to ground or 5V. If the chip's output voltage follows the pull-up / pull-down, then that would indicate high-impedance.
Lower the clock rate to generate 1 clock with push button so you can step through the boot. Compare the boot sequence with the la with the working and not working board.
Makes sense, but how do you single-step 6502 clock with its phases? (serious question) Also I recommend function-generators built into some logic analyzers to generate enough pulses to get to faulty parts. Or any arduino or something like that.
TMS9901 CPU has a minimum clock speed, unfortunately. Any less than 500KHz and the chip itself forgets what it's doing. What would be better is to record both the working system and the dead one trying to boot up with a modern logic analyzer that can send the data to a connected computer for a long-term recording.
I already said something similar but you really need a soldering iron and desoldering iron upgrade, avoid messing up rare PCBs like that. You have a TH-cam channel try to hit up some manufacturers or look around there is many good options for a decent desoldering iron that has an electric pump and good temperature control. That would have probably avoided your lifted pad situation and will for sure avoid problems to come
I suggest doing a very deep clean. maybe with an ultrasonic cleaner. that could remove anything under components that could be causing issues. but you may just have to start stripping components off the board to find the fault. but everything i have said is just be throughing darts in the dark lol.
This brings back some not so fond memories of my days as a Commodore tech. I could usually diagnose the problem just by turning the thing on, but there were a couple boards that I literally changed every component with known good ones, down to the resistors, and checked every trace and still the same issues. I sincerely hope this is not going to be the case with your board.
It's been a long time since I worked with a 9900. But I have a vague memory that the bottom 256 bytes of the address space was SRAM (normally used for the 16 pseudo-register blocks). Of course that means that the address decode has to special-case that region. And that was probably done by individual logic gates rather than MSI or LSI chips, at that time. Probably a good idea to bite the bullet and look at the address logic?
Actually after a bit of a refresher look at the manuals, I remember that the bottom of the 9900 processor address space is actually the interrupt vectors. I may have been thinking of the 9995 which had 256 bytes of on-chip RAM which was supposed to be used for the register blocks: but of course that wasn't the processor used in the TI-99/4. (In fact the system I worked on was a specialized aerospace design, not a 99/4. ) I think the 99/4 did have a chunk of SRAM, but I can't say where that sat in the address space. Or where the program ROM lived either. I also seem to remember that in the 99/4 there was some really funky arrangement where access to memory had, for some reason, go via the video controller? Keep at it, I'll be interested to see what you find!
My first computer TI994a, had a 300 baud modem, that expansion bay with 32K additional memory, a diskdrive, and a printer card I believe... MAN I miss it...
Here's what I do. Take a red sharpie and mark ALL outputs of every chip and use that to probe those outputs with a scope. All chips with outputs that are switching are likely good. All chips with either steady high's or low's need to be marked and further tested via checking their inputs to see if their truth tables match. And ofc any chips with in-between logic levels that aren't tri-state are likely bad and that chips should be pulled and tested out of circuit. Tri-state logic can trip you up when all chips go high impedance and the resistor network pulls that line high/low. It will look like an extra slow transition on the scope and gives the illusion of something being bad when it's not.
What an odd way to jump rails about, a fascinating factory bodge. Have all the other papered rails been checked? They seem quite fragile. Were any used for signals? Perhaps comparing signals in the discrete logic between the working and non-working systems might help?
As others have mentioned you CAN NOT just replace those busbar units with wires. They have very low inductance and some inherent capacitance. If TI could have used cheap wires to reun the power they would have, but clearly they didn't. You may remember that in the early machines the DRAMs were very hard to make work properly due to power supply bounce as precharge (Row/Column select) currents are quite high. Many memory card vendors for the S100 systems failed due to inability to get their boards stable. What you really need to do is get a fast scope with very low capacitance and start watching VDD/VSS/etc lines to see if the power is stable. If power isn't stable then you will see lots of toggling but signal integrity will corrupt your data flow. I wonder if part of the boot sequence to the SRAM is working (they don't need as much bypassing) but the rest of the boot sequence starts running in DRAM and that's where the troubles begin
Sometimes it's almost impossible to bring up a system like that, to many dependencies. if you can write a tiny program loop that toggles some I/O port. burn it to a eeprom and try. you can see if the memory addressing is working, the one chosen I/O is working. if you get this far then it's a matter of trying other I/O and memory addresses.
Ouch! I feel for those lifted traces, and I have many under my belt. I think I may have tried low-temp alloy, or failing that I would have sacrificed the machine-pin strip housing. The individual pin sockets will still be functional, even if not useful as a strip.
From my experience: it is better to cut off the chips (if you're sure they're defective) and leave the legs in the PCB then solder a socket to them. Less work and no risk of damaging the PCB vias.
I've got a Texas Instruments DS990 Model 1, which uses the same ceramic TMS9900 CPU. Curiously, I've read somewhere that the Model 1 was used in the design of the TI-99/4, which I wouldn't be surprised if that were true. Unfortunately, the only thing it does is show 'LOAD ERROR 22' on power on, and if I try to power cycle it, all I get then is a blank screen. I have to leave it alone for hours (maybe a whole day) before I can get that error message again. I've been working on this machine off and on for about 6 years now, so I'm not holding my breath I'll get it to work any time soon. Good luck!!!
I noticed U506 pin 6 going to the enable line pin 6 of U505. As U506 is open collector and the 138 is doing something then 2k2 pull-up must be ok but still leaves the gate to be checked. If you remove all memory chips and set the databus to the opcode for NOP with resistors to the rails, will the cpu behave like a counter to enable easy checking the rest of address decode logic? Only other thing is you burn an eprom with a short test program to run through addresses in a specific pattern and check out the logic pattern with a scope. Do the same on your 99/4a assuming decoding logic the same and compare behaviour of logic lines (a little like signature analysis of days of old at this point). Maybe that might help find a clue? A silly thought just in case. Best of luck 😃
Seems obvious so no-one said it. Re: lifted tracks? I use a PACE PPS - 85AE / MBT-250. Use this station with an SX-65 or SX-70 desoldering hand-piece. Not later ones.
Good God man your patience !! :) I'm jealous.. I just got a new TV and I'm burned out just trying to get all the pictures settings the way I want it,,, it's been 2 and a 1/2 days and I'm sick of it... How in the hell can it be too bright and too dim at the same time ?? lol
Well a reason for that might be the the enable pins must be in the correct state G2A and G2B must be low and G1 must be high. This was not checked in the video, but maybe it was in real life.
UGH! I can't believe I left the TI-99/4 I found years go hanging on my old computer center wall on display. Back then, retro computing wasn't popular, and I had no idea how rare the 4 was!
I think it's about time you put an ESD mat on your benches. these old chips are not very good with static, ok in the board but a bit risky when the pins are exposed. Even if the first hits don't kill them it can slow them down as it can increase the gates latency. Still nice to see this old stuff getting fix, these are the computers i grew up with along with boards like the UK101, superbrain, and Nascom's
Point to point tedious wiring checks. Data bus signatures from reset of good vs bad using la. Check dram refresh signatures. Are clocks stable prior to reset?
I would start with a thorough visual inspection of the board, solder joints and components. Reflow. Did you check the voltage (and ripple) after replacing the broken bar with bodge wires?
Regarding the ram, since the majority of the pins are paralleled between all of the chips, socketing the whole lot is actually a good move as it makes diagnosis far easier. Any short or stuck pin on one chip, would affect all of the other chips, if that pin was common to them all. Back in the day, I've played this game, and ended up doing exactly this. Socketing a bunch of chips when you have a good de-soldering machine is actually not much of a chore, and can save you a bunch of time in the long run. Especially when more than one chip turns out to be faulty.
Nice project. You mentioned that the decoders were not decoding fully, have you checked all the enable pins to ensure that you have enabled decode outputs. What does the Logic Analyzer say about this ? What about noise on the power rails - are they clean, are the caps any good ? Is the reset signal working properly ? Are all address, data and control lines moving, particularly important ones for addressing / memory control (ALE, R/!W, etc) - or whatever they are called on that CPU Can you dump the ROMS, disassemble the code and look at what the instructions are that form that loop - to see why its failing whatever test is being done, this should help focus in on what's going on and help focus in on the fault domain
I think he meant they are decoding - just not getting signal because the boot process never reaches the point when GPU is initialized Otherwise, agreed.
Ok, so here is what you do. You build a “CPU” emulator using a rPi or Arduino to statically set addresses, data bits and control signals so you can then statically trace the selects, address and data to memory and devices. So just use a set of those pin headers wired to the rPI, arduino, or even manual switches and then plug them in in place of the processor.
There are a lot of chip testers floating around, in theory they should be able to test at least some of the logic chips without desoldering if you run the wires...
Does anyone know of a "dead test ROM" for TI-99 or similar? Compare bit-by-bit to a working system! Try connecting the logic analyzer to at least low bits of address bus (you are probably better off soldering the wires to a chip than doing the clip porcupine again) and recording first few seconds on good and bad system with the same ROMs (probably doesn't matter if it doesn't boot all the way as long as it gets past "sound disable" step) then compare them and try to see where exactly it fails. one other possibility is to remove RAM, ROM, and other chips and compare what happens to working and dead system. From what I can see the CPU seems to be executing code from the ROM, but does not go past basic initialization so it never even gets to the point where it's supposed to initialize the display. It seems it's really easy to mess up TI-99 boards and connections. Probably a trace corroded *somewhere* . It may be a bit of a stretch, but you may try swapping all socketed chips at once (and the power supply if compatible) between working and dead system. Sometimes some chips appear to work in one computer but not in the other for some strange voodoo reasons. try watching Noel's and Adrian's videos not just on TI-99 but other systems. They show a LOT of troubleshooting techniques. if everything fails, it's ok to admit defeat. rechecking every single trace is probably too much work for a ti-99 which is not that rare or important to warrent so much lost time you could use for more interesting stuff that you CAN do. Send it to some other guy who specializes is TI-99 repairs and call it a day.
The processor's activity after it has gotten off track may not be related to the actual problem. If a bad bit in an earlier opcode sends the CPU into the weeds and it starts executing from the graphic roms, looking at what it's doing at that point won't tell you much. Maybe capture a trace from reset ending on the 99/4A and compare that to what's happening at the start on the bad system. If you are lucky, the problem will show itself soon after reset ends. Also, if you can find a disassembly on the web of the boot code, that would make it a lot easier to understand what you are capturing on the analyzer. Especially if you capture the data along with the address.
Apart from everything you already tried, I would try to figure out which instructions are throwing the CPU into the loop, what is it actually trying to do. Waiting for a device to be ready, perhaps?
This reminds me of one of the issues I was having with my Tempest boards when I first bought them. That turned out to be marginal ROMs. They would read okay in my reader but apparently the output voltages were too weak to be read properly by the CPU on the board.
Have you tried checking the output of the 138 for shorts against +5V? If the input is correct but the output is stuck high that would be my prime suspect and the video didn't show if you did... If the system is stuck in initializationmode, i.e. never accessing the video RAM at all, the "mode" line should be high, but the CSW line should go low now and then at least. The Nabu has the "A" revision of the chip, but still, I think those signals are the same?
i had similar fault in a famiclone. everything tested good in fully socketed motherboard but the broken one still didn't work i tryed transplanting clock from another board, testing wierd stuff going insane, smoking up one cpu and then i being frustrated removed everything andpoint to point tested every chip connection to another, they were all good, but then i tested if any data line wasn't shorted to the one next to it, still no luck but i started testing at random everytrace going in between soldering points and i found one fault, reset was shorted with one data line in cart socket, after fixing that one short the whole console was back to life and i did that without any fancy equipment, just a multimeter and a lot of probing so if this pcb has no solder mask between pins, chcek every trace that goes between legs of any ic or socket. you don't need a lot of current to flip a state of high impedance logic so even tin wisker or a blob or snot can do it you can also try to partition the board if you can offload part of a circuit to breadboard analogus circuit, a lot of thinkering but can rule out any boardfault by bypasing selected part you can also check in circuit if for instance music, or video part of the board working by removing your cpu and ram and pulling data from interposer on another working board with that chip removed
Take a break and think about it then go back to it. That’s what I do. But keep at it in the long run. Best drug in the world fixing something like this, at least it is to me.
Hold on hope, buddy! You’ll get it! I have a device that’s sitting under a cloth thinking about what it’s done wrong too. These machines will work again, dammit!
The “bus bars” are also distributed decoupling caps! This makes sense if you look at their construction; you’ve got a metal strip on one side of an insulator, and another on the other side, and encased in an insulating sleeve. Two conductors separated by an insulator (dielectric) = capacitor. And this capacitance is distributed along the length of the bus bar, instead of having discrete decoupling caps like you would find in an Apple ][ or C64, for example.
Interesting, but if this were the issue wouldn't it be still failing to even 'partial' boot the way it did before he broke the bus bar?
Welp you are right about this. I doubt tho that this would totally render the system to constantly fail. My guess would be that the capacitance that's missing here is maybe in the range of picofarads...I know, a TI is not an Amiga, but I know that Amigas (my field of expertise) are running fine even with a lot of bulk capacity missing as long as the PSU is stable. Same goes for 64s.
Yes I first thought was "Dude! that is your decoupling caps!".
My first thought is that if one of those bus bars was faulty, perhaps the others are too. It's worth checking, I'd say. If some of the circuits aren't getting clean power, they just won't work. Your main problem is that it "just won't work."
And it has a very low inductance so cant be replaced with wire and add some ceramic cap because they will have a sharp resonance and uneven impedance.
Those power buss bars are designed to replace wires/traces and bypass capacitors. When laying out pcb you need large power traces and when other traces cross over/under them noise is injected into the. The bus/cap bars allowed very low impedance power distribution and the sandwich makes a capacitor tamping down noise
That's interesting. It would be why they were ran in vertical alignment, to get them away from other traces. It might be needful to fabricate a new buss bar using solid core wire so that it will stand in proper alignment to the board?
You say it's addressing the peripherical expansion area. I'd imagine there's a "hook" to allow certain expansions to tie in early in the boot process. I'm thinking the computer is getting a bad signal from the expansion port that sending it into that loop waiting for something that never comes ready.
Setting a problem child aside can be extremely useful. You can think yourself into a corner, and taking a break can give you fresh insight and new paths to try. Good luck!
You'll get it.
With 105% probability, haha!
13:00 LS138 have THREE chip select inputs ( G1, /G2A, /G2B ), you only checked two . Try testing G1 and the logic gate preceeding it.
Also worth noting that some replacement logic will not be fast enough when used with other types. IE: mixing TTL and CMOS chips even when they state they are compatible. Try to always go with what the original was.
TMX9918 instead of TMS9918? Interesting - it might be an engineering prototype instead of a commercial part. Those strips were a reasonable alternative to 4 layer PCBs at the time, which were far more expensive than 2 layer boards. They not only deliver power but also act as decoupling capacitors, so replacing them with thick wires might make the supply a little more noisy but that shouldn't be a problem.
An important note about the 74LS138… The 3to8 decoder also has 3 enable pins. Two are active low and one is active high. If these are not set correctly the outputs of the 138s outputs will all stay high regardless of the address input pins. So check the enable pins 4,5,6
+1 for the HP logic analyzer! Got one myself for a few bucks complete with break outs and probes..
Time to get the thermographic camera out and look for hot ttl logic.
i know this is going to be a bit of work but...
1) deep clean the board, its a LOT easier to see if anything is wrong when the board isnt covered in dust and grime
2) re flow all the solder that you havent done already. ive seen joints that look good but werent making a stable connection due to both vibration and age.
3) use your logic analyzer and a camera in slow mo to record the boot up of the known good machine and the dead one so maybe you can get an idea where its hanging up at.
Seems like you got close to it at 7:36. Why didn't you drill down there? If good logic is coming in thru 1,2,&3 and output is always high, look at the other pins and signals to/from that chip. Also, beware of "if I can't fix it, I can fix it so it can't be fixed". (grin). Finally, cat update?
I’m familiar with the ‘138… I use it on my NABU expansion boards. It won’t do anything unless all three of the gate lines are in the correct configuration - you need to look at both the address lines and the gate lines.
@@darkwinter6028 That's a good point. If pin 6 is low or pins 4&5 are high the output will be high under all conditions, like what he is showing.
The inputs to the 'LS138 but the outputs were not changing. Either the '138 is bad or something is pulling on the lines and preventing them from changing. To decide which is going on you need to bend the output pins slightly to allow you to put the chip back in the socket but the output pins will be out in the open. You can then check the outputs of the '138 to see if they are changing as the inputs change. If you can get a program listing of the ROM(s) you can use the logic have a logic analyzer to watch the boot up sequence and see how far it gets by comparing what you see on the LA vs what you expect it to do based on the listing of the ROM. Good luck with breathing life back in to the system.
I'm going with this. "New parts" doesn't mean "good parts", so replacements can't be assumed to be working. The fact that the line is high all the time makes kevin's suggestion a good way to check if the line is pulled high past the 138, perhaps a shorted trace somewhere.
I have found those chips marked "E4" are of inferior quality and/or counterfeit. Even though some of them work, I NEVER use them anymore. So, he may have actually installed a problem early on when he changed out the LS138's. I consider the E4 labeled LS138's to be an unnecessary variable, and would replace them with genuine LS138's with a date code before the year 2010.
The only thing that comes to my mind is using multimeter beep and logic analyser to check the traces, and compare the boot sequences between the good and the bad system, to see what went wrong
Loved those old HP logic analyzers. Crazy expensive when they came out but so useful. The ones with the built in oscilloscope were the best.
no
Your right, I have a HP1660AS and its running forever, real workhorses !!
@@BenjiKimba no
8:51 - The clue is the way address line A13 randomly goes high causing address to flip between 0194 and 2194 and back again, or between 0192 and 2192 etc. I would scope the a13 line to see if it is a genuine clean pulse or noise. Suspect a faulty ic is causing it but tracing which one will take a while as you would need to isolate each in turn.
Look for open resistors- pull up/down bus termination? Plus diodes. If board had flexed enough that the power bus failed these will need checking too.
+1 on the resistors, not just open, but also significantly out of spec
You can probably find a strong clue to finding the fault (potential fault) in the addresses the machine is getting stuck on. It very probably isn't/wasn't the CPU though unless its a far more subtle fault. Should also be focusing on the rest of the glue logic in the address bus or looking for a short trace in that area. Can you pull the chip select wires down for instance?
Computer repair can be real torture sometimes.. Especially when the final answer turns out to be something obvious.
Seems like some interrupt problem
@@monad_tcp yes you're right. I believe it's a non maskable interrupt problem or one of the signal requirements of the cpu aren't being met. Either way, this should be an easy fix if he stops throwing parts at the problem.
Put the logic analyzer onto the good board and record the signals. Compare them to the signals from the bad board.
I have a stock of 40-pin sockets. Your CPU is a whopping 64 pins. I probably would have made the mistake of trying to use those round pin headers too. Seeing you using the HP logic analyzer brings back fond memories of working at GE in the 1980's.
One good thing you can take for you is, that now you know, which Chips are good. So you are on the safe side here. Also for future projects.
That's indeed a lot of mess in that system, I admire how you Keri on with this project. It fills me with determination.
Tek AN/USM-425 "G.I. Scope"? Beauty!
Such a deep dive into this machine. Loving the content. Truely trailblazing, these are issues that few people have even dared to attack. Big cheers!
At 5:39 pin 8 on the 74LS362 looks broken... but I could be mistaken.
Yes, it looks like that to me too, although maybe it's the remains of the thermal paste? 🤔
If I remember correct, the "paper" power bus bars also had distributed capacitance to enhance power noise filtering. Haven't touch similar board design in 40 years so I am not sure any more.
Adding all the sockets is well worth the effort. Thanks for the explanation and troubleshooting process.
Seeing all those wires at 8:17 made me yell "HOLY SHIT WTF IS THAT MESS". I feel sorry for you right now, I've had stuff just refuse to work too.
A few other people have already mentioned it, you need to 'scope the power on each power domain/chip to make sure it's clean and those bus bars are doing their job of delivering *enough* power cleanly.
I have been at that point and wired up a logic analyzer to all address lines, read and write strobes, data lines and trigger by coming out of reset. You see the each instruction executed and compare that to a ROM listing. The first deviation gives you a clue where to look. It takes hours to set up and debug, but it does deliver answers and at this point a few more hours won't really make anything worse.
May have been mentioned above, but since it is executing SOME code, you could make a simple ROM and boot from that. Start with a NOP loop. Then add progressively more functionality. Such as memory or IO reads/ that should wiggle the chip selects.
Then observe with logic analyzer.
I’m not familiar with that CPU, but what you saw where it was going between something like 0094 and 2094 for one clock: that could be normal if the cpu multiplexes an address line for status or something. You’d need to look closely at the timing diagrams on the data sheet.
An example of similar behavior is the Z80 if you only read sequential addresses, the logic analyzer will capture other addresses interleaved with the real ones because of the built in memory refresh logic.
Anyway goal would be to observe the addr, data, and control lines going thru the correct sequence and matching the timing diagrams when it’s executing the extremely simple loop of a single operation.
You mentioned 'rust' on the barn find. I'd check for open circuit inputs on the logic gates. Just scan down each of the ICs with a scope, look for a floating level like 1.5v or so which is what TTL floats to (it will see it as a 1 input though).
18:18 You forgot to show how you checked not only the A, B and C inputs (pins 1, 2 and 3), to confirm that the '138 was receiving something to demux, but also the enable pins /G2A, /G2B and G1 (pins 4, 5 and 6) to show that at some point the selected output was actually enabled.
“Let it think about what it’s done wrong.” Ah man, that was hilarious. 😅 Good luck with the rest in the fullness of time.
I feel your pain.... I had a piece of equipment that the 5v rail would every intermittently put 7.5v "AC" on to the rails as the low voltage regulator would for some unknown reason fail to regulate.
I had check the rails...all good ... its just some time later that I happened to just check them again that I thought I saw a glitch....and so much patience later..BANG, I caught it.....rude words were spoken loudly. And it STILL did not work....more rude words. I eventually tracked it down to a header connector where one pin was not locked in fully and again would intermittently connect or not and I only found it because the signal I was looking at was easier to grab off that pin rather than shift the scope over to the other side of this machine to look at it on the board it originated from and I notice the pin moved.....MORE rude words...followed by VERY rude words when it all worked flawlessly afterwards .
I am learning a lot about troubleshooting. I am also reminded of the most important lesson in technical work -- know when to ask for help. Keep up the great work. I really like your presentation style. Looking forward to seeing the process of picking your way through the main board logic next time you are feeling ambitious 🙂
At 6:11 at least some solder joints on the bus bar on top of the CPU look like cold joints… Thanks for the video!
LOL... sometimes you just have to shelf it. I am working on a powered three way speaker with an interesting fault... I keep finding new problems as I chase the issue and replace components. I have a number of days to put it aside while more output ic's arrive from China. I will, "put it in the corner and let it think about what it has done wrong"
Fighting the good fight my man. You got this!
Have you made a blood offering to the computer gods? Sometimes after I cut myself working a computer and suddenly the computer boot right up!!!!
You got a lot of iron in that blood of yours - to fix a broken trace
Using a logic analyser is overkill. Start with the basics by checking the penny logic. For you, as a starting point, check the 74LS138 with its Y0-Y7 outputs disconnected from the PCB. If the outputs are working in this state look downstream else look upstream.
Man, this is exactly like my repair project right now. Hope you have more sanity left than I do!
First place to look in old electronic equipment is the electrolytic capacitors, especially the lower values (e.g. 47 μF). It may not seem "logical" in digital equipment, but years of practical experience should not be ignored readily.
I know you want the 99/4 because it is the "more pure" version, the "more rare" version, like a rare post stamp, but there is a reason they discarded the 99/4 and replaced it with the A revision... ;)
I'm late to the party, but I thought one way to test high-impedance outputs would be to monitor the chip-select, output-enable, and output bits with a scope. Then place a 1k resistor from the data bit under test to ground or 5V. If the chip's output voltage follows the pull-up / pull-down, then that would indicate high-impedance.
Lower the clock rate to generate 1 clock with push button so you can step through the boot. Compare the boot sequence with the la with the working and not working board.
Makes sense, but how do you single-step 6502 clock with its phases? (serious question)
Also I recommend function-generators built into some logic analyzers to generate enough pulses to get to faulty parts. Or any arduino or something like that.
Not sure if memory would work, needs a refresh every so often does it not?
TMS9901 CPU has a minimum clock speed, unfortunately. Any less than 500KHz and the chip itself forgets what it's doing.
What would be better is to record both the working system and the dead one trying to boot up with a modern logic analyzer that can send the data to a connected computer for a long-term recording.
@@ovalteen4404 Correct, it's not a fully static design, requires continuous clocking to keep state internally.
@@jwhite5008 IIRC you can't, the 6502 isn't a fully static design (The 65C02 on the other hand is).
I already said something similar but you really need a soldering iron and desoldering iron upgrade, avoid messing up rare PCBs like that. You have a TH-cam channel try to hit up some manufacturers or look around there is many good options for a decent desoldering iron that has an electric pump and good temperature control. That would have probably avoided your lifted pad situation and will for sure avoid problems to come
I suggest doing a very deep clean. maybe with an ultrasonic cleaner. that could remove anything under components that could be causing issues. but you may just have to start stripping components off the board to find the fault. but everything i have said is just be throughing darts in the dark lol.
This brings back some not so fond memories of my days as a Commodore tech. I could usually diagnose the problem just by turning the thing on, but there were a couple boards that I literally changed every component with known good ones, down to the resistors, and checked every trace and still the same issues. I sincerely hope this is not going to be the case with your board.
It's been a long time since I worked with a 9900. But I have a vague memory that the bottom 256 bytes of the address space was SRAM (normally used for the 16 pseudo-register blocks). Of course that means that the address decode has to special-case that region. And that was probably done by individual logic gates rather than MSI or LSI chips, at that time. Probably a good idea to bite the bullet and look at the address logic?
Actually after a bit of a refresher look at the manuals, I remember that the bottom of the 9900 processor address space is actually the interrupt vectors. I may have been thinking of the 9995 which had 256 bytes of on-chip RAM which was supposed to be used for the register blocks: but of course that wasn't the processor used in the TI-99/4.
(In fact the system I worked on was a specialized aerospace design, not a 99/4. )
I think the 99/4 did have a chunk of SRAM, but I can't say where that sat in the address space. Or where the program ROM lived either. I also seem to remember that in the 99/4 there was some really funky arrangement where access to memory had, for some reason, go via the video controller?
Keep at it, I'll be interested to see what you find!
My first computer TI994a, had a 300 baud modem, that expansion bay with 32K additional memory, a diskdrive, and a printer card I believe... MAN I miss it...
I've got one of those HP 1630Gs as well, always look forward to any opportunity to use it!
Those ceramic 9900's are gorgeous!
Here's what I do. Take a red sharpie and mark ALL outputs of every chip and use that to probe those outputs with a scope. All chips with outputs that are switching are likely good. All chips with either steady high's or low's need to be marked and further tested via checking their inputs to see if their truth tables match. And ofc any chips with in-between logic levels that aren't tri-state are likely bad and that chips should be pulled and tested out of circuit. Tri-state logic can trip you up when all chips go high impedance and the resistor network pulls that line high/low. It will look like an extra slow transition on the scope and gives the illusion of something being bad when it's not.
What an odd way to jump rails about, a fascinating factory bodge.
Have all the other papered rails been checked? They seem quite fragile. Were any used for signals?
Perhaps comparing signals in the discrete logic between the working and non-working systems might help?
As others have mentioned you CAN NOT just replace those busbar units with wires. They have very low inductance and some inherent capacitance. If TI could have used cheap wires to reun the power they would have, but clearly they didn't. You may remember that in the early machines the DRAMs were very hard to make work properly due to power supply bounce as precharge (Row/Column select) currents are quite high. Many memory card vendors for the S100 systems failed due to inability to get their boards stable. What you really need to do is get a fast scope with very low capacitance and start watching VDD/VSS/etc lines to see if the power is stable. If power isn't stable then you will see lots of toggling but signal integrity will corrupt your data flow. I wonder if part of the boot sequence to the SRAM is working (they don't need as much bypassing) but the rest of the boot sequence starts running in DRAM and that's where the troubles begin
Sometimes it's almost impossible to bring up a system like that, to many dependencies. if you can write a tiny program loop that toggles some I/O port. burn it to a eeprom and try. you can see if the memory addressing is working, the one chosen I/O is working. if you get this far then it's a matter of trying other I/O and memory addresses.
Ouch! I feel for those lifted traces, and I have many under my belt. I think I may have tried low-temp alloy, or failing that I would have sacrificed the machine-pin strip housing. The individual pin sockets will still be functional, even if not useful as a strip.
Nice, happy to see you still working on this. 😎
If the LS138 is stuck high but the multiplex input is fine then it’s the select lines.
From my experience: it is better to cut off the chips (if you're sure they're defective) and leave the legs in the PCB then solder a socket to them. Less work and no risk of damaging the PCB vias.
I've got a Texas Instruments DS990 Model 1, which uses the same ceramic TMS9900 CPU. Curiously, I've read somewhere that the Model 1 was used in the design of the TI-99/4, which I wouldn't be surprised if that were true.
Unfortunately, the only thing it does is show 'LOAD ERROR 22' on power on, and if I try to power cycle it, all I get then is a blank screen. I have to leave it alone for hours (maybe a whole day) before I can get that error message again.
I've been working on this machine off and on for about 6 years now, so I'm not holding my breath I'll get it to work any time soon.
Good luck!!!
I noticed U506 pin 6 going to the enable line pin 6 of U505. As U506 is open collector and the 138 is doing something then 2k2 pull-up must be ok but still leaves the gate to be checked. If you remove all memory chips and set the databus to the opcode for NOP with resistors to the rails, will the cpu behave like a counter to enable easy checking the rest of address decode logic? Only other thing is you burn an eprom with a short test program to run through addresses in a specific pattern and check out the logic pattern with a scope. Do the same on your 99/4a assuming decoding logic the same and compare behaviour of logic lines (a little like signature analysis of days of old at this point). Maybe that might help find a clue? A silly thought just in case. Best of luck 😃
Seems obvious so no-one said it. Re: lifted tracks? I use a PACE PPS - 85AE / MBT-250.
Use this station with an SX-65 or SX-70 desoldering hand-piece. Not later ones.
Good God man your patience !! :)
I'm jealous..
I just got a new TV and I'm burned out just trying to get all the pictures settings the way I want it,,, it's been 2 and a 1/2 days and I'm sick of it...
How in the hell can it be too bright and too dim at the same time ?? lol
I highly recommend investing in a Pace SX100 desoldering tool.
Maybe I missed something, but when you tested the 138s, didn’t you see good inputs, but no changes in the output?
Well a reason for that might be the the enable pins must be in the correct state G2A and G2B must be low and G1 must be high. This was not checked in the video, but maybe it was in real life.
I suggest.... Sod it, go for a beer! Send the damned thing to Adrian for a 'holiday'.
UGH! I can't believe I left the TI-99/4 I found years go hanging on my old computer center wall on display. Back then, retro computing wasn't popular, and I had no idea how rare the 4 was!
Ls138 problem. Swapped bad with bad, or connection problem between it and vdp
I think it's about time you put an ESD mat on your benches. these old chips are not very good with static, ok in the board but a bit risky when the pins are exposed. Even if the first hits don't kill them it can slow them down as it can increase the gates latency.
Still nice to see this old stuff getting fix, these are the computers i grew up with along with boards like the UK101, superbrain, and Nascom's
Point to point tedious wiring checks. Data bus signatures from reset of good vs bad using la. Check dram refresh signatures. Are clocks stable prior to reset?
Are all the quartz frequency generators generating? May be a recap is in order, just to be sure?
Maybe a crystal is cracked or broken?😁
Something wrong with the video signal? Perhaps a broken solder joint on the display connector?
I would start with a thorough visual inspection of the board, solder joints and components. Reflow. Did you check the voltage (and ripple) after replacing the broken bar with bodge wires?
It was rusty so... flush it with flux and reheat every soldered pins. I might have missed but have you checked the rom?
It's a model hellzno...
My first test from this point, would be to see how far I could throw it. If it doesn't return like a boomerang, it wasn't meant to be.
Regarding the ram, since the majority of the pins are paralleled between all of the chips, socketing the whole lot is actually a good move as it makes diagnosis far easier. Any short or stuck pin on one chip, would affect all of the other chips, if that pin was common to them all.
Back in the day, I've played this game, and ended up doing exactly this. Socketing a bunch of chips when you have a good de-soldering machine is actually not much of a chore, and can save you a bunch of time in the long run. Especially when more than one chip turns out to be faulty.
Nice project. You mentioned that the decoders were not decoding fully, have you checked all the enable pins to ensure that you have enabled decode outputs. What does the Logic Analyzer say about this ?
What about noise on the power rails - are they clean, are the caps any good ?
Is the reset signal working properly ?
Are all address, data and control lines moving, particularly important ones for addressing / memory control (ALE, R/!W, etc) - or whatever they are called on that CPU
Can you dump the ROMS, disassemble the code and look at what the instructions are that form that loop - to see why its failing whatever test is being done, this should help focus in on what's going on and help focus in on the fault domain
I think he meant they are decoding - just not getting signal because the boot process never reaches the point when GPU is initialized
Otherwise, agreed.
Oh hai! ^-^
great video!
Ok, so here is what you do. You build a “CPU” emulator using a rPi or Arduino to statically set addresses, data bits and control signals so you can then statically trace the selects, address and data to memory and devices.
So just use a set of those pin headers wired to the rPI, arduino, or even manual switches and then plug them in in place of the processor.
PCB wiring issue maybe? Damaged trace or even a missing white wire that fell off?
I remember back in the day there where TTL chip testers that would test the chips in situ, maybe time to recreate that with a RP2040....
There are a lot of chip testers floating around, in theory they should be able to test at least some of the logic chips without desoldering if you run the wires...
Does anyone know of a "dead test ROM" for TI-99 or similar?
Compare bit-by-bit to a working system!
Try connecting the logic analyzer to at least low bits of address bus (you are probably better off soldering the wires to a chip than doing the clip porcupine again) and recording first few seconds on good and bad system with the same ROMs (probably doesn't matter if it doesn't boot all the way as long as it gets past "sound disable" step)
then compare them and try to see where exactly it fails.
one other possibility is to remove RAM, ROM, and other chips and compare what happens to working and dead system.
From what I can see the CPU seems to be executing code from the ROM, but does not go past basic initialization so it never even gets to the point where it's supposed to initialize the display.
It seems it's really easy to mess up TI-99 boards and connections. Probably a trace corroded *somewhere* .
It may be a bit of a stretch, but you may try swapping all socketed chips at once (and the power supply if compatible) between working and dead system. Sometimes some chips appear to work in one computer but not in the other for some strange voodoo reasons.
try watching Noel's and Adrian's videos not just on TI-99 but other systems. They show a LOT of troubleshooting techniques.
if everything fails, it's ok to admit defeat. rechecking every single trace is probably too much work for a ti-99 which is not that rare or important to warrent so much lost time you could use for more interesting stuff that you CAN do. Send it to some other guy who specializes is TI-99 repairs and call it a day.
The processor's activity after it has gotten off track may not be related to the actual problem. If a bad bit in an earlier opcode sends the CPU into the weeds and it starts executing from the graphic roms, looking at what it's doing at that point won't tell you much. Maybe capture a trace from reset ending on the 99/4A and compare that to what's happening at the start on the bad system. If you are lucky, the problem will show itself soon after reset ends. Also, if you can find a disassembly on the web of the boot code, that would make it a lot easier to understand what you are capturing on the analyzer. Especially if you capture the data along with the address.
I was about to suggest rom issue, but you check... Soooo, besides the 138, what else is involve in rom selection?
I feel the same about the ram...
I legit put sockets in my apple iie because of that, lol😊
Apart from everything you already tried, I would try to figure out which instructions are throwing the CPU into the loop, what is it actually trying to do. Waiting for a device to be ready, perhaps?
Smells like a circuit continuity issue. Hopefully you'll figure it out.
It's so frustrating when all the parts work but the whole doesn't... think the best thing to do at that point is, indeed, to take a breather.
This reminds me of one of the issues I was having with my Tempest boards when I first bought them. That turned out to be marginal ROMs. They would read okay in my reader but apparently the output voltages were too weak to be read properly by the CPU on the board.
Have you tried checking the output of the 138 for shorts against +5V? If the input is correct but the output is stuck high that would be my prime suspect and the video didn't show if you did... If the system is stuck in initializationmode, i.e. never accessing the video RAM at all, the "mode" line should be high, but the CSW line should go low now and then at least. The Nabu has the "A" revision of the chip, but still, I think those signals are the same?
Were you able to make sure you don't have a leaky capacitor creating a DC offset and holding a pin high or something?
Check the 138 three enable pins (correct logic obviously).
There is no sich thing as an unrepearable computer. Just the lack of stamina, chips or ideas.
i had similar fault in a famiclone. everything tested good in fully socketed motherboard but the broken one still didn't work
i tryed transplanting clock from another board, testing wierd stuff going insane, smoking up one cpu and then i being frustrated removed everything andpoint to point tested every chip connection to another, they were all good, but then i tested if any data line wasn't shorted to the one next to it, still no luck but i started testing at random everytrace going in between soldering points and i found one fault, reset was shorted with one data line in cart socket, after fixing that one short the whole console was back to life
and i did that without any fancy equipment, just a multimeter and a lot of probing
so if this pcb has no solder mask between pins, chcek every trace that goes between legs of any ic or socket. you don't need a lot of current to flip a state of high impedance logic so even tin wisker or a blob or snot can do it
you can also try to partition the board if you can offload part of a circuit to breadboard analogus circuit, a lot of thinkering but can rule out any boardfault by bypasing selected part
you can also check in circuit if for instance music, or video part of the board working by removing your cpu and ram and pulling data from interposer on another working board with that chip removed
Take a break and think about it then go back to it. That’s what I do. But keep at it in the long run. Best drug in the world fixing something like this, at least it is to me.
Socket one socket all, I heartily concur.
Hold on hope, buddy! You’ll get it! I have a device that’s sitting under a cloth thinking about what it’s done wrong too. These machines will work again, dammit!