Forty Years of Personal Computing - Modems and Serial Ports

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. 

Forty Years of Personal Computing - The ISEF (1979)

Yours truly, at the 1979 ISEF, with my exhibit.

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

The Single-Point Ground (SPG)

SPG all hooked up to coax
and control lines.

As radio amateurs, taking proper precautions against lightning and electrical surges can be a difficult and expensive proposition. We often neglect them and rely on luck.

After reading Bonding and Grounding for the Radio Amateur,  I decided it was worth the investment. I already had all ground connections - house, tower, station - bonded. What was missing was bonding the antenna connections to the ground as they entered the house. I needed a Single-Point Ground panel.

A Single-Point Ground is a metal panel or box providing a common bonding point for all cables as they enter a building. This metal is connected to the external ground rods, which are all bonded together. The idea is to bond the cables connected together, so that lightning or surge potentials all rise and fall together. Without a potential difference, damaging currents cannot flow. 

SPG panel ready to mount
on basement wall

I cut a 0.090" Aluminum panel 12" by 16" and mounted the KK1L antenna switch to the bottom edge. I added lightning arrestors for the antenna coaxial cables, plus a barrier strip holding gas discharge tubes for the rotator and shunt antenna control cables.

I chose MFJ-272 lightning arrestors. I needed six of these, and the MFJ units were about $40 each. The Alpha Delta and Polyphaser units were more expensive. The arrestors are mounted to the panel with a single large screw, supplied with the arrestor.

Short coaxial jumpers connect the arresters to the KK1L switch. I made these out of 18 inches of RG-400 coax using new Amphenol UHF connectors and a UG-175 adapter. RG-400 is doubly-shielded, eliminating the potential for any coupling between the jumpers. (Notice I didn't quite have enough RG-400 for all six jumpers, so there are only five at the moment. I'll have to purchase more)

The panel mounts on the basement wall where the cables enter the house through a 4 inch PVC pipe. A grounding block connects a short piece of copper wire to an eight foot ground rod on the outside. The ground connection is also bonded to the perimeter ground wire between the house, tower and station grounds using a split bolt. 

I had a bit of trouble with the coax running from the A and B ports of the KK1L to the operating desk. Since the coax to the antennas ended at the basement wall, I trimmed some coax from the antenna feed lines. To get the right length, I pulled the feed lines outside, then trimmed them from the far end. Simple, eh? Except the first one looped around and got stuck, and the cut piece ended up being about five feet too short.

The next feed line was a newer run of Davis Buryflex. I ran it to the A3S/A743, and then cut the right length. For some reason, I had problems with the connectors on both ends, but once they were redone, the cable worked as expected. For a short while, I thought the cable itself might be defective.

To do these tests, I made good use of my RigExpert AA-55 Zoom. Which of two pieces of old coax is any good? The cable loss test is quick and give one real numbers to compare. You just need to test the coax both open and shorted. 

With the SPG installed, the next step is to automate the switching of the KK1L.

Forty Years of Personal Computing - "Compilative" BASIC Interpreter

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.

Cable Management for Desktop Shelves

Cable management trays
added to back of desktop
selves.

Now that my station desktop is on wheels and has a set of nice shelves, I wondered might be done about the rats nest of wires hanging down from the back of the desk. Some kind of cable management system was needed.

These systems can be expensive. I found a solution on Amazon.com that worked pretty well. It is a kit of eight cable raceway trays about 15" long, 1.5" wide and just under 1" tall. All for just about $20.

These worked well with my desktop shelves. Three cable trays fit neatly on the back of the shelves just under the copper pipe ground bus bar. I mounted them using three short wood screws on each tray.

The tops of the trays either slide or snap off. The fingers on the sides are easily displaced to insert wires of just about any size. In some cases, cables are routed in the trays from one end of the shelves to the other.

From the picture, there are still a lot of wires, but it is neater and more manageable than before. Many of those are antenna coax or power connections. The antenna coax will be moving to the back wall of the basement once the Single-Point Ground (SPG) panel is in place. 

I also improved the bonding between units. I'm using 1/2" tinned copper braid, a fork lug and a cable clamp around the 1/2" copper tube grounding bus. This creates a low-impedance connection between the equipment and the station ground. In a few cases, I had to drill a hole and add some #6 screws and nuts to make the connection.

The best part is, I still have five left-over cable management trays to use elsewhere.

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 - MC6800 years - Cassette Tape and BASIC

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