Hi a couple notes I am going to pin: I call it 80 and 40 column several times, but I know the TRS-80 is actually only showing 32 and 64 characters. FWIW, the official service manual on page 24 calls it 80 column mode, but says 64 are displayed, 16 are blanked. The two internal expansion connectors on the top edge of the motherboard are for floppy controller and the serial RS232 card. They do not mount to the motherboard at all, but instead mount to the back of the metal bracket holding the motherboard and use a flimsy ribbon cable to connect up. Picture of a M3 motherboard installed: dunfield.classiccmp.org/trs80/h/m3board.jpg Notice the ribbon cable at the top plugged into the expansion connector and flipping over the board? I can't find a picture of the floppy controller mounted, but it's on the backside behind the motherboard and metal cage.
I'm working on a Model III right now. I have both floppy controller and RS232 card. While dismantling for service, the flimsy ribbon connectors LITERALLY DISINTEGRATED... Can't imagine to find a replacement for them, so I guess I will have to make my own cables...
The chip that is trying to pull the line down seems to fight against another component holding the line up the whole time. There may be another broken chip whose select(&deselect) lines are not working properly allowing it to drive the line high the whole time… make a list of all chips directly connected to the bus (or the line you were measuring) and try checking their select state. If a chip is trying to write to the bus all others should be silent.
I used to repair TRS-80s with nothing more than a very cheap DVM, so I’ll be interested in watching your follow up. I will give you 2 little hints, 1) At boot, the system will prompt for “Memory Size?”, 2) The keyboard is memory mapped, and should always be scanning.
Truly astounding. Only someone with many years of experience can talk with such authority and joyful clarity. You are like a captain of your own vessel, and you keep it nice and tidy, and yet know that life isn’t about the destination but for the glorious journey that keeps life full of astonishing possibilities. This is truly the essence of the Q: how to become an elephant? A: One bite at a time.
I, for one, like these "failure" videos. On YT you often get the sense that the creator is always batting 1000 and just never fails. I think a diagnostic ROM is a great next step.
@@CalintzJerevinan546 Really? You must have A LOT of free time if you feel the need to uselessly "correct" my post to your preferred numbering format and your hatred for accepted acronyms.
I think creators feel a lot of pressure to get it right, viewers like a payoff. But I agree with you, I like seeing failures as well as successes. Makes you feel less stupid when you hit a stubborn problem yourself.
I rather disagree. This is a project in progress open to the public to participate. It is only a failure when you entirely give up, and when a youtuber does that I tend to unsubscribe. Luckily Adrian isn't the type. I am sure he will crack this nut eventually.
There was nothing unrewarding about this video, Adrian! I thoroughly enjoyed it, watching it in 3 parts throughout the day. Thanks for letting us in on your thought processes as you go so that we can learn with you. Looking forward to the next part. You'll fix it. I believe in you!
Also, i also really appreciate these videos where you keep your viewers in the loop of the troubleshooting even (especially) when there is no resolution. It really gets us involved in the process.
Great video, as always. You poke data and address pins directly on z80. However data and address pins are buffered, so you should check them after the buffers/latchs. Looking on manual of the TRS, is pretty easy to figure that out. Them you will be able to detect if some chip is holding some of the lines up/down effectively. Also, you should check NMI/Interrup pins, to check if interrupt are not being hold on of not occurring. Another point to check is M1, as someone else pointed out this thread. I would also isolate all ICs that are not directly plugged into CPU or are much likely not possible of interfering with the CPU, to not look at them, and narrow down the search. Also, the video circuit probably put CPU on HOLD to avoid it accessing display memory while drawing stuff on screen, so WAIT line should be pretty active. CPU only get between lines and blank time to process. There are some 74LS157 that do multiplexing, changing address lines between CPU and graphics counters. That should be changing correctly to update of video ram content to happen. I would assume that the counters for video are working, since you are getting charactes on screen. A possibility is the MUXES to be lock on just the graphics side of address bus. Look for that line (U69, U70 and U71 pin 15 and pin 1)
@@adriansdigitalbasement O yeah, now I also remind peek and poke direct into memory... It worked great voor getting characters on your screen fast...(Instead of 'print' to screen). Damn, that system was so fun!
@@adriansdigitalbasement I already send you a message previously, but I will put here another very important tip. Please, don't touch crt boards and power supply boards surface with your bare hand, even if disconnected from power supply. I saw that you discharged crt correctly, but the boards have a lot of high voltage capacitors that always hold power for prolonged time. I saw you many times, in other videos touching the bare crt boards without taking attention into that. Please, hold them by borders, and take more care on that. I don't wanna that my favourite TH-camr lose a finger because a capacitor discharge. Also, as good practice, be carefull when touching heat sink on these boards. sometimes they are not on ground plane.
Love the TRS-80 videos. I've worked with the Model I, II, III, and IV back in the day. Love them all. Please do more! And hope you come back to my favorite, the Model II, one of these days.
@@TheDurdane Not sure! It was a marvelous machine. Felt like computing on a tank. That 8” drive seemed so heavy duty compared to the 5.25” units on home computers. Happy memories!
Maybe a broken solder joint or trace? Trying to explain why you got the blank screen while piggybacking, maybe it was just the physical pressure? Failing that, I agree my next step would be to make test ROMs to exercise each chip select line for scoping.
NOT a failure of a video at all. You've gone down some of the obvious troubleshooting paths that were readily apparent but didn't get to a conclusive resolution. Not only does this happen to all technicians sooner or later but documenting this is even the more heroic step to take. Do not see this as failure. This is more the educational epic step to take in showing the steps to take
we learn from failures and successes - i'm glad you left the video in even though it wasn't fixed, it's still interesting to follow the diagnostics and all knowledge is good knowledge!
I really appreciate you posting this as it's an educational experience. Certainly the opposite of a "wasted" time. Thanks and am looking forward to the next one.
Taking a break from a machine and clearing your mind is good. Sometimes I stayed with a computer or disk drive too long instead of setting it aside and coming back to it later.
There was something that was irritating me: The ROM that showed a flaky behavior at testing with the Retro Chip Tester was the 2316(b) - The replacement you built was showing as the 2364 TRS80 Model III in the testers display. Are you shure, you used the right ROM for the last test?
Not only is it a 2316B, it's displayed at 23:16 in this video... with checksum 0x84A5702D, identified as file 8040316B.U106. The adapted ROM is displayed at 45:11, with checksum 0xEC0C6DAA identified as file 8041364.u104.
This is a good catch and I don't know whether Adrian used a different image than the original when testing in the adaptor. But the original ROM is 2K and the adapter allows socketing an 8K ROM. Whether the 8K ROM was loaded with multiple copies of the 2K ROM, or just the first 2K and the rest filled with FF, the checksum will be different. I wonder if that's what's going on. Also, keep in mind there are three ROM sockets and I think he's testing more than one of them in the RCT pro, even though he's only replacing the boot ROM with the adapter.
a video like this is just as educational as one where everything works in the end. so i hop you`ll keep posting the videos even if the machine doesnt end up working.
Great discussion of how to "secure" an open power supply. Again - it's not necessarily the details of how to fix a TR80 (because I'll probably never do that) - but the best practices. Thanks!
Welcome to my world :D It's exactly for these reasons I went down the logic analyser route many years ago. If you know ROMs are good and RAM is good you can hook up an analyser to watch what the CPU is pulling from the ROMs and see exactly at what point the boot process fails. This is assuming of course that you have the docs and disassembled ROMs available as you do with this board. I'm struggling with my Positron 9000 because the only source of schematics is me, but I have some great 6809 people helping me. You'll get there because you always do :)
I used to fake something like this with an oscilloscope. Trigger the 'scope from reset and you can see the first few cycles of machine operation. That allows you to look at the various control signals and data in context, rather than at some random time when the machine has already crashed. You can see everything this way, the CPU control signal outputs, the address decoding outputs to enable the ROM and then the ROM data. One advantage over a logic analyser is that ambiguous logic levels are clearly visible, but clearly both approaches have their uses.
Totally agree the logic analyser would be the way to go on this one. There is a good TRS-80 revival site which has disassembled roms, schematics and much more. A must have in order to troubleshoot effectively.
I used to own a Model I system, extensively modified. First, Tandy needed two revisions of the expansion interface (third try was successful) for it to work. I avoided all that by building up an LNW Research board. Took a *lot* of soldering (I think about 60 chips). It came up with no soldering problems. Then I: 1. Overclocked the processor from 1.77 MHz to 2.01 MHz. Anything faster trashed the video. 2. Modded the character generator for lowercase with descenders. 3. Added a CP/M daughter board. 4. Changed to 80 TPI floppy drives. People used to ask me what software I used. I told them, "Wordstar, SuperCalc, dBase II, and MTV." That was around 1980. Newcomer, but I have noticed Adrian is a little sloppy with "floating". A TTL Logic Low is defined as less than 0.8 volts, but typically around 0.1 - 0.2 volts. A TTL Logic High is defined as more than 2.8 volts, but typically around 4.5 - 4.8 volts depending on the 5 volt PS rail. A floating input will read about half the rail (around 2.5 volts) and *generally* act as a Logic High.
You could just remove the Z80 CPU then wire up the address, data, and the RD,WR , MREQ, IORW signals using wires. Unlike some CPUs which have a phase signal that makes things complicated the Z80 signaling is very simple. Hold the IORW high, the MREQ low and pulse the RD to WR signals to read/write to memory. Reverse the IORQ and MREQ signals to write to IO ports to control things like the video modes. The other control signals can be ignored for this type of testing. This would allow you to directly read and write to areas of the memory manually. While it would not work correctly for the dynamic RAM as the refresh would not be happening but you could write to the video memory and see the change reflected in the video. The would also enable you to check address decoding signals. It also lets you verify DC signal levels from the various buss drivers. This is the method I used back in the day with my Model I and Model 4 computers because I did not have any fancy test equipment. One the Model I there were 74LS367 chips that failed, on the Model 4 found a 74LS245 chip had failed. The model III is very similar in design to the Model 4 but the Model 4 had an 80 column video mode and could support up to 128K through bank switching. If memory serves me the 74LS645 had a higher fan out than the 245 which may be important for driving the dynamic memory chips just because there are so many of them. The output from the decoder chips will show some garbage transitions because the address bus signals are transitioning and can only be relied to be valid during an active MREQ or IORQ. Also with the digital noise these boards generate and the less than great supply busses on the board, getting noise on the oscilloscope is just going to happen. You might also wants to check the power supply caps just to make sure your inconsistent behavior is not due to poor power quality. Another possible issue is the ROM chips are just not be fast enough due to age, they were pretty slow (450 ns) to start with which limited the speed of the CPU to 2 MHz without adding some circuitry to insert wait states. Replacing them with some EPROMS which are much faster could make a difference. On my model 4 I build an accelerator board which allow running the CPU at 2 MHz or 4 MHz which worked fine with all the hardware except the ROMs which required injecting a wait signal during a read from the ROM. I only had a cassette for storage and reading and write data to tape was much faster and worked just fine running at 4 MHz as long as you used good tapes. I created a little program loaded from tape that would copy the ROM into shadow RAM, patched the ROM image to provide support for using 80 column mode and setup a key combination to switch CPU speeds.
Great job!! This is part and parcel of troubleshooting and you made a great video. NEVER SAY DIE! I know you’ll get this one fixed, booted and running great again! Be sure to let Stephen know you’re using the RCT II to troubleshoot. He would be thrilled to see it.
Great to see the details of the TRS-80 Model III in operation. I grew up with a Model I so know how it functions reasonably well. Interesting to see how it's sister computer works at such a low level. A nice change is the move to 74LS245 buffers...the Model I has much older chips which only buffer 6 lines which make the schematic much harder to follow.
Honestly, I think you got this at least partially working at one point. Others have pointed out the ROM issues, which I think are relevant, however I haven't seen anyone mention the piggybacking working at first. Might be wrong, but something to check: what if both chips are good, but there's something on the other end of the line that's shorted somewhat strongly to the +5v rail, and a single chip isn't enough to drive through it, but two chips *is* enough, or maybe was. Seems like you honed right in on the right circuit, just not quite the right end, to me. Good luck with the rest of the repair
I would not call that stumbling on to it. You were troubleshooting based on what output you were seeing and the boot process took you to the place you needed to go. Good work. I wonder if it's a cold/cracked solder joint or even a cracked trace. When pressing on the board it made a better connection.
That occurred to me, too. I've had inconsistent motherboards that I had trouble finding the problem with, and discovered that had tiny cracked traces and/or cold solder joints that were causing the weird inconsistencies. Seems like a possibility, anyway. Inconsistent, 'flakey' behavior is the hardest to troubleshoot, in my experience.
I have repaired hundreds of Z80 devices, in industrial use and computers. The largest failing devices were the Z80A itself after almost exactly 5 years power on they would fail. We (the company I worked for), had great records of installation and failures for many thousands of Devices. The Zilog Z80A, very accurate to 5 years power on fail. Intel Z80A run forever at less than 4Mhz at exactly 4Mhz they fail at 5 years. The center port was a memory expansion if I remember correctly. Next failing thing was the 74(LS)367, look for half level signals. Next the memory ROM /EPROM, and memory 4116 etc. The difference between the LS245 and LS645 is in the output speed the 645 is about twice as fast.
Great video, great mystery, and nice cliffhanger. I still remember the MIII well. In fact I can give you your diagnostic ROM off the top of my head. F3 3E 55 32 00 3C C3 03 00 That will continuously write 55 ('U') to the upper left character position.
Intermittent fault with master faults as well.... about as frustrating as it gets. I'm thinking from the description when you piggybacked the chip and those issues, one thing that changed was you were placing pressure on the chip to piggyback it. Trace or soldering problems may change under physical pressure. (?) (I missed a couple of minutes in the video so sorry if you covered that possibility.). There is nothing as boring as tryjng to do visual and or continuity inspections. But it was a fascinating video to watch - I owned a Model III for many years - takes me back!!!
This is very cool. I still have my first computer, a TRS-80 Model IV with all the extras in the basement. Years ago I damaged the CRT tube though so there no chance the on in the machine is ever going to work. One of these days I'd love to get the machine up and running again and a converter that can take in the video signals from the main board and put out HDMI would be a great solution for that. BTW...the TRS-80 model I and III ran 32 or 64 character modes while the Model IV added an 80 column mode to better work with conventional terminal 80x24 displays. I'm an EE by training and the next step I'd probably take with the board you're looking at would be to instrument the CPU data, address and control bus with a logic analyzer and set it to start capture on the inactive edge of reset. Capture the first few cycles and the CPU should be fetching from address 0, 1, 2 and the first byte read should be an absolute jump instruction I think (C3) followed by the destination address. If that seems to be working then move out and check the address decoding and some of the other stages in the system where early boot activity touches things. Using the known good machine as a reference might help too. Its first few fetches should match those that the broken machine should be making. It has been a very long time since I messed with Z80 code but I still have quite a bit in my head. I spent my teen-age years disassembling the boot ROMs and TRS-DOS code by hand and learned a lot. These days I'm generally coding in C++ and C# on machines where the cache memory is vastly larger than the TRS-80s whole DRAM array but I have fond memories of those old machines.
It's a rewarding video imho, especially if you don't give up and come up with new strategies! Can't wait for the next video on this board! Thanks for sharing with us :)
Wasn't it the 2316B that was marginal in the Retro Chip Tester Pro? Also, the fact that the BCD is trying to drive ROM B and ROM C low but is failing to do so reeks of a bus conflict. I also feel like the fact that the two chips together when you piggybacked the first-time confirms that because two chips together are enough to sink the amount of current to resolve the conflict (just a hunch). I know you have replied to other comments saying all will be revealed in the next video, I am just providing my hunches.
Indeed, the address decoder at U60 (74LS145) appears to not be pulling to ground; these are open collector chips, hence the pull-up resistors on the outputs, and should be able to sync 80ma to ground, but if there is a short to 5V (internally or externally) it would certainly look like what's on the scope. It might also also cause VCC to fluctuate in sync with the select. Dual channel scope would be useful for that.
@@awebster that was kinda my thought, and when Adrian piggybacked the chip, it was able to sink the current long enough to clear the screen RAM, but didn’t resolve the conflict; so it still wouldn’t boot.
My old friend, the trs-80 (model 3). I had 2 5.25 floppy drives, a tape drive (Radio Shack tape recorder) and my grandfather bought a 30 MB hard drive for it that cost as much as the computer itself. Good times.
Really good video, I start it jumpers in the ribbon cables (is conected but if have some resistance con drop a signal). The worst first, then the rest.
Good Video Adrian, Years ago when I used to teach a 6502 micro course, we had some very handy logic analyzers that we could hook to the Address and Data Bus. We could then trigger off the reset vectors of the CPU and display the address and data that had been captured by the analyzer. The analyzer also had two BNC outputs to connect to a scope that allowed us to display all the lines against one another and scroll that display. If you had a copy of the Boot ROM disassembled and a logic analyzer you could confirm that the CPU is actually executing the ROM code correctly. I'm sure there are similar devices available today but I don't know what the cost would be or if the cost would be too limiting. I have seen inexpensive 8 bit logic capture devices for as little as $10-$15 and this machine only runs at 2MHz so it might not be prohibitively expensive. The other issue would be to get a copy of the boot ROM code disassembled into Z80 code so you could follow the boot sequence. I guess with a hex dump you could work that out or get a program to do that for you from the ROM dumps, given time. You also could do with a memory map of the Model III if you don't already possess one. I used to have a printed disassembled copy of the TRS80 Model 1 ROMS years ago when a group of us were into the TRS80 back in the 80's. I would also check again around the address decoding for the video and ram. I wonder if you could single step a clock pulse and monitor the address and data lines with buffers and LEDs ? The System RAM could be an issue tho because its dynamic RAM and not static. Maybe even decode the Address and Data binary into HEX form to display on a 2 data and 4 address, 7 segment displays ! Good Luck.
Often, when I'm stumped like this, going back to first principles can help me find the overlooked piece I need to build a better hypothesis. Have you looked at power, ground, and clk (for those that use clk) and verified a probable-looking signal is present at each chip? If yes, press the chip and validate each signal again? Dull work for sure, but if the real problem is a flakey trace, this is about the only way to localize and then find it. Good luck!
Great video. Don't give up - you should have enough skill to fix this. * Have a working TRS-80 on the bench and powered up - check for differences. Maybe even synchronize them. * I'm not quite sure but that "working" chip select logic results looked a bit wierd. Are you sure replacement chip is good? Remove the CPU and try applying levels to see if it operates correctly. * Those ribbon cables most definitely need to go - you don't know what they are doing at several MHz * Do your favorite thing - deoxit those sockets! A pin can easily make unstable contact * I think a working TRS-80 with all ROMs removed should display a non-random pattern. Try it out on a working computer. * There are a couple of diagnostic ROMs floating around, probably there is one that does not require VRAM to work * If everything fails, ask on TRS-80 related forums. They may be able to help.
I have a model I with very similar issues! Have replaced a good number of suspect ICs, but was eventually able to breadboard it to an EPROM and send a message to the screen with my own code. My next step is actually checking the ROM's CRC, but had to put down the project a few years ago. Working on one of these tends to humble you very quickly.
About that capacitor in the power supply - assuming the leads are long enough, it could be mounted off the board to get it away from that resistor. To keep it from flapping around in the breeze, silicone snot it (RTV or your basic silicone caulk) to the transformer.
I use to repair all manner of coin-op equipment including: arcade games, juke boxes, vending equipment and even slot machines and quite often I would not have schematics on one off boards. A lot of intuition and guesswork got me through those as well as a few tricks (like brushing denatured alcohol on a running board to spot 'hot' chips and possible shorts). Many times I would have to leave it be a few days or even a week then come back with new interest and I will say that 99% of the time I ended up solving the issue (in our shop, I was the top tear tech so if I couldn't fix it, it got shelved and never fixed (or shipped out to a pro shop with all the schematics and fancy test equipment (while I used a 30 year old O-scope).
I've found the TRS-80 Model 1/3 to be some of the most complex to troubleshoot and repair. I spent 7 months to get a Model 1 up and running again. Fortunately I also rescued a Model 3 that had sat in someone's attic for 30 years and was a much easier repair than yours!
Yup. I do 8-bit and 16-bit machine repair, and the TRS-80s are always a treat. They have far more failure modes than other 8-bit machines, probably because they're built from an enormous pile of 74LS chips rather than having custom chips with well established failure modes. The net effect of their design is that you *really* need to study the schematics and the theory of operations manuals, because inevitably there's one 74LS chip *somewhere* that's doing something outside of specs, and sometime it can be really close to spec, but not quite there (for example when it heats up it suddenly exceeds the chip family's propagation delay specs). They can absolutely be a bear to debug because you can be *really* close to working and still have strange symptoms like Adrian's seeing here. (I would suggest however that he rule out the fact that the keyboard isn't connected and he isn't holding Break. I can't remember what happens when the keyboard isn't there, but I do seem to remember that you can get some weird behavior).
I would suggest to go the logic analyser way, because of the inconsistent readings etc.. A way back we had an Atmel AVR CPU with external ram (with battery) and we have searched a half a day to figure out that we have missed the write impulse timing by a 20 ns! When we fixed that it worked flawlessly. Anyway great video and failures are sometime part of the job... failures makes us to learn.
Love your videos, Adrian, and I don't even mess with old computers. But the thing about putting one chip on top of another - I'm an EE as well and I can't figure out why that would work at all. It wasn't a fix, but I just didn't expect that putting a good chip on top of a bad chip would do anything useful... The bad chip could negatively affect the good one that way... But maybe you have a new technique there.
If you get bad logic levels and the chip that outputs these turns out to be good and/or piggybacking makes it work, then there's likely a shorted input on one of the chips it tries to drive. Happens a lot on overvolted boards, but this failure mode isn't unheard of on non-overvolted boards. I'm pretty sure yours wasn't overvolted. Sometimes, if you try to just connect the power rail it's stuck at and connect the other power rail to the pin that isn't working, you can do the finger test, which chip gets warm. (in your case it's stuck high, so you connect +5V, and connect GND *only* to the offending pin, wait a little and feel which of the connected chips are getting warm or hot) (in my case - a badly overvolted board - , pins were stuck low, so I connect GND to the board and connect the +5V only to the offending pin and more often than not, at least one chip got hot even though it doesn't get power, so I replaced that chip and that got me a little further, then I look for more stuck bits, repeat process and eventually the board started to output video, eventually it would clear the screen and finally it started to boot)
Hi Adrian Love your channels, always look forward to new videos. Can we have more content like this? It's fascinating to follow your thought processes in fault finding these problems. Seems a little perverse to enjoy your frustration though! 🤣
Looks like bus contention. The chip is trying to drive the bus low (and also it's replacement) and another thing on that line is trying to drive it high. Two chips piggyback driving it lower makes sense in this scenario. Just check the schematic on the line to see what other chips are able to drive this line active high. The Model III was the computer I used at university to do all my work coupled the the line printer VIII with a 1200pbs modem to the VAX/VMS system. Then I upgraded to the Commodore Amiga 500 and finally to PC. I went on to develop chips at Intel for most of my career and then decided to move to a non profit organization after 15 years to write software. The easiest way to deal with this scenario is to scope every digital chip and find the pattern of undefined logic levels and then consult the schematic.
If my memory serves me well, if you have a floppydisk controller connected the TRS80 (model 1 and 3) will NOT clear the screen as the screen is cleared by TRS-DOS (or another DOS like NEWDOS-80 or LDOS) so typically you would get a screen full of 64x16 characters for a few seconds before DOS took over, and without a working floppy you just ended up with a creen full of garbage. To get to BASIC when you had a floppy capable machine you had to push the break key down while powering up the TRS-80! I expect that you don't do this now, so this result is exactly what I would expect.
Adrian, are you stalking me? This is the 3rd or 4th time I've come home with a new acquisition, gone online to find out more about it's innards, and you have a less than an hour old video on the same machine! Lol, keep up the great work!
I think it's very useful to show the troubleshooting process regardless of the outcome because this is the reality of the repair game... sometimes the fault just can't be found within a reasonable timeframe. I reckon you'll crack it though... Cheers
I would try to jump the flex cables with dupont cables or simular. The continuity test doesnt tell you wether there is very high resistance it only tells you that there is none infinite resistance. It has bitten many a car mecanic.
On switch mode power supplies, you should be able to see a clear dividing line between the line side and low voltage side with only two parts spanning the division. One is an optoisolator and the other is the transformer.
Also, if memory serves me correctly, powering it on it tries to boot from disk, and if there's no disk, you get garbage, (like what you're seeing), to get it to boot to BASIC, you have to connect the keyboard, then hold the BREAK key and power on (or push reset). I think that's where your problem is.... also, looking forward to hopefully getting a chance to meet you at VCF Midwest. :)
I was thinking that an In Circuit Emulator (ICE) might be helpful in situations like this. You could single step the ROM, see if it's executing code. If you have an annotated ROM decompilation you could probably get a hint about what is bad. Alternatively a logic analyser with decoder for the CPU might be able to do something similar. Needs lots of channels and a decoder. Not sure if Sigrok has one, but I seem to recall someone made one for the 6502 and Z80 for people making their own computers.
Looking forward to the next installment. I think I haven't looked forward to a to be continued ADB since the Compaq Deskpro series. The TRS-80 Model II is right up there. I'm sure you saw the other posts about the ROM you tested late in the video not being the one that gave you issues with the tester.
Nice Video, IC sockets are notorious. May be some socket is causing a loose contact. I would try replacing all old sockets or try cleaning the same with WD40
Oh noes - missing the dopamine rush of a successful repair! I guess I'm addicted... 😅 But actually it's a great learning exercise to see what happens when troubleshooting keeps on bouncing off the hoop. Our skills are built by experience - the bad as well as the good.
FYI: ubiquitous IDE 40 pin ribbon cables work pretty well as a replacement for these always dead TRS-80 pieces, the ide ones are exactly twice as dense (10cpi instead of 5cpi), so you just need to cut off the ends off every other conductor. At least on the model 3 there were pin headers, on the Model 1 the cables were hand soldered between the keyboard PCB and main board.
Its so genuine to see the process not always result in a fix. This is good stuff. And your process was logical and correct as far as i can tell anyway. My personal thoughts are; because of the inconsistency of results, maybe the 5v rail is slightly too low (borderline for older TTL). Maybe try a bench supply just for the 5v rail or a known good supply. also, is there any noise on the rail? any decoupling caps across it? Second, could be a PCB dry joint or crack. Maybe you were flexing the board.. Either way, its a time consuming tricky fix. Keep going! great vid.
That "trying to come down" instead of completely coming down is an indication of a short or internal continuity. I would investigate that line, and try probing it with all chips that connect to it removed or swapped not just one. There can be some inconsistencies at power up if a line like that isn't logically high/low, getting cross talk, etc.
Hi a couple notes I am going to pin:
I call it 80 and 40 column several times, but I know the TRS-80 is actually only showing 32 and 64 characters. FWIW, the official service manual on page 24 calls it 80 column mode, but says 64 are displayed, 16 are blanked.
The two internal expansion connectors on the top edge of the motherboard are for floppy controller and the serial RS232 card.
They do not mount to the motherboard at all, but instead mount to the back of the metal bracket holding the motherboard and use a flimsy ribbon cable to connect up.
Picture of a M3 motherboard installed:
dunfield.classiccmp.org/trs80/h/m3board.jpg
Notice the ribbon cable at the top plugged into the expansion connector and flipping over the board? I can't find a picture of the floppy controller mounted, but it's on the backside behind the motherboard and metal cage.
I'm working on a Model III right now. I have both floppy controller and RS232 card. While dismantling for service, the flimsy ribbon connectors LITERALLY DISINTEGRATED... Can't imagine to find a replacement for them, so I guess I will have to make my own cables...
You seriously need to shave your beard off.
@@CalintzJerevinan546 OKAY, **KAREN!!**
The chip that is trying to pull the line down seems to fight against another component holding the line up the whole time. There may be another broken chip whose select(&deselect) lines are not working properly allowing it to drive the line high the whole time… make a list of all chips directly connected to the bus (or the line you were measuring) and try checking their select state. If a chip is trying to write to the bus all others should be silent.
I used to repair TRS-80s with nothing more than a very cheap DVM, so I’ll be interested in watching your follow up. I will give you 2 little hints, 1) At boot, the system will prompt for “Memory Size?”, 2) The keyboard is memory mapped, and should always be scanning.
Truly astounding. Only someone with many years of experience can talk with such authority and joyful clarity. You are like a captain of your own vessel, and you keep it nice and tidy, and yet know that life isn’t about the destination but for the glorious journey that keeps life full of astonishing possibilities.
This is truly the essence of the Q: how to become an elephant? A: One bite at a time.
I, for one, like these "failure" videos. On YT you often get the sense that the creator is always batting 1000 and just never fails. I think a diagnostic ROM is a great next step.
^1,000 not 1000 ^TH-cam not YT
@@CalintzJerevinan546 Really? You must have A LOT of free time if you feel the need to uselessly "correct" my post to your preferred numbering format and your hatred for accepted acronyms.
I think creators feel a lot of pressure to get it right, viewers like a payoff. But I agree with you, I like seeing failures as well as successes. Makes you feel less stupid when you hit a stubborn problem yourself.
I rather disagree. This is a project in progress open to the public to participate. It is only a failure when you entirely give up, and when a youtuber does that I tend to unsubscribe. Luckily Adrian isn't the type. I am sure he will crack this nut eventually.
@@OscarSommerbo No shit what do we have here a fucking comedian Private Joker.
There was nothing unrewarding about this video, Adrian! I thoroughly enjoyed it, watching it in 3 parts throughout the day. Thanks for letting us in on your thought processes as you go so that we can learn with you. Looking forward to the next part. You'll fix it. I believe in you!
Even with no working motherboard at the end, I loved this one. Lots to learn.
Also, i also really appreciate these videos where you keep your viewers in the loop of the troubleshooting even (especially) when there is no resolution. It really gets us involved in the process.
I realllly want to see more of this, I really like how deep it is going, and where the mystery issue is. Keep up the great work!
Great video, as always. You poke data and address pins directly on z80. However data and address pins are buffered, so you should check them after the buffers/latchs. Looking on manual of the TRS, is pretty easy to figure that out. Them you will be able to detect if some chip is holding some of the lines up/down effectively. Also, you should check NMI/Interrup pins, to check if interrupt are not being hold on of not occurring. Another point to check is M1, as someone else pointed out this thread. I would also isolate all ICs that are not directly plugged into CPU or are much likely not possible of interfering with the CPU, to not look at them, and narrow down the search. Also, the video circuit probably put CPU on HOLD to avoid it accessing display memory while drawing stuff on screen, so WAIT line should be pretty active. CPU only get between lines and blank time to process. There are some 74LS157 that do multiplexing, changing address lines between CPU and graphics counters. That should be changing correctly to update of video ram content to happen. I would assume that the counters for video are working, since you are getting charactes on screen. A possibility is the MUXES to be lock on just the graphics side of address bus. Look for that line (U69, U70 and U71 pin 15 and pin 1)
You'll see in the second part you have some really good thinking Hemandi!
@@adriansdigitalbasement O yeah, now I also remind peek and poke direct into memory... It worked great voor getting characters on your screen fast...(Instead of 'print' to screen). Damn, that system was so fun!
@@adriansdigitalbasement I already send you a message previously, but I will put here another very important tip. Please, don't touch crt boards and power supply boards surface with your bare hand, even if disconnected from power supply. I saw that you discharged crt correctly, but the boards have a lot of high voltage capacitors that always hold power for prolonged time. I saw you many times, in other videos touching the bare crt boards without taking attention into that. Please, hold them by borders, and take more care on that. I don't wanna that my favourite TH-camr lose a finger because a capacitor discharge. Also, as good practice, be carefull when touching heat sink on these boards. sometimes they are not on ground plane.
Love the TRS-80 videos. I've worked with the Model I, II, III, and IV back in the day. Love them all. Please do more! And hope you come back to my favorite, the Model II, one of these days.
I've never seen a Model II... Perhaps it wasn't sold in Europe?
@@TheDurdane Not sure! It was a marvelous machine. Felt like computing on a tank. That 8” drive seemed so heavy duty compared to the 5.25” units on home computers. Happy memories!
The important thing here is that you are learning a lot and so are we. Thats a great win, my friend.
Maybe a broken solder joint or trace? Trying to explain why you got the blank screen while piggybacking, maybe it was just the physical pressure?
Failing that, I agree my next step would be to make test ROMs to exercise each chip select line for scoping.
All will be revealed in the next video! :-)
Dude, You’re doing a knockout job and you have figured out a ton on your own. Unfortunately you can’t fix them all.
NOT a failure of a video at all. You've gone down some of the obvious troubleshooting paths that were readily apparent but didn't get to a conclusive resolution.
Not only does this happen to all technicians sooner or later but documenting this is even the more heroic step to take. Do not see this as failure.
This is more the educational epic step to take in showing the steps to take
we learn from failures and successes - i'm glad you left the video in even though it wasn't fixed, it's still interesting to follow the diagnostics and all knowledge is good knowledge!
Wow my first computer. Haven't seen inside one of these in over 30 years. This computer taught me programming and electronics repair.
I really appreciate you posting this as it's an educational experience. Certainly the opposite of a "wasted" time. Thanks and am looking forward to the next one.
Nothing unrewarding about learning best practices of diagnostics (and I learned a bunch about 8-bit computers in general!).
Taking a break from a machine and clearing your mind is good. Sometimes I stayed with a computer or disk drive too long instead of setting it aside and coming back to it later.
There was something that was irritating me: The ROM that showed a flaky behavior at testing with the Retro Chip Tester was the 2316(b) - The replacement you built was showing as the 2364 TRS80 Model III in the testers display.
Are you shure, you used the right ROM for the last test?
You are correct. That irritated me as well.
Not only is it a 2316B, it's displayed at 23:16 in this video... with checksum 0x84A5702D, identified as file 8040316B.U106. The adapted ROM is displayed at 45:11, with checksum 0xEC0C6DAA identified as file 8041364.u104.
Hopefully Adrian reads this. Sounds like you caught a mistake that could make a significant difference in reviving this board.
This is a good catch and I don't know whether Adrian used a different image than the original when testing in the adaptor. But the original ROM is 2K and the adapter allows socketing an 8K ROM. Whether the 8K ROM was loaded with multiple copies of the 2K ROM, or just the first 2K and the rest filled with FF, the checksum will be different. I wonder if that's what's going on. Also, keep in mind there are three ROM sockets and I think he's testing more than one of them in the RCT pro, even though he's only replacing the boot ROM with the adapter.
Hopefully he sees this
Props to you for also sharing the failures. The diagnostic that you performed will no doubt be helpful should I tackle such a board myself someday.
a video like this is just as educational as one where everything works in the end.
so i hop you`ll keep posting the videos even if the machine doesnt end up working.
@32:12 I was yelling at the screen "It's right there on U70!" (VWR) but I guess you didn't hear me. Lol.
Great discussion of how to "secure" an open power supply. Again - it's not necessarily the details of how to fix a TR80 (because I'll probably never do that) - but the best practices. Thanks!
Welcome to my world :D It's exactly for these reasons I went down the logic analyser route many years ago. If you know ROMs are good and RAM is good you can hook up an analyser to watch what the CPU is pulling from the ROMs and see exactly at what point the boot process fails. This is assuming of course that you have the docs and disassembled ROMs available as you do with this board. I'm struggling with my Positron 9000 because the only source of schematics is me, but I have some great 6809 people helping me. You'll get there because you always do :)
I used to fake something like this with an oscilloscope. Trigger the 'scope from reset and you can see the first few cycles of machine operation. That allows you to look at the various control signals and data in context, rather than at some random time when the machine has already crashed. You can see everything this way, the CPU control signal outputs, the address decoding outputs to enable the ROM and then the ROM data. One advantage over a logic analyser is that ambiguous logic levels are clearly visible, but clearly both approaches have their uses.
Totally agree the logic analyser would be the way to go on this one. There is a good TRS-80 revival site which has disassembled roms, schematics and much more. A must have in order to troubleshoot effectively.
I used to own a Model I system, extensively modified. First, Tandy needed two revisions of the expansion interface (third try was successful) for it to work. I avoided all that by building up an LNW Research board. Took a *lot* of soldering (I think about 60 chips). It came up with no soldering problems.
Then I:
1. Overclocked the processor from 1.77 MHz to 2.01 MHz. Anything faster trashed the video.
2. Modded the character generator for lowercase with descenders.
3. Added a CP/M daughter board.
4. Changed to 80 TPI floppy drives.
People used to ask me what software I used. I told them, "Wordstar, SuperCalc, dBase II, and MTV." That was around 1980.
Newcomer, but I have noticed Adrian is a little sloppy with "floating". A TTL Logic Low is defined as less than 0.8 volts, but typically around 0.1 - 0.2 volts. A TTL Logic High is defined as more than 2.8 volts, but typically around 4.5 - 4.8 volts depending on the 5 volt PS rail. A floating input will read about half the rail (around 2.5 volts) and *generally* act as a Logic High.
You could just remove the Z80 CPU then wire up the address, data, and the RD,WR , MREQ, IORW signals using wires. Unlike some CPUs which have a phase signal that makes things complicated the Z80 signaling is very simple. Hold the IORW high, the MREQ low and pulse the RD to WR signals to read/write to memory. Reverse the IORQ and MREQ signals to write to IO ports to control things like the video modes. The other control signals can be ignored for this type of testing.
This would allow you to directly read and write to areas of the memory manually. While it would not work correctly for the dynamic RAM as the refresh would not be happening but you could write to the video memory and see the change reflected in the video. The would also enable you to check address decoding signals. It also lets you verify DC signal levels from the various buss drivers. This is the method I used back in the day with my Model I and Model 4 computers because I did not have any fancy test equipment. One the Model I there were 74LS367 chips that failed, on the Model 4 found a 74LS245 chip had failed. The model III is very similar in design to the Model 4 but the Model 4 had an 80 column video mode and could support up to 128K through bank switching.
If memory serves me the 74LS645 had a higher fan out than the 245 which may be important for driving the dynamic memory chips just because there are so many of them. The output from the decoder chips will show some garbage transitions because the address bus signals are transitioning and can only be relied to be valid during an active MREQ or IORQ. Also with the digital noise these boards generate and the less than great supply busses on the board, getting noise on the oscilloscope is just going to happen. You might also wants to check the power supply caps just to make sure your inconsistent behavior is not due to poor power quality. Another possible issue is the ROM chips are just not be fast enough due to age, they were pretty slow (450 ns) to start with which limited the speed of the CPU to 2 MHz without adding some circuitry to insert wait states. Replacing them with some EPROMS which are much faster could make a difference.
On my model 4 I build an accelerator board which allow running the CPU at 2 MHz or 4 MHz which worked fine with all the hardware except the ROMs which required injecting a wait signal during a read from the ROM. I only had a cassette for storage and reading and write data to tape was much faster and worked just fine running at 4 MHz as long as you used good tapes. I created a little program loaded from tape that would copy the ROM into shadow RAM, patched the ROM image to provide support for using 80 column mode and setup a key combination to switch CPU speeds.
This is quite interesting troubleshooting - its good to see how to go about this for those of us that don't know where to start.
Great job!! This is part and parcel of troubleshooting and you made a great video. NEVER SAY DIE!
I know you’ll get this one fixed, booted and running great again!
Be sure to let Stephen know you’re using the RCT II to troubleshoot. He would be thrilled to see it.
Those schematics are hell. Amazing they did it all by hand with metric tons of aliases and somehow put it all together on the board.
Great to see the details of the TRS-80 Model III in operation. I grew up with a Model I so know how it functions reasonably well. Interesting to see how it's sister computer works at such a low level. A nice change is the move to 74LS245 buffers...the Model I has much older chips which only buffer 6 lines which make the schematic much harder to follow.
What a wonderful video! Thanks for your great work, Adrian!
Honestly, I think you got this at least partially working at one point.
Others have pointed out the ROM issues, which I think are relevant, however I haven't seen anyone mention the piggybacking working at first.
Might be wrong, but something to check: what if both chips are good, but there's something on the other end of the line that's shorted somewhat strongly to the +5v rail, and a single chip isn't enough to drive through it, but two chips *is* enough, or maybe was. Seems like you honed right in on the right circuit, just not quite the right end, to me. Good luck with the rest of the repair
I would not call that stumbling on to it. You were troubleshooting based on what output you were seeing and the boot process took you to the place you needed to go. Good work. I wonder if it's a cold/cracked solder joint or even a cracked trace. When pressing on the board it made a better connection.
That occurred to me, too. I've had inconsistent motherboards that I had trouble finding the problem with, and discovered that had tiny cracked traces and/or cold solder joints that were causing the weird inconsistencies. Seems like a possibility, anyway. Inconsistent, 'flakey' behavior is the hardest to troubleshoot, in my experience.
I have repaired hundreds of Z80 devices, in industrial use and computers. The largest failing devices were the Z80A itself after almost exactly 5 years power on they would fail. We (the company I worked for), had great records of installation and failures for many thousands of Devices. The Zilog Z80A, very accurate to 5 years power on fail. Intel Z80A run forever at less than 4Mhz at exactly 4Mhz they fail at 5 years. The center port was a memory expansion if I remember correctly. Next failing thing was the 74(LS)367, look for half level signals. Next the memory ROM /EPROM, and memory 4116 etc. The difference between the LS245 and LS645 is in the output speed the 645 is about twice as fast.
Great video, great mystery, and nice cliffhanger.
I still remember the MIII well. In fact I can give you your diagnostic ROM off the top of my head.
F3 3E 55 32 00 3C C3 03 00
That will continuously write 55 ('U') to the upper left character position.
Just bumped into your channel by watching 8 bit Show and Tell and it was in the feed. Subbed!
lol dang it adrian, why are your videos so dang entertaining :) keep it up man. fixed or not, still a good video thanks for putting it out.
I really enjoyed this video! You may not have fixed it, yet... But I learned a lot about these Model III boards. Keep up the great work!
Intermittent fault with master faults as well.... about as frustrating as it gets. I'm thinking from the description when you piggybacked the chip and those issues, one thing that changed was you were placing pressure on the chip to piggyback it. Trace or soldering problems may change under physical pressure. (?) (I missed a couple
of minutes in the video so sorry if you covered that possibility.). There is nothing as boring as tryjng to do visual and or continuity inspections. But it was a fascinating video to watch - I owned a Model III for many years - takes me back!!!
This is very cool. I still have my first computer, a TRS-80 Model IV with all the extras in the basement. Years ago I damaged the CRT tube though so there no chance the on in the machine is ever going to work. One of these days I'd love to get the machine up and running again and a converter that can take in the video signals from the main board and put out HDMI would be a great solution for that.
BTW...the TRS-80 model I and III ran 32 or 64 character modes while the Model IV added an 80 column mode to better work with conventional terminal 80x24 displays.
I'm an EE by training and the next step I'd probably take with the board you're looking at would be to instrument the CPU data, address and control bus with a logic analyzer and set it to start capture on the inactive edge of reset. Capture the first few cycles and the CPU should be fetching from address 0, 1, 2 and the first byte read should be an absolute jump instruction I think (C3) followed by the destination address. If that seems to be working then move out and check the address decoding and some of the other stages in the system where early boot activity touches things. Using the known good machine as a reference might help too. Its first few fetches should match those that the broken machine should be making.
It has been a very long time since I messed with Z80 code but I still have quite a bit in my head. I spent my teen-age years disassembling the boot ROMs and TRS-DOS code by hand and learned a lot. These days I'm generally coding in C++ and C# on machines where the cache memory is vastly larger than the TRS-80s whole DRAM array but I have fond memories of those old machines.
It's a rewarding video imho, especially if you don't give up and come up with new strategies! Can't wait for the next video on this board! Thanks for sharing with us :)
Wasn't it the 2316B that was marginal in the Retro Chip Tester Pro? Also, the fact that the BCD is trying to drive ROM B and ROM C low but is failing to do so reeks of a bus conflict. I also feel like the fact that the two chips together when you piggybacked the first-time confirms that because two chips together are enough to sink the amount of current to resolve the conflict (just a hunch). I know you have replied to other comments saying all will be revealed in the next video, I am just providing my hunches.
Indeed, the address decoder at U60 (74LS145) appears to not be pulling to ground; these are open collector chips, hence the pull-up resistors on the outputs, and should be able to sync 80ma to ground, but if there is a short to 5V (internally or externally) it would certainly look like what's on the scope. It might also also cause VCC to fluctuate in sync with the select. Dual channel scope would be useful for that.
@@awebster that was kinda my thought, and when Adrian piggybacked the chip, it was able to sink the current long enough to clear the screen RAM, but didn’t resolve the conflict; so it still wouldn’t boot.
These videos are the best! More raw and unfiltered attempts - don't they say it's about the journey, not the destination! :)
My old friend, the trs-80 (model 3). I had 2 5.25 floppy drives, a tape drive (Radio Shack tape recorder) and my grandfather bought a 30 MB hard drive for it that cost as much as the computer itself. Good times.
Great video, “the more one fails the more one learns”
Really good video, I start it jumpers in the ribbon cables (is conected but if have some resistance con drop a signal). The worst first, then the rest.
Good Video Adrian,
Years ago when I used to teach a 6502 micro course, we had some very handy logic analyzers that we could hook to the Address and Data Bus.
We could then trigger off the reset vectors of the CPU and display the address and data that had been captured by the analyzer. The analyzer also had two BNC outputs to connect to a scope that allowed us to display all the lines against one another and scroll that display. If you had a copy of the Boot ROM disassembled and a logic analyzer you could confirm that the CPU is actually executing the ROM code correctly. I'm sure there are similar devices available today but I don't know what the cost would be or if the cost would be too limiting. I have seen inexpensive 8 bit logic capture devices for as little as $10-$15 and this machine only runs at 2MHz so it might not be prohibitively expensive.
The other issue would be to get a copy of the boot ROM code disassembled into Z80 code so you could follow the boot sequence.
I guess with a hex dump you could work that out or get a program to do that for you from the ROM dumps, given time.
You also could do with a memory map of the Model III if you don't already possess one.
I used to have a printed disassembled copy of the TRS80 Model 1 ROMS years ago when a group of us were into the TRS80 back in the 80's.
I would also check again around the address decoding for the video and ram. I wonder if you could single step a clock pulse and monitor the address and data lines with buffers and LEDs ?
The System RAM could be an issue tho because its dynamic RAM and not static.
Maybe even decode the Address and Data binary into HEX form to display on a 2 data and 4 address, 7 segment displays !
Good Luck.
Often, when I'm stumped like this, going back to first principles can help me find the overlooked piece I need to build a better hypothesis. Have you looked at power, ground, and clk (for those that use clk) and verified a probable-looking signal is present at each chip? If yes, press the chip and validate each signal again? Dull work for sure, but if the real problem is a flakey trace, this is about the only way to localize and then find it. Good luck!
Great video. Don't give up - you should have enough skill to fix this.
* Have a working TRS-80 on the bench and powered up - check for differences. Maybe even synchronize them.
* I'm not quite sure but that "working" chip select logic results looked a bit wierd. Are you sure replacement chip is good? Remove the CPU and try applying levels to see if it operates correctly.
* Those ribbon cables most definitely need to go - you don't know what they are doing at several MHz
* Do your favorite thing - deoxit those sockets! A pin can easily make unstable contact
* I think a working TRS-80 with all ROMs removed should display a non-random pattern. Try it out on a working computer.
* There are a couple of diagnostic ROMs floating around, probably there is one that does not require VRAM to work
* If everything fails, ask on TRS-80 related forums. They may be able to help.
I have a model I with very similar issues! Have replaced a good number of suspect ICs, but was eventually able to breadboard it to an EPROM and send a message to the screen with my own code. My next step is actually checking the ROM's CRC, but had to put down the project a few years ago. Working on one of these tends to humble you very quickly.
32:12 you scrolled past VWR two or three times :) I was saying out loud - “it’s right there!!!” :) thanks for the videos :)
This is good to follow, I'm looking forward to the next video. It will be interesting to see where the problem or problems are found
You checked for continuity on the small ribbon cable but, given it's corroded state it would be worth checking for leakage across the pins.
or just replace it with a normal ribbon cable, it seems DIP compatible to me
I was thinking exactly the same thing.
About that capacitor in the power supply - assuming the leads are long enough, it could be mounted off the board to get it away from that resistor. To keep it from flapping around in the breeze, silicone snot it (RTV or your basic silicone caulk) to the transformer.
This was great. I think you should keep going.
I use to repair all manner of coin-op equipment including: arcade games, juke boxes, vending equipment and even slot machines and quite often I would not have schematics on one off boards. A lot of intuition and guesswork got me through those as well as a few tricks (like brushing denatured alcohol on a running board to spot 'hot' chips and possible shorts). Many times I would have to leave it be a few days or even a week then come back with new interest and I will say that 99% of the time I ended up solving the issue (in our shop, I was the top tear tech so if I couldn't fix it, it got shelved and never fixed (or shipped out to a pro shop with all the schematics and fancy test equipment (while I used a 30 year old O-scope).
Oh, and my first computer was a TRS-80 model III level II 4k
Ahhh, even with a fresh approach & updated knowledge this board fault remains ever the mystery!
If those flat flex ribbon cables ever go bad for you, they are available in pretty much any length and pin count from a company called Nicomatic.
Do they make modern kapton based ones or are they same crappy old school paper and glue styled ones like the one shown?
@@SockyNoob I think the ribbon is polyester. I've had eyes on ones that were 20+ years old that looked identical to brand new ones (work experience).
The difference between the LS245 and LS645 is that the 645 has schmitt trigger inputs, so it will be better at handling noisy signal lines.
Great video - always enjoyable and interesting even when I don't understand all of it.
I've found the TRS-80 Model 1/3 to be some of the most complex to troubleshoot and repair. I spent 7 months to get a Model 1 up and running again. Fortunately I also rescued a Model 3 that had sat in someone's attic for 30 years and was a much easier repair than yours!
Yup. I do 8-bit and 16-bit machine repair, and the TRS-80s are always a treat. They have far more failure modes than other 8-bit machines, probably because they're built from an enormous pile of 74LS chips rather than having custom chips with well established failure modes. The net effect of their design is that you *really* need to study the schematics and the theory of operations manuals, because inevitably there's one 74LS chip *somewhere* that's doing something outside of specs, and sometime it can be really close to spec, but not quite there (for example when it heats up it suddenly exceeds the chip family's propagation delay specs). They can absolutely be a bear to debug because you can be *really* close to working and still have strange symptoms like Adrian's seeing here. (I would suggest however that he rule out the fact that the keyboard isn't connected and he isn't holding Break. I can't remember what happens when the keyboard isn't there, but I do seem to remember that you can get some weird behavior).
I love that shirt. I havent seen that logo since like 1994 when i had my apple 2c
I would suggest to go the logic analyser way, because of the inconsistent readings etc.. A way back we had an Atmel AVR CPU with external ram (with battery) and we have searched a half a day to figure out that we have missed the write impulse timing by a 20 ns! When we fixed that it worked flawlessly.
Anyway great video and failures are sometime part of the job... failures makes us to learn.
Don’t give up. I’d love to see you conquer this board! 🤓
I had similar issues with my OSI Challengers. Was always a bad transceiver or a broken foil trace.
Was fun watching and I learned quite a bit. Many thanks Adrian.
For those dying to see the outcome, Adrian just posted part 2 for patrons, so if you want to find out now, you know what to do. ;)
Hi Adrian...that was a great thumbnail. That image of despair made me want to watch it right away 🙂
Love your videos, Adrian, and I don't even mess with old computers. But the thing about putting one chip on top of another - I'm an EE as well and I can't figure out why that would work at all. It wasn't a fix, but I just didn't expect that putting a good chip on top of a bad chip would do anything useful... The bad chip could negatively affect the good one that way... But maybe you have a new technique there.
love the ROM detector!
Too bad this second attempt failed too, but there's still a ton of useful information in this video!! Many thanks.
I totally agree with your proposed fix of the heinous .1" flex cables with yellow wires (to use IBM slang).
If you get bad logic levels and the chip that outputs these turns out to be good and/or piggybacking makes it work, then there's likely a shorted input on one of the chips it tries to drive.
Happens a lot on overvolted boards, but this failure mode isn't unheard of on non-overvolted boards. I'm pretty sure yours wasn't overvolted.
Sometimes, if you try to just connect the power rail it's stuck at and connect the other power rail to the pin that isn't working, you can do the finger test, which chip gets warm.
(in your case it's stuck high, so you connect +5V, and connect GND *only* to the offending pin, wait a little and feel which of the connected chips are getting warm or hot)
(in my case - a badly overvolted board - , pins were stuck low, so I connect GND to the board and connect the +5V only to the offending pin and more often than not, at least one chip got hot even though it doesn't get power, so I replaced that chip and that got me a little further, then I look for more stuck bits, repeat process and eventually the board started to output video, eventually it would clear the screen and finally it started to boot)
Hi Adrian
Love your channels, always look forward to new videos.
Can we have more content like this? It's fascinating to follow your thought processes in fault finding these problems.
Seems a little perverse to enjoy your frustration though! 🤣
Looks like bus contention. The chip is trying to drive the bus low (and also it's replacement) and another thing on that line is trying to drive it high. Two chips piggyback driving it lower makes sense in this scenario. Just check the schematic on the line to see what other chips are able to drive this line active high. The Model III was the computer I used at university to do all my work coupled the the line printer VIII with a 1200pbs modem to the VAX/VMS system. Then I upgraded to the Commodore Amiga 500 and finally to PC. I went on to develop chips at Intel for most of my career and then decided to move to a non profit organization after 15 years to write software. The easiest way to deal with this scenario is to scope every digital chip and find the pattern of undefined logic levels and then consult the schematic.
If my memory serves me well, if you have a floppydisk controller connected the TRS80 (model 1 and 3) will NOT clear the screen as the screen is cleared by TRS-DOS (or another DOS like NEWDOS-80 or LDOS) so typically you would get a screen full of 64x16 characters for a few seconds before DOS took over, and without a working floppy you just ended up with a creen full of garbage. To get to BASIC when you had a floppy capable machine you had to push the break key down while powering up the TRS-80!
I expect that you don't do this now, so this result is exactly what I would expect.
Do I remember well that without a floppy controller, you booted directly in cassette mode?
Adrian, are you stalking me? This is the 3rd or 4th time I've come home with a new acquisition, gone online to find out more about it's innards, and you have a less than an hour old video on the same machine! Lol, keep up the great work!
I think it's very useful to show the troubleshooting process regardless of the outcome because this is the reality of the repair game... sometimes the fault just can't be found within a reasonable timeframe.
I reckon you'll crack it though... Cheers
I would try to jump the flex cables with dupont cables or simular. The continuity test doesnt tell you wether there is very high resistance it only tells you that there is none infinite resistance. It has bitten many a car mecanic.
Not quite. The continuity test will beep when it is low resistance. Different from DMM to DMM, maybe
@@Drew-Dastardly Yeah that was my point even if it was made in the wrong context. I would still test it with known good cables though.
We learn more from failure than success. I love this video!
On switch mode power supplies, you should be able to see a clear dividing line between the line side and low voltage side with only two parts spanning the division. One is an optoisolator and the other is the transformer.
Also, if memory serves me correctly, powering it on it tries to boot from disk, and if there's no disk, you get garbage, (like what you're seeing), to get it to boot to BASIC, you have to connect the keyboard, then hold the BREAK key and power on (or push reset). I think that's where your problem is.... also, looking forward to hopefully getting a chance to meet you at VCF Midwest. :)
an unrewarding video here and then is great, it makes you appreciate the rewarding ones even more.
It's very frustrating with intermittent faults but great video again keep up the good work. 👍
I was thinking that an In Circuit Emulator (ICE) might be helpful in situations like this. You could single step the ROM, see if it's executing code. If you have an annotated ROM decompilation you could probably get a hint about what is bad.
Alternatively a logic analyser with decoder for the CPU might be able to do something similar. Needs lots of channels and a decoder. Not sure if Sigrok has one, but I seem to recall someone made one for the 6502 and Z80 for people making their own computers.
VWR# is on U70 pin 12 at 32:19
I suggest you give the overheating cap in the psu a couple of layers of kapton tape to shield it a bit for a longer life.
What a crazy repair so far. It's not always so straightforward, esp. if it is one of those little logic chips.
Looking forward to the next installment. I think I haven't looked forward to a to be continued ADB since the Compaq Deskpro series. The TRS-80 Model II is right up there. I'm sure you saw the other posts about the ROM you tested late in the video not being the one that gave you issues with the tester.
I tried diagnosing a Model I many years ago and reached the same confused conclusion. :)
That 2nd ribbon cable is needed for the RS-232 board that piggybacked on the motherboard.
Can't wait for the your next try!
I feel your pain. I'm having similar issues on a soviet spectrum clone that i cant find an exact schematic for.
Nice Video, IC sockets are notorious. May be some socket is causing a loose contact.
I would try replacing all old sockets or try cleaning the same with WD40
Oh noes - missing the dopamine rush of a successful repair! I guess I'm addicted... 😅
But actually it's a great learning exercise to see what happens when troubleshooting keeps on bouncing off the hoop. Our skills are built by experience - the bad as well as the good.
FYI: ubiquitous IDE 40 pin ribbon cables work pretty well as a replacement for these always dead TRS-80 pieces, the ide ones are exactly twice as dense (10cpi instead of 5cpi), so you just need to cut off the ends off every other conductor.
At least on the model 3 there were pin headers, on the Model 1 the cables were hand soldered between the keyboard PCB and main board.
Hey, Beagle Brothers! I used look at their catalog/pamphlet and lust over it, for some reason.
Its so genuine to see the process not always result in a fix. This is good stuff. And your process was logical and correct as far as i can tell anyway.
My personal thoughts are; because of the inconsistency of results, maybe the 5v rail is slightly too low (borderline for older TTL). Maybe try a bench supply just for the 5v rail or a known good supply. also, is there any noise on the rail? any decoupling caps across it? Second, could be a PCB dry joint or crack. Maybe you were flexing the board.. Either way, its a time consuming tricky fix. Keep going! great vid.
A supply issue (decoupling / low 5v at 4.8v) is my instinct here too.
TTL specs for the 5 volt rail is 5.0±0.5 volts. A 4.8 volt supply is well with tolerance.
Hey Adrian! I really like your videos eventhough I don't have a clue what you're doing. :D
That "trying to come down" instead of completely coming down is an indication of a short or internal continuity. I would investigate that line, and try probing it with all chips that connect to it removed or swapped not just one. There can be some inconsistencies at power up if a line like that isn't logically high/low, getting cross talk, etc.