Retirement Project - Fixing up the SWTPc 6809

Given that it is 50 years old, the SWTPc 6800 Computer System which I call my retirement project has been in need of some "fixes". 

Having made the BBUG ROM monitor changes to allow for extended address decoding, it was time to do some surgery on the motherboard. Might as well make some fixes.

Post close-up

Posts

The original SWTPc kit held the motherboard in place with seven plastic clips along the edge. They were designed to be pushed down from the top and clip in to the chassis bottom. A plastic arrow held the motherboard in place and could be easily unclipped. In theory.

The sad reality is the clips never engaged correctly with the chassis bottom, and often one whole end of the motherboard would be loose in the box.

Seven posts

Around 1979, just before heading to the ISEF, I replaced these clips with #6 screws, lock washers and multiple nuts. Four nuts supply the spacing, with a fifth nut holding the motherboard in place. The #6 screws are a tight fit through the holes in the motherboard, but everything is aligned. 

I took some pictures of these beauties in case someone needs to replicate them.

Feet

Chassis bottom with new feet,
and the adhesive of the original.

The original SWTPc 6800 Computer System kit supplied rubberized stick-on feet. Honestly, they held up pretty well nearly 50 years. Along the way, one of them had fallen off and gotten lost, and the replacement foot wasn't quite tall enough. I replaced them with rubber feet held in place with a #6 screw.

This meant drilling some additional holes in the pan of the chassis. Not a big deal, nor was the placement critical. One foot borrowed the #6 screw holding the clamp for the power cord. The other three used new hardware.

I eyeballed the placement of the other three screws, and the results were acceptable -- certainly compared to the old stick-on feet.

LM7805 Bypass Caps

Input and output 0.1 uF caps
lap-soldered across LM7805.

Because the SWTPc uses an unregulated 8 volt supply, every board has one or more LM7805 +5 volt regulators. Examining my bit rate generator board, I wondered the regulator was properly bypassed. I remembered an issue in a different project where an LM78xx regulator oscillated because it wasn't bypassed correctly. 

A search of the data sheet provided a concise answer:

• All LM7805 regulators should have 0.1 uF ceramics across the input and output.
• LM7805 regulators that supply 50 mA (or more) current should have 10 uF per 100 mA on the output.

These were simple rules to follow. A quick survey of the SWTPc schematics made it clear that the designers had never heard of the first rule. There were no input bypass caps at all. Output electrolytic bypass caps were present on those drawing more current, with an occasional 0.1 uF cap. The Tanner and Gimix boards were more heavily bypassed. My home-brew boards were no better than the SWTPc designs.

This problem was easy to solve. I have a bunch of 0.1 uF multi-layer ceramic caps. I added them to the boards:

• 0.1 uF on input of bit rate generators card
• 0.1 uF on input and output of MP-S cards
• 0.1 uF on input and output of MP-C (modified to MP-S) card
• 0.1 uF on input and output of MP-LA card
• 0.1 uF on input of MC68B09 V2 CPU card
• 0.1 uF on input of MP-B motherboard

For the MP-S, MP-C and MP-LA cards,  I lap-soldered the caps on the back-hand side of the board, rather than drill holes. Easily done in a few minutes.

I added some small-value electrolytic caps to the output of some LM7805's. Generally, boards that include these caps have a 100 uF unit, which is good enough for 1 A of current -- overkill for some boards.

• 22 uF on output of bit rate generator card (more than necessary, 15 uF would be enough)
• 10 uF on output of MP-B motherboard 

It could be that none of these bypass caps are required, but seems like they can't hurt.

Extended Decoder

Dec 1986 decoder circuit

December 1986, I added an extended address decoding circuit to the motherboard. The decoding avoided aliasing of the xExxx pages that prevented access to RAM or other devices. With the MC6809E V1 CPU card, this worked fine with BBUG, but the OS/9 ROMs had a different idea on how to program the DAT, so it didn't work with OS/9. I disabled the decoder and didn't figure out the problem until much later.

When I switched to the MC68B09 V2 CPU card the problem had reversed -- the decoder would work with OS/9, but not with BBUG. 

With BBUG updated to initialize the DAT in a compatible way, I could fix the decoder. The picture shows  the original decoder was a hastily improvised circuit using a 74LS21 4-input AND gate to detect all "1" values on S0-S3, connected to IC6 Pin 6 (Enable).

I sketched out some changes to decode several address lines, but I either never made those changes, or I removed them. The key to the MP-B motherboard is IC6 - a 74LS138 3 to 8 decoder. These other address changes messed with IC3 -- a different 74LS138. The MP-B I/O port data buffers are activated from IC6, so additional decoding against IC3 was an incorrect solution, as the data bus was active, even if no I/O slot was selected.

The new decoder board had simple requirements:

• Disable Extended decode entirely
• I/O accessible from FE000-FE07F (and FF780-FF7FF)
• I/O accessible only from FF780-FF7FF

The I/O ports are aliased over a 2KB block -- each 16 byte I/O slot appears 128 times. This meant decoding S0-S3, A15-A12, A11, A6-A4. A15-A13 is handled by IC6, A6-A4 by IC3. A3-A0 is done by each I/O card. A10-A7 are not decoded. The decoder circuit just deals with S0-S3, A12 and A11.

Decoder showing jumpers

Decoder operation is jumper-selectable. This allows me to test each change and back out changes if something didn't work. The first jumper selects between the FFxxx I/O address or the FExxx / FFxxx aliased I/O address. The second jumper enables/disables extended decoding entirely. 

The 74LS21 has the first AND gate connected across S0-S3. The second gate is wired as a two-input AND that uses the output of the first AND gate and jumper-selectable A12 or a pull-up. The output of the second AND goes another jumper selecting IC6 pin 6 (Enable) to the output of the AND or a pull-up. A11 goes to IC6 pin 4 (Enable*) to ensure the I/O data bus buffers activate only on the lower 2 KB of the 4 KB memory page.

Clean mount of decoder

Circuit uses a bit of perf board and a 3M Scotchflex socket I've used for other projects. Surprisingly, I did not have a 74LS21 in my junk box. I salvaged the soldered unit I had hastily assembled in 1986. That worked out. The board is cleanly mounted on a spacer to the motherboard and all of the connections are made with wire-wrap wire.

Testing

Testing, much to my surprise, went perfectly. The disable jumper worked as before. Enabling the aliased extended decoding allowed me to use the xE pages of memory, and a special burn of the BBUG ROM allowed me to test I/O at FF780-FF7FF. This worked as expected. I could enable and use the FExxx block of RAM on the MC68B09 V2 CPU board and access it using the DAT,

Not sure why I was afraid of all these "fixes". I suppose I was shy about changing the motherboard in a way that might break the computer entirely.

Forty Years of Personal Computing - 16/32-bit Dreams

Back in the days when we were fooling with 8-bit computers, we dreamed about 16 or 32-bit processors. Digging through my notes and records, I found a couple of items. These projects were contemplated, but never built. 

MC68008

When Motorola introduced the MC68008 in 1982, I toyed with the idea of putting one on the SS-50 bus. In my notes, I mapped out the signals required. It might have worked, but it was an awkward fit. The MC6800/MC8609 had synchronous memory access, but the MC68008 was asynchronous. Plus, the MC68000 family really wanted a 16-bit bus.

While I never built anything -- it was more of a thought experiment -- it might have been one of the first applications of a 32-bit processor running on a bus designed solely for an 8-bit processor.

A couple of years later, I spent a lot of time programming the 68000 processor when I started doing Mac development in August of 1984.

NS16032 / NS32016

NS32016 chip set samples, plus a couple
of Dynamic RAM and Refresh Controllers

National Semiconductor (NS) got left behind in the microprocessor chip races even though they were an early entrant. In 1974, they produced a single-chip processor known as the PACE -- a 16-bit design inspired by the DataGeneral Nova. This early pMOS implementation required three power supply voltages, and the bus requirements made designs complex.

By 1976, NS introduced an 8-bit processor, the SC/MP. Compared to the Intel 8080 or the Motorola 6800, it was underpowered. While it may have been a good choice as a micro-controller, the second-generation designs such as the MC6811, MC6805, Intel 8051 and Z-8 choked the SC/MP out of that space.

In 1982, National Semiconductor introduced the NS16032 -- later re-branded as the NS32016. NS32xxx refers to the 32-bit nature of the processor, and the trailing 16 refers to the bus width. It was clearly a competitor to the Motorola 68000, which was introduced in 1979. The NS32016 family was actually a collection of five devices:

• NS32016 CPU - Central Processing Unit
• NS32081 FPU - Floating Point Unit
• NS32082 MMU - Memory Management Unit
• NS32202 ICU - Interrupt Control Unit
• NS32201 TCU - Timing Control Unit

Together, they form the processing core. Depending on the type of system, you might not need much more than the CPU and TCU, provided you didn't need floating point, memory management, or prioritized interrupts. This made for an extensible system based on a common processor core

National Semiconductor also offered a Direct Memory Access Controller -- the NS32203.

Clock speeds of 6, 8 and 10 MHz don't seem fast by today's standards, but where competitive back in 1982. This chip needed a minimum of four clock cycles to access memory -- the same as the Motorola 68000.

Architecture

National Semiconductor devoted a lot of their design work to producing a Complex Instruction Set Computer (CISC) specifically to support high-level languages. The NS32016 has a rich set of addressing modes including direct register, register relative (including the Frame Pointer, Stack Pointer or Static Base registers to which an additional displacement may be added), immediate, absolute, external (using a link table entry). Indexing by a register allowed easy access to local and global variables of high level languages. 

The NS32xxx architecture sported eight registers, a program counter, two stack registers (user and supervisor), a frame pointer and a static base register. The design specified module and interrupt tables in memory. 

Design Ideas

In late 1983, The NS32016 process inspired me to write a 20-odd page article about a "personal minicomputer" -- since I considered this design to be more of minicomputer power level that a microcomputer. It certainly was a lot more powerful than the 8-bit microcomputers of the day.

Sometime in 1984, I obtained a couple of engineering samples of this chip set. From this, I started creating hardware designs. Drawing out the basic core from the five chip set was easy. But a real computer needs memory and peripherals.

At some point, I obtained a second-hand S-100 chassis -- a BYT-8 system. Just a motherboard, power supply and front panel. The S-100 bus had a lot of interconnections and could serve as the backbone of an NS32xxx system, but it wouldn't use the same signals. I ended up scrapping the front panel and painting the cabinet flat black.

For memory, I decided to make use of other members of National's line up:

• DP8419 - Dynamic RAM Controller
• DP84300 - Programmable Refresh timer
• DP84412 - Dynamic RAM Interface

These chips made it very easy to construct a memory array with dynamic memory chips. The designs involved 64K bit dynamic memory totaling 256 to 512 KB. It all depended what I could fit on an S-100 board.

The presence of a memory management controller made virtual memory a possibility. The rest was a small matter of software. In my initial designs, I planned to use the Pertec 8" floppies for virtual memory. Perhaps slow, but possible. In mid-1985, I mapped out the Pertec FD400 internal interface boards as part of this effort.

Other than a bunch of schematics and a painted chassis, I never built anything. A good thought experiment, perhaps. Even with working hardware, the operating system software would have taken years to get going.

And the NS32xxx series wasn't without problems. Part of the reason this chip set never caught up is it was full of defects. National went through several iterations over years to resolve the defects, missing their window to catch the MC68000 family or the Intel 8086 family.

Forty Years of Personal Computing - Gimix 256 KB Static RAM

256 KB Gimix Static RAM board, sans battery.

In 1991, my employer moved to a new building. Before the move, we cleaned out storage closets containing old equipment. Much of this was obsolete gear. Things like pairs of "twiggy" disk drives removed from early Apple Lisa systems upgraded to 3 1/2" disks in 1985.

In one closet, we discovered something unusual. It was a complete Gimix III "Ghost" system. This was a  2 MHz 6809 system sporting a fifteen-slot SS-50 motherboard and eight SS-30 slots and floppy disks: a top-of-the-line 6809 system from the early 1980s. 

By 1991, the company had no use for this equipment. I had the impulse to take the entire system home, but I didn't have room. My wife and I were living in a small house and the garage was already packed. She would not have been happy if I brought home a bunch of equipment. 

Instead, I salvaged exactly one board -- a Gimix 256K CMOS Static RAM board. It sported 256 KB of memory, with several options, including battery backup. The rest was scrapped by an electronics recycler. 

Obtaining the board, I tried it out in my system. I was able to map in 4 KB blocks of memory and test them. They all worked. I might use the additional memory as part of a virtual disk drive. 

In 1994, I moved, and the entire system was stored away for over 25 years. Looking at it recently, I found it needed repair. Over the years, the backup battery failed and leaked electrolyte on the board and motherboard. Several Molex connectors are damaged, and need to be replaced. Some of the components show signs of corrosion from the battery electrolyte. 

I removed the failed battery. I do hope the rest of the board still works once the repairs are complete. Perhaps I'll fix it in my retirement.

Forty Years of Personal Computing - MC6809 V2

MC6809 CPU card, version 2.

By March 1988, the MC6809E V1 card I designed in 1983 needed updates. I built an entirely new card with new features intended to run OS-9 more effectively. 

CPU

A MC6809 chip simplified things with the on-chip clock oscillator. The chip handled M.RDY without extra logic, and the rising edge of the Q clock did not need delay.

Memory

The MC6809E V1 card had no on-board RAM. There wasn't room. By 1988, a number of manufacturers had 32 KB static RAMs in 28-pin packages. 64 KB of memory is realized with a couple of chips. 

For the V2 board, I allowed for eight chips, totaling 256 KB of memory. This was a good compromise between cost and the space available. The memory is logically separate from the rest of the card -- decoding from the physical address and data bus, using appropriate buffers. In this way, the memory can be accessed by a bus master other than the CPU. It responds to physical addresses C0000-FDFFF or FEFFF, jumper selectable. For years, it held two chips -- 64 KB on the board -- with only 56 KB accessible. The six remaining chips were added recently, making 248 KB or 252 KB accessible. 

Buffering

20-pin bus driver chips reduced the chip count, even with two sets of bus drivers, one for the CPU, and one for the memory array.

Program ROM

The design allows for a much larger ROM. The MC6809E V1 card originally had two 2KB 2716-compatible sockets -- one for a ROM and another for ROM or RAM. To make swapping OS-9 and BBUG easier, I changed this to a single 4 KB 2732-compatible ROM socket

For the MC6809 V2 board, the ROM can be a 27128 or 27256-compatible device, holding 16 KB or 32 KB, respectively. The larger ROM permitted more OS-9 modules to reside there, if desired. 

As built, a 27256-compatible EPROM is used, containing a BBUG image in the top 4 KB of the lower 16 KB and the OS-9 ROM image in the upper 4 KB of upper 16 KB half. A jumper selects which half is active. This is much easier than swapping chips to go between BBUG and OS-9.

Accessing the correct amount of the ROM requires clever decoding. 

Decoder

A hard-wired decoder would limit the flexibility of the system, and it would be complex and difficult to change. Rather than discrete logic, the decoder consists of a Cypress Semiconductor CY7C291 2Kx8 EPROM. This is a fast device with a 70ns access time. The CPU address lines A5 to A15 are connected directly to A0 to A10 on the chip. The decoder is enabled with the logical OR of E and Q, which asserts during three quarters of the memory cycle. This way, the eight data output pins can be used as decoder selects programmable on every 32-byte segment of memory.

Three select lines are used: one for bus access (including the on-board memory array), one for the program ROM, and one for the DAT. Each select line is pulled up to +5v. Placing a 0 bit in the decoder ROM data array makes the select line active for that 32-byte memory segment. 

Modifying the memory map becomes a simple matter of programming the decoder ROM. I programmed the following logical memory map:

• 0000-EFFF - Bus
• F000-F77F - Program ROM
• F780-F7FF - Bus
• F800-FFFF - Program ROM
• FFE0-FFFF - DAT (writes only)

This configuration is compatible with the existing ROMs for BBUG and OS-9, which require I/O at E000-E07F. It has 4KB of program ROM, except for the hole at F780-F7FF. This hole deserves a bit of explanation. 

I/O Port Address Migration

BBUG occupies the top 2 KB of ROM. The OS-9 ROMs take up nearly 4KB. However OS9p2 doesn't use the last 128 bytes of that space. This unused space became an alternate location for the I/O ports. If the I/O ports moved from E000-E07F to F780-F7FF, the MC6809 could use RAM in the logical E block (E000-EFFF), for a total of 60 KB of RAM, up from 56 KB. 

Moving the I/O address requires motherboard decoder changes and software changes to the BBUG and OS-9 ROMs, as well as revision to Flex09 and OS-9 I/O configurations. The V2 board decoder ROM would work with the existing motherboard, or with the motherboard and ROMs altered for the new I/O addresses.

Larger ROM

Once the I/O addresses are moved, the decoder can be reprogrammed to allow for more ROM space. This opens the option of moving OS-9 modules into ROM. The decoder allows the lower limit of the ROM to be changed in 32-byte increments. This allows an OS-9 system to be entirely in ROM. OS-9 would start from the reset button without requiring a boot disk.

DAT

Back side of MC6809 V2 card.

The DAT configuration is similar to the MC6809E V1 board, with one important difference. In the SWTPc MP-09 board, as well as my V1 board, the outputs of the DAT are inverted on the lower four bits (A12-A15), but non-inverted on the higher four bits (S0-S3). 

This means that values programmed into the DAT must be one's complemented on the lower four bits (A12-A15), with the higher four bits (S0-S3) not complemented. 

For the V2 board, all eight bits of the DAT are inverted on the bus. Thus, the value programmed into the DAT is the one's compliment of the highest eight physical address bits (A12-A15, S0-S3). 

Which makes programming correct DAT values simpler, since the entire byte is complemented.

I introduced a hardware bug in the DAT decoder. More on this later.

Building

Rather than wirewrap, I opted to try something new. A technician from work gave me a couple of 3M Scotchflex Breadboarding kits. This breadboarding system was brilliant. Chip sockets connected to IDC pins. Wiring is accomplished by forcing wire-wrap wire between the IDC pins with a special tool. 

It is way  easier than wire-wrap, because there's no tedious cutting, stripping, threading and winding of wire. One lays the wire down and pushes it on to the pins. Wiring several connections in succession, such as with a bus, is a breeze. The results also look great. The IDC pins are low profile, so there's less chance of shorting a connection than with wire-wrap.

It's sad 3M discontinued this product. It was great. 3M has since re-used the Scotchflex brand on three other products.

Fixing the Bug

The MC6809 V2 board worked great. There were no wiring errors. I did find a problem with the DAT.

In the default BBUG and OS-9 configuration, the DAT is written once during reset and never touched. And that seemed to work just fine.

Then I started playing with an OS-9 driver called VDisk. It created a virtual disk from selected extended memory blocks. At the time, I had 56 KB of memory from the MC6809 V2 card, plus another 60 KB from the Digital Research Computers / Tanner card. That made possible a 60 KB virtual disk.

Every time I tried to access the virtual disk, the computer would crash. This took a while to track down. 

I eventually realized the new decoder did not take into account the clock cycle when accessing the DAT. Transients on the R/W* line early in the clock cycle could cause bad data to be written to the DAT. After I added the missing gate, the VDisk driver worked perfectly. 

Usage

Like the MC6809E V1 board, this V2 board was exactly how I wanted it. There are only two jumpers. 

The jumper at the top edge of the board selects the 4 KB portion of the EPROM. This makes it easy to switch between OS-9 and BBUG. No more hassle of changing out chips - just move a jumper.

The jumper in the middle of the board, just above the decoder ROM enables the FE000-FEFFF block of on-board memory. This would be installed once the motherboard I/O addresses are moved out of the E-block of memory and would allow 60 KB of RAM to be used.

Future

Moving the I/O addresses out of the E-block gains 4 KB more usable memory for OS-9. Perhaps I'll try that in my retirement.

Another fun project would be to put a full OS-9 Level I system into ROM. Unfortunately, all of the essential modules take up just over 16 KB of memory, so the division doesn't fall on a natural 4 KB boundary. This might cause a conflict accessing extended memory with the DAT.  I'd also have to figure out how to program the decoder ROM. There are not many EPROM programmers that can program the Cypress Semiconductor CY7C291 devices, and I no longer have access to the ones I originally used. 

OS-9 Level II

This design works well for OS-9 Level I. To run OS-9 Level II, which allows each process to have a full 64 KB address space, requires more hardware. First, a second set of DAT memory chips allows the user and supervisors states to have separate memory maps. Second, a means of switching between those maps automatically -- like when servicing and returning from interrupts. Third, would require ROM to be accessible from an extended memory address, and then mapped into the supervisor space. 

Those requirements go beyond the scope of this design. Perhaps there's room for a V3 board. All of this assumes access to a copy of OS-9 Level II, which may be difficult to find. 

Forty Years of Personal Computing - Tanner/Digital Research 64KB Memory Board

Digital Research Computers 64 KB SS-50 Board

I graduated from Georgia Tech in the fall of 1983 and got a full-time job. By 1984, 20 KB of memory didn't seem like enough for the MC6809E V1 board. My attempt to expand the  8 KB MP-8M to 16 KB didn't work. And I never built the dynamic RAM circuits I designed. I wanted more memory.

Digital Research Computers marketed an SS-50 card designed by Tanner Computers in the early 80s. It sported thirty-two sockets for 2 KB RAM or ROM chips. These 2716-compatible chips were quite popular at the time.

I bought a kit for about $225 with a full 64 KB of RAM in June 1984.

Assembling the kit was straightforward, along the lines of the SWTPc kits. The board worked right away, with no soldering issues -- largely due to the excellent solder mask on the board.

For SS-50 systems, this board has several flexible options. The first 48 KB presents as three 16 KB banks that are enabled individually. Each 2 KB segment in the top 16 KB is enabled individually, allowing one to navigate conflicts in the C, D, E and F blocks of memory. This allowed for I/O on the motherboard, or perhaps RAM or ROM on the CPU board.

The board supports extended addressing on the S0-S3 pins. When enabled, the entire board responds as one 64 KB block. Each socket can contain either RAM or ROM chips, selectable by the jumper next to each chip.

Initially, I used this board without extended addressing as a 56 KB board. I later enabled extended addressing to access the full 64 KB, after modifying the MP-B motherboard to decode the 20-bit address for the I/O slots. This allowed me to use that 8 KB of RAM for a virtual disk drive, briefly.

I discovered some  extended memory issues between BBUG/Flex09 and OS-9, so I disabled the MP-B decoding.

As pictured, the board has the E000 and E800 blocks disabled, with F000 enabled, and F800 disabled. This configuration was appropriate for the MC6809E V1 CPU board and MP-B motherboard without the 20-bit address decoding, although, technically, the E800 block could be enabled, and the F000 block would not be accessible after I modified the MC6809E V1 CPU board for a 4K ROM.

Forty Years of Personal Computing - MC6800 Years - Hardware Accessories

MP-8M sans modifications.

During the summer of 1978, I ordered more parts for my SWTPc 6800 computer. 

MP-8M

I ordered an 8KB memory board, the MP-8M. The board used 4Kx1 chips, compared to the 1Kx1 chips on the MP-M. Even though it held twice as much memory, the MP-8M looks barely populated by comparison. It also drew far less power. Notice the LM7805's have no heat sinks. The kit came with them, but they really aren't needed.

The original MP-M boards drew about 1.5 amps from the 8 volt supply for each board. SWTPc recommended running a maximum of four MP-M boards to avoid exceeding the capacity of the power supply. With the MP-8M, the machine could be populated to the 32 KB of continuous memory the MIKBUG memory map allowed. 

At some point, I tried expanding the 8 KB board to 16 KB. I did this by buying 16 more 4Kx1 RAM chips and piggy-backing them on the original devices. All the pins were soldered except for the CE - Chip Enable (pin 10), which was raised to the side and wired together in two groups of eight. A couple of additional chips were used to drive the CE pin for the upper and lower 4 KB banks. 

In theory, it should have worked. When the CE pin was high, the chips were unselected and all their outputs were in a tri-state mode. The decoder should select only one set of 8 chips at a time (or none at all, depending on the memory address).

I never could get it to work. The original 8KB worked fine, but the additional 8KB never responded properly. I suspect there was something incorrectly wired in my additional decoder. I removed the decoder circuits and left the piggyback chips. Eventually, I removed those as well.

One feature of the MP-8M was the write-protect switch. Flipping the switch made the memory unwritable. I never found a use for this feature, so I removed the switch.

SWTBUG

Two other purchases I made in the summer of 1978 -- SWTBUG and the MP-LA. SWTBUG was a MIKBUG-compatable ROM with several extra features. Perhaps the most important feature was that it supported the MP-S serial interface, and not just the MP-C serial interface. More on this in a later article.

MP-LA

MP-LA board.

The MP-LA was a parallel interface card using a 6821 PIA. I didn't have anything to hook this up to, but I wanted to experiment with parallel interfaces. So I built something.

The Kreepie-Peepie

I cobbled together a small aluminum box that contained 8 red LEDs, plus a small audio amplifier. The amplifier design was taken from the May 1977 Kilobaud article, "Adding 'Plop' to Your System" (page 98).

Kreepie Peepie - says so with dry-transfer letters.

The original amplifier design used a 7406 hex inverter with open-collector outputs. One inverter buffers the input, the next creates a 180 degree phase difference, and the rest are hooked in pairs to drive either side of a 500:8 ohm transformer. The 500 ohm winding is center-tapped and fed through a 1 k ohm potentiometer as a volume control.

For some reason, I used two 7400 NAND gate chips. Probably because it was what I had one hand. This did not work the same, since the 7400 does not have open-collector outputs. But it worked despite my error. 

The 8 LEDs connected to the B port of the MP-LA, and the audio amplifier was hooked to the CB2 control pin. The whole unit was powered by stealing 5 volts off the MP-LA's LM7805 regulator.

While it sounds simple, this tiny box was fascinating. I spent the next several weeks writing and modifying small assembly language programs to exercise it. Programming different patterns of the 8 LEDs was easy and fun. Animating the lights at different speeds required mastering delay loops in the code.  

Inside the Kreepie Peepie.

Even more challenging was the audio interface. Whenever the CB2 pin was changed, it would make a "tick" sound in the speaker. Making sounds required one to constantly change the state of the CB2 pin. By toggling CB2 rapidly, one could create tones, the frequency of which was controlled by the speed of toggling. Experimenting, I found that I could create more than one tone simultaneously by using two numbers and computing the delay loop. Changing the delays algorithmically produced weird rising and falling sounds.

I spent a lot of time hand-modifying machine language programs and running them to see what new sound or LED pattern I could produce. One Saturday, my mother got really annoyed that I was playing with the computer instead of coming to dinner. She complained that I was spending "too much time with the kreepie peepie." And thus the little box was dubbed the Kreepie-Peepie. I even applied rub-on letters to the box with this name.

Forty Years of Personal Computing - SWTPc 6800

Old computer veteran from November 1977,
showing a few front-panel modifications.

After I completed the SWTPc CT-64, I ordered the SWTPc 6800 computer system in November of 1977. How much memory to order was a consideration. The original kit had the MP-M board with only 2 KB of memory. SWTPc changed this earlier that year to add an MP-MX expansion for a total of 4 KB. 

I wanted to run BASIC, plus the co-resident Assembler / Editor (called Co-Res), and this required 8 KB, plus space for programs. To basic kit, I added two MP-M boards. But, I did not order the MP-MX 2K expansion kits. I figured I could purchase the 2102 1Kx1 static RAM chips cheaper somewhere else. 

Design

The design of the SWTPc 6800 Computer System results from the MIKBUG ROM. Motorola developed MIKBUG to run a MC6800 evaluation kit. The essential features of the SWTPc system are drawn from this evaluation kit. The ROM resides at address E000, 128 bytes of RAM at A000, and a serial device at address 8004. 

The serial device is worth mentioning. For the original evaluation kit, the MC6850 serial device wasn't ready, so Motorola shipped the MC6820 parallel interface adapter (PIA), a bit of divider logic and used software to "bit-bang" all serial communications. SWTPc offered two serial port boards, the MP-C and the MP-S. The MP-C uses a MC6820, while the MP-S uses the MC6850 asynchronous communications interface adapter (ACIA). MIKBUG requires the PIA, so that's what the MP-C uses. This means that the original 6800 computer system cannot receive any characters from the console terminal unless the CPU is actively polling the MP-C I/O board.

The resulting memory map makes perfect sense for an evaluation kit, but left something to be desired as the system grew:

• 0000-7FFF - available for RAM (32 KB)
• 8000-9FFF - 32 bytes for the 8 I/O slots (4 bytes per slot) repeated
• A000-BFFF - 128 bytes of ram repeated
• C000-DFFF - available for RAM (8 KB)
• E000-FFFF - 512 bytes of MIKBUG ROM repeated

Back in 1975, 32KB of memory space seemed enormous. SWTPc recommended only four 4K boards be installed, based on power supply considerations, which topped out at 16 KB. Later, it would become a serious constraint.

Building

The 6800 computer system kit consisted of several sub-kits:

• MP-B Motherboard
• MP-P Power Supply
• MP-A CPU Board
• MP-M + MP-MX 4K Memory Board
• MP-C Console Serial Port Board
• Metal chassis and case to house the computer

After my experience with the CT-64, I was prepared for SWTPc's minimalist assembly instructions.

MP-B Motherboard

MP-B

The MP-B was straightforward, although there are nearly 600 connections to solder the bus pins to the heavy bus traces. That was a lot to ask for my 25 watt Weller soldering pencil. The motherboard design has some decoding and buffering logic to separate the seven 50-pin main slots from the 30-pin I/O slots.

(In the picture, you'll note that I have replaced the original nylon spacers with #8 screws. SWTPc used nylon spacers that clipped into chassis bottom and allowed the MP-B to snap in. Those goofy nylon spacers never worked well and often would come loose from the chassis bottom. There's also some additional logic that enhances decoding -- more on that in a future article)

MP-P

I struggled a bit with the MP-P power supply. It had a lot of heavy wiring and board traces. But it is simple and went together quickly.

MP-A

MP-A CPU board

The heart of the whole computer system is the MP-A board. Compared to later CPU boards, there's quite a few discrete components on this board, related to the clock drivers and 555 reset timer. Given my experience with SWTPc kits, it wasn't difficult.

(You might notice my board is missing a few things - like the MC14411 chip and its associated crystal as well as the heatsink on the 7805. These components moved to other projects when the board was retired)

MP-M / MP-MX

MP-M 4KB memory
boards

The MP-M boards with the MP-MX expansion were the most dense. They have 32 total memory chips, plus seven other integrated circuits, two voltage regulators and a handful of discrete components, all on a 5 1/2" by 9" board. It was a lot of soldering. I did this twice, using parts from the second MP-M kit to act as the MP-MX kit. 

A few weeks later, I built the third MP-M/MP-MX, using 2102 chips I ordered by phone. It was cheaper, but not by a lot. There were a few other components for the MP-MX I either obtained from my junk box, or bought locally. You can tell that board by the yellow disc ceramic 0.01 uF capacitors. 

(In the photo, these boards are missing components, too. The molex connectors are missing from the center board, and the two top boards have donated their heatsinks as well. If you look closer, you'll find a few memory chips that are socketed or are mounted on socket pins. All these chips failed in the first couple of years of use and had to be replaced)

MP-C

MP-C board, modified

The MP-C was easy to build by comparison. Generally the I/O boards are really simple. The MP-C had nine integrated circuits, but three of these are six-pin opto-isolators. 

This board was designed to support RS-232 connections, as well as 20 mA current-loop interfaces that were typical of mechanical teletypewriters. 

(In the photo, the MP-C card has been modified into an MP-S type card using a MC6850 ACIA. The components related to the 20 mA current-loop interface have been removed, as well as the clock divider circuits)

Debugging

The big challenge for this kit was making it all work. Yes, I had a few solder-bridge problems with the CT-64 kit, but I managed to puzzle them out. It was easier where I could see things on the screen.

For the SWTPc 6800, this was harder. A lot of the system had to work to get the MIKBUG asterisk "*" prompt to show up. How as a kid who is not even 17 years old and owns no test equipment other than a cheap Volt-Ohm Meter going to do this?

I was lucky my father worked for a local college and they allowed me to borrow a dual-trace oscilloscope for a few weeks. This allowed me to track down my problems. I was experienced in building enough that I managed to avoid obvious problems like putting components in backwards, or putting the wrong components in a spot. 

You'll note most of the integrated circuits in the SWTPc kits are not socketed. Sockets were considered optional for most components. The MP-A board has sockets for four chips: MC6800, MC6810, MC6830 (MIKBUG), MC14411. The MP-C board has a socket for one chip: MC6820. There were no sockets supplied for the MP-B or MP-M/MX boards. Some builders opted to supply their own. 

Without sockets, it was important to place components correctly. Unsoldering misplaced components was not a pleasant experience, and it risked damage to the board.

That said, virtually every problem I encountered was either due to a solder bridge, or an unsoldered connection. The SWTPc boards had no solder mask (another cost-saving measure), so making accidental bridges was easy. I found solder bridges on the MP-A board, on the MP-B board, and several on the MP-M boards. 

Indeed, getting the memory boards to work correctly was enough of a challenge that it made me appreciate memory test programs. Some simple tests won't find memory convergence problems.

The SWTPc 6800 computer would function with only the MP-A and MP-C boards plugged in. The MIKBUG ROM monitor could be used to enter short machine language programs into the 128 bytes of scratch memory at A000.  This made it easy to test the other components, such as the MP-M boards.

The Unit

The resulting unit is a smart-looking turnkey box without any flashing lights. (Mine has been modified with 16 LEDs and a few other holes on the front panel, but I'll tell that story later) It came with aluminum angle trim, but I tended to leave it off. I generally had my hands in and out of the box so often I didn't even screw the lid on.

On the original kits, the back panel had four large holes which passed all I/O cables. In later units, SWTPc added punch-outs for DB-25 connectors for serial devices. Mine has four punch-outs arranged in two horizontal groups just inside the two outermost holes. Other units have four punch-outs in a line above the holes. Other builders have modified their back panels to add other connector types.