Notebook containing the BASIC interpreter source code

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

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.

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. 

Percom CIS-30+. Note that the handles of two switches have broken off.

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+.

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.

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....