This Web page last updated June 04 2008, addition Feb 27 2012.
This Web page has some accumulative notes and images about repair of old computers, up to about year 2008. I"ve done more work since then, and most of my "repair and restoration" Web pages are in another section of my Web site. I'll probably move this material there. - Herb Johnson Feb 2012
There are unique challenges to repairing digital electronics of the 1970's and 1980's. Many of those challenges are well-known problems for computers of the period. I'll try to illustrate them here.
For now, the linking page for this and similar documents will be my S-100 home page.
Index:
shorting capacitors
Cross Assembly, File Transfers to IMSAI
pulse generator as 8080 clock source
early Altair 8800 design issues which links to this Web page.
reading and replacing 2708 EPROMS with 2716 2732
Les Bird on Heath H-8 connector and disk recovery problems
![[burned circuit trace]](h89_trace.jpg)
I'm going to describe the consequences of a common problem with computers of the 1970's and 80': shorted tantalum capacitors which catch fire. Pictured on the left is a portion of a Heath/Zenith H89 computer board. I'll explain the image soon, but first let me describe what happened and what I did.
In March 2005 I decided to get an old H89 out of years of storage and into operation. After dusting and cleaning, I considered what I might do before powering up. A common problem on 1980's digital systems is that the tantalum capacitors - the little gumdrop-like device on the board which filter the various DC regulators - will short. The tantalum grows crystals which puncture and short the capacitor. When you apply power, all the current goes through the short. So the short typically ignites and smokes and burns. Some people find this a diagnostic method. They allow these caps to get "blowed up" and then find and replace the charred remains. There's problems with that method, as you'll see.
Other people, usually including me, will use an ohmmeter and capacitance meter to look for shorted caps and to verify their values. Sometimes you have to remove one "leg" of the cap from the circuit to test the device. Shorts measure zero to a few hundred ohms. Replacement caps must have the same capacitance, and equal or higher voltage rating. Values for these caps are a few microfarads to a few tens of microfarads: voltages from 16V to 50V, some small multiple of the actual DC voltage in use.
Note: tantalum capacitors are polarized, they have a "+" mark for connection to the positive side of the circuit. Also, tantalum caps can't be "reformed" or fixed by gradually applying DC voltage from zero. That's an old fix for electrolytic capacitors from vacuum tube equipment decades earlier - that does not apply to tantalums, and generally is not a problem for equipment "only" a few decades old.
This day, I got brave and decided to use the "blowed up" test. Sure enough, with the BRIEF application of A/C power, I saw a curl of smoke, and smelled the usual smell of burned circuit board or capacitor. I figured I'd remove the offending circuit board and find the bad component. Well....I removed the most likely of the two boards, given the source of the smoke, but I could not find the fried component! I DID find a shorted capacitor, uncharred and on the wrong part of the board, and replaced it. Since I could not find the smoking source on ONE board, I checked the other board, the H89 computer card. No shorted caps there...no fried components....
I needed more clues. So I reassembled the boards and powered up again, and KEPT power on. In due course, the CRT showed a cursor - a good sign for the terminal board. But there was no response on the keyboard. The simplest tests then are: does each regulator produce the correct voltage? MOst 1980's digital board have one or more on-board regulators, and the terminal and computer cards are no exception. Sure enough, one of the negative regulators on the computer card had no input or output voltage! But the DC power supply was producing reasonable outputs. That meant something was interrupting the unregulated DC; or the regulator was shorting it out. But the regulator, a T0-220 device, was COLD, so it was not shorted.
The next step is to trace the circuit back from the regulator. I pulled the card to do just that. Then I noticed the board area which is photographed on the left. See the three bright vertical bars? Those are three circuit board copper traces, covered with a insulating but translucent coating. The fourth, dark vertical bar is - or rather was - another copper trace, only it has pulled up off the board and is curled over to the left, from the top and from the bottom of the image. That is what caused the smoke. The short did NOT destroy a component, it conducted enough current to use the circuit trace as a fuse! I've seen this before, as these old digital power supplies produce AMPS of current which will fry even a strip of copper.
This is why it's preferable to test for shorts with an ohmmeter, instead of your power supply. Fortunately this trace is repairable, by soldering a length of wirewrap wire across the broken trace. If this were a multilayer card, with power traces inside the circuit board, I'd be obliged to bridge the gap between two junctions. I got lucky this time. Bu I still have to find the short that caused the "'splosion".
Herb Johnson
It's been suggested that when a tantalum cap shorts out, you can simply remove (the carcass) from the board and the circuit "will still work". While that may be true, it's not correct and it WILL cause some problems you won't easily detect. Here's some design reasons for tantalum and other capacitors. - Herb Johnson
Tantalum caps are there to provide DC power regulation, believe it or not. While they are small, in the tens of microfarads, that's enough to handle changes in DC "load" due to millisecond power demands. When that section of a digital circuit, or that board in a multi-board system, becomes "active", it draws power and that will dip the DC voltage if the cap is not there. When on a voltage regulator, they "isolate" the circuit at that point, from OTHER changes elsewhere in the system.
These larger caps WON'T filter microsecond noise, the power surges and induced currents from megahertz-switched logic circuits. That's why there are ALSO "bypass capacitors" in the .1 uFd range throughout digital circuits. At those speeds, every wire is a capacitor, an inductor AND a transformer. Digital wires are full of noise, digital chips generate noise. That's what the small bypass caps get rid of. The bigger tantalum caps have too much "impedance" at megahertz speeds to do that.
Any book in the last 40 years on digital design will describe this stuff. The reason 30-year-old computers work at all, is because their designers paid attention to this stuff. Conversely, designers in the era who did NOT pay attention to this stuff, produced boards that did not work WHEN SOLD.
As to why tantalum caps instead of other kinds? Tantalums are smaller than conventional "electrolytics". But they have the habit, over years or decades, of growing little metal crystals of pure tantalum. These puncture the insulators (dielectric) between the tantalum "plates", creating shorts. The shorts draw amps of current and the cap blows up. Electrolytics don't have this failure mode.
One of my customers, Denver Hull, is working on his IMSAI 8080 with SD Systems Versafloppy II and IMSAI SIO serial card. He describes below how he assembles code on a non-CP/M system and moves code to the IMSAI using a simple serial program to run the SIO card. The "remote" system is running Unix NetBSD; but the same applies to any Windows or Mac system which supports an 8080 emulator or cross-assembler and a simple telecom or file transfer program. - Herb JOhnson
"My Imsai has an original 8080 processor. I understand that that's probably only going to be fast enough for single density, but that's ok (I also have an old Multitech MIC-501, not S100!, with SSSD 5.25 disks). I do have a Cromemco ZPU 2/4 MHz processor card, but it behaves oddly when I plug it in, so that's another project for later."
"Essentially I'm bringing this up from scratch - I have no other S100 system available with disks. But I have CP/M on the MIC-501, and I'm running simh (altairz80 with CP/M) on my FreeBSD systems. I've written a short program that I can toggle into the Imsai. It transfers binary files through the RS232 port to any location in RAM. Works quite well with cu on a UNIX system. I even echo the lower byte of the destination address on the IMSAI front panel so I can see when it's done, and if it finished in the right place. I can probably do the same thing in the other direction, but haven't needed to, yet."
"[The serial connectors] are all pretty standard stuff. I didn't have to do anything special for that part - the SIO2 is jumpered with the default configuration from the manual. Currently, it's connected to an sgi O2, but it could just as easily go to a PC. I made the two internal cables. They're straight through, like it shows in the manual: 25 pin D on one end, 26 pin edge on the other, with 25 conductor ribbon cable between. Skip pin 26 at the [SIO2] edge connector....
Here's the code to do the RS-232 transfer:
E100 ORG 0E100H ; INITIALIZE THE SIO PORT E100 3EAA MVI A,0AAH ; DUMMY, SO WE CAN E102 D303 OUT 03 E104 3E40 MVI A,40H ; RESET IT E106 D303 OUT 03 E108 3ECE MVI A,0CEH E10A D303 OUT 03 E10C 3E37 MVI A,37H E10E D303 OUT 03 ; GET WHATEVER THE OTHER SYSTEM SENDS E110 110000 LXI D,0000H E113 DB03 LOOP: IN 03 E115 E602 ANI 02 E117 CA13E1 JZ LOOP E11A DB02 IN 02 E11C 12 STAX D E11D 13 INX D E11E 7B MOV A,E E11F 2F CMA E120 D3FF OUT 0FFH E122 C313E1 JMP LOOP E125 END
"It's a little bit long, but not too bad. You have to change the address at E110 to fit whatever you're loading, of course. Here's how it works:
1. First, you need to get the program you are working on into a plain binary format that isn't offset somehow. I use CP/M's ASM to produce an Intel hex file. Then I transfer that to a FreeBSD system and use objcopy: objcopy -I ihex -O binary infile.hex outfile.bin
2. Have the CP/M system (Imsai, in my case), connected to an appropriate RS232 port on a Unix system that has access to the binary file you just created.
3. Run cu on the Unix system, with appropriate parameters. In my case, I use: cu -lttyd2 -s9600
4. Toggle in the above code and start it running at e100.
5. In the cu window on the Unix system, type: ~$cat outfile.bin (you could probably use ~| to go the other direction).
6. The Programmed Output LEDs on the Imsai will blink until the transfer is done. They should end with the lower byte of the last address of your program plus one.
"The only real problem with this is with programs that are mostly located at the upper end of memory, but have a few things ORG'd at the lower end. What you end up with then is a large binary file, with lots of zeros in the middle , that will probably wipe out the loader. You could break something like that up into pieces to get around that problem. In fact, it would probably be easiest just to split up the .HEX file.
"I've found that using SIMH on the FreeBSD system to run CP/M to assemble programs works quite well. The Altair Z80 simulator and CP/M that comes with it contains two programs: "R.COM" and "W.COM" that make it extremely easy to move files between the host filesystem and the emulator's CP/M disk file(s). A typical edit/assemble/load process would go like this:"
1. Edit the file with your favorite Unix editor, vi perhaps, and save it. Make sure there's an embedded ^Z at the end. Save it wherever the emulator's disk files are.
2. I use unix2dos to add all the ^Ms to the ends of the lines. You may also need to do something to convert everything to upper case, depending on how forgiving your CP/M assembler is (in vi you can type: :g;[a-z];s;;\U&;g).
3. In the emulator's CP/M session, type: R PROGNAME.ASM. That copies it into the current CP/M disk. 4. Assemble it: ASM PROGNAME.AAA. Use appropriate drive letters for where you want the output files to go.
5. Transfer the .HEX file to the host filesystem: W PROGNAME.HEX.
6. Convert that to binary, using the host's objcopy: objcopy -I ihex -O binary PROGNAME.HEX PROGNAME.BIN
"Now you're ready to use my loader program and cu to squirt the code into the Imsai. You're probably wondering why not use the CP/M LOAD program? Well, LOAD isn't made for making a direct conversion from Intel Hex file to binary, so things don't come out quite right when you try to use it for this. At least that's what I found when I tried."
-- Denver Hull
[Note from Herb: CP/M's DDT will read a hex file and load binary in memory, which can be saved. One could write in 8080 assembler a hex to binary converter, or find such a program.]
Allison Parent regularly posts in comp.os.cpm about computers and software of the 1970's. In October 2006 in one of her posts she said: "For an experiment I once pulled the 2mhz [crystal from a MITS Altair 8800 CPU board] and ran off a pulse gen at rates as low as 10khz. It was very interesting then to see the 8080 marching along at dead slow." I asked her for details and she gave the account below. - Herb
"Actually the !@#$ crystal failed and I figured I can use the pulse generator to run it; it just happened to be set low initially. It was quite interesting to see the system cycle at the speed of molasses in winter".
"The pulse generator was an 8038 based signal source that would run up to 500khz as modified. If you want details it's the SWTP Function generator modified for greater range and a few other improvements. I actually used the square wave setting. It was coupled DC to the first input of the logic osc used as the crystal osc. The 8800(early not even A) used a series crystal with two 7404s biased as an osc, a poor circuit at best."
"This was done in the spring around March of 75. Age of the unit was not a factor. At the time I also tried a few crystals from 2.0 to 3.0mhz. It got flaky around 2.470 likely due to one-shot timing not scaled to clock."
"On a good day I'll conceeded that I learned a lot off that POS Altair. However time spent dealing with a flaky system was not time spent developing software or getting better at programming. I was thrilled when I got the NS* Horizon as once it was built I was replacing solder with assemblers and editors."
After Allison Parent's description of clocking the Altair 8800 with a pulse generator, I asked about her specific design issues with the Altair. She told me how early her Altair was, and then how she or MITS improved it. Follow this Web link to see her comments.
In a discussion of Northstar repair in comp.sys.nortstar, a poster referred to the following Web site:
This site discusses repair of an old Z80 CPU pinball board. But it's about how to replace a 2708 with a 2716 or 2732 (5V versions only). Also, how to program a 2708 using a 2716 programmer. I'd be very very careful about adding -5V and +12V to a programmer!
(If the link dies: For adding a 5V 2716 to a 2708 socket, bend pins 19 and 21 upwards, wire 19 to ground, 21 to +5V. For adding a 5V 2732 to a 2708 socket, bend pins 19 and 21 upwards, wire 19 and 21 to ground.)
(For READING a 2708 on a 2716 programmer: bend pins 19 and 21 upward. Solder wires on to pins 19, 21 and pin 12. Set the programmer to 2716. POWER DOWN THE PROGRAMMER. Insert the 2708. Apply -5V to pin 21, use pin 12 as the ground for those voltage supplies. THEN AND ONLY THEN power up the programmer. then apply +12V to pin 19, use pin 12 as the ground. Read the EPROM. Then remove +12V, THEN AND ONLY THEN power down the programmer, then remove -5V. FOLLOW THIS ORDER AS DESCRIBED. )
Herb Johnson
Copyright © 2012 Herb Johnson
New Jersey, USA
follow this link to email @ me