Sunday, April 13, 2014

Milo's Meadow

During the Christmas break of 1983, I was pretty active in the local Omaha Bulletin Board Systems (BBSs) - for those of you too young to know what those were, they were what we used before the web. Everything was dial-up then, so speeds were pretty slow compared to even phone internet today, and ASCII art ruled.

I was involved in a bit of a flame war with some of the SysOps (the people who run a BBS) of some of the local boards operating on IBM PCs of the day. According to them, the Commodore 64 was just a toy, and you couldn't write a decent BBS for a toy. Of course I took that as both an offense and a challenge, and ended the debate on a Thursday, proclaiming that I would prove the haters wrong.

For the next three solid days, I coded every hour I was not sleeping - and since I was on vacation from work, that was a lot of hours of coding. Using a mix of BASIC and 6502 assembler, by late Monday the 2nd of January, 1984, I had a working BBS ready to bring online. My roommates and I were big fans of the comic strip Bloom County, and so named the BBS "Milo's Meadow". Naturally, I took the name Opus, and my roommates adopted other characters - Binkley and Milo.

But this was just the beginning - I wanted to provide services on my "toy" that no other BBS in the area had. I wanted a multi-line system in which two users could interact. So I bought a second C64 and modem, and got another phone line installed. I took a number of my old BASIC games and added the ability for them to have multi-player, with each player coming from the BBS running on each C64. I took two old joysticks, cut the joysticks off from the cords, then wired them together as a very simple network. Now two users who were on at the same time could challenge each other to one of the games, or to even just chat back and forth. And since my games already had computer opponents built in, if no one was dialed in to the other system, they could just play a game by themselves.

As the popularity of Milo's Meadow grew, I started getting requests to show how my BBS was written, mostly from teens. I ended up conducting classes on Saturdays to teach 6502 assembler, and to review the organization and function of the BBS code. It was a great time, and the site got popular enough that when we had our first user party, over 200 users showed up at Elmwood Park for grilling, frisbee, and general mayhem. One of the most popular "games" at these gatherings was "Kill Opus with as many Frisbees as we can" - it was awesome!

BBSs had one advantage over the web today - just about every user was local, otherwise they'd be paying long distance charges. It made user parties possible, and we held quite a number of them. The users were always great, and we always had a great time.

(Here is a blog post about Milo's Meadow and some other BBSs in the 80's I dug up from one of my old users)

Saturday, April 12, 2014

Pride Lost

I eventually outgrew working in BASIC on my Commodore 64 home computer. By 1986, I yearned for what I really wanted to do on the C64 - continue working on the games and programs I wanted to complete, but to write them in something more structured than just BASIC. A higher-level language that provided more powerful programming structures, even windowing and multitasking. The Macintosh was taking over the world, and I wanted to join in with my C64 in the revolution of the user interface (UI) for home computing.

It was time to get back into 6502 assembly language programming. Could it be possible to write an extension to the C64's BASIC that would support windowing and multitasking? I decided it was, and set out to do just that. The result was the product I called "Structured BASIC".

Structured BASIC had lots of classic programming structures missing from normal BASIC: For loops, While loops, block structures, and formalized data structuring were just some of them. It also had a windowing system with which you could open new windows for your program to display within - a huge step forward from working with just one screen. Multitasking was also supported through an NMI (Non-maskable interrupt) facility where special "Task" routines could be coded in Structured BASIC and then run concurrently with each other and your main program that owned them. There was incredible overhead in this process, and so running more than a single Task could really bog down the C64. The multitasking system was strictly equal-share, so every task got the same amount of CPU time before it was switched out with the next Task or main program, all in round-robin fashion.

It was an incredible creative problem to solve, particularly the multitasking and windowing parts of Structured BASIC. It was also very rewarding - I've never been more proud of anything I've ever coded before or since Structured BASIC. Not for what it did really, which is primitive by today's standards, but for when it did it and that it was just me working alone to accomplish something never done before on that platform. There was also something magical to me about working in assembly language again, probably because so few coders these days even know what it is.

I've long-since lost all traces of Structured BASIC, which makes me a little sad. I've done searches on the web, but little can be found:

Even though I felt Structured BASIC was my absolute best work, it had a very short lifespan. This was because a new C64 operating system was released shortly after it, something that would grab my Macintosh-inspired attention away from Structured BASIC, and rightly so: GEOS, and the C64 world would never be the same.


1983 saw the beginning of my decade-long love affair with the Commodore 64 home computer. Ten years is an incredibly long time to use just one home computer, but the avenues to explore with the C64 truly required an entire decade of my life to exhaust.

For its time, it was light-years ahead in capability for the money. But even though I already knew the 6502 assembly language it used, it was the power of what I could accomplish even in BASIC that amazed me.

When I bought my C64, I was just a few months out of college. Since I was working, I didn't have as much time to program for my C64. So that meant plenty of all-nighters - some nights I would program on my C64 literally from the time I got home from work until I had to go back to work. And even when at work, all I could think about was the project that work had interrupted. Some of my coworkers would catch me spacing out as I designed or debugged something in my head, and would tease me about it. Everyone knew that I was always working on home programming projects, and it became something of a running gag. "Kent's in the zone again, get a tissue and clean up the drool," ribbing like that.

In those early days, I wrote a lot of games in BASIC. The first game I ever wrote was the classic Battleship, complete with a computer opponent. I loved such logic games as a kid, and so wrote all kinds of them: Mastermind, Othello, and Backgammon to name a few, and all with computer opponents. I also played a lot of Avalon Hill Bookshelf games as a teen, so I wrote versions of a lot of those as well. One in particular was Stocks & Bonds.

My two roommates and I played a lot of Stocks & Bonds on my C64. For one session, I decided to play a prank on one of them, Dave. I secretly modified the program so that any stocks he bought would always go up, and my other roommate Alex and I would mostly avoid whatever Dave was buying. On the last turn of the game, all of Dave's stocks would crash. As the game progressed, Dave could not believe the luck he was having and was, of course, destroying us in the game. It was a struggle for Alex and I to not crack up as the last turn approached, but we managed. As soon as the C64 displayed the closing valuations, the look of confusion on Dave's face was priceless - right before Alex and I burst out laughing. Ah, computer pranks!

Friday, April 11, 2014

Imagination Machine

After getting hooked on the KIM-1 and the intimacy of working with such a small computer, I was desperate to make the leap to a personal computer. It was 1982, so the choices were slim: IBM had a PC, Apple of course with both the II and III, Commodore VIC-20, Atari 400/800, and Timex/Sinclair 1000 are the ones I remember. Of these, the Timex/Sinclair and VIC-20 were the cheapest, but as a poor college student, I needed something that was a far better deal. The VIC-20 was the only one that had a real keyboard that I thought I could afford, and was $300. But then I came across an ad in a magazine for something called the APF Electronics Imagination Machine.

The VIC-20 only had 3KB of RAM, while the IM had 9KB and came with two joysticks (with numeric keypads!) and a built-in cassette tape for data storage, something that was an extra cost on most other systems. Best of all, it was $250! I ordered one the same day I saw the ad.

The wait for the machine to arrive was agonizing. When it finally did, I was like a 6-year old on Christmas morning! Even the cassette storage unit seemed like high-tech compared to my beloved KIM. And an added bonus: The IM had a different CPU than the KIM. The KIM was MOS 6502, while the IM was a Motorola 6800. I had a brand-new assembly language to learn! It even had BASIC, which I also got to learn. I spent so many sleepless nights working with my Imagination Machine, and unlike the university mainframe, my time was not monitored or restricted. Looking back on that now, it was a little like locking up an alcoholic in a liquor store.

With a real keyboard now at my disposal, the first major program I wanted to write was an assembler that could translate the 6800 source programs I wanted to write into the hexadecimal machine code for me. That was the first program I ever wrote that I sold commercially, in a package along with some other utilities and games long lost to history.

In my senior year, I was in a computer hardware engineering class, and for my big project in the class I modified my IM to have 32KB of memory. In the days leading up to the project being graded, the unit started to get a bit twitchy, but held up until the day after it was graded, then died. It was quite sad for me at the time, but it was now 1983. There was a new home computer that came out just a few months prior, one that would possess me beyond all the obsessions with computers and programming I had ever known: The Commodore 64.

Dates with KIM

In 1982 as a junior at KSU, I took one of the more advanced classes in computer science. There were six of us in the class, but I forget its name. The class was for 6502 assembly language, and was held in an attic lab of one of the oldest of the computer science building, Fairchild Hall. It was my first computer science class is such an intimate setting. No lecture hall, no classroom, just the professor and us six students up in an attic. Us and KIM.

The KIM-1 was a 6502 kit computer with a hexadecimal, calculator-style keypad, 6-character 7-segment LED display, and a whopping 1 KB of RAM. There was no mainframe and no compiler, just coder and machine working together in absolute real-time. You would write your program on paper, compile it into hexadecimal numbers, then punch the numbers in to the KIM using the keypad. It was a tedious process, but it felt like peeking behind the computer curtain, and I loved that. After several weeks I had the entire op-code set for the 6502 memorized so I could compile programs in my head and just punch them in to the KIM. The sense of power it gave me to be able to do that - not even the professor could do it - was more than just gratifying. It was empowering, it was like freedom to me.

Debugging was another story for most of the students in the lab. All you had was that 6-digit 7-segment LED display. It was like an old digital clock display. If your program didn't work properly, more often than not there were simply no clues. You could step through your program one instruction at a time, and then use the keypad and display to show values in memory. It was like the most complex puzzle I'd ever known, and I loved it.

The KIM also had two input/output ports, and the lab was full of miscellaneous equipment you could interface to the KIM for one of your projects. Equipment like analog printers that had no buffer and required that your program start the print head moving, and then send it one character at a time at just the right intervals in order to form text coherently. You would have to calculate how much time each instruction in your program required, so that you could perform the printing correctly according to the print head movement speed. It was glorious. Or equipment like an old rotary phone dialer where your application had to read the numbers dialed as the voltages spiked and waned, accounting for signal bounce as you went, as your evil professor would half-dial repeatedly to mess with your program. All the equipment in the lab worked this way, and I was in heaven with the myriad of challenges. I completed twice the number of projects as required, I just couldn't get enough.

But my new obsession with assembly language programming with the KIM and all the wonderful equipment in the lab started to eat into all the extra time I normally spent in the big computer labs helping students outside my normal TA hours. And they let me know it every time they saw me! Instead of heading to the big labs when I had free time, I found myself heading up to that little attic lab to discover some new piece of equipment to interface. The challenge of helping students debug their own programs was becoming replaced with the challenge of discovering how far I could take my own skills. I had taken courses in all kinds of higher level languages like Pascal and PL/1, but those now seemed like just variations on a theme. What I could do with a KIM felt more real, it felt more intimate and more limitless. This passion would consume me for the next decade - the decade of the personal computer revolution.

Thursday, April 10, 2014

"That is NOT our Professor"

In the spring of 1981 I was a 19-year old undergrad at KSU. My FORTRAN professor from a class I had previously completed had to take a two week family emergency leave to deal with a death in the family. The timing was terrible as it was also two weeks before finals when he needed to go. He was not thrilled with the department's grad student substitute he had been assigned that semester for the FORTRAN class, especially given the timing with the approaching finals. As we commiserated over the dilemma, I casually suggested that I'd be thrilled to take over the class for those two weeks.

Engineering FORTRAN was a required class for engineering students, and was typically taken the sophomore year. I had taken mine early as a freshman, since I was in an accelerated program. This would make almost all the students in the class the same age as me, if not little older. It didn't help that in 1981 at the age of 19 I looked closer to 15. Still, he agreed that he would much rather have me help his students out than his grad TA. But since I was just a sophomore, the department and the TA could not know about the arrangement.

The class was held in a huge lecture hall. I arrived early and sat down in the first row to review the textbook and waited for the students to arrive. As the hall began to fill, I got pretty nervous to start the class - that's one reason I didn't start behind the desk or on the dias. A number of the students would recognize me from my work in the computer labs, but for most they would just assume I was another student in the class.

When it was time to start, I closed my textbook and went up beside the desk to address the class. Picture the scene - a lecture hall filled with a hundred or so sophomore engineering students, and this guy who looked to be about 15 stands up to address the class to start teaching - wearing cut-off jeans, a tank top, and sandals, with shaggy hair. As I briefly explained that there had been an emergency and I would be teaching the class for the next two weeks, a stunned quiet fell over the room. From somewhere in the middle of the class came a rather loud, "Oh that is NOT our professor!"

It all turned out fine, and the two weeks went by without incident. The students all did great on their final projects and exam. It was my first introduction to really teaching on a scale larger than in the labs, and I was absolutely hooked. While I've never had a teaching career beyond some guest lectures and leading professional training courses, I've always dreamed of teaching when I retire. At going on 53 now, that is not that far off.

Parallel Computing, TA-Style

When working as a TA in the computer labs of KSU in the early 80s, I was often the only help available to students. I paid no attention to my official work hours, and was always in the lab helping out with most of my spare time. When the lines got really long outside the lab's corner TA office, I would sit a student down at each of the three desks and help them in parallel. I would look at the first student's program listing, and start asking questions to guide them to discover their own answers. As soon as they would need to think for a moment, I would go to the next student at the next desk and do the same thing, then the next in a round-robin style, until they needed to go adjust their programs. Then someone else would take their spot the process would continue. I found I could help so many more students this way in the shortest amount of time.

Some really busy nights, this process could stretch on for hours without a break. I got to know so many different types of students. KSU had a large international student body, so I worked with students whose home countries were all over the world. I grew up, as I like to say, a poor hillbilly - born in the Ozarks of southern Missouri and raised in rural Kansas, so this was quite an eye-opening experience. At times, I would have three students from three different countries seated at the TA desks, helping them all at the same time. It was quite a challenge to switch from understanding one heavy accent to another, all in the span of a minute or two in succession. It took enormous concentration, and at the end of a lot of those nights I would be utterly exhausted.

It was the beginning of my exposure to a much larger world than I had ever known. One filled with ordinary people just like me and yet nothing like me, people with experiences I could hardly imagine and yet readily relate to, people whose language was both foreign and familiar. I would be an entirely different person today without the sum total effect all of these experiences had on me, and I know they made me a better person, a more empathetic human being. Despite the long hours, missed sleep and skipped meals, this was where I knew I belonged in those days: In the lab and helping everyone who needed it equally, with no borders and no limits.

Wednesday, April 9, 2014

Golf Balls and Terminals

At KSU in the early 80's, only grad students had access to the computer labs with actual terminals connected to the mainframe. Undergrads like me had to use the open labs with the card punches, card reader, and printer. After becoming a TA while just a sophomore, I got to know a lot of the grad student TAs. They shared with me a little known, little spoken about secret. There was a grad student lab room - only one - that was in an isolated, combo-locked basement room of one of the computer science buildings that had two terminals, and no one ever used it. And they told me the combo.

At my very first opportunity, I made for this new, secret lab. Excitedly I punched the buttons on the cypher lock and swung open the door to the dark, unoccupied lab. I flipped on the lights, and there they were - two glorious terminals. Sort of.

Technically what I was looking at in front of me were terminals, just not the monitor/CRT type. These were IBM Selectric golf-ball typewriters. These were teletype-style terminals, which were basically typewriters hooked up to a computer. No doubt my grad student friends probably thought they had played quite the prank on me. These terminals were slow, loud, and inconvenient - and I was in love with them! Compared to a card punch and card reader, this was interactive heaven! And I had them all to myself.

I soon discovered the joy of terminal use, even with terminals such as these - games! I played hours and hours of Colossal Caves Adventure (spoiler alert - XYZZY!) and Star Trek. Eventually I grew tired of them, and yearned to create my own games, based on my ideas and hard work. But those are stories for another time.

Tuesday, April 8, 2014

Line Bar Printers Gone Wild

The days leading up to a project being due were always hectic times in the computer lab, with midterms and finals being the absolute worst. My shift as a TA helping students in the lab would end by 8 pm, but I'd still be in the lab until 3 or 4 during these periods.

One particular night in late 1980 or early 1981, I was in the lab the night before the big midterm projects where due, when the ribbon of the line bar printer got wrapped around the print bar fingers and basically disassembled it. Perhaps I should explain just exactly what that means, in all its glorious detail.

A line bar printer has a long bar that would move left and right to do the printing. The bar has a large number little metal fingers with the print symbols embossed on the end, sort of like on a typewriter, but the fingers were short - maybe an inch long. These fingers were in groups of four on a unit as I recall, attached all along the print bar by snapping into place. There were multiple identical sets so that the bar could print many characters at the same time with a minimum of movement. So, there were a LOT of these groups of fingers - this will be important to the story shortly. The print bar would just shimmy back and forth only a few inches at a time, but very quickly as the line of print was completed. The speed and momentum of this bar action will also be important to the story very soon.

The lab was packed that night and there were lines at the card punches, the card reader, and the printer. About midnight I was in the glass office in the corner of the lab helping students debug their projects, when the printer made a tremendous screeching noise. To put this in perspective, these line bar printers were loud, thundering away with the heavy impacts of the print process and the bar chug-chugging back and forth sounding like a freight train. So I was accustomed to the noise, but what I heard grabbed my full and undivided attention. I sprang to my feet and ran over to the printer, popped open the hood, and out fell all the little finger groups that the ribbon had pulled off the bar, partially shredding itself in the process. This was not good.

There was no manual for this printer on site, and keep in mind there was no Googling for one either. The lab had dozens of students desperate to get their jobs done and printed, and the lab had but the one printer - this self-dismantled printer. I figured out how to remove the print bar and gathered up all the finger groups, and the last couple were difficult to find, hiding inside the printer where they had fallen. I then set out trying to debug the situation: What order did these finger groups go in? I laid them all out, sorted them by identical groups, and then assembled them back onto the bar in what seemed like a reasonably logical order. The ribbon was pretty shredded in a couple of places where it had torn the fingers from the bar, but was still intact. I just looped the big ribbon spool past the frayed ribbon section so that it would maximize the time before the ribbon would reverse direction and get back to the frayed section. I knew what would happen when that happened, but I didn't know how long that would be from now once the printer got going again.

I purged the print queue, threw together a quick program on the card punches to just print every character across the page, and gave it a try. I don't think any of the letters were in order on that first attempt, but that wasn't the real point. Now I could compare the expected output with the real output and adjust the ordering of the finger groups to match. The second attempt was much closer, although I still had some sequencing problems. I reasoned out my mistakes, reordered a few finger groups, and the printer was now printing correctly as far as I could determine. My hands and face were covered in ink from handling the ribbon and print fingers - it was quite the mess!

I opened up the card reader for jobs, and students were soon back to work. The whole process took about an hour. At least for about an hour, when the frayed section of ribbon came back around and took out the print bar again. At least then I knew what to do, and had it going again in about 15 minutes. The process repeated about every hour until around 4 am when the last student left. You might think it was a long, challenging night, but it wasn't that way to me. I was in the zone, helping students non-stop in between bouts of the printer eating itself and my putting it back together again, with nothing but my wits and determination to see it through.

Man, I miss those days.

The Great Lab TA Challenge

From 1980-82 I was a TA in the computer lab at Kansas State, answering questions for students. One of my good friends, JB, was a tall, skinny grad student and also a TA in the labs. He fancied himself a pretty good coder, debugger, and TA, as did I, and often when we were working in the same lab at the same time, we would institute a challenge: We would wait for a line of students needing help to queue a bit, then split them into two groups - one for him and one for me, of at least 3 students each. Starting at the same time, whoever could clear their line the fastest was the winner.

As a safeguard against just rushing through the analysis, we also instituted a 30 minute rule: After our lines were cleared, if the same student came back for help again, the additional time to help them was added to the total. Once the required 30 minutes passed without any of the same students coming back, then your total time was finalized and the winner determined. I know I won more of those wagers than I lost, but JB was definitely one of the more talented TAs and coders I knew while at KSU. I don't remember the wagers, but at most it would have been a trip to the vending machine, as we were both skinny and poor. I remember many times when winning that wager was the only food I would have on campus that day until I returned home.

Monday, April 7, 2014

Life in the Lab

After switching majors to computer science from electrical engineering in 1980 while at Kansas State University, I spent a lot of time in the computer lab. I spent far less time working on my projects than I did helping anyone and everyone with theirs. I was in one computer lab or another with the majority of my free time from 1980 through 1983, when I left college.

If you're imagining rooms full of terminals and PCs, you're forgetting that this was 1980. The computer labs were full of punch card machines, with 1 punch card reader and line bar printer. You would write your programs by hand on paper, then punch them in one line of code at a time on a single punch card. When you were done, you would wait in line to feed your deck of cards in to the reader, desperately hope that a card wouldn't jam, and wait for your time slice on the university mainframe until your printout was spooled to the line bar printer near the card reader. The process was often aggravating, tedious, time-consuming, and fraught with many points of failure that could delay you for hours.

I would rotate tours among the various computer labs helping people. When one lab became dead, I'd pack up and walk to another to see if I could help out there. This would continue some nights, particularly near a big project deadline for various classes, until 3 or 4 am, meaning I was in the labs for sometimes 12 hours straight. I was obsessed, but it was also immensely gratifying. My own projects had become so easy that they just weren't fulfilling. I hungered for more, and guiding other students through the logical process of deducing what was wrong with their own code was intoxicating.

My method was to never just give out the answer to the student. I would look at their program listing, figure out the problem, then start asking questions until they figured out the problem themselves. Depending on the skill of my fellow student, this process could take from a couple of minutes to several hours. But unless I had class (and even sometimes then), I never gave up on anyone.

Each lab had a small office staffed at random times with teacher's aid grad students employed by the department of computer science to help students. I tended to avoid those labs if the TAs where there, because a lot of them really didn't like me doing their jobs better than them. Students who I'd helped before would just come to me even if the TAs were there, because I really, deeply helped them. But the lab I spent most of my time at in those earlier weeks was in Seaton Hall, which was one the college of engineering buildings. The small, corner office in this lab was not defined by clear glass walls like the other labs, but with frosted glass because it was the office of one of the professors. I had never had one of his classes, and he didn't come out to help students. But after several weeks of my nearly constant presence in that lab, he saw me there helping students almost every time he was going into or coming out of his office. He came out one day, and walked straight up to me while I was just waiting around for someone to have a question. He wanted to know if I was employed by the department, since he had seen me helping so many students so often. I told him that I wasn't, so he asked me if I wanted to get paid to help them. I told him that I thought the TAs were all grad students, and I was just a sophomore. He said that they were, but he'd convince the department to make an exception in my case. He had overheard how I helped students through guided questions, and thought it was a better approach than any TA he'd ever seen. I couldn't believe it - I was going to get paid to do something I had been doing for free. I still spent a large number of unpaid hours in the labs outside my official, paid hours, but that was just fine with me. It was never for the money; it was for the high I got from just helping out.

Born to Code

In the fall of 1980 I was an undergrad at Kansas State University. I was majoring in electrical engineering because I was bright and all my teachers in high school said I should be an engineer. As a kid in junior high, I was fascinated by lasers. I even built a very low functioning model laser in 7th grade for a science project, so I figured being an engineer was a step toward my dream job to work for Bell Labs doing laser physics research.

One of the required classes for my engineering degree was a programming class in Fortran. I was in a heavily accelerated program for honor students, and had to get special permission from the dean to take 23 credit hours in order to fit all my classes in. Needless to say, I was a very busy student. It was a wonderful time of learning and discovery, and it hardly seems like 35 years ago now.

I was doing great in all my classes except Fortran. I was really struggling with programming, and was only barely hanging on to a C in the class coming up on the midterm, despite having As in all my other classes. Structuring my thoughts into algorithms was just escaping me. I could handle the learning part - the science - but the art of it was the problem: the creative aspect of programming that requires inventing solutions to programming problems.

About a week before the midterm, I awoke suddenly in the middle of the night, and everything about programming that I had been struggling to fully comprehend made sense to me. It wasn't a dream that did it, or at least I didn't remember any dream. My subconscious was just working away in the background and finally had a breakthrough. It was a surreal experience, and I've been that way ever since as well. If a programming problem has me stumped, I just have to go to sleep (or to the bathroom, a future story!) to figure it out. I got up and finished my Fortran project due by the midterm, and aced the midterm exam. The feeling was unforgettable - like I had just discovered what I was born to do. I changed my major soon after that to computer science, and never looked back - though I never did make it to Bell Labs.

Memoir of a Coder

I just finished reading the entirety of Andy Hertzfeld's for the second time, and it really brings back memories spread over my 35 years as a coder. This series of blog posts will serve as my personal tribute to the spirit of Andy's work to preserve the history of the development of the Macintosh, by telling my own stories of life as a coder from the days of punch cards through today.