Wednesday, July 13, 2016

Ziff Davis Interactive, Liberty BASIC, and Bill Gates

Robert Gerami, a close friend of mine worked for Ziff Davis (the owner of PC Magazine) in Cambridge, Massachusetts.  He was in charge of their free downloadable utilities.  They were particularly well known for their whimsical screensavers, including one where a cartoon of Bill Gates would smash your Windows 3 desktop to reveal a shiny new Windows 95 desktop which would then be eaten by bugs before your eyes.

Robert liked what he saw in Liberty BASIC and decided to offer me a chance to have it featured on their web site as a special edition.  But, before he was willing to do this he want it to support making API calls.

The best part of this arrangement was that Ziff Davis would pay me to do the development, and that the resulting work would still be owned by me.

This is one of the important features of what became Liberty BASIC v2.0.  This was promoted by Ziff Davis Interactive on their website for several years.

Thursday, January 21, 2016

DOOM and the raiders of the lost hours

My first PC compatible computer ran DOS and Windows, and OS/2 and... DOOM.

In between rounds of development work on Liberty BASIC I would take breaks playing DOOM.  By today's standards this is a crude looking game, but back then it was really groundbreaking.  Playing it in a dark room was a good way to scare yourself half to death.  Today I would surely consider it rather tame.  The only thing that really compared to it was a game called Ultima Underworld which was actually a smoother and more detailed real-time 3D game.

In the world of PC gaming it really was all DOS.  Running Windows or OS/2 sucked up too many resources from what was typically a 33MHz 80486 computer.  The game would not play well.  Even when running DOS you needed to use HIMEM and play all the tricks in the book for there to be enough memory.

Other games that wasted my time included Falcon 3.0 which is probably the perfect air combat simulator and a cool game called Theatre of War which was sort of a real time version of Chess, kinda.

Friday, January 15, 2016

When a bad sector error is not a drive problem

When I was working on my book for NRI Schools I was having a lot of bad sector errors and cross linked sector errors on my computer.  Stuff like that.  Every day.

I even continued to get these after I upgraded my hard drive so I began to smell a rat.  My 32MB of RAM tested good so it wasn't that.  If the processor cache RAM was bad this should also cause the main RAM test to fail, unless the algorithm for the memory test is too naive.  I decided to replace the cache RAM chips on my motherboard anyways.  I think this was 128K of chips in eight sockets on my motherboard.  I don't remember how much this was, but I don't think it was very expensive.

I'm sure I got the RAM chips from Metrowest Computers in Framingham, Massachusetts because that's where I bought the computer from.  I tore the machine down.  I was very careful not to static out anything.  Inserting those little DIP chips with their little legs requires some care or they get bent!

Got it all back together and crossed my fingers as I booted it up successfully.  :-)

I never got another sector error.  Mission accomplished.

Thursday, January 14, 2016

Murphy's Law of book publishing

Once the book was all proofed and the camera ready art produced, and once I had the color separation for the cover all produced I was ready to order the first run of books which was approximately 1000 copies.

NRI Schools sent me a check in advance for these books.  How can you beat that?  So I sent everything off to Whitehall Publishing and waited nervously.

A couple of weeks later several heavy boxes arrived.  So exciting!

I cracked open one of the boxes and grabbed one of the fresh books.  What a neat thing to hold the result of so much work in my hands.  This really looked just like a book that you would buy at the store.

And then... I opened the book to the first page and my heart sank.  The very page had a spelling mistake.  I misspelled the word congratulations.  :-/

It read Congradulations.   What?  How could I miss that?

Ah well, it was still a great day!  :-)

Sunday, January 10, 2016

Liberty BASIC book preproduction

In addition to actually writing the Liberty BASIC book which involved developing the tutorial examples and explaining them, creating a quiz for each chapter, developing and proofreading each chapter, etc. There was the matter of producing camera ready pages.  They needed to be a certain size and they wanted crop marks on the pages.

NRI Schools also wanted a full color color, which I really didn't know how to create.  A friend of mine named Robert Gerami actually helped me with the graphic, and he even added a funny cartoon to the back of the book.  The cartoon was of a building with a sign saying "Programming School" and there was a hot dog stand outside the building.  A character with a fishing rod up on the second floor was trying to snatch a hot dog from the vendor's stand with his fish hook!  It was a humorous way to polish off the book's cover design.

There was a local company that created the acetate color separations for the cover, and all this went off to a company called Whitehall Publishing.  They charged me approximately $6 for each copy of the book when ordered in 1,000 or more.

All I needed to do now was write the check and wait...

Friday, January 8, 2016

Writing a book was more than I bargained for

I really had no idea how much work this was going to be.  I had good starting material with the Liberty BASIC tutorial, which had actually been fashioned into a spiral bound book which I produced at the local Staples store, but this had to be more polished.

I had no serious word processing software.  This meant that I needed to use the Write application that came with Microsoft Windows.  The only strengths that this provided was that it was essentially free, it was easy to understand and didn't burden me with any strange gotchas that full blown word processors often do, and it allowed page footers.

This was hard work.  The process was to produce a draft of a chapter, print it out and then I would lay down on the carpet with a pencil and read it, marking it up as I went.  Then I would go back and enter in all my changes and repeat the process several times until that chapter seemed good enough for the book.

This took weeks.  By the time I was done, I was determined to never, ever do it again.  Of course this didn't end up being my last book.  :-/

Thursday, January 7, 2016

NRI Schools and my first book

About this time I received a phone call from someone at NRI Schools, McGraw-Hill Continuing Education Center which was a popular adult education company.  They told me that they were developing a new computer programming course and they wanted to base it on Liberty BASIC.  Wow!

Here's what they wanted to do.  They would write their own course, which would be a staple bound series of books that they would distribute to their students.  They also wanted an actual official Liberty BASIC manual from me for which they would prepay me.

This was to be a perfect bound book with a full color cover.  I had never done such a thing before, so I had a lot to learn.  It was very helpful that they were willing to prepay for the first 1000 copies of the book because otherwise I was not going to be able to bankroll this project.

I decided that the book would be based on the tutorial that came with Liberty BASIC.

This was going to be a lot of work, but it was very exciting!

Sunday, January 3, 2016

Bugs Bunny and Raytheon

When we were well along in our project for the Defense Nuclear Agency, a couple of developers from our team were chosen to go to Albuquerque, New Mexico to field test the system.  Part of the system was designed to help provide security by means of motion detection in the desert.

To make this happen we needed to build a custom computer that ran OS/2..  This PC included hardware which could interface with motion detection cameras in order to log motion detection events which included video frames showing what the motion was.  So we were all excited to know that our system was going to take pictures of tumbleweeds and Bugs Bunny in the desert wasteland.  ;-)

Most of the assembly of this custom hardware was done at the Wyman Street, Waltham IBM office where we worked, but Raytheon in Burlington, Mass was responsible for the final integration and shipment to the test grounds in Albuquerque.

So, off to Burlington we went with server in tow.  When you visit Raytheon you have to go in the front door and sign in, and you have to have an appointment with someone who will meet you at the door.  So one of my colleagues and I followed this procedure and found one of our other teammates working on the machine, trying to get OS/2 to start up and load all the drivers properly, but he was having some trouble.

Then a couple other members of our team showed up, but they were unescorted.  So they were asked how they got into the building.  They said rather innocently that they parked in back and as they approached the back door someone came out.  That person held the door for them and they got in without signing in at the front desk!  Uh, oh!  Who was it that let them in?  They didn't know this person, and presumably he went for a walk for took off in his car, so it wasn't going to be easy to figure this out.  They didn't know they were breaking security protocol.  Okay so they went to sign in.

Now we turned out attention to the server again.  We were trying to figure out how to get all the drivers working and we were having some trouble.  This fellow with a clipboard came to us and said that he needed to pack up the computer and put it on the truck to ship it to Albuquerque.  We told him that it wasn't ready, and he walked off.  Some time later he came back again and we told him it still wasn't ready.  Finally he returned and said, "Okay let's ship this thing.  I've got to check this off my list!"  We game him a sharp look and told him firmly "Look buddy, this machine isn't going anywhere until it works.  We will tell you when it's ready."  He did not like this at all, but we really couldn't have cared less.

I guess he thought a non-working computer was good enough for government work.


Friday, January 1, 2016

How to make a RAID array failsafe

The computer that we used to manage the source code for our Defense Nuclear Agency prototype was an IBM System 95 server.  One of the nice features of this system was a three hard drive RAID array.  The special property of this system was that if one of the drives failed, the contents of that drive are recomputed on the fly based on the other two good hard drives.  The drives were hot-swappable, so it was possible to eject the bad drive and replace it with a new one while the system was running.  That drive would then be formatted and it contents rebuilt from the other two drives while the system was in use.  Very cool technology!

One day we decided to reboot the server.  When we did the OS/2 operating system produced an error message on startup saying that one of the drives in the RAID array had failed.  We were shocked.  We should have received an indication of this when the drive actually failed.

So what happened?  These special hot swappable hard drives have an error light that turns on, and also a piezo buzzer that sounds when the drive fails.  The trouble is that the drive failed so completely that the piezo buzzer also failed.  We never heard the audible error sound that we were supposed to hear.  This was a vulnerable moment for us.  If one more of the hard drives were to suffer failure we would have lost work.  We did back up our code periodically to an external cartridge, but it had not been done for weeks.

So clearly IBM had some work to do perfecting their RAID products.  For example, if the piezo buzzers on the other hard disks were designed to sound when any of the other drives failed, this might have proven much more effective.

Thursday, December 31, 2015

Liberty BASIC at IBM!

While working on our prototype for the Defense Nuclear Agency I discovered that we needed to reset some files repeatedly whenever we tested and demonstrated the functionality of our system.

I was eager to put Liberty BASIC to good use, and since we were running on OS/2 this gave me an opportunity to create a utility that would make things easy.  Liberty BASIC to the rescue!

It was actually easier to create this utility in BASIC than it would have been in Smalltalk.  Smalltalk is very powerful and really is one of the best languages, but BASIC is stronger for banging out small and simple programs.

I took great pride that when were were demonstrating our system to the customer that they also got a demo of Liberty BASIC in action!

The IBM dress code

Our contracting work at IBM in Waltham was back when IBM had a particular dress code.  All the men had to dress like the agents in the Matrix (without sunglasses).  All the women also needed to wear a lady's business suit.

However since we were not employees we could wear whatever we liked.  The fun part of that is that we got to wear IBM badges which gave access in and out of the building, to the cafeteria, etc.  I got the biggest kick out of this because the IBM employees gave us the strangest looks.  They clearly could not figure out who we were and why we were permitted to dress in casual attire.

Wednesday, December 30, 2015

IBM Smalltalk and team development

One really great thing about getting the job at Gem Consulting was that we were developing in IBM Smalltalk for OS/2, on IBM computers at IBM.  So we had access to quality support.

My experience using Smalltalk up to this point was using Smalltalk/V which was a popular and very good Smalltalk product.  The IBM Smalltalk was fancier and included GUI drawing tools and source code management, and working with a team of developers (there were four of us) gave me important experience that I never had before.  I learned so much by developing software with others and it taught me to break software down into modules even more effectively than I ever had.

The working space was an audio visual presentation room with an LCD projector that dropped down from the ceiling.  Around the outside of the room were tables where we worked.  We were able to communicate effortlessly because we were in the same space, and when we needed to design or make plans we would all turn our chairs around and use tables in the middle of the room.

Our development of this project went swiftly and smoothly.  I really enjoyed this style of work.

Tuesday, December 29, 2015

Onward and upward!

In my time at CFC Incorporated I had several interviews for work in Smalltalk.  One of them was in Cambridge, Massachusetts.  They focused a lot on Unix in the interview, or at least that's the way I remember it.  I never got a call back from them.

Another interview was with a company in Waltham called Marble Associates where my friend Laird Popkin worked.  This job seemed fantastic, and the interview was going great.  But when they told me that it was a traveling job which required that I fly to the client every Monday through Thursday I regretfully declined because I was unwilling to be away from my wife and children and also my church community in that fashion.

One day in 1995 I was contacted by one Peter Statterman, and he told me that his company GEM Consulting was looking for an experienced Smalltalk developer for a joint IBM and Raytheon project for the Defense Nuclear Agency of the US military.

We met at a coffee shop in Natick, Massachusetts and he interviewed me.  I must have said something right because he hired me!  It was exciting to be working on a project for IBM on the OS/2 operating system platform.  I was already working on Liberty BASIC for OS/2 and so this gave me the experience I needed to jump right into the project.

GEM Consulting hired me as a subcontractor.  The money was really good, but it was only a three month contract to create a prototype.  If that went well they would extend that to another six month phase.

My intention was to focus on Liberty BASIC when the contract ended and try to launch a full time business.

This was the start of a new chapter in my software development career!

Tuesday, March 13, 2012

I do own a leather jacket!

Sometimes when a computer breaks the cure can be surprising. We purchased a very expensive software solution for one our engineering tasks. It came with an HP Unix workstation. I never really used this machine. It was a single task appliance and I'm not even sure precisely what it was for. One day however it refused to boot, and I guess we must have stopped paying for support because they called me over to have a look.

Turning the machine on yielded the usual power supply fan noise and nothing else. None of the expected hard drive spinning or seeking was heard. This could be a bad power supply, or it could be a failed hard drive controller, or it could be... sticktion! That is pronounced stick-shun. Yes, really. Look it up. This happens on some hard drives when the hard drive sits powered down for hours or days, and the mirror smooth surface of the hard disk platters get stuck to the magnetic heads which have come to rest on the surface. The coating is just soft enough to stick.

The only way to find out if the problem is sticktion is to open the machine and bang on the hard drive casing to see if the heads can be freed. An ideal tool for this is the plastic handle of a screwdriver.

We opened the computer and I rapped on the hard drive a few times with the butt end of a screwdriver. We turned on the computer and waited... success! I felt just like the Fonz! :-)

Monday, March 14, 2011

Power BASIC and the Uncrashable Kingdom

I had it in mind to use Power BASIC as the compiler to implement the new DOS file server for the factory. This was a new, slicker and rebranded version of Turbo BASIC which I had been using for a while. It wasn't cheap. Power BASIC was a nicely polished compiler and had good documentation. I think we paid $300 or so for it.

I wanted to create a nice UI for the file server so I purchased a windowing library for Power BASIC. It made it easy to create text mode windows using graphics characters. The way it worked was very similar to the way that a Windows programmer would do it in C. You called functions which created windows, buttons, etc. These would return a numeric handle.

Your program would intercept messages from the UI library in an event loop and act on them. Each message would include the handle for the window or widget it was about, and also a value for an action such as a click or a key press. This is not an easy way to write windowing code, but the file server would have a simple enough UI. The end result looked nice and was functional.

I learned a lot on this project. This must have been the highest quality BASIC code I had written to this point. It was a multitasking file server using state machine techniques. Unlike its Xenix based predecessor, this file server never crashed once we had it up and running. Never.

Saturday, March 12, 2011

Hacking a file server

No, I'm not talking about hacking an Internet file server. At CFC, Inc. we kept the CNC drilling and routing programs on a file server running Xenix which was a Microsoft branded version of Unix. The CNC machines were plugged directly into this file server using RS-232 ports. Until we purchased this server we had been keeping all our programs on punched paper tape and stored on shelves but now we could keep all this stored electronically.

Okay, this new way of doing things would have been great except that the file server cost lots of money and it wasn't reliable. Every so many weeks or months the computer would crash for one reason or another. When this happened it would run fsck on bootup. This would sometimes find some file system records to repair because the machine didn't have a chance to write everything to disk when it crashed. The end result? We would sometimes lose files from the file server. Bad, bad and worse because all our backups were on tape and we had really bad luck restoring from tape.

We didn't want to spend any more money on this file server. I wanted to develop a replacement in house. It would run on DOS which didn't have the bad habit of delaying writes to the file system. Not bulletproof, but bullet resistant and cheap. But, I had a problem. The only documentation I had which explained the communication protocol for the file server was very thin and hard to understand. I was stuck.

Remember the RS-232 monitor that I grabbed at the GTE auction? I knew right away how useful it would be for this project! Back at the factory I installed this monitor between one of the CNC machines and the Xenix file server. With the ability to see data moving back and forth I was able to figure out how the file server worked. It was tricky because data was actually delivered in packets. There was a non-trivial conversation that happened between these machines but it looked like the code for this was going to be fun to write!

I was ready to get started!

Tuesday, March 1, 2011

An Auction, an RS-232 monitor and an Apple Lisa

My father called and told me that GTE was auctioning off old equipment. Me and my friend Ray took a break from work in the middle of the day to see if there was anything useful we could use at the factory. There was.

A piece of equipment about the size of a small benchtop oscilloscope caught our attention. It had a 5 inch CRT display, a flat panel keyboard on the front next to the screen and a ribbon cable with a pass-through 25-pin D connector. It was an RS-232 monitor! When I realized what it was I had to have it for a project at work. The idea is that you place this device between devices and it allows you to spy on data that goes back and forth over the serial line. It displayed data in both directions, and you could see it as text or hexadecimal. The price? If I remember correctly I paid $35 for it. Amazing!

I also managed to buy an Apple Lisa computer for $25, but it didn't come with a keyboard. Luckily I noticed the keyboard on a palette of keyboards. I talked to the fellow who won that palette and convinced him that the Lisa keyboard wasn't valuable to him without the computer, and he let me have it.

This was a huge win. I still have the Lisa computer.

Thursday, February 24, 2011

Poor Big Bird

No, this isn't a Sesame Street reference! ;-)

One day at CFC the power went out, sort of. Some of the offices had power and some didn't. Maybe a circuit breaker tripped? No, that wasn't it. Like most factories we had 3 phase power. Some parts of the building ran off one phase, and some another. One of the phases went out. This was no big deal for office equipment, but on the factory floor some of the motorized equipment required all 3 phases. If a phase dropped out while a motor was running, it could stall and even burn out. Some of the motors did burn out. Even worse, there was a reflow machine with a steel wire conveyor which ran fiberglass circuitboards through an oven to melt the solder plating to give it a nice shiny finish. The conveyor stopped moving, and the boards caught on fire and filling the factory with a nasty odor. Burning epoxy smells really, really bad.

It took a while to get all this repaired.

Outside on the curb was the cause of all this trouble. A very large bird (maybe a stork?) had decided to take a break. It chose a very dangerous place to sit and met an untimely demise. Up on the utility pole there was a large power transformer which had exploded, and on top of that? A large bird, burnt into a very black cinder, the recipient of that day's Darwin Award!

Friday, April 23, 2010

The Expensive Break Clock

One of our Tandy Model 100 computers had become relegated to controlling the buzzer for indicating shift changes, breaks and lunch. We used the signal for controlling the cassette interface to turn the buzzer on and off. A twenty line BASIC program was used to check the time against a schedule that was hard coded into the program.

Invariably for one reason or another this computer would forget the program. Either Bob or I would then run over and type the program in from memory, set the clock and get it running again. I cannot even count the number of times I did this while I worked there, but it was really no big deal because after a few times it only took a minute.

So here was have this computer which was originally purchased for more than $1000 and we were using it to blow a whistle 8 times a day. Nowaways this would be completely appropriate because you can buy a computer on a chip with all the power of the Model 100 for about $30.

Wednesday, April 21, 2010

101 Stupid LaserJet Tricks

When I was moved into my new office downstairs, it was located in a space behind what used to be the reception area of the building. The front door was locked from the inside, and visitors would enter a door slightly off to the side and climb stairs to a new reception area.

When anyone visiting would come back down those stairs they would sometimes forget that they came through the side door. Instead they would go out the original glass door, which was an inner door and an outer door. The first door had a lever you pushed to unlatch and open the door. This was locked so that if you passed through this door you couldn't come back in. Once through this door there was another door right there. This had a locked bolt, but you could just unlock the bolt and get out, and invariably this is what people did.

Then I had this idea for a prank. Using the LaserJet printer I printed in great big letters READ THIS. Then below in a tiny 4 point font I printed "If you can read this then you are trapped!" I drew an arrow from the large words to the tiny words by hand. I hung this on the wall between the two glass doors.

Weeks later I was in my office working and I heard some banging and the sound of someone calling out. I went out to find out what was going on. Shock and amazement overcame me when I saw this fellow between the glass doors, banging with his fist and calling for help! He had read the sign and believed it! I laughed and opened the inner door for him and explained that he really wasn't trapped at all. So I showed him how to unlock the bolted outer door. Unfortunately he didn't think this was funny at all. He didn't smile or laugh but he just left without saying a word. Perhaps he was humiliated that he had fallen for the trap?

I was very pleased to see that someone had read the sign and believed it. This was absolutely priceless. Looking back at this prank I should count myself lucky that I didn't get in trouble.

Our First Laser Printer

We decided to purchase a laser printer so we could print bill of materials sheets for each job. I managed to find a used HP LaserJet cheap. This was the original LaserJet printer model and had only 128K of RAM. This was fine, except if you wanted to print graphics. You could not even draw a half page of black and white graphics with 128K. This also meant that there was very little room to load fonts into the printer. The saving grace was that there was a font cartridge slot. I bought one of those super font cartridges that had lots of fonts. It turns out that we really only needed one font. I don't remember which one we used, but it was a small monospaced font.

The printer had a serial port, not a Centronics printer port. Normally this would have been considered a limitation, but this was perfect for our shop floor control system which I was building around Arnet multiport RS-232 cards.

I needed to learn just a little bit of Hewlett Packard's PCL (printer control language) to make the LaserJet do its thing. I wrote some code in Smalltalk to drive the printer. Depending on how complex the board design was, these bills of materials sometimes had a lot of information on them. It was somehow very satisfying to produce software that would drive a printer elsewhere in the building. I had never done that before.

The printer was located up in the engineering department, and after they designed a circuitboard for an order they would fill in some fields into the shop floor control system and print out the bill of materials on the LaserJet.

Friday, April 16, 2010

Little Guatemala

Most of the employees at C.F.C. were from below the Texas border. I don't remember ever there being anyone from Mexico, but there probably was. There were people from Nicaragua, El Salvador, Costa Rica, Brazil, Chile, Peru, Ecuador and the Carribean islands like Puerto Rico, the Dominican Republic and Haiti. You name it. There seemed to be more people from Guatemala than from anywhere else. We liked to joke that we were going to fly the flag of Guatemala over the building and declare C.F.C. a sovereign nation, Little Guatemala.

Monday, April 12, 2010

The Fastest Computer in the World

I invited Bob to my office to show him what I had done with the tracking system idea and I demoed the Smalltalk/V prototype I had written. I showed him what it could do and I explained that we could attach many terminals to it. This went over very well. I told him that in order to do this well we would need a copy of Smalltalk/V 286, which was a more powerful version of Smalltalk/V that could access up to 16MB of RAM. This was $199. We would also need a computer more powerful than anything we had in the factory at that time, and we would need to purchase at least one multiport RS-232 card to get started.

Bob agreed to all this. On top of that he was willing to go all out. The company usually quoted as having the fastest PC clones at that time was Compaq with their DeskPro systems. Bill Machrone from PC Magazine was famous (in my own mind at least) for having said that the DeskPro/20 ran its startup tests so fast that it made him giggle. But the king of the hill at the time I went looking for a speed demon for our shop floor system was made by CompuAdd. In the reviews I read, the CompuAdd 386/25 was a terrific performer for the budget price of only $6100. Then we needed to add 4MB of RAM for about another $2000, and I'm pretty sure the multiport card was about $900. He agreed to buy this equipment. Wow. Just, wow.

My office wasn't the best place for this machine, so they moved me downstairs into a more central location. The office they gave me was spacious with a very large window. This was great except sometimes the window leaked when it rained. Our facilities manager Joe (yes that was his real name) helped me run some serial cables, and I soldered the 25 pin D connectors onto each end. RS-232 is only designed for 50 foot cable lengths. We needed longer runs than 50 foot. I had to source special low capacitance cable so that we could run cables of 100 foot or more. I needed to short across handshaking lines to make them work, and I made a null modem adapter for each one. I found a supplier in Framingham called Marcus Associates where we bought some used ADM-5 terminals, which were much newer and nicer than the ADM-3A I had prototyped the system on.

Before long we had a working system with terminals in different departments, and a printer for reports. I created a simulated terminal window for the computer itself so I could test the system without consuming a valuable serial port in my office.

This was the beginning of what was an exciting and productive project, even with some very challenging hurdles to overcome.

Sunday, April 4, 2010

My Skunk Works Project

What is a skunk works? A definition from Wikipedia: The designation "skunk works", or "skunkworks", is widely used in business, engineering, and technical fields to describe a group within an organization given a high degree of autonomy and unhampered by bureaucracy, tasked with working on advanced or secret projects.

In order to prototype the multiuser shop floor control system, I needed a real video terminal. The idea would be to take a computer and install one or more multiport RS-232 cards and connect terminals to them from all over the building.

The following work was done more or less under the radar. I wasn't trying to get away with anything, but I hoped to surprise Bob with the results I hoped to achieve. I managed to requisition an old Lear Sieglar ADM-3A terminal on the cheap. This was one of those pastel blue terminals with a "space age bubble" look to it. Needham High School had a few of these connected up to their PDP-11.

In order to make this work with Smalltalk/V I needed a tiny machine code routine so I could make calls to the serial port. I was lucky to find someone on a bulletin board who was kind enough to write this for me. I was even luckier that it worked! The machine code file was only 14 bytes long!

It didn't take me very long at all to create a master monitor, a login routine, a simple command parser, a simple job object, departments that could hold jobs, and the ability to move the work from one department to another and list the contents of each department.

What was absolutely most amazing about what Smalltalk/V made possible is that the system was extensible and debuggable... as it ran! If there was a runtime error while executing some command from the terminal, a debugger opened on the computer screen. I could then fix the bug right there, and the terminal could be restarted without bringing the system down for a recompile.

This was very promising to say the least.

Saturday, April 3, 2010

Christmas Vacation

I didn't take the plunge into Smalltalk right away. I wasn't completely sure it was the right choice. I was at the SoftPro store in Burlington in late 1988 and I noticed that they had a copy of the Smalltalk/V software from Digitalk. I asked them if they had any brochures, and they did. Three different full color, double sided marketing sheets. Very nicely done. Everything I saw about the language reminded me of Forth, but it had this idea of objects.

I wasn't about to ask my boss to buy yet another programming tool, so in December I bought it myself. I took the Tandy 1000SX home from work over Christmas vacation and dove into the Smalltalk/V manual, following the tutorial.

I was not disappointed. What an amazing language! I had never used anything so dynamic, or so graphical. Almost all the source code for each and every thing in Smalltalk is there. You can see it and you can modify it if you like. This was very compatible with my observation that Smalltalk and Forth were conceptually similar. The one surprise that really topped off this sundae with a cherry? Smalltalk has built-in multiprocessing. This was the ingredient that I sorely needed to produce the multiuser shop floor control system! What luck!

From Actor to the Real Thing

I decided that I needed more information about the Actor programming language. While at The Bit Bucket one day I asked Laird if he could get me some literature about Actor, figuring the store could place an order for me. He gladly accepted my request.

A few weeks later Laird had the materials in hand and he presented them to me. Then he said something that would completely change everything. He asked me, "Why don't you have a look at Smalltalk?" He told me that Smalltalk was the real deal.

This was not the first time I had heard of Smalltalk. At the New England Mobile Book Fair I had seen a book about it. I ran back to my office and started digging through issues of BYTE until I found an ad for something called Smalltalk/V.

I had seen this sort of ad before, but I just skimmed over it thinking it was a kind of communications program of the sort used with modems. There was at this time a very popular application of this kind named Crosstalk XVI, and this was the source of my confusion.

The ad seemed very interesting. I began to research Smalltalk. I learned that there was an August 1981 issue of BYTE dedicated to exploring Smalltalk. I went to the Boston Public Library and xeroxed all the articles from that issue. It cost me about $40 to do this. So I began to educate myself about Smalltalk.

Friday, April 2, 2010

What's a Popkin?

Well, the question really is "Who is Laird Popkin?" Good question.

In the summer of 1988 I met Laird Popkin when he was working at The Bit Bucket in West Newton. The Bit Bucket was this cool store with cool people and with cool stuff in the windows, like Amiga computers showing ray traced animations with shiny chrome balls and also a PDP-8. Try to find one of those on ebay!

Now, Laird was this nice fellow a couple of years older than me. He gave me my first ever demonstration of Windows 2.1. He showed me how an Atari ST could run Mac software if you ripped the contents of a Mac ROM. He introduced me to bulletin boards and FidoNet, and emoticons! He even invited me to his place in Sudbury (or was it in Weston?) where he shared a house with a bunch of other techies and their Apple II's and a Jaguar motoring enthusiast. He loaned me his copy of The Eudamonic Pie, which is this fascinating book about how some west coast nerds invented a computer in a shoe for beating roulette. Eat your heart out Maxwell Smart! I still have the book. Sorry Laird.

Laird and I had lunch a few times and struck up some great conversations. We talked about computers, science, consciousness and God.

Wherever you are Laird, thank you!

Sunday, March 28, 2010

Welcome to My Research and Development Lab

In search of the perfect next development tool to create our shop floor control system I was now in full blown research and development mode. I would read lots of magazines looking to learn as much as I could. I had a modem and a phone line in my office now too, and I was downloading free programming tools and trying them out.

Bob allowed me to take off and go to the public library so that I could read magazines articles about languages and programming. There were plenty of articles about object oriented extensions to languages like C and Forth. I found all this very interesting, but I had no experience with object oriented programming so I really didn't know what to think.

I saw an ad in a magazine for a language called Actor by the Whitewater Group, and this really caught my attention. The code looked like C, but it was supposed to be object oriented. There was a code snippet in a screenshot in the ad that implemented a very simple drawing program. The code was just a few lines long. The screenshot also showed the simple drawing program and they used it to draw a version of the product logo. The idea was that you could create very sophisticated software with very little code. The only thing was that the software was not cheap, and it required a copy of Microsoft Windows 2.1. We weren't yet running Windows on any computer in our office. This was in the summer of 1988.

One other tool I was interested in was called Matrix Layout. This was a visual flowcharting tool that produced graphical DOS applications. I guess you could call it a kind of HyperCard, which is a Macintosh programming tool for end users. It was only $149 so I obtained a copy for myself. The developer's office was in Boston, so I just drove there one day after work and bought it at the receptionist's desk. I was ultimately quite disappointed by this product. I tried to prototype a version of the video rental application I wrote in BASIC, but it was too much effort for the result. Once you've used a real programming language, these visual tools for non-programmers feel very limited. Clarion is really a lot better because it has a real programming language you can use to script extensions beyond the visual layout tools. Matrix Layout did not provide any way to write scripts. A simple BASIC interpreter would have done great things for this tool.

Then there was Ashton Tate's Framework. This was a fascinating programming system where modules of your application are in a frame, which can hold more frames, and these can hold yet more frames, etc. It had a scripting language called FRED which was based on a Lisp, a very powerful language. Framework was an integrated office suite, and it was extensible using the frame concept and the the scripting language. I never actually got to try it out, but I'm not sure it would have been suitable for the shop floor control system I wanted to develop anyways.

If Bob was beginning to wonder about whether I was ever going to produce anything for all the time and money spent, I never knew it. He was very patient. I did manage to stay busy with smaller projects. He had lots of ideas to enhance the applications I had already written, and he would come to me and we would talk about what he would like.

Tuesday, March 23, 2010

Thinking Forth

After my disappointing experience with Wendin DOS and C I decided that I needed a more expressive programming language. I started to dabble in different languages, and I would write toy shop floor control systems to see how the code would come together. My work was exploratory in the sense that I wasn't in a big hurry to produce a result. I felt that I didn't know which course to take. In particular, I didn't know how to code a solution to overcome the hurdle of multitasking.

For example I experimented with a 4GL called Clarion. Bob was willing to spend several hundred dollars on this based on some stellar reviews that it received in magazines. Clarion really was great, but it was oriented primarily as a development tool for forms based database apps, and it had a nice reports engine. It did also include a compiler for BASIC-like language, but this was a short lived experiment. I do seem to remember creating a custom app for accounting with Clarion so we did get some value for the money.

So after this my mind turned back to the Forth programming language. I had already some experience with it, and I was excited to see if I could use it to create a multiuser shop floor system.

I found a version of Forth called Fifth, which included a simple IDE for MS-DOS. I also played with a couple of other Forth implementations.

So I went looking and bought a book titled Thinking Forth by Leo Brodie, the same author of the wonderful Starting Forth book I encountered a few years earlier. This was the most inspiring book about programming I had read yet. I enjoyed Leo's explanations about how software needs to be written abstractly, that code should be as small and simple as possible, about the importance of choosing the best words for procedures and variables, and also how to write well factored code and what that really means. The book also has great interviews with experienced Forth programmers and many funny and illustrative cartoons. Great stuff. Now, where did I put my copy?

Monday, March 22, 2010

Books I didn't buy

Before there were big book stores like Borders or Barnes & Noble there was The New England Mobile book fair in Newton. This could hardly be considered walking distance from my home growing up in Needham, but I had made the trip on foot a couple of times as a kid with my brother Ernie. Now I made the trip more frequently since I had a car.

This store was really just a big warehouse, poorly lit, and not very well organized. However this was the largest collection of books for sale to be had for miles.

I remember clearly two books that I browsed there that I didn't buy but which left an impression on me.

One was called A Small C Compiler, by James Hendrix. Not the famous musician, of course. ;-) I read just enough of the book to appreciate its biggest idea. Once you write enough of a C compiler in assembly language, you can use that C compiler to write itself! Like I said I didn't buy the book, but I learned important ideas from just browsing through it.

Another book was call Smalltalk-80: The Language and Its Implementation. This was a tan and blue hardcover. I can't say I really understood at that time what I was looking at, but it was interesting enough that I didn't forget it. In more recent years I did find a copy of it used and now am a proud owner. Smalltalk is a terrific language this book explains in wonderful detail how it works. Nowadays the entire contents of this book can be read for free online.

Friday, March 19, 2010

Moving to Belmont

About this time I moved to Belmont with my brother Paul and his little daughter Christina, and also a friend of ours from our church named Stuart Harrington. Belmont is a very nice little town between next to Waltham where I worked, so I had a 15 minute commute. What a great place to live. Drive 15 minutes one way and you're in Boston. Drive the other direction and you're in Lincoln. I really enjoyed that.

Eventually Stuart got married and moved out and we were joined by another friend from church named Paul Ward. Paul was a sonar operator in a fast attack sub when he served in the Navy. He told interesting stories. We decided to share a room. We bought a steel tubular framed bunk cot. I would get up early in the morning and help him deliver newpapers in Lexington. I had inherited one of the Osborne 1 computers from work which Paul and I would spend some time tinkering with and banging out simple BASIC programs. My memory is a bit foggy, but I seem to remember giving the computer to Paul.

I thought I might be able to purchase a new computer for myself now that I had a regular paying job. I was interested in practicing my C programming and Radio Shack had a nice little portable called the Tandy Model 600. I read somewhere that CP/M and a C compiler could be had for this little machine and I thought this would be a very neat computer to own. When they were getting ready to discontinue this model the price dropped well below a thousand dollars. However I wasn't very good at saving money.

I never did purchase a Model 600. Just as well because I think I would have outgrown it very quickly.

Thursday, March 18, 2010

Mousing Around

Since my Tandy 1000SX had high resolution graphics (if you could call monochrome CGA 640x200 high resolution) we thought it made sense to get a mouse and learn to program with it. Then we might be able to write even better software for the engineers to use when setting up each circuitboard for production. We had a crude graphical CNC simulator that ran on the Kaypro machines, so this could be a step forward for us with more detailed graphics and a mouse for a pointing device.

We bought the mouse at Radio Shack. It was a pretty nice little mouse, and it came with its own interface card like most mice did back then. I'm guessing that this mouse was made by the same people who made the the famous Microsoft Mouse. It was very similar. All the mice at that time had a ball for tracking movement, and this one was a metal ball with a rubber coating.

I believe that my first experiments with the mouse were in Turbo BASIC. There were no built in commands for the mouse. I don't remember exactly how the mouse was read either, but I remember there was documentation. Playing around with some code for drawing on the screen with the mouse inspired me to write an experimental character recognizer. I would draw letters on the screen and the program would attempt to convert them to ASCII characters. It really wasn't that hard to do, but prototypes don't have to be practical. It was fun.

The Epson QX-10

Somewhere we had acquired an Epson QX-10. This was a Z80 powered machine running CP/M, but it wasn't originally conceived as such. Epson had written a CP/M compatible operating system called TPM, and they had some lofty ideas about how a computer should interact with people. They chose Forth as the language to deliver their ideas. So there were some applications which were seamlessly integrated together, but this didn't wind up being a successful product.

So instead we treated this machine like it was another Kaypro. Bob asked me to write a program that would optimize the use of the fiberglass panels we made our circuitboards from. The panels were 24 by 36 inches (I think). For some order we might need a panel that was 8 by 10 inches. How should we cut the panel to reduce waste?

So I wrote a program in Microsoft BASIC for the QX-10. The user would enter the desired size of the material, and it would draw a rough image of the panel as it should be cut with instructions something like:

Insert the long way and cut 10 inches for 3 panels 10 by 24 inches.
Take each of those panels and cut 8 inches for 3 panels 8 by 10 inches each.
Total yield 9 panels 8 by 10.
Waste 1 panel 6 by 24 inches.

We used the computer for this purpose for several years. Hopefully the computer paid for itself in this role. :-)

Monday, March 15, 2010

Wendin DOS and C

One of Bob's ideas about improving our shop floor tracking system was to purchase a bunch of very simple wall terminals and control them from a single computer. This was meant to be a very economical solution. Workers in each department would type in the job numbers and quantities and so no one would need to run around collecting data with a bar code wand. I thought this was a great idea, and I figured I could write something like this in C.

To make this work I would need to write a service routine to monitor the serial ports, and the application would need to essentially multitask. I used C structs to manage related bits of information and created routines to read and write data to disk files. The program would present a simple prompt for logging in, specifying a department and entering a job information.

This was all fine, but it was hard to add new functionality to the system, and I was finding it frustrating dealing with memory bugs and pointer related bugs.

I decided that I needed a multiuser system. If I took the multitasking out of my C code then my programs would be simpler. I noticed an ad in a magazine for a multitasking version of DOS called Wendin DOS. This version of DOS was based on a VMS architecture, and it was very inexpensive. I approached Bob and he bought a copy.

On my Tandy 1000SX Wendin DOS was sluggish. I hoped that this wouldn't matter much because if I could create a working system then we could buy a more powerful 80286 computer to run it on. I was able to create multiple sessions and run my C tracking system in them. Each of them ran in its own text window. This was amazing to me!

Now the bad news. Wendin DOS would crash without warning. The whole screen would suddenly clear and display a "guru" error message. Guru error number such and such. This was really weird. What was a guru, and why was it in my computer?

Some of the error messages were explained in the manual, but some weren't. It became clear to me that there was nothing I was doing to make this happen. I contacted the people at Wendin and even got a response, but they didn't fix anything.

Ultimately I had to give up on Wendin DOS and look for another solution.

Friday, March 12, 2010

Watch City

C.F.C. needed a bigger place to make its product, so we decided to move to 179 Bear Hill Road in Waltham, Massachusetts right on Route 128 and across from a Polaroid plant. 3Com was in the building next to us. This facility was huge compared to the building it occupied in Newtonville. I got my own office, as did a lot of other people. This was an interesting turn in my own life just because my mother grew up in Waltham and I was born there.

Waltham is often billed as "the birthplace of the American industrial revolution" and is famous for being the home of the Boston Manufacturing Company. It was also home to the Waltham Watch Company, and so Waltham is known as Watch City. As of the time of this writing I live in Ashland, Massachusetts which is the birthplace of the electric clock. An interesting coincidence.

C.F.C. was growing fast and a lot of interesting things were about to happen.

Monday, March 8, 2010

All Night Long

About this time I got a phone call from the video rental store in Somerville which was using the software that I wrote when working for Patrick Alessi. They were having a problem with their hard drive. They were using an IBM PC/XT with a 10MB hard drive. They were backing up their hard drive onto about 30 floppy disks but for some reason their restore wasn't working correctly. They asked if I could help.

I drove to Somerville and took their computer home with me. I used a disk editor application to examine the disk. I needed to look at each sector on the disk and manually reconstruct their database. I was up all night long working on this. Thankfully I did manage to make their system work again. I took their computer back to the store and gave them the bill. $115. I was surprised to see the owner thought this was too much, but I thought it was actually a good deal given the heroic effort I put in. I didn't lower my price.

I was really, really tired and when I got home there was a church meeting going in our living room, so I sat down. My eyelids were very heavy, and I could barely stay awake. When the meeting was over I'll never forget that Joe Silipo, the one doing most of the speaking, came up to me. I thought he was going to scold me but he just smiled and said, "Brother, get some sleep."

MIX C

Unlike today, in the 1980s most computer magazines like BYTE, Compute!, and PC Magazine had lots of articles about programming and programming languages. BASIC, Pascal, Prolog, Lisp, Forth, assembly language; you name it. In 1987 C was a very popular language and a good C programmer made good money so I decided that I should learn it.

I found an magazine ad for MIX C headlined "C for yourself". They had a very special deal called MIX C Works and this included the compiler, a split screen code editor, and a source level debugger for only $89.90. The ad claimed that the included book would make learning C easy. I paid for this software myself, and it was so exciting to open the package when it arrived in the mail. Nice new crisp books and disks. It all felt very professionally done. It was a great investment.

It was very exciting to dig into the C tutorial and use the editor and the source level debugger. This was really well written software and book was as good as the ad promised. C is a nice, small language and well written C is actually quite pretty to look at with those curly braces.

We had some simple applications in engineering that were perfect for learning a new language. Open a file, translate the information in some way and write it back out to a new file.

VP Planner application development

Accounting wanted an application using a spreadsheet like Lotus 1-2-3. We did a little research and decided to try VP-Planner which was an inexpensive Lotus 1-2-3 clone. One of the nice features of VP-Planner was that it had a macro recorder. Instead of just creating a spreadsheet using a completely unrestricted form, it was possible to create a more shrinkwrapped type of application that limited which fields could be entered and to perform validation and such. I had never used this sort of development tool before so I had to learn everything fro scratch.

In retrospect I probably would have been able to produce what they needed faster in BASIC, and I certainly would have had more control over the result but this was a useful experience. Spreadsheets can be a good tool for people who don't want to learn a real programming language.

Tuesday, March 2, 2010

Enter the Robots, or... Old Apple IIs Don't Die, They Just Walk Away

Bob had made an arrangement with an entrepreneur (I wish I could remember his name.. Steve, maybe?) who was developing robots. The idea was that a robot could be developed that could tour a factory or other business and move materials automatically from one place to another. I don't know the details of their agreement, but it was probably that Bob would get one of these robots on the cheap or for free for providing the developer with space to work and for providing a real world factory for the robot to be tested in.

The entrepreneur was also the engineer developing the robot technology. I had a few good conversations with this guy because I shared an office with him briefly. He explained to me that the robot had two computers. One was an IBM PC compatible motherboard and the other one was an Apple II+ motherboard. The Apple II+ motherboard would later be replaced with a more generic 6502 card later on. One computer controlled the movement of the robot and read sensors, and it was programmed in C. The other computer had a goal seeking program written a language called Arity Prolog, and this computer controlled the other one.

The robot itself looked kind of like a big R2D2 with a flat top for placing materials to be transported. It had small sonar detectors like you would see on early Polaroid instant cameras, and on the top it had a small dome with a rotating infrared sensor. The robot was taught the layout of the factory, and it would continually adjust its course based on what it knew, what it sensed with sonar, and also by using the rotating sensor to look for infrared senders located in different locations in the factory.

Trouble with the Floppies

In my first years of computing my experience with floppy drives was pretty good. I had used several computers for thousands of hours total, and had seen hardly a hiccup reading and writing floppy disks.

The computers I had experience with floppies included:

Apple II+
IBM PC
Heathkit H-89

These used brands like Shugart and Tandem for their floppy drives.

Working with Patrick Alessi there was little trouble. He did smoke a pipe constantly around the equipment but this didn't seem to cause any problems.

At C.F.C. it seemed like floppy disks were more temperamental. Not that they weren't reliable enough for day to day use but they would cause problems just enough to be annoying. Maybe it was the industrial environment, or maybe the quality level for drives and floppy disks was falling. I dunno. Some of our disks came from customers and were formatted by their computers, so maybe that also had something to do with it. Floppy disks had become cheap and didn't have the same quality they did a couple of years earlier.

Some floppy drives could be calibrated using software and a screwdriver. I did try some of that, but I can't say I remember it being very successful.

Monday, March 1, 2010

Bombs away!

If a customer sent us a disk with drilling hole data this made our job easy, but many times they only sent us artwork on film, or worse. In this case it was up to Daniel Donoso (a very nice guy from Chile) to digitize all the drilling locations for a board. You take a different color permanent magic marker for each hole size, and then you connect the dots making a track that leads through all the drilling positions.

Then you place the artwork on a large digitizing machine called an OPIC II made by Excellon. This had a large polished granite platform, and on top rested a platform on top of felt pads. The artwork is placed on the table, and then using two control wheels the table is moved with several decimal places of precision through the course laid out in marker. Daniel would sit and peer into a "bombsight" down at the table and drop imaginary bombs on each position with a foot pedal. Each time he did this the X and Y position of the table was recorded to paper tape. This could take a while to do, and it took practice.

One really cool thing about the OPIC II was the digital display for showing the X, Y coordinates. It didn't have an LED display. Instead each digit position had one of those little vacuum tubes that had incandescent filaments shaped like each digit. I guess this might have been a plasma display, and not incandescent, I'm not sure. If you looked carefully you saw that the different digits were not all the same exact distance from your eyes because they were all packed into the tube in a row, one behind the other.

The OPIC II could not be called a computer, but later on we would find a way to use a computer with this machine.

The TRS-80 Gets a New Home, Briefly

After we built the new tracking system using one of the the Kaypro II machines, the TRS-80 was re-purposed by the drilling crew. A fellow by the name of Robert Doulbakian was in charge of that group. He wanted to use the TRS-80 to manage inventory for the drill and rout tool bits. I was very familiar with inventory management, having worked with Mr. Alessi on a couple such systems and Robert's requirements were very simple. I pulled something together for him quickly in Level II BASIC.

It seems to me that this particular computer was beginning to reach the end of its useful life. The keys were beginning to be sticky (and I think one of the keycaps had fallen off). In addition the machine was exposed to a more corrosive environment out in the factory, and these TRS-80 Model I computers had only silver and tin solder for contacts between the main unit and the expansion box. The computer would hang or reboot frequently.

Thursday, February 25, 2010

The Job Tracking System

It was time to put my new SBASIC tool to good use. Bob wanted a new tracking system to replace the old TRS-80 one. We decided to use one of the Kaypro II machines for this. I'm a little fuzzy on whether Bob started this one and handed it off to me, or if I was the developer from the get-go.

This was a pretty easy application to build. There were a dozen or so departments on the factory floor. Each time a new job was ordered there were some essentials entered like job #, customer name, board type, due date, etc. and these were just stored in a simple random access file. Several times a day a young lady from Brazil named Danusa would make rounds collecting information about jobs and where they were in factory. Then she would come back and enter this information. Status reports would get printed out.

C.F.C. specialized in quick turnaround orders. Anything we could do to improve information about important rush orders was critical. A more timely tracking system was in our sights. We took one of the Tandy Model 100 portables and bought a barcode wand for it. This would be used to collect the locations of all the jobs. I wrote a program in the tracking application for printing 3 of 9 bar code on label stock using an Epson compatible dot matrix printer. These had job numbers on them and we stuck them on the job bill of materials sheets that went with each order. Then we printed large bar codes for each department.

So now all Danusa had to do was go to a department, scan the bar code on the department sign, and then go to each bill of materials sheet and scan in the job number bar code. Then she would repeat this with each department. When this was done (and it was a lot faster than using a pen and clipboard) all she had to do was come back and we would read the information into the Kaypro II using an RS-232 cable and we would just suck that information into the tracking system and print the reports.

It really stands out to me that this sort of very useful application programming was easily achievable by a high school graduate with a knowledge of BASIC. End users used to do this kind of thing a lot more back then and I'm sure that Bob could easily have written this himself if he were so inclined and it he weren't so busy running the company. People should take more interest in programming because it's fun, it teaches important thinking skills and even untrained programmers can accomplish real productivity enhancements.

The SBASIC Preprocessor

I had become familiar with structured programming ideas from my casual experimentation with Forth. I wanted to do something to improve the quality of my Microsoft BASIC programming. I realized that I could write a program that would take BASIC source code without line numbers, and adding in named labels for the GOTO and GOSUB targets and output line numbered BASIC. Then I could run this code in an interpreter or compile it. This was a cool idea for me. After having done the CNC simulator this lit up a part of my brain that brought me closer to realizing that a compiler is just another kind computer program that treats source code as data.

I wasn't familiar with QuickBASIC at that time, so I didn't use Microsoft's syntax for this. Instead I used square brackets for branch labels like so:

[loopHere]
a = a + 1
print a
if a = 10 then [quit]
goto [loopHere]

[quit]
print "done."
end

Liberty BASIC programmers will recognize this syntax. I called this preprocessor SBASIC for Structured BASIC.

Here's what it looks like in QuickBASIC:

loopHere:
a = a + 1
print a
if a = 10 then quit
goto loopHere

quit:
print "done."
end

I think that my syntax is better. It certainly is more consistent because in QuickBASIC the branch label will either be quit or quit: but in SBASIC it is always [quit].

So here we see a direct precursor to Liberty BASIC. At this time I did not have plans to create my own BASIC. That wouldn't come for four more years.

Monday, February 22, 2010

The Job Does Has Its Perks

When I got promoted to computer programmer they moved me out of the engineering area and into the room next to it. They also gave me a desk and bought me a computer. This was a Tandy 1000SX, sporting a 7.16MHz 8088 processor, 384K bytes of RAM, two floppy drives and a 20MB hard card (a hard drive that is mounted on a frame in line with the controller card).

This was a slightly quirky machine. Tandy was used to producing their own designs, and their IBM PC clones up to this point were attempts at going their own way. As every computer manufacturer was learning it really didn't work to make an almost IBM compatible computer. The 1000 series was their first really compatible line. Even so they stubbornly kept their own keyboard layout from the Tandy 2000. I even needed to draw some missing symbols on keys with a permanent marker. The printer port was just circuitboard fingers on the motherboard instead of the popular Centronics printer connector.

The machine had CGA graphics and a green screen monitor. This would prove to be very important to software I would write but I couldn't imagine at this time where this would lead.

101 Things You Can Do With a Floppy Disk

C.F.C. hired a college student for the summer of 1987 to operate their TRS-80 system which had three 5.25 inch floppy drives. The young student (he might have been older than me) would sometimes come to me when he had computer questions or if the machine wasn't working perfectly.

So, one day he comes to me and says that he's getting errors from the floppy drive. Okay, I followed him over to the computer. He reaches over and perfectly naturally reaches down, opens the drive and pulls out the disk... backwards! The disk was in the drive backwards, and his fingers were touching the magnetic disk through the access hole. I wasn't ready for that, and I don't think he was ready for my surprised outcry!

The good news? Even with fingerprints on the disk surface the data was still intact. The disk read fine when it was reinserted correctly.

Sunday, February 21, 2010

CNC Machine Simulator

The two Osborne 1 computers we were using in engineering were getting a bit worn, so Bob sprung for some Kaypro computers. I don't think they appeared all at once but soon enough we had two Kaypro II machines and one Kaypro 10. The Kaypro II's were similar to the Osbornes but with bigger screens. Now we had 80 columns of bright green text. The Kaypro 10 also had a built in 10MB hard drive.

One really important difference with these new machines is that they had block graphics characters, and you could plot lines and points. This wasn't high resolution but it was good enough to inspire me to write a simple interpreter for the CNC programming language. Remember how I tried to write a programmable calculator program for my VIC-20 but never finished it? This interpreter was the realization of ideas that I'd been kicking around for a while. I wrote this as an extension of the machining text editor in MBASIC.

Now we could run a rough simulation of how a routing or drilling program would work and see the result on the screen. There was no fine detail, but it was easy to see if we accidentally drilled outside the board, or if a panel would be ruined by an accidentally placed cut. This certainly saved time and money because we were able now to make fewer first pieces so the single head Excellon machine and it's operator were more efficient.

Friday, February 19, 2010

Moving Up

A few months into my new job at C.F.C. I wrote an application for Tina in accounting. She had the only computer in the building that had a hard drive. It was an Epson Equity which is an IBM XT clone with a monochrome green screen and a 20MB hard drive running MS-DOS 2.11. I'm guessing a heard Tina and Simone (who is Bob's wife and VP of the company) talking about a need, and I must have offered to craft a solution for them. Simone probably asked me with surprise, "Can you do that?" I was eager to jump right in. I'm pretty sure that GW-BASIC was already installed on the computer. :-)

Up to this point my programming work for engineering and accounting was done on my own initiative. I wasn't trying to attract attention, but Bob noticed my enthusiasm for software development. He is an open minded person, and his whole business was personal and informal so he must have found it easy to promote me out of engineering. I became the company's in-house computer programmer. That was quick! I didn't get a pay raise but how could I complain? This was exactly what I wanted and it was an opportunity for him too.

This is the sort of business that just begs to be automated. Bob certainly knew this. One programmer could keep himself busy with interesting work for many years and I was the lucky fellow.

Thursday, February 18, 2010

My First Text Editor

Using a word processor to edit CNC programs didn't seem quite right to me, so I decided to write a text editor especially for editing drilling and routing programs. I had never written a text editor before, but I had a pretty good idea how to go about it. The Osborne 1 had a terminal style display, so there were control and escape sequences for inserting and deleting lines and characters which makes it pretty easy to write a screen editor.

One thing that motivated me to write this editor was to save time. Sometimes it was really useful to be able to mark of bunch of drilling coordinates and move them or make copies at an offset. My editor made this easy to do.

I wrote the editor in MBASIC. I'm pretty sure it was also compiled to a standalone application using BASCOM. This was in a before IDEs, and programs needed to be compiled and linked.

The Osborne 1

The Osborne 1 was a portable CP/M computer with a Z-80 processor. It looked like a portable sewing machine. You tip it on its side and undo the latches and the end would come off revealing a keyboard which was attached to the rest of the machine by a wide ribbon cable. Removing the keyboard revealed two large floppy drives, a tiny 5 inch screen, cubbies for floppy disks, and a bunch of ports. We would plug the RS-232 cable from the paper punch into one of the ports.

The 5 inch screen could only display 52 characters wide, but it could scroll. You had to have a tolerance for reading very small type to use this machine. I was okay with it, but today I probably wouldn't enjoy it.

Aside from editing CNC programs, we also had MBASIC on these machines and so we could do a little programming to help us with our work. Bob knew how to write in BASIC and he had written a few things. For example there was a program for spitting out a simple routing program for a rectangular board. You just punch in the size of the board and it would generate a file. Anything more complex than that required manual coding.

One problem we had with the Osborne 1 machines we had was that the keyboard bezel was metal and it wasn't grounded well. If you walked up to the computer and touched the keyboard it wasn't unusual to discharge some static electricity and reset the computer, losing whatever work you were doing.

Wednesday, February 17, 2010

Paper Tape

When there was a mistake in a long CNC program, sometimes it was easy to tell that it was a mistake at the beginning of the program. Rather than read the whole thing in, edit it in WordStar and then punch a whole new tape, sometimes it was easier to repair the paper tape itself.

Usually you could just create a new section of paper tape, and then you unroll the tape to the section you are looking for and splice in the change. With some practice it wasn't too hard to read the binary numbers by eye. Instead of ASCII values, CNC programs were punched to tape using EIA (Electronic Industries Association) codes.

In some instances if you didn't need to change the number of characters, but just which values (change some digits for example), you could just cover the holes with tape and punch new holes. I think I did that at least a couple of times.

So, this all seems very archaic right? On the plus side you really had control over the stored data. Today if your disk drive or your flash memory loses a bit you can't even see it let alone fix it. ;-)

Tuesday, February 16, 2010

Welcome to the Machine

Or welcome to the machines as it were. I think there were four Excellon drilling and routing machines at C.F.C. One of them had just a single head and was used for making first pieces to test for errors in the drilling and routing programs.

So my first job was to learn the programming language for these machines. Bob Spain and a young lady named Kristen Van der Laan were my teachers. This is no high level programming language, but more like a machine code of sorts. Circuitboards are still drilled and routed this way today more than 20 years later.

Here is an example of a very short Excellon drilling program. The actual language for CNC machining is based on commands used to control Gerber Scientific plotters:

M48
T1C0.028
T2C0.032
%
M48
G05
M60
T1
X2.550Y1.550
T2
X2.600Y1.650
X2.600Y1.750
M30

That drills just three holes of two different sizes. Writing programs to drill holes wasn't really the engineer's job. We mostly wrote programs to cut the boards out. Most of these were simple rectangles, and the program for this wasn't much longer than the example above. Sometimes boards would be circular, or have odd shapes. Some would have chamfers, fingers, slots, large inner cutouts. There was great variety. Sometimes we would make palletized panels which have more than one circuitboard. The routing was designed to leave only small perforated spots to hold it all together, and the boards would be removed from the panel either by hand or by machine.

We would write a program for routing using WordStar and then save it to a floppy disk. Then we would send the program out to the paper tape punch machine. The tape was usually gray, blue or pink. There were little tiny round pieces of colored paper all over the place.

A finished program would go out for a first piece to make sure it was correct. If you left just one digit out of a routing program the machine could destroy the panel, cutting straight through the middle of it.

Saturday, February 13, 2010

A Cornucopia of Computers

So I joined the engineering group at C.F.C. Our job was to write and debug CNC programs for the Excellon drilling and routing machines. Most of the programs were written using WordStar on Osborne-1 and Kaypro CP/M machines. We did not use hard drives to do this work, and the final medium of storage was punched paper tape. Yes, really! That was the format the machines used, and we had a storage library for keeping the tapes.

There was one Macintosh in engineering for special purposes, but here again I never used it.

There was a TRS-80 used for managing job tracking in the factory. It had the standard silver expansion box and three floppy drives.

Accounting had an Epson PC clone (or was it a Leading Edge Model D?), and there were a couple of Tandy Model 100 laptops that look like Alan Kay's Dynabook prototype.

Things were about to get interesting.

Friday, February 12, 2010

A Fortunate Series of Events

In the spring of 1986 I discovered something that would change the direction of my life completely. I had been reading the Bible a lot in my teen years, but I didn't have a church community that fit what I understood from my studies until I found the Boston Church of Christ.

Late that year I decided to move in with some other young fellows from the church in Newton, but in order to do this I needed to find more regular paying work. I continued to work with Mr. Alessi but I began to look for a job. For some reason in the cold early spring of 1987 I worked for a few weeks at McDonalds and then suddenly I found an ad in the local paper. I remember the ad was titled "Programmer Trainee".

I went in for an interview. The company was called Circuitboard Fabrication Company, or C.F.C. It was hidden neatly in a neighborhood right next to a grade school in Newtonville. The president of C.F.C. was Bob Spain. He explained that this was a job programming CNC drilling and routing machines which are used to cut circuitboards out of fiberglass sheets. I told him that I was interested in developing computer programs and he responded that I may have an opportunity to do some of that at C.F.C. Small business owners like Bob Spain and Patrick Alessi are so openminded. :-) He offered me $5.50 an hour, and I accepted the job.

I began my new job taking the bus from Needham center to Newtonville because my car had broken down. Then after a few weeks I moved in with the guys from church. I only took with me what would fit in one carload. My new home just happened to be walking distance from C.F.C. It was very easy for me to see the hand of God in this arrangement.

I was surprised to learn soon after starting my new job that Mr. Alessi had used C.F.C.'s services to produce the circuitboards I had been assembling for two years. I had notice the marking CFC-1 on the boards and now I understood what it meant.

How I met the transistor

When I was perhaps 11 years old my father brought me home a book, and what a book it was! It was a red covered paperback titled Transistors, and I think it was published by Tab. The book was a perfect introduction to semiconductors for the neophyte. It was peppered with cartoon characters and helpful diagrams. The wonders of doped germanium and silicon were laid bare. PN, NPN and PNP junctions, holes, valence electrons and more all demystified. I already had a basic understand of what a transistor was, but until I read this book I really had no idea how they worked. The book blew the door wide open!

This was obviously a well written book to be suitable for an 11 year old to grasp and the information has stuck with me even after all these years. Thanks Dad! Now where did I leave that book?

Thursday, February 11, 2010

VIC-20 Blues

Here's an embarrassing story. One day I got the bright idea to put my VIC-20 on my lap and then I put my nearly new black and white television on a milk crate on the floor in front of me. I sat on a chair in front of it and wrote code. This would have been awkward I suppose if not for the fact that the VIC-20 had only 23 rows of 22 characters. The letters on the screen were huge, so the screen could be rather far away and I was comfortable.

Alas, I put my foot on the corner of the milk crate. At some point I shifted my weight to get comfortable and unwittingly kicked the television over backwards. It fell only about a foot to the floor. The back of the plastic case was so close to the back of the cathode ray tube that the case only needed to deform slightly to press against the tube. The back of the tube snapped off and it was ruined. The phosphor on the front of the screen was removed by the action of the gasses rushing in and you could see inside. What a disappointment, but it was a good lesson for me.

I never found an opportunity to replace the TV, and I never used my VIC-20 again and all these years later I don't remember what happened to it.

Tuesday, February 9, 2010

On the Road in a Green Bug

In addition to the East Coast Video in Brockton, we picked up a second customer for our video rental software in Somerville, Massachusetts. It wasn't unusual for me to drive myself to these locations in my forest green 1965 VW Beetle. Sometimes there were bugs that needed fixing and sometimes they wanted enhancements. There was at least one evening when I was at the Somerville store late into the night.

These two customers were the very last work I did with Patrick Alessi, and the only real money I made with him aside from the circuit assembly work he provided. Perhaps if we had managed to sell to more stores I might have continued to work for him, but my life was about to take a turn in a totally different direction.

Soldering my way to Israel

Patrick Alessi wasn't just interested in the software business. He was an electrical engineer. There was a company up in Wilmington, Massachusetts called Cryovac. They made machines that shrinkwrapped fruit, and presumably other things too. Mr Alessi had managed to win a bid on some business to provide them with electronic controller boards for their machines. There were two different boards, and he offered me a chance to make some money assembling and soldering them together. It's amazing to me how I was able to memorize where hundreds of parts should be inserted and soldered into place. The more I worked the faster I got and the more money I made.

In my junior year of high school I had met a very sweet girl who was a foreign exchange student from Israel. Her name was Michal Zilberman. I began to spend a lot of time with her and we became very close. When she went back home we wrote back and forth a few times and I called her on the phone once in a while. I decided to visit her the following year.

I would pay for the trip by assembling circuitboards for Mr. Alessi. It only took me a few weeks to earn the $850 or so dollars I needed for the plane ticket. When my folks noticed what I was doing and that I had obtained a passport they figured I wasn't ready to be a world traveler (probably true) and they sent my grandfather with me. He had always wanted to go to see the Holy Lands, so he was eager to go. When we got to Tel Aviv we didn't actually see each other very much. He was a great traveling companion and we did enjoy some time together and he let me beat him at checkers. When he took off to go on tours including a diversion to Egypt, I enjoyed exploring Tel Aviv with my camera in the mornings and then I would walk to Michal's home and see her family. We spent a few days together in Tel Aviv seeing the city. The we went to stay with her sister in Jerusalem for a few days and spent a day in Haifa.

My relationship with Michal was not meant to be, but this was an unforgettable adventure.

Monday, February 8, 2010

Mis-adventures in PDP-11 Programming

I mentioned earlier that I didn't become much of a Pascal programmer, but I neglected to mention one very important reason. We were too busy messing around. Brice Illingsworth (I hope I got that right) managed to get copies of all the manuals for the PDP-11 and the RSX-11 operating system. The most useful thing we managed to produce with these generously donated manuals was a simple internal email system. Pretty amazing when I think back on it.

However, we did almost get ourselves into some real trouble. Brice had the brilliant idea that we should create a mock login routine that would capture people's account information into a file and then present a login error and then quit to a real login. We managed to capture a few passwords before someone noticed our little mischief. Thankfully he gave us a wink and a nod and we didn't repeat this bad behavior.

Since graduating from high school I have not used a PDP-11. I just checked ebay.com and found a DEC Digital PDP 11/03-LK Rack Mount Computer for a mere $203. I'm sure I wouldn't know what to do with it. ;-)

Sunday, February 7, 2010

My own Commodore 64

One of my close friends Jeff Benitz (whom I had originally met years before at Radio Shack while playing with their TRS-80s) bought a Commodore 64. I went with him to Westwood, Massachusetts to buy the used computer. It included a monitor, a cassette deck, and a dot matrix printer. We enjoyed staying up late into the night playing a game called Telengard, which was a popular Dungeons and Dragons style game. I seem to remember we went to Toys R Us to buy the game back when you could buy tons of software for this machine in the stores. Telengard was written in BASIC, and we figured out how to break into it to modify it. Terrific fun (if you ask me).

One other cool thing I remember doing with this computer was writing a custom routine to reprogram the custom graphics characters on the fly to draw detailed images. This was in BASIC. It was slow but it worked.

Eventually Jeff sold this computer to me. I didn't use it for much and after moving a couple of times I tossed it because I couldn't find the power supply. Oops. What was valuable became obsolete and disposable. Nowadays I wish I could find the time to rediscover the simple joy of programming old home computers.

Saturday, February 6, 2010

Computerized Cameras

Nowadays most everyone uses a digital camera without film. Back in 1983 I became involved in the old fashioned sort of photography. My brother Neil sold me his Canon FTb-n camera and a couple of very nice lenses. This was a completely mechanical SLR camera, the only electronic part being the meter which was a real meter with a physical needle that swung back and forth in the viewfinder.

A couple of years later my brother sold me his Canon AL-1. This was a smaller camera based on their popular AE-1 model. It had a computer in it, and needed batteries just to fire the shutter. It also had an early autofocus system. It didn't actually turn the focus ring on the lens with a motor like modern cameras do. Instead the computer in the camera controlled a red LED in the viewfinder to tell you to turn the focus one way, another red LED to tell you to turn it the other way, and a green LED in the middle to say that focus is achieved.

This was a nice enough little SLR I suppose, but it wasn't as durable as the FTb-n. Also, the batteries didn't last very long.

My attitude at this time towards computers in cameras was "computers are wonderful computers, but computers are not wonderful cameras." I still feel this way about computers in automobiles, but digital cameras have finally come into their own. I still love film, but it's too expensive now.

Friday, February 5, 2010

The Macintosh and its Imitators

While I was busy learning how to develop software for the IBM PC and it's copies, Apple was marketing a complete new kind of computer called the Macintosh. I didn't know anybody who owned one, and somehow I never found my way into a computer store to try one out. My only experience of the Mac was what I read about it in magazines. It certainly looked cool and amazing.

To me it was a very distant phenomenon, sort of like a distant land. Very exotic and unreachable. One thing seemed clear from what I read. Programming a Macintosh required a different way of thinking about software. Microsoft did produce a version of QuickBASIC for the Mac.

Other manufacturers were working hard to create their own Mac-like products. Atari has their ST computer with GEM desktop. Commodore announced the Amiga which had a similar windowing system as the Mac. Microsoft was demoing their very primitive early version of Windows as far back as 1985. Berkeley Softworks released GEOS, which was a Mac style operating environment for the Commodore 64, the Apple II, and later on the PC. Nowadays you can still buy the PC version which is sold by its new developer Breadbox Computer Company under the name Breadbox Ensemble.

Wednesday, February 3, 2010

East Coast Video - Communications Breakdown

Our friend James Foster had found us some contract work. A video rental store in Brockton, Massachusetts wanted to get out of their 3x5 index card system and into a computerized one. The software was going to run on an IBM PC clone with two floppy drives. This was to be a pretty big project worth thousands of dollars. I went with James to meet the owner of the store. He began to explain what he wanted. I would ask him questions to try and clarify the details and I took notes. He was very enthusiastic about our designs.

I went back to Mr. Alessi's house and with great energy proceeded to build this system. We wrote and debugged it using the BASICA interpreter and then created binaries with the IBM BASIC Compiler. It had to manage a catalog of customers, and catalog of video tapes, and also keep track of who rented what, and for how long, and how much that cost depending on what category of movie it was. It also had to calculate total charges including taxes, and of course the cashier had to be able to override the price.

One month later we were ready and we took the system to Brockton. Wouldn't you know it, the system was not anything like the way our customer was expecting even with the long design session together. So, now equipped with the knowledge of what they didn't want we sat down for another design session.

The software needed to be rewritten from scratch, and this time they wanted in a week! I spent the next week working late into the night to create the new system. When we were done and showed it to the customer we were relieved that he was happy with the result. We just needed to deal with some minor tweaks and some performance optimizations.

In retrospect this would have gone a lot better if I had developed the software there in the store. That way we would have learned very quickly if we were straying from the customer's needs.

Tuesday, February 2, 2010

Noisy Calculator, the SR-56

One very interesting feature of the Texas Instruments SR-56 calculator was that it was noisy. I know that sounds strange, but if you held it up to your ear you could hear some quiet humming noises. If you used a trig or a log function it would change the sound as it worked out the answer. I can't think of any other digital devices I've ever owned (actually this particular calculator belonged to my brother Billy) that make noises you can hear. Sure, you can hear your cell phone blasting out data packets over your stereo or PC speaker system, but that's radio interference. This was actual audible noise. I wonder if they made any other noisy calculators back then.

Monday, February 1, 2010

Pocket Computers and Programming

My brother Ernie was a fan of the Radio Shack pocket computers. He started with the original pocket computer. This was a neat little machine with a QWERTY keyboard and a BASIC interpreter. This was a real step up from a programmable calculator. Later on he bought their Pocket Computer 2 model. I think this model had two microprocessors, and you could draw very simple pixel graphics with it. You could save your programs to tape, and there was a printer for it. My brother managed to discover a machine code monitor in that model and he was experimenting with that. This reminds me of what another friend of mine told me about the first model of the HP-41 calculator, that it was possible to program it in machine code in an undocumented way.

Today these pocket computers would seem quite primitive and wanting, but for many purposes even today they would be very useful. Of course nowadays people expect their pocket devices to have Wifi and Internet access. What was great about these machines? They shared the same approachability as home computers like the VIC-20 and TRS-80. Just by reading a simple 100 page manual you could learn how to make the computer do your bidding. Want to be a programmer?

You + pocket computer + 100 pages of reading = programmer

Sunday, January 31, 2010

Pascal on the PDP-11

When I was a junior I transferred from Xaverian Brothers High School to Needham High School. One of the great things that NHS had was a DEC PDP-11/40, and there were several classes you could take in order to access this minicomputer. I enrolled in the APP Computer Science class, which was essentially a course in Pascal programming.

I'm guessing there were at least a dozen terminals on the school property. I remember four Lear Sieglar ADM-3 terminals and two DECWriter dot matrix terminals in the room where we studied Pascal. I'm sure there were a bunch more in other locations, but I never saw them. I never saw the PDP-11 either, but I'm pretty sure it was there. ;-)

The experience was pretty sluggish. To compile a very short Pascal program took 15 seconds at least. If you made a mistake in your code it would give you a cascade of error messages. It took some practice to figure out what the errors meant. The computer system was so slow we didn't actually get to be very good at Pascal because the maintenance guy would kick us out of the building just 20 minutes after the end of the school day and before anything interesting could get done. Ah well, I had a good time.

Saturday, January 30, 2010

Enhancing Your Apple II

Back in the day friend Richard Stoddart loaned me a book titled Enhancing Your Apple II by Don Lancaster. Mind you, I didn't even own an Apple II but I was very interested in learning, and the book seemed promising so I took it home. The author Dan Lancaster was a popular writer and quite an Apple II guru. My understanding is that he was part of the same computer users group that Steve Wozniak, the creator of the Apple II belonged to. The contents of this book are certainly compatible with the idea that he had an insider's caliber of insight.

The book starts off with some really neat but simple modifications to the motherboard of the Apple II. The kinds of modifications described were things like adding a single wire to connect together circuits that would otherwise not have any knowledge of each other. Then he explains how with this and some simple software tricks you can do multimode graphics and high resolution text. He even shows how to do this from an Applesoft BASIC program by calling some machine code he provides in the book. Very nice.

Later in the book he explains how to disassemble machine code and figure out how a machine language program works so that you can make modifications. What an excellent education!

There is also supposed to be a Volume 2 of this book, but I'm not sure what it contains.

Friday, January 29, 2010

Whoa Daisy!

I don't know if we were quite prepared for the noise and vibration of the daisy wheel printer that Mr. Alessi bought. This kind of printer was called a daisy wheel because it has what looked like a black plastic flower with the letters and numbers on the petals. This sort of device was borrowed straight from typewriter technology. To print each letter the wheel would spin around and a hammer would knock the desired petal against the paper. It would also rapidly shift up and down because there was more than one symbol on each petal. The wheel assembly would swing back and forth energetically (zooming is a good word for this) as it printed each page. It was loud, and it would shake the table like a bucking bronco! It was intolerable. The printer did produce nice clean and smooth black characters on the page, so we kept using it. The solution to all the noise and vibration was to sit the printer on top of a very large and thick piece of mattress foam. This worked a lot better than it probably should have.

Thursday, January 28, 2010

Enter IBM

After I had worked on a couple of projects on the Apple II+, Mr. Alessi decided it was time to develop software for the IBM PC. I think he bought his at the Sears Business Systems Center in Natick, Massachusetts. He purchased one with two floppy drives, an expansion unit housing a 10MB hard drive (the first one I had ever used), and a green phosphor monitor. He also bought a daisy wheel printer so we could produce letter-quality documentation for our software.

I enjoy discovering a new computer, but my initial impression was not all positive. The machine was big and expensive. It felt slow. This didn't make sense to me because even though the PC's 4.77MHz Intel 8088 processor was clocked at nearly 5 times higher than the 1MHz 6502 processor in the Apple II+, the Apple felt much, much faster. Steve Wozniak's hard work on the Apple II+ was clearly more efficient in many ways.

In addition, the computer came with PC-DOS 1.10. I was expecting something more advanced than CP/M from IBM but was disappointed. In fact PC-DOS seemed to me to be nothing but a ripoff of CP/M.

Overall, this computer was underwhelming. With IBM behind it this design would be copied widely. The variety and innovation in the microcomputer market was slowly wiped out by this computer and its imitators.

Wednesday, January 27, 2010

Rumblings of the Future

One formative project I started but never finished on my VIC-20 was a programmable calculator program. I got my start programming the HP-67 calculator, and I've always been fond of these little pocket sized computers so this was my inspiration for this project. This was going to be the simplest interpreter you could write in BASIC. I didn't bother to sit down and design it on paper first. I just starting coding it. Really, I can't remember much about it except that I was motivated to give it a try. I didn't get very far.

Another idea I've always been very interested in pursuing is to create a robot battle programming system like Robot Wars on the Apple II. This is similar to CRobots for the PC. It's a very simple real-time simulation of two or more robots duking it out in an arena. The robots search and destroy each other by executing battle programs written by a human user.

I never finished my programmable calculator. Years later on I would go on to write different kinds of interpreters and some similar things in connection with paid work, and ultimately Liberty BASIC and Run BASIC.

Programming languages have always fascinated me, and I enjoy reading books and articles by other programming language implementors to improve my understanding of the field.

Monday, January 25, 2010

6502 Assembly Language

My brother Ernie is a little more than a year than I. He was ahead of me in the programming department when we were kids, and my first exposure to assembly language was through a book he had on Z-80 assembly language. I never did have an opportunity to try Z-80 assembly, but when I had my VIC-20 I decided to try 6502 assembly language. I didn't find machine language hard at all to grasp because it seemed very similar to the language used to program calculators, especially the HP-67.

I was a regular reader of COMPUTE! magazine, and in one issue they included source code in BASIC for a 6502 machine code monitor. This was a far cry from an assembler, but it was better than nothing. I wanted to try speeding up a side-scrolling video game, so I decided it made sense to write an assembly language routine to move characters from the right to the left by one character. This is how video game graphics were done on the VIC-20. You could program up to sixty four 8x8 pixel custom characters, and you put these on the screen for some crude graphics.

So, since I didn't have an assembler I needed to be my own assembler. The VIC-20 Programmers Reference Guide included all the information I needed to write my first assembly language program. Once I had the code written, I translated the assembly language instructions into machine code. On the 6502 the instructions are in the form of hexadecimal numbers. I typed these into the machine language monitor to try them out. I don't remember if I got this to work the first time.

When using machine code in BASIC on the VIC-20, you would usually convert the hexadecimal numbers into decimal and then put them in a DATA statement. Then READ the numbers and POKE then into memory and call the routine with the SYS statement.

The great thing about the VIC-20 is that anyone can learn to do these things. It's fun!

Stop reading this right now. Go to ebay.com and buy a VIC-20. Go to amazon.com and buy a copy of the VIC-20 Programmers Reference. Try it yourself! Seriously!