Good First Draft

During the early eighties, I attended engineering school at Worcester Polytechnic Institute. WPI had a different approach to education. Instead of handing out cookie cutter degrees, the entire program revolved around teaching students how to learn. Even the grading system reflected this attitude, instead of getting the usual A, B, C, D letter grades, grading worked as follows -- AD, means acceptable with distinction; AC, means acceptable; and NR, means no record, as in no record of you taking the class. That's it. You either failed, passed, or passed really well.

For all practical purposes there were no required classes. Sure, individual classes had prerequisites, but you were pretty free to pick whatever classes appealed to you. You also had to take classes that would prepare you for working on your degree requirements. And you had to accumulate a certain number of credit hours.

Most schools stopped there -- grades and credit hours. WPI went beyond this with their degree requirements. To get a degree you had to complete the following projects -- humanities sufficiency, interactive qualifying project (IQP), and major qualifying project (MQP). You also had to pass a compentency examination in your major. When I started it was possible to get your bachelor's degree in three years, since the credit hour requirement was fairly low. By the time I graduated things had tightened up a bit and it would then take about 3 1/2 years.

The humanities sufficiency project was typically completed during your sophomore year. This degree requirement specified that you complete 5 courses and write a thesis in your chosen area -- literature, history, sociology, etc. I chose English literature. In particular, I studied the writings of SF writer Ursula K. LeGuin and how many of her stories shared the common theme of dualism.

The IQP was typically completed during your junior year. The intent of this project was to research the impact of science on society or vice versa. It was a year long project. Most IQP's resulted in a major thesis being written. I worked with a partner and we researched the study of the future, or how people predict the future of technology and it's impact on society. I tackled the science fiction angle, and my partner handled the futurism angle. Our type of project required a great deal of reading and research. All IQP's are assigned a professor who acts as your project advisor. You had to meet with your advisor regularly and give status updates. Once we reached the last quarter, we started work on our thesis. It took several weeks to complete the paper, it ended up 80+ pages in length. We actually completed the paper about 3 days ahead of our deadline. So we turned in a copy to our advisor and planned to meet him the next day. Thoughts of relaxing for the rest of the school year filled our heads on our way to meet with our advisor. Imagine our suprise when his first comment was "this is a good first draft". He went on to say that our conclusion was weak and we needed to beef up our examples to better support our conclusions. So instead of relaxing, we spent the next 48 hours, mostly sleepless, feverishly working on revising and rewriting our thesis. We turned in a revised copy to our advisor and met with him later that day. It turned that our original draft would have been acceptable and we would have gotten an AC as the grade. But he wanted us to go for the AD, which we did end up getting.

The MQP was typically completed during your senior year. Depending on your engineering major, this project often involved designing and then building something. Since I was an electrical engineering major specializing in computer design, I chose to design a microprocessor controlled smart printer buffer. Back in the early eighties, computer printers were mainly of the dot matrix type and hence quite slow. Whenever you printed something, the computer would have to wait until your printout completed before being able to do anything else. My project was to build a device which when connected to a computer would pretend to be a printer and accept the data to be printed and store it in a temporary memory. This process was expected to be much faster and would free up the computer to go onto more useful work. After receiving the data, the device would then communicate with the attached printer and forward the data producing the desired printout. And since the device stored the data in memory, you could get a second copy of your printout just by pressing a button on the device. Overall the design process went well and the construction of the prototype device went pretty well also. But when I tried debugging the prototype things stalled pretty quickly. I couldn't get the processor to come out of reset and actually execute any instructions. I spent weeks trying to solve the problem. Eventually I had to write up my project as a thesis, my only hope was to document everything and try to explain what I would do next assuming that I had more time. I turned in my thesis and met with my advisor, he said he liked my design and agreed with my conclusions, and gave me an AD straight away.

The final degree requirement was the compentency exam. My senior year the had changed the format of the exam and now it consisted of two 3 hour exams and a half hour meeting with your examination board. The first 3 hour exam covered the basics of your major, the second 3 hours covered your specialty area. My specialty area was computer design. Both exams were completely open book and open notes. Most people brought along a milk crate full of stuff. Personally I brought in several cheat sheets that I had prepared ahead of time and a couple of carefully selected textbooks. I seem to remember looking at a single cheat sheet once or twice during each exam. The reality was that if you had to look things up, you really weren't prepared and would never actually complete the exams on time. My meeting with the examination board was interesting. They asked me several questions that led into a major one involving the effect in transistor based amplifiers that limits the bandwidth performance of the amplifier, known as Miller Capacitance. I nailed it, and have never forgotten how to explain this effect.

Overall my experience at WPI was excellent and has served me quite well in my career, first as a hardware engineer, and now as an embedded software engineer. I truly did learn how to learn and am still learning new things all the time.

Punch Card Hell

I attended college (engineering school) during the early 80's and got to experience first hand the transformation of computing from mainframes to early personal computers. I took my first programming class during my Freshman year. It was Fortran. At this time (1981-82) you had to type in your program onto punch cards.

For those who aren't familiar with these "wonderful" items, punch cards were manila stock cards about 4 inches tall and 8 inches wide. Each card had a series of columns of numbers on them, I don't recall how many. These numbers were used to encode a single letter, number, or other symbol from a keyboard. The encoding for a single character was "punched" into the column of numbers by the keyboard on the card punch device. So to enter a line of your program, you placed a blank card onto the card punch device and typed in the line of characters. When complete, you removed the punched card, and placed a new blank one on the card punch and entered the next line from your program.

So if your program had say 100 lines of Fortran statements, you ended up with a deck of 100 punched cards. To execute or run your program, you handed in your deck of cards to the computer system operator and he would load it up onto the machine when it was your turn to run your program. Once the machine processed your program (i.e. read each card, compiled the program, executed the program, and returned results), you got back your program deck and a printout of the program's results. If everything ran perfectly (assuming no typos in your program), you would get your expected results on the printout based on whatever you had asked the computer to do/calculate/etc. But it hardly ever went perfectly. You would often get compilation errors (typos again), or logic errors, or who knows.

To edit your program, you removed the "bad" line of code by removing that particular punch card and retyped a corrected one on the card punch device, re-insert the new card in place of the "bad" one, and submitted your program to run again. This process often took a long time for each edit / execute cycle. You could easily spend hours debugging a single program and still have to come back to repeat the exercise over several days. God help you if you dropped your deck of cards and had to re-assemble the program back into the correct order. At various times the computer room floor would be so littered with "bad" cards that you could not see the color of the carpet. At the end of the semester, students often created "snow storms" by throwing their card decks into the air as they exited the computer facility and headed back to their dorm rooms.

Luckily the Fortran classes were the last time I had to use punch cards for anything. Later on I took an Assembly Language class that used terminals connected to a Dec-20 mainframe computer. You still had to collect your printouts from a system operator, but at least you could edit and debug your program on the terminal itself. At other times, I got to use an Apple II for some database programming, a Digital PDT-11 for documents and other tasks, and the school's Wang Word processing system. During my grad school years, I was happy to see that all the old clunky systems had been replaced by various Unix workstations. Now I realize that I had participated in a part of computing history that most recent engineering students have little to no knowledge of.

Droppin' Quarters

Arcade games. Those two words conjure up very distinct images in people all based on what was hot when they were in their early teen years. For me it was the arcade game "Tempest" and the pinball game "Black Knight". I spent alot of quarters on those two games.

I certainly enjoyed other games, but these two were my favorites. My brother was a wiz at "Asteriods" and "Centipede", but I never quite got the hang of either of them. For me "Tempest" was where it was at. I have since tried to play "Tempest" via the MAME game emulator, but it's just not the same. Without the spinning controller that the original arcade game had, it just doesn't play the same.

One of our greatest Christmas's ever was the year that we got an Atari 2600 VCS. Today's kids are spoiled with the wide availability X-boxes, Playstations, and other consoles. Before the Atari 2600 came out, you either went to an arcade and spent oodles of quarters, or put up with the lame Pong-clone TV games that had come out the year or two before. Imagine, being able to play video games in your own house, on your own TV. Even back then the graphics seemed fairly primitive but it was the game play that truly won people over. Many games were extremely addictive. I was addicted to playing "Missle Command". I once played it for 10 hours straight, rolling the score over a million points, only taking a break to eat dinner while letting my brother play for me.

Hopefully the game designers of today look back at the games of yesteryear and try to understand what made them so fun and addictive to play. Fancy high-tech graphics alone do not guarantee a game's success. It is still all about the game play.

Commodore Computers

My first real experience with a "commercially" available computer was when my Dad bought a VIC-20, I don't recall the exact year but must have been around 1983 or so. It was definitely kind of limited -- only 5K of RAM, no floppy drive, programs loaded from cassettes. But it was a "real" computer. You could write your own programs on it -- in Basic.

About a year later, I got the much improved C-64 for Christmas, and then a floppy drive for my birthday. It was great. It had pretty cool graphics (for the time), ran games from cartridge and from floppy, had about 40K of usuable RAM. I wrote my first text adventure called "Thuria" on it, in Basic. Also I learned how to write assembly code for its 6502 microprocessor. I even took it to college with me during my senior year (there'll be more about college computing in a future post). Later on I got the GEOS software package -- sort of a Mac like GUI interface and Office application suite. Pretty cool, but it ran kind of slow.

A few years ago I started collecting old computers. I actually still have my original C-64 and all the other associated peripherals, software, etc. And have since picked up some of the variant machines including a C-16 and a Plus-4. Still looking for a C-128 and the portable SX-64. Now I have kids of my own and of course they are interested in computers, but it's hard to get them to see these old machines and understand what kind of impact they had on a young mind at the time of their introduction. These days the "PC" is so ubiquitous and so ultra-capable that it's hard to realize that things weren't always so. I guess the ready access to such things as the WWW, Internet gaming, chat, etc., will have its own impact on the young minds of today. We will see...

When I Was Ten....

When I was about ten years old (circa 1974), my father bought his first computer, an RCA Cosmac Elf. It was a kit that you had to build yourself. It came with printed circuit boards, all the chips, wires, and so on. It used an 8-bit processor that amazingly didn't come from Intel. The system actually predated IBM type PCs by several years.

To use it you had to enter (by hand of course, there wasn't even a cassette tape interface for storage) the program as a series of hexadecimal codes (technically machine language). The system's keyboard was only a numeric keypad and the display was a set of four seven-segment LEDs. After a couple of years, my father obtained a normal keyboard, installed a BASIC interpreter, and built a video controller for a text display monitor (from a kit of course).

A couple of years later, I wrote my own version of the Space Invaders game, written mostly in BASIC but had some portions written in machine language (to speed up the keyboard control). So I guess I've been a software geek since I was in the sixth grade.

The Adventure Begins

Hi. I'm a geek. Or rather I should say that I am many geeks rolled into one. At various times I have been known to be a software geek, a computer geek, an electronics geek, a science fiction geek, a comics geek, an H.P. Lovecraft geek, a creative writing geek, a genealogy geek, a Star Trek geek, a role playing geek, a toy collector geek, a computer gamer geek, and even a motorhead geek.

This is a collection of essays and reminiscences about my experiences with geekdom in all its many forms. Some of these pieces will be historical in nature, stemming from a one time desire to write a book about my development as a software engineer. Other pieces will simply be my review of a book, movie, game, etc.

Most of these were written for my own enjoyment, possibly for the benefit of my two sons when they are older. Hopefully, others may find these pieces entertaining.