This Web page last updated Feb 02 2008.
This Web page has some accumulative notes and images about repair of old computers. 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
reading and replacing 2708 EPROMS with 2716 2732
![[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
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."
Allison talks more about her early Altair 8800 and the design issues she grappled with, in this section of my repairs page.
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. The "8800a" model came out after the original Altair as offered in 1974-75. The "8800b" models were a major re-design sometime later. Allison's reply is below. - Herb
Mine was early, I got a copy of the January 1975 PE [announcing the Altair] in the mail on the 13th of December 1974 as subscribers generally did then. As I'd been working in the industry with the 8008 and had read some stuff from Intel on the 8080, I was a fast leap on the bandwagon. First order was box, CPU, 4K, and PIO card ($1157 as memory serves). I would later add two more 4k memory [cards], ACR and MITS 4k basic and 8K basic.
To put that [price] in context my first truck cost $2500!!! My parents thought I was really off my rocker. My mother was agast, it's spend that kind of money? My father was surprized but curious: he felt there was a computer industry out there, beyond the white coat TV depictions, especially for USED computers. This was in 1974!
Because I was fast on the trigger I got mine in January and it was assembled in a weekend. Those that were even a few weeks slow would have delivery times sometimes measured in months. I was young/crazy then and projects like that meant working Friday and not sleeping till Monday say 2:00AM. That would give me around 50 hours of working time by time you factor meals and needs other than sleep. So I made time to solder it all up. Since I had gotten my engineering degree by carrying a bag as a land-mobile tech, [my] soldering was up to stuff and I had good temp controlled irons and even a desoldering station. Unlike other RF and audio projects it was a kit, populated [with parts to] solder and [needing] some limited mechanical assembly.
[But] by 1977 I'd retired it! I still have it but haven't powered it in years. The last time it was powered was 1979 after a lightining hit to the house. I used the front panel to troubleshoot the NS* Horizon system. During the repair effort I got a Netronics Explorer 8085 system and used that to check and test cards that was far better than toggle switches. That Netronics system still live and gets used as does the NS* Horizon.
The [later] 8800A was an improved machine all the way around.
Things the basic early 8800 needed fixing...
120VAC switching was brought to the front panel and was unprotected against contact by user. Most relocated that switch to the rear panel.
8080 Clock circuit. MITS found some one-shots behaved better than others. I found I hated one-shots and ripped them up and put in a 8224 in spring of '75.
Power [supply]. The stock transformer could not support the CPU, PIO and 12k of S4K dynamic ram. At that loading the rail was barely 8V and the ripple was below 7.4V. [Also the] rectifiers on PS card would melt at high current on the 8V bus.
If you extended the bus (it came in 4 slot segments) and wired them as directions said the interconnecting wires for the 8V bus would melt between the first and second card. If you fixed that the 8V bus trace would burn up with 4 8K static cards!
If the bus was extended to two or more 4 card slots bus ringing was a severe problem. The 4-slot cards were single sided etched! [No ground plane to reduce noise. - Herb] It was much worse if your front-panel interconnect was the specified length. Those leads remade as short as possible helped. At that point a WAMCO Quiet Mother (backplane) was assembled and installed.
Various mods to the S4K dynamic 4k rams were followed by a reduced cost kit for S4K owners of a 88MCD card sans rams. The 88MCD was a cleaner design but didn't work well with all Z80s (card dependent).
Cooling was always an issue, as the fan is in the middle of the rear and can either blow or suck air at the cards but the cards in the middle of the 80 or so slots had no place for air to go to (blow mode) or for air to come from (suck [air out of the case] mode) due to the card having one end abutting the front panel. Solution was bend a new cover with inlet slot two inches by 18 inches on top behind the point where the cover meets the front bezel. Didn't hurt to use a Rotron fan with 120CFM capability either!
FYI: my I/O then was via a PIO card to SWTP [TV Typewriter] (modded for 64x16) and keyboard later replaced with [Processor Technology] VDM1 64x16 video card.
When the system [reliability] wasn't "the project" du jour. I was working on getting off the d@** flaky ACR [cassette interface] and moving to a saturation recording system (Redactron cassette drive) FM (phase encoded) at a more palatable ~20kbaud. My goal at the time was a block replaceable directory based storage. I was also an early adoptor of the NS* MDS controller and a single drive as that represented the Ne pas ultra of the time (1977). Imagine 82k of storage and it was fast! It did however underline the flaky altair as needed retirement for something without painful switches and zillions of oneshots.
From Jan 1975 to late fall of 77 I spent banging my head against the wall with the early Altair. A while ago I got a complete 8800BT [turnkey] with floppy disks and every thing Altair even the desk with rack. It is designed better and still works as well as when the owner got it back in '79. However, the one thing they didn't fix was the lousy airflow. It has one very noisy fan working hard to get air across all (it's a full box) of the cards.
When I saw the first IMSAI I was greatly impressed as it solved so many of the Altair problems and was also easier on the eye and fingers!
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 © 2008 Herb Johnson
New Jersey, USA
follow this link to email @ me