Refurb weekend(s): Commodore/MOS KIM-1

Actually, it was more like a whole stinking Refurb Two Months. The KIM-1 is one of the earliest MOS 6502 computers, a single-board system with 1K of RAM (actually 1152 bytes total) and a one-megahertz CPU developed by Chuck Peddle in 1975 as a way to introduce engineers to the new 8-bit microprocessor. However, its low cost meant it ended up taking on a life of its own as it was one of the cheapest ways to assemble an entire working hobbyist system, and Commodore continued to sell them for several years after they bought MOS. You could hand-key in programs with the hexadecimal keypad and the six LEDs as a display or wire up a TTY. It also supported saving and loading from cassette and paper tape, all built-in to the standard ROMs.

I have a couple KIM-1s and they are the oldest machines in my personal collection, including a Revision A pre-Commodore MOS unit with ceramic processor and RRIOTs, but the one that's the most special to me is the briefcase Revision D system you've seen here in other entries. The Revision D is notable historically as the first Commodore-branded KIM after their 1976 buyout, but it's important to me because this unit was my first KIM, and the one we got in high school from our high school math teacher and learned to program it over the weekend (we'd grown up with the Commodore 64, so we already knew all the machine language opcodes). It conveniently sits in a briefcase with a power supply and has one of Bob Applegate (RIP)'s I/O boards to provide the RS-232 connection.

While working on our most recent KIM-1 project, I noticed that the RAM from $0280 to $02bf wasn't working right. The serial uploads from KIMup would succeed, but the data it stored in that range was wrong, and when I checked with the monitor it would only store values 0-3. I got around the problem by assembling the code to a different address, but on a system with a single kilobyte of memory, you can't ignore a whole 32-byte failure. It was time for a Refurb Weekend.

The KIM-1 is a very simple single-board computer and MOS/Commodore included full schematics, making it very feasible to completely understand and repair. For memory, each 6102 static RAM chip at U5 through U12 stores one kilobit (1K times one bit), so with eight, you have one kilobyte. (The extra 128 bytes come from 64 bytes each in the 6530 RRIOT RAM-ROM-IO-Timer chips, which are at a higher address separate from the main RAM.) Chip select, read-write, address lines from the CPU and power/ground pass through all eight chips in parallel. Four of the chips send their input and output to one 74125 quad bus buffer (U13) and the other four to the other (U14), which are what actually connect with the data lines.

The 6102 was a MOS Technology-specific version of the 2102 SRAM and was dispensed with early in the KIM's lifetime; my Rev A has Synertek 2102s, which are also one-kilobit static RAM chips, and all my later KIMs have third-party 2102s as well, mostly NEC.

To have a 32-byte range fail wouldn't seem a typical way for a RAM chip to die, but it was pointed out to me that given all RAM chips organize their bits into a matrix of rows, the most likely array size for a 1Kbit chip is 32 by 32 (to equal 1024). A single blown internal driver or sense-amp could cause a single row of 32 bits (spread across 32 bytes) to drop out but the remainder of the chip to still function.

Because the KIM's monitor enters data from the keypad by shifting bits left, a bit stuck to zero could cause every bit after it to be also zero, even if the other chips were functional. Since we still had other places to assemble code, I dashed off a quick assembly language subroutine to compare and step through every possible eight bit value as I pressed a key on the keypad.

*=$0000
r=$0280

        inc w
        lda w
        sta $f9
        sta r
        sta r+1
        lda r
        sta $fb
        lda r+1
        sta $fa

        jsr $1f1f
        jsr $1f6a
        cmp #$12
        bne *-8

        jsr $1f1f
        jsr $1f6a
        cmp #$15
        bne *-5

        jmp $0000

w       .byt 0

The upper nybble was unaffected, but the lower nybble went through this pattern:

0 1 2 3 4 5 6 7 8 9 a b c d e f
0 1 2 3 0 1 2 3 8 9 a b 8 9 a b

This indicates that bit 2 (which would be a value of 4) was bad. On our schematic, DB2 comes off the RAM chip at U10.

Before possibly making a hash of a historical artifact, however, we should find a reversible test to confirm the failure. RAM chips can often be piggybacked for verification, so our first step is to piggyback a replacement SRAM on the likely bad one. This sometimes works and sometimes doesn't, but it wouldn't work at all if it weren't the problem, and in this case we were able to get a clean byte stored after a couple attempts. At minimum we'll be replacing that one and then we'd see.

Obnoxiously none of the chips are socketed and that demands more drastic means of removal. (This is typical, but not necessarily universal, for KIMs: my Rev G, the last known KIM-1 revision, has a socketed 6530-003 RRIOT dated 17th week 1980, though I can't determine if this was a third-party or factory repair.) First step was to snip the legs off with diagonal cutting pliers. Note that the pliers scraped a trace, but before repairing that we need to get out those legs and clean the holes. Here I heated the solder points on the back and pulled out each of the legs with a mosquito clamp.

With them removed, the only other damage was a lifted trace on the back.

After reworking the scuffed trace on the front with a silver pen, I soldered in a socket and reattached the lifted back trace. With the socket in place I buzzed out the nearby pins with the continuity tester and seemed to get a good set of readings. I then installed a spare 2102 RAM in the socket and turned the KIM on, and it went crazy. I put in a different 2102 in case I got a second defective one, and the KIM was still going crazy.

I went over my work again and found two address lines that did not have continuity. I reworked those lines, got a healthy beep from the continuity tester and turned the KIM back on, and this time it was just plain unresponsive. It wouldn't light any LEDs or do anything else.

At this point I was worried I had wrecked the board or somehow caused damage to the other RAM, or buffers, or all of the above, or there were other issues that just chose to fail now. Unfortunately with an apparently dead KIM that I happened to be very fond of I really didn't want to be shooting in the dark here. Fortunately, Dwight Elvey had developed a debug board harness kit for the KIM some years ago. Although are plans to build your own diagnostic board off Dwight's design, after a couple weeks I was serendipitously able to locate one of Dwight's original kits (thanks Gary!).

Assembling the board. Some assembly required.

Most of the business end is this card which connects to the top expansion connector (a harness with power and address lines connects to the bottom application connector and through the three lines at the bottom). The setup is pretty simple, just some indicator LEDs and discrete logic, and a ROM with multiple tests which is run by the KIM's own 6502. The red indicator LED lights when there is bus traffic; the green LED blinks (or doesn't) in a particular way varying on the specific test set with the DIP switches, which also may use the LEDs on the board for messages.

I was paranoid I'd botched building this too, and repeatedly tested my work, but found no shorts and no breaks, and the harness "just worked." I connected it to my Rev F and G KIMs and got a clean bill of health for both boards on the first try, so I pulled it off and readied it for this one.

The KIM-1 can decode a 4K range with the logic it already has onboard ("internal decoding" or "DECEN" on the schematic), which is why 4K expansions were quite common. Internal decoding is enabled by jumpering pins 1 and K (i.e., ground pin K) on the bottom application connector. However, the debug board contains a 16K EPROM, so it has to provide its own decoding (when the "DB" switch on the DIP switch pack is switched on).

On this KIM, the previous owner actually wired the power supply directly to the board instead of to connectors to the card edge, and also wired the internal decoder line between solder points instead of the card edge pins. This is another reason I like this KIM because that setup is nice and clean and lets you connect cards without the power lines getting in the way, but required me to desolder the K-1 jumper on the underside temporarily to allow the debug board to function.

The harness, all connected to our sick Rev D and ready for analysis.

The first test on the debug board is a simple "dead board test." With the DIP switches all on, the red LED showed the 6502 was accessing the bus, and it was able to load the first and simplest program from the debug ROM to slowly blink the green LED. This tells us the CPU works, the data lines work, and at least some of the addressing. It uses no RAM or anything else.

The second test is a RAM test, without which the other tests can't run. The code is designed to work using only the registers of the 6502 (given that the 6502 only has three main registers, each with only somewhat overlapping functionality, this is no mean feat) and will blink the green LED in a pattern of long (good) or short (bad) for each of the eight bits. It didn't do anything.

I asked Dwight about this and he suggested the address lines were the most likely culprit. That also most likely meant there was still something wrong with my socket work, since most of the socket is addressing lines. I went over all the pins again and still couldn't find any continuity losses or nearby shorts.

Going as crazy as the KIM, I next started buzzing out every single pin on the socket combined with every other one. At last a new fault emerged: pins 1 and 15 were shorted.

The address lines run very close together on the back of the board. The arrow is pointing to pin 15, which ever so slightly is overlapping the trace to the left of it. Walk that trace back and you get pin 1. In my defense I don't think anyone would have spotted it with a cursory glance.

I got out the solder sucker and braid and pulled some extra off, but that didn't fix it. Eventually I was reduced to getting out a pick and scraping every bit of the solder away from the trace, just not so far as to actually dig into it. After a few painstaking cycles of scrape and test, finally no more short was detected, and the RAM test passed!

After that, it was easy: the LED, keyboard, RRIOT ROM checkums and RRIOT RAM tests all passed, terminating in the lovely word "Good" showing up on the LEDs. After reattaching the K-1 jumper, the suitcase KIM was back in operation and now functions normally.

In the end there were no other failures except me, but fortunately not only is the KIM a very simple system, it turns out it's a very forgiving one too. The moral of this story is: after a repair, check your work, and then check it again. And maybe a few more times after that.