In the spring of 1980, as my first year at Georgia Tech was coming to a close, my parents were coming to pick me up and take me home to West Virginia in June. My brother Ben suggested during the trip, we could take the FCC exams for Amateur Extra class. At the time, we were both General class, and all exams were administered at official FCC offices, such as Atlanta.
I wondered how I might practice for these exams. Although I was a member of the Georgia Tech club station W4AQL, getting access was a hassle. I hadn't been on the air since I'd come back to Tech in January. I was afraid I had forgotten Morse code entirely. My solution was to write a code practice program for my SWTPc 6800 Computer System, using the Kreepie Peepie.
The program is small, just over 200 bytes long. It creates a five character code group by choosing characters randomly. Then it sends the group, complete with a word space. A check of the serial port determines if someone has input a character, indicating a request to stop. If not, it continues to generate and send the next five character group.
The characters themselves are sounded out by toggling a bit on the Kreepie Peepie. A wait loop of roughly a millisecond is used. This gave a pitch of about 1 kHz. The wait cycles are repeated a sufficient number of times to sound out the element (BAUDV). Silent periods used the same timing element, without toggling the Kreepie Peepie. This made it easy to adjust speed by changing the BAUDV location. I had this programmed to 64, which came out right about 20 wpm.
I'd typically run the program for a few minutes, copying as many of the five character groups as I could. It was enough. I passed the FCC 20 wpm exam.
The GE TDM-114 Data Set. The big toggle switch is my modification so I could turn it off.
GE TDM-114 Data Set
In the fall of 1979, I headed off to Georgia Tech and brought my computer with me to the dorms. My roommate that first quarter wasn't impressed. Nevertheless, I continued to work with the computer and learn new things.
In those days, Georgia Tech used a CDC Cyber 74 system for instruction, and one could dial into the system with a modem. I managed to locate a GE surplus modem for about $40. It was an acoustic coupler modem -- you would dial the phone manually, then jam the handset into the unit. Speakers and microphones would pick up the sounds from the phone line through the handset.
Rear View of TDM-114.
In my second quarter, I ordered a unit. When I got it, it did not work. Fortunately, it came with a manual with a schematic and troubleshooting and adjustment guide. I didn't have any test equipment other than a Volt-Ohm Meter (VOM). I don't remember how I fixed it. With youthful curiosity and dogged persistence, I managed to find a diode that didn't appear to be working, replaced it, et voila! It worked.
Manual with unit.
This was a BELL 103 modem, which meant it supported speeds from 110-300 bps. Back in 1980, that wasn't as slow as it seems. Who am I kidding? It was really slow. It was what we had.
Schematic
Initially, I hooked the modem directly to my CT-64 Terminal system. It was fun being able to dial the Cyber 74 and work on programs from my dorm room. But, it was a pain to swap the cables around between the computer and the modem. It would be nice to leave the CT-64 plugged into the computer all the time, and plug the modem into another serial port. I needed more serial ports.
MP-S
I purchased two MP-S serial ports in early 1980. These boards use the MC6850 Asynchronous Serial Adapter (ACIA). The advantage of the ACIA is it could transmit and receive individual characters without any CPU attention. The big-banging serial port used by the MP-C required the CPU to actively perform all sending and receiving.
The MP-S is really simple, especially after removing the current-loop circuitry, as I've done. I liked this about the design of the SWTPc 6800 Computer Sytem - I/O devices could be added very inexpensively.
One board replaced the MP-C (since I was using SWTBUG by then) and communicated with the CT-64 at 1200 bps. The other used a different slot and was wired for 300 bps. Making them talk to each other was a small matter of software.
The Terminal Program
My initial attempt was a mad polling program in 6800 assembly language. It consisted of a crazy loop that looked for received characters from one port and transmitted them on another, and then did the same thing going the other direction. It even had buffering in each direction. It probably wasn't even 100 bytes long. It worked well.
In the fall of 1980, it occurred to me this could be an interrupt-driven program. This took a bit of doing. You had to configure the proper interrupts and then have an interrupt service routine to determine the cause of the interrupt and service it. Get something wrong, and nothing would happen. This made it much more difficult to debug.
I rose to the challenge and got it to run. I included even larger buffering than in the first program. I had hoped to use the MC6800's WAI (Wait for Interrupt) instruction, but ended up using the idle time to perform buffer housekeeping.
The buffering came in handy. For a while, I had a switch on the CT-64 that would pause reception from the computer. I could run a long listing at 300 bps, flip the switch and read a screenful while the next screen slowly buffered in my computer. flipping the switch again and it would spool on the screen at 1200 bps -- the top speed of the CT-64.
This experience laid the groundwork for my first job -- at Hayes Microcomputer Products, Inc after I graduated from Georgia Tech. I spent nearly twelve years writing much more sophisticated terminal programs.
I've written about my attempt to write a BASIC interpreter. While I never finished the project, it did win a few awards at science fairs.
Area Fair - Fairmont State College - March 30-31, 1979
While writing the interpreter, my parents thought my efforts would make a good science fair project. I entered the West Virginia Area Fair. My father, being a professor there, was a judge. To avoid any conflict of interest, he did not judge my category.
My interpreter was by no means "done". I was still working on it. I put together an exhibit discussing the various things I did to improve computer performance, including fixing the CPU clock source.
I did well at the Area Fair, winning the US Air Force Honors award for the most outstanding exhibit in my category. I also placed first or second overall. This was a matter of debate. The first place winner would travel to the International Science and Engineering Fair (ISEF). This trip was sponsored, in part, by a consortium of coal mining operations. The other exhibitor I tied with had built an impressive and detailed model of a modern coal mining operation. The coal miners wanted to send him. After all, his exhibit said "COAL!"
The professors of science weren't that impressed with the model, and they wanted to send me. (My father, of course, declined to vote) They worked out a compromise. They would see how we did at the Regional Fair, and break the tie that way.
Regional Fair - West Virginia Wesleyan College - April 20-22, 1979
West Virginia Wesleyan College impressed a kid from a small town like Fairmont. I toured their computer science lab, using a PDP-11. I met some of the students and got to talk to professors of computer science. One of them (sadly, I cannot remember his name) gave me some helpful suggestions on how to solve certain parsing problems, as well as methods to compute mathematical functions I needed.
I was impressed with the lab, the professors and the other talks that I scarcely remember my presentation. My mother remembered me holding up the October 1977 issue of Kilobaud magazine like everyone must have read it.
It must have gone well. My exhibit won two awards, an outstanding exhibit award in my category for large schools, plus a US Army / Science Service certificate for outstanding achievement in my category. I also placed 3rd in the state overall. My competition from the Area Fair? He didn't do so well, and didn't even place in his category. That meant I was first place in the Area Fair, and would be going to the ISEF.
Trying to Finish
I was desperate to finish my work before the ISEF in San Antonio. It was my Senior year of High School, and there was a lot going on. I had less than two weeks to prepare.
I read the rules of the ISEF competition. The venue required all equipment have 3-wire electrical plugs. I replaced the cords on the terminal and computer to 3-wire cords and plugs -- the only ones I could find at the local hardware store were bright orange and very heavy. The tape recorder had a two wire plug, but I could run it on batteries if anyone complained.
That job done, I turned to the interpreter. I've already described that during one of the late work sessions I over-wrote dozens of hours of work. There was no way to replace this work in the time remaining. I would go to the ISEF with an incomplete project.
The Trip
The time came to ship my equipment to San Antonio. There would be no further work done.
Shipping my computer worried me. There were so many things that might fail in transit, I wanted to be able to repair them. The airline allowed a small personal bag. I filled it with virtually every tool I owned. A soldering iron, multi-meter, screwdrivers, wrenches, solder, parts. In all about 35 pounds of tools in a small gym bag.
Today, you couldn't walk through airport security with 35 pounds of tools, they would never let you board. In 1979, they asked me what all of it was for. I explained that I needed them to fix my equipment that had been shipped to San Antonio. This seemed satisfactory, and they let me board.
International Science and Engineering Fair - San Antonio, TX - May 7-11, 1979
At the Fair, I worried about setting up my exhibit. Fortunately, everything survived the trip, and was set up in short order. It all worked. I noted the exhibitor next to me had a Radio Shack TRS-80 computer -- all with two-prong AC plugs....
If you study the picture, you can see that I brought everything -- CT-64, SWTPc 6800 computer system, CIS-30+, cassette recorder, tapes and even the Kreepie Peepie. I also had hand-outs, a paper and the source code sitting on the table. (And, yes, I could not spell "binary" correctly)
Without an interpreter to show, I wrote a simple program that drew a sine wave vertically on the terminal using asterisk characters and spaces. This was a good demonstration of how slow SWTPc 8K BASIC was. I left this program running each time I left the exhibit. When I returned, the program had crashed. I never figured out why.
I don't remember my presentation to the judges, so it must have gone OK. I didn't place in my category. I was just happy to be there at all, especially with an unfinished project.
The ISEF arranged some tours for the exhibitors. One was to a solar power farm at the University of Texas. Another was a trip to the USAA offices, touring their computer center. They had all IBM equipment, including a large mainframe and one of the new laser printers with a 77" imaging drum. It was my introduction to a corporate computing environment.
I remember one of the docents talking about who they hire at USAA. It wasn't all computer science majors. In fact, some of their best programmers were actually music majors.
And there was a welcoming event for the exhibiters. I was super shy back then, so I don't remember meeting anyone. But I do remember the food. It was my first experience with tamales. They were much easier to eat once you removed the corn husks....
Notebook containing the BASIC interpreter source code
In June of 1977, Kilobaud (later Kilobaud Microcomputing and still later Microcomputing) magazine published an article by Tom Rugg and Phil Feldman entitled "BASIC Timing Comparisons"(page 66). A few months later, they revised this article in the October 1977 issue, with a follow up "BASIC Timing Comparisons - Revised and Updated" (page 20).
In the late 1970s, there weren't many computer languages available for small computer use. One either wrote BASIC or assembly language programs. Microsoft got their start this way -- selling BASIC interpreters to a variety of small computer manufacturers.
Assembly language is difficult. Having a high-level language, even one as, well, basic as BASIC made programming more accessible. I used Robert Uterwyk's 8K BASIC interpreter, sold as SWTPc 8K BASIC. When the Kilobaud articles came out, I was shocked to find the SWTPc 6800 Computer system ranked near the very bottom.
No way! The Motorola MC6800 was capable a spot near the top of the list, once you adjusted for relative clock speed -- a 2 MHz Z-80 or 8080 is equivalent to a 1 MHz 6800 or 6502. Something wasn't right. The problem wasn't the machine, it was the software.
The Problem(s)
My experience with SWTPc 8K BASIC showed there were three issues. First, it did no syntax checking on entry. This told me statements weren't parsed until the program was run. Second, each line had to be re-parsed during execution, which slowed things down further. The third wasn't really a bug. All the other BASIC interpreters used 32-bit floating point numbers for their calculations. SWTPc 8K BASIC floating point numbers used Binary Code Decimal (BCD), and supported nine-digits of precision and exponents of plus or minus 99. These numbers took six bytes to store, and many more instructions to calculate, but covered a larger numeric range and precision.
Math Routines
I decided I would write a BASIC interpreter. I started with math routines. My floating point format was straightforward. One byte was the exponent, and the next four bytes were the mantissa. Both were two's complement binary numbers. I worked on these routines hard, and manage to test them to the point I believed they were complete.
The math routines used a sixteen level expression stack, all in page zero. The bottom of the stack held the X and Y registers -- where all math operations took place. This meant the basic math operations where coded directly on X and Y using zero-page addressing modes -- which was very fast. In retrospect, this meant a lot of shuffling values around in memory. Given the MC6800's lack of registers, perhaps this was a reasonable choice.
Science Fair Project
At some point, this became a science fair project that got me to the International Science and Engineering Fair (ISEF) in San Antonio, TX. I'll tell that side of the story in a separate article.
The Interpreter
Flowchart of edit / command mode
With the math routines in place, I focused on the editor/interpreter.
My editor parsed input on entry, storing keywords with one-byte tokens, where the high bit was set. This took less memory to store, plus it was faster to interpret. For this reason, I dubbed it a "compilative" interpreter -- due to the pre-parsed statements in memory.
I had decided my BASIC would replace SWTPc BASIC. It would support the same statements, functions and language. From the start, I allotted for every statement, function, and expression.
I continued to work on the interpreter in the spring, even as I was showing my exhibit at various science fairs. I was nowhere near done.
My style of working in those days was simple. I hand-wrote assembly language in notebooks, later typing it into the computer to build. Then I would write out the source and object to cassette tape. My terminal had only 16 lines, so hard copy in a notebook was easier to study. It also allowed me to write code when I wasn't at my computer -- like when I was at school.
The project grew a lot, and the source exceeded the capacity of my small system. There was more code than would fit in my 20 KB system with the co-resident assembler/editor loaded. I worked on it in sections.
As things moved faster, my coding sessions got longer and longer into the evening. Then, one evening, I screwed up. I had just finished a programming session, and went to write the source out to cassette tape. But I had the wrong tape in the cassette recorder. I over-write dozens of hours of work. I didn't have time to re-do this work, and ended up going to the ISEF with an incomplete project.
My code had run into a problem in any case. I made clever use of tables to deal with different aspects of parsing. I used three different tables for different situations. The tables had grown to the point where the code exceeded 8 KB. By the time of my late-night coding accident, I had decided to consolidate the three parsing tables into one large one, which should have solved some of the memory problems.
Looking Back
"Compilative" Interpreter
After the ISEF, I never took up the project again. I was dismayed at losing work, plus I was busy that summer -- a trip to Spain, and getting ready for college.
Writing a BASIC interpreter was a huge project. After forty years as a software development professional, it's clear I'd gone about this all wrong. My strategy was to build all the components of a full-fledged BASIC -- math routines, transcendental functions, editor, parser, execution, variable handling, and then stick them all together into a working program. I had a lot of pieces, but very little of it was actually working.
In retrospect, I should have started small -- focus on a simple subset of BASIC and gotten that working. Then incrementally add features to it. This would result in a working solution sooner. Plus, I would have had something to exhibit. I'd learn this later, with experience.
In this alternate path, at some point there would have been enough of an interpreter to run the Kilobaud timing programs. Once I could measure what performance was like, I would know if my solutions would work, or if it needed something more clever.
Even so, I'm impressed with how much I wrote. Looking back at the two hundred notebook pages of assembly code and notes I've kept, there's much I'd forgotten I'd written.
Epilogue
I wasn't the only one to react to those Kilobaud articles. Technical Systems Consultants (TSC) read them as well. TSC had a Micro BASIC Plus product in 1976 - a BASIC that fit in 3 KB. It supported integer arithmetic only, and no string operations.
TSC developed a full-featured 8 KB BASIC for the MC6800. When they delivered it in March/April of 1979, it outperformed everything else on the market -- including Microsoft BASIC.
This was about the same time as my late-night programming sessions. Had I only known.
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.
Percom CIS-30+. Note that the handles of two switches have broken off.
I don't have a lot of records about the early use of my my first personal computer - the SWTPc 6800 Computer System. I purchased it in November of 1977, built initially with 8 KB of memory, shortly upgraded to 12 KB.
Around December 1977, I purchased the Percom CIS-30+ cassette tape interface. These interfaces allowed one to store and load programs on audio cassette tapes.
The CIS-30+ had major advantage over the SWTPc AC-30 cassette tape interface. Like the AC-30, the CIS-30+ supported the 300 bps Kansas City standard, but it could also record and decode at 600 and 1200 bps. This allowed programs to be stored and loaded two to four times faster.
Insides of the CIS-30+.
One early modification I made to the CIS-30+ was a small LED for the Tape On switch. This switch changed the serial input from the keyboard to the tape interface. More than once, I had left the switch in the on position and wondered why I couldn't type anything from the keyboard.
Originally, the CIS-30+ sat on top of the SWTPc 6800 Computer System. At some point, before I moved to Atlanta, I removed the board from the small aluminum case, and mounted it on the front panel of the SWTPc 6800 Computer System, in a space right above the power switches. This made the whole unit more compact, and reduced the number of cables that had to be dealt with.
I've since removed the cassette interface, and the holes that remain in the computer font panel.
The first program loaded was Rob Uterwick's Tiny Basic, which required 4 KB of memory. That was perfect for my machine, as it left 8 KB of space for programs.
Tiny Basic was distributed uniquely. The May 1977 issue of Interface Age contained a thin plastic record with Tiny Basic in Kansas City standard format. I jigged up a circuit so I could play the record on my family stereo and record it on a cassette tape. It took several tries to get the levels right, so the recording was readable. The magazine also had a hex dump of the program, so I verified that everything loaded correctly.
Tiny Basic was fun, but very limited - no string variables or functions. In the spring of 1978, I purchased SWTPc's 8K BASIC and the 6800 Co-Res Assembler / Editor.
Rob Uterwyk's 8K BASIC Manual.
With a full-featured BASIC interpreter, I amused myself by entering games. I had a copy of David Ahl's 101 BASIC Computer games. The dialect of BASIC was slightly different than that in the book, so minor changes had to be made. Still it was fun. I also entered programs that were published in magazines. Hunt the Wumpus was one of my favorites. As was Lunar Lander.
6800 Co-Res Manual.
The Lunar Lander game was amusing. It prompted you for an amount of fuel to burn at each step, as you headed toward the moon. One time I let the lander get really close, then entered 1.0E+99 -- the largest possible number -- as the amount to burn. The result must have caused some kind of weird numerical overflow, since the next step had the lander successfully on the surface!
One of the magazines published a Fantasy Adventure text game in BASIC, and I managed to get it running on my computer. At school we had a "Fantasy and Renaissance Fair", and my computer was featured running this game as one of the exhibits.
Setting up the computer to run this game was an involved process. First, you had to load the BASIC interpreter. The first part of the 8K BASIC tape had a binary loader program (which was twice as fast as the Motorola S1 format). With that program loaded and executed, you would load BASIC. The second step, after BASIC was running, one loaded the game from a different cassette tape. Then one could execute the game. All of this was done at 1200 bps speed, and the process took nearly 30 minutes.
Someone managed to kick the power button on the computer in the middle of playing, turning it off. I spent the next 30 minutes of the festival re-starting the game....
The 1.0 MHz clock board, attached to the back of the MP-A CPU board.
When I ordered my SWPTc 6800 Computer System, I was expecting a 1 MHz 6800 computer. It wasn't quite.
Yes, 1 MHz seems glacially slow by today's standards, but this was 1977! And the Motorola and MOS Technology chips of that time could access memory in a single clock cycle, so they were just as fast as the Intel or Zilog chips at twice the clock speed. (Those devices needed two clock cycles, minimum, to access memory and typically ran 2-5 MHz)
Perhaps as a cost-saving measure, the SWTPc MP-A board only has one crystal. This crystal connects to the MC14411 bit rate generator, which requires one specific frequency: 1.8432 MHz. The MC14411 contains a number of divisor networks to offer common bit rates for serial communication.
The designers of the MP-A used one of those outputs to drive the MC6800 at exactly 0.9216 MHz through clock conditioning circuitry. The MC6800 has two clock inputs that must be non-overlapping. This required about three integrated circuits and about 20 discrete components to produce. (Motorola later developed the MC6875 chip for this purpose. The later MC6802 had an on-chip clock oscillator and driver)
Clever, perhaps, but disappointing. It meant that my computer was almost 8% slower than specified.
Harsh Reality
Original crystal from my MP-A.
All this assumes you are start with a 1.8432 MHz crystal. In my unit, the crystal was actually 1.7971 MHz! This must have been another cost-saving measure. Perhaps the 1.8432 crystals weren't available, or perhaps they were more costly, since they substituted a unit that was 2.5% slower.
This meant that I didn't have a 0.921 MHz computer, I had a 0.89 MHz computer. It was 11% slower than 1 MHz.
This would not do.
First Modification
Changing the clock speed is actually a simple matter - one need only introduce a clock signal into the conditioning circuits that drive the MC6800. All you needed was a crystal oscillator and a 1 MHz crystal.
Close-up of the clock board.
I used a very simple circuit using two gates of a 7400 to create a very reliable oscillator. Even though this circuit was really simple, I wanted it to neatly attach to the CPU board. So, I etched a small circuit board. This was perhaps my second or third attempt at making a printed-circuit board, so it isn't pretty.
I masked the board by hand-painting etch resist. The lines are not very straight, and the lands have all different sizes. Most of the board was unetched and forms a ground plane that the crystal case is tied to. The result is very crude and rough.
Crude but functional etching.
The smallest drill bit I had was quite large for the pins, so the chips and other components don't rest very snugly, and are held in with solder blobs. All of the parts came used out of my electronics junk box, so they are different sizes. Only three wires connect to the MP-A: 5 volt power, ground, and the oscillator output.
It worked!
I now had a computer which was 11% faster than stock. At the time, It really felt like I had improved the computer.
Overclocking
Having an external clock oscillator means you can experiment with different clock speeds. Some time circa 1980, it dawned on me that I might push the processor faster than 1 MHz
Now, the Motorola 6800 microprocessor line had different codes for different speeds. No letter indicated 1 MHz, and "A" indicated 1.5 MHz, and "B" was 2 MHz (eg an MC68A00 is 1.5 MHz, and MC68B00 is 2 MHz). This wasn't just for the processor, but it applied to all the peripheral devices in the line (MC6810, MC6820, MC6830, MC6850, etc). All of my components were 1 MHz only. Could it possibly work at higher speeds?
At an electronics shop, I found a surplus 2.01 MHz crystal cheap, so I figured I'd give it a try. I removed the 1.0 MHz crystal and installed the new unit.
It worked!
I ran that computer for a couple of years in that configuration, and I never had a problem. Those 1 MHz components could work at 2 MHz, although likely not through the entire 0 to 70 degrees C rating for commercial devices.
This experience proved useful several years later at work, circa 1985. We had upgraded from the 4.77 MHz IBM PCs to 6 MHz IBM ATs. Of course, I opened up mine immediately and noted that the CPU crystal was 12 MHz and socketed. A trip down to the electronic surplus store netted several crystals at 16, 18 and 20 MHz. That IBM AT on my desk would not boot up at 10 MHz (using the 20 MHz crystal), but it ran just fine at 9 MHz. I made the same modification to several other colleague's computers as well to 8 or 9 MHz. We ran that way for years. And when it came time to turn them in, the original 12 MHz crystal was easily swapped back in.
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.
Login
