*****************************
Title: The Bleeding Edge of Technology
Date Occurred: Autumn 1982 and Spring 1983
Date Written: January 24, 2006
Written By: Joseph T. Arendt
*****************************
While John Stilwell had transferred up to University of Wisconsin-Madison, his former roommate Alan Raichel still lived in the same room of Wilgus Hall at Platteville in the autumn semester of 1982. I had moved into the new Consideration Wing on the ground floor of Morrow Hall at UW-Platteville. I was excited to show off my Commodore Vic-20 system to Alan, plus show him what I had managed to do with it over the summer. He had news that upstaged me! He had a brand new Commodore 64!
The Commodore 64 went on to become a cultural phenomena, completely upstaging the Vic-20. Few people except Alan Raichel had a Commodore 64 in 1982, though. The machine had just been launched in August or September of 1982. It was a product that did not even exist in the marketplace when I bought my Commodore Vic-20 in late May 1982 just before that summer began. Alan had gotten one as soon as it was possible for him to do so. Madison, Wisconsin was a large enough city for it to appear there not long after its official introduction.
Alan had gone out on the cutting edge of technology buying this. Alan himself kept claiming that being on the cutting edge often turned into being on the bleeding edge. I did not yet understand what he meant, but he was going to show me by tragic example!
The price Alan paid for only the Commodore 64 computer itself was six hundred dollars. That is, it was six hundred dollars without adding in a tape drive, disk drive, monitor, or printer. Of course, the actual price for it would have been something like $595 or $599.99 or something like that, then sales tax would be charged.
Six hundred dollars is what I had paid in late May of the same year for my entire Vic-20 system that included the computer, 16 kilobyte memory expansion, Commodore 1515 printer, tape player, and black-and-white television as a monitor. That six hundred had nearly wiped me out financially. I could not have spent a hundred dollars more because I simply did not have it in the bank! However, I had all the essentials. I had a working and capable system. If I had not bought used, the Vic-20 by itself would have been about three hundred dollars. The printer was much more expensive than the Vic-20 computer itself, so the jewel of my system.
I had failed to get a job the entire last summer. I thought I would have to sell the Vic-20 just to survive financially. However, I had unexpectedly learned that I had been chosen to get a two hundred dollar academic scholarship! That might have been the F.H. Russell scholarship, but that might the one I got later. I had applied to many. This was certainly a long way from a full ride scholarship, but it helped me incredibly and at just the right time. In addition, Dr. Allan Richert of the Mathematics Department had hired me as a part-time math tutor at the Math Science Learning Center. With those two unexpected windfalls, I was going to give the school year a try while keeping my Vic-20 computer system. I figured that I could always sell it later if I had to. For now, I wanted to see if it lived up to its promise to help me academically.
Externally, the Commodore Vic-20 and the Commodore 64 looked nearly identical. The only apparent difference was that the case of the Vic-20 was tan in color while the Commodore 64 was gray. It would hardly be worth three hundred dollars extra (six hundred for Commodore 64 new and three hundred for Vic-20 new) to get a gray case rather than a tan one, so I knew something else had to be different.
Besides spending six hundred on the Commodore 64 itself, Alan had also bought a dedicated color monitor and a disk drive. Just the disk drive was another three hundred dollars or so. The color monitor was perhaps another two or three hundred, which was why I was using a sixty dollar black-and-white television as a monitor back then.
What Alan did not have was a printer, which I would not have wanted to be without! As a rough estimate, Alan had perhaps twelve hundred dollars in his system. That is, about double what I had in my system, and mine included a printer. However, Alan’s had a disk drive while I only had a tape drive.
When my system was turned on, the screen announced I had about 19 kilobytes available because of the expensive memory expansion I had purchased. A stock Vic-20 has far less and in my opinion is useless for most computer work unless more memory is added. When Alan’s system was turned on, the screen announced he had about 39 kilobytes available. The 64 in the Commodore 64 name referred to 64 kilobytes of memory, but the computer language BASIC could only access 39 kilobytes of it.
The immediately striking difference was Alan’s system had 40 columns. My Vic-20 had an annoyingly small 22 columns. I did not like 22 columns. Not one bit (computer pun)! However, to get a system I could afford, I could live with it. I could not have afforded Alan’s system, after all.
Alan did not really need the printer because even back when he had only his Sinclair ZX-80 computer and a not-very-useful ELF, he already had a modem. He got that interfaced to work with his new Commodore 64. The modem would let him communicate to University of Wisconsin-Platteville’s PDP mainframe. He could upload files to that, then print them out on the PDP’s printers. His former roommate John had regularly done that last semester with his Vic-20, so it was obviously possible.
Despite being upstaged by Alan, I still felt pretty good about my own purchase.
However, then Alan explained to me about the important internal differences between our two computers.
In that era, internal memory for the computer known as RAM for Random-Access-Memory was very expensive, but had begun dropping in price. RAM is memory that the computer can read and write to endlessly. At that time, ROM for Read-Only-Memory was cheaper than RAM. A ROM had something written in it once by the manufacturer, and that was what was in it forever. That is, ROM was like a published book. What was in it was in it, and that was that. RAM was like having a chalkboard, chalk, and an eraser. It could be written on, erased, and new things written in.
The microprocessor in the Commodore 64 is a Motorola 6510. The microprocessor in the Vic-20 is a Motorola 6502. An Apple II also used a Motorola 6502 microprocessor. The 6510 was only slightly different from the 6502. The clock speed was almost the same. In fact, the Commodore 64 was slightly slower than the Vic-20! I will come back to that.
If you take two and raise it to the sixteenth power, the result is 65,536. This is known as 64 kilobytes. Those used to the metric system with a kilometer being a thousand kilometers might think instead this would be 65 kilobytes. In computers and electronics, a kilobyte was defined as two raised to the tenth power, which is 1,024. That is close to but slightly more than a 1,000.
In the early eighties, I saw some published advertisements that deliberately switched the kilobyte definition between the metric idea of kilo being a thousand and the computer definition of it being 1,024 to make their products look better.
So, the Vic-20 could address 65,536 bytes. Each byte was made up of eight bits, where a bit is a value of 1 or 0. That is, binary. Two raised to the eighth is 256. So, each byte could store a number between 0 and 255. Counting started at zero rather than one, which is why it went to 255 rather than 256.
Although there are various ways to compress the data, it was and still is common to store one letter in one byte. There are 26 letters in the alphabet. Double that to 52 for upper and lower case. Add in various punctuation and control characters. A letter fits well in a byte and a byte is just such a natural unit to use in the binary system.
Now consider a sheet of typical typing paper done in a monospaced font like Courier. At 12 point font, a sheet typically has 80 columns across and 66 rows. Allowing some space for margins, we can roughly say that one sheet of paper written on in English in this font type would hold about sixty times fifty-six, which is 3,360. If you use a proportionally spaced font like Times New Roman, considerably more can be fit in. That is, would writing “w” take more space than an “i”? If so, that is proportional font. If not, that is a monospaced fone.
So, the Commodore 64 could theoretically address a memory space that is about 65,536 bytes divided by 3,360 bytes per page, so roughly 19.5 pages long.
That is, roughly twenty pages of plain typewritten English text would accessible by the Commodore 64 in its memory.
However, there was a big catch. When the Commodore 64 was turned on, it did not say 65,536. I do not remember the exact number and I have not had a Commodore 64 in many years as I type this in 2006, but it was around 39 thousand. So, about ten pages or so of regular English text was what the language BASIC could see.
Where was almost half of the rest of the memory?
Some of it was used for important and necessary things. Some of the rest was just badly organized and wasted!
For example, there was a ROM chip that held the operating system. That was needed, otherwise the computer would not know how to do anything. That might be 8 kilobytes. The microprocessor did not know how to change bytes to letters a human could read without being told how to do that. Another 8 kilobytes or so was used to provide the character set to do it. Real machine code that the microprocessor can understand is bulky and hard to read. A language was included with the computer called BASIC. Another 8 kilobytes or so went to telling the computer how to do that language. What the screen showed was really a reading of a mapped out section of memory. So, some memory was allocated to screen memory.
The screen memory brings me back to the Commodore Vic-20 and its annoying 22 column screen display. The Vic-20 machine was introduced in 1979 or 1980, whereas the Commodore 64 came out in August 1982. In 1979, RAM cost considerably more than it did in 1982. To keep the cost of the Vic-20 as low as possible, it was given in stock configuration hardly any RAM at all! I think it only had 8 kilobytes of RAM total, with only 3.5 kilobytes accessible by the language BASIC.
Other ways of keeping the cost down for the Vic-20 is having it use a tape recorder for storage and a conventional television as a monitor. Still another way of keeping costs down was making the case small, fitting the entire computer in what seemed to be only a keyboard and keyboard case.
Like the microprocessor of the Commodore 64, the microprocessor of the Vic-20 still needed an operating system, a character set, and the BASIC computer language. These were done with ROM chips, which were much cheaper than RAM at that time.
There was no getting around screen memory being in RAM, though. The fewer letters that could possibly be put up on the screen, the less RAM the screen memory would need. This is why the Vic-20 had the annoying 22 column wide screen. It used much less RAM than having a 40 column or 80 column screen.
With scrimping like that on screen memory, the Vic-20 in stock configuration when turned on had 3.5 kilobytes free for BASIC. That is, roughly one to one and a quarter typewritten page. That is not much space to put programs and data into. This is why I found the stock Vic-20 nearly useless. I felt a memory expansion essential.
Yet, the 6502 microprocessor in the Vic-20 could address 65,536 bytes. Most of those addresses in the Vic-20 were simply empty! Nothing was there.
When I bought my Vic-20 in late May of 1982, the retail price of a Vic-20 on its own was about three hundred dollars, although I bought mine used. I then bought a 16 kilobyte memory expansion for $110, where I paid the retail price. That is, the memory expansion I bought was more than a third of the price of the computer itself if I had bought the computer brand new! This is a reflection of how expensive RAM was at that time.
Getting ROM was comparably cheap back then. This resulted in a big difference in the games that were available for the Commodore Vic-20 and most of the games that soon would come out for the Commodore 64. Most commercial games for the Vic-20 came out as cartridges. These were about five inches wide, three inches deep, and an inch thick. One edge showed copper traces of a printed circuit board. The plugged into a socket of the Vic-20.
If one opened up a cartridge, it contained a ROM. Common ROM sizes were 4 kilobytes, 8 kilobytes, and 16 kilobytes.
At that time, a typical game cartridge cost about thirty to forty dollars. Reflecting my poverty of the time after nearly going broke to get the Vic-20, it is probably not surprising that I had no cartridges other than my RAM cartridge.
The Commodore 64 could use game cartridges as well, but not those made for the Vic-20. The Vic-20 cartridges would not even fit in the socket for the Commodore 64. A few games and other programs actually did come out on cartridge for the Commodore 64 very early on, but the vast majority instead came out on floppy disks. Floppy disks were a far less expensive media than a cartridge. Also, each single-sided low-density floppy disk held 170 kilobytes, while most cartridges of that time held a maximum of 16 kilobytes. Not only that, disks can be written to, so some games could take advantage of that to record positions, scores, and so on even after the computer was turned off and on again. The games on cartridge forgot everything with a reboot.
Knowing the importance of game cartridges to selling the Vic-20, a block of empty space was allotted for the ROM of game cartridges to fit into.
One of the more idiotic decisions in the Commodore 64 was to have a similar space allotted, discontinuous from the memory for BASIC, for cartridges. What it did is chop down the memory that BASIC could use for no very good reason.
The Commodore 64 had 64 kilobytes of RAM included. How Commodore did this while keeping the cost down is why the Vic-20 computer was actually slightly faster than the Commodore 64! It also meant my printer was not compatible with the Commodore 64.
(In 1985, John Stilwell and I forced my Commodore 1515 printer to be compatible with the Commodore 64. We pulled out the ROM in the printer, which controlled what the printer did. We replaced it with an EPROM that a friend of John’s...I forgot who that was...coded with the program copied from the later Commodore 1525 printer that was compatible with the Commodore 64. EPROM means electrically programmable ROM. It still took some equipment to code an EPROM, but it was relatively modest and John’s friend had it. Incredibly, that worked like a charm! I almost felt like a real electrical engineer when John, his friend whose name I forgot, and I pulled off that trick!)
I had paid $110 in late May of 1982 for a 16 kilobyte RAM cartridge. That type of RAM was called static RAM. What this meant is as long as the power remained on, it remembered what it was told.
Another type of cheaper RAM was called dynamic RAM. What was in those chips was simpler, so cheaper to make. There was as penalty to be paid. It needed a refresh signal every so often.
This could be compared to two grade school students. Imagine we have a wonderfully good student who gets A's in everything and never did anything wrong. Let us call him James. Then, you have me when I was in grade school!
Imagine the teacher tells James to remember something.
If the teacher asks James ten minutes hour later, he will give the right answer. If the teacher asks him an hour later, James will give the right answer. That is similar to static RAM.
Now imagine the teacher told me to memorize this. If he asked me ten minutes after he told it to me, I would give the right answer. If he waited an hour, though, I would have looked out the window at the melting snow. My mind would have wandered. An hour later, my answer would likely be wrong.
However, imagine the teacher knew how distractible I was. After ten minutes, she snapped at me, “Joe, do you remember what I told you?”
The delay was short enough that I do remember, so I replied, “Yes, it was...”
She cut me off, “I don’t need you to tell me yet. Just remember it.”
Ten minutes more went by, then she interrupted what she was doing to ask, “Joe, do you still remember?”
“Yes, ma’am,” I replied meekly but honestly.
She kept that up until an hour goes by, then has me give the class the answer, which I do correctly. I remembered although left to my own devices and not being told every ten minutes to keep remembering it, I know I would have forgotten it in an hour.
That is more like how dynamic RAM works. Every so many milliseconds, the processor has to tell the dynamic RAM, “Hey, guys! Remember what I told you before!”
As long as the dynamic RAM gives those reminders frequently enough, they do remember flawlessly. Without the reminders, they forget.
It slowed the grade school teacher down to have to every ten minutes tell that distractible student Joe to remember what she told him. She could have gone faster and covered more material if all the students had been like James and remembered on their own without constant reminders.
Similarly, since the Vic-20 used static RAM so did not need the processor to keep doing those reminders...actually called refresh signals...it went slightly faster than the Commodore 64, which with dynamic RAM had to have the processor repeatedly stop what it was doing to send them.
The timing difference because of those refresh signals is why the Commodore 1515 printer would only print a few lines then stop when connected to the Commodore 64. (That is, until 1985 when John and I changed the brains in my printer by swapping the ROM. That removed the timing confusion.)
So, dynamic RAM rather than static RAM was part of the reason the Commodore 64 could be made with so much more memory than the Vic-20, but not as much more expensive as it would otherwise have been.
I followed all that when Alan explained it, but still did not see a great advantage over the Commodore 64 over my Vic-20 other than the 40 column display rather than 22 column and about double the RAM available in BASIC to what I had with my memory expansion.
It was obvious Alan’s disk drive was an advantage over a tape player. Alan had bought a tape player as well, by the way, for backward compatibility. If my finances were better, I could have gotten a disk drive too. The Commodore 1541 disk drive was compatible with both the Commodore 64 and the Commodore Vic-20. The timing problems with the refresh signal in the Commodore 64 had all been take care of.
I read someplace that an earlier Commodore 1540 disk drive had the same timing problem when used with a Commodore 64 as my Vic 1515 printer did, but I never saw a 1540 model, so that did not much matter to me.
Thus, Alan and I exchanged programs by tape, even though he much preferred floppy disk.
Alan seemed frustrated with my ignorance at not appreciating how much better his system was then mine. He had spent so much time and effort explaining the differences in the Vic-20 and Commodore 64, but I still did not comprehend this! It involved much more than a 40 column display and having more memory accessible in the computer language BASIC!
There were some differences that were present and somewhat important, but not for my academic needs for what I was doing and going to do with my Vic-20. The sound chip, or SID for Sound-Interface-Chip, in the Commodore 64 was more sophisticated than the Vic-20. The sound in the Vic-20 was not bad. It had three sound registers that produced a tone of constant frequency and volume when you told them to do it. It had a fourth sound register that was tied in to a clock or randomizer to add a sort of constant hiss. That last was used often in videogames for explosions and noise-like sounds of that nature.
The Commodore 64’s SID added attack rate, decay, sustain, and some other things to its sound registers. It had four of them, just as the Vic-20 did, with the fourth having that deliberately hissing quality as well. These other parameters let the sound be changed to sound like a piano, a church bell, a guitar, a violin, and so on.
I felt that was neat, but was not anything I was likely to use for a class. What my professors would get was some numbers or plot or report that came out of my printer. They were not going to come to my room to hear the computer!
Another feature of the Commodore 64 was called Sprites. The Vic-20 did not have these at all. I find Sprites hard to explain. They let programmers easily make iconic figures that can move smoothly around the screen, moving pixel by pixel. Collisions between two Sprites were easy to detect. What it seemed Sprites were mainly used for was writing nice videogames. A Sprite could be made to look like a spaceship, or a figure of a man, or a little race car.
By telling me about the SID and the Sprites, Alan convinced me that the Commodore 64 would eventually much surpass the Vic-20 as a game machine.
However, I had spent most of the summer trying to find a way to convince Dad that my Commodore Vic-20 was not just a game machine, but a serious computer. I had finally convinced Dad at the end of the summer by showing him how he could do a statistical analysis using the computer language BASIC with his numbers put in DATA statements, editable with a full-screen editor, rather than typing the numbers into a calculator with a one-line display.
I still remember Dad’s surprise when it worked as well as it did. (What he was doing I would instead do with a spreadsheet like Microsoft Excel today in 2006. It was only slightly harder to do it with DATA statements in BASIC. The task in BASIC was absurdly easier than typing a long list of numbers into a calculator.)
Dad had then looked through the list of mathematical functions built into the Vic-20 and said in disbelief, “This is a real computer!”
It took most of the summer, but I had finally convinced him that my purchase was more than just a time-wasting game machine. I felt if I told Dad about Sprites and the new SID chip, I might make him return to his original viewpoint! Neither of those features of the Commodore 64 would have affected doing linear regression lines and problems of his like that.
My own attitude on computer games was contradictory. I was fanatical about getting through the electrical engineering program. I had not been too good of a student until my last two years of high school, so I knew I had an uphill battle. To succeed, I stopped reading most novels. I came close to stopping watching television.
After I found out that I was not to have a summer job in 1982, I stopped putting quarters in videogames. Although there were rare exceptions, I have hardly ever plugged my own quarters into videogames since then!
Although we would not play them, Alan and I would go see the latest games to see what was going on with graphics and sound. Scott Bille, Dan Main, and Richard Knowles were far more likely to actually toss in a quarter and play. Like me, Alan wanted to see what the new games did, but not really play them.
Videogames on my Vic-20 were different. I mentioned I did not own any game cartridges then. (I do now in 2006. I bought a bunch off eBay, like Donkey Kong and Defender, often for just the cost of shipping. This is false nostalgia, because I could not afford any game cartridges back in my undergrad years!)
However, not all videogames for the Vic-20 were on cartridges. Some were programs that I could load off tape.
Various computer magazines of that era had type-in programs. While some of these programs were utilities, many were games. I think in the end I spent more time typing in and then debugging games from the magazines then I did playing them!
I firmly believe that the number of videogames I did play as an undergraduate did me no perceptible harm. In similar fashion, I did not actually read no novels whatsoever, but did make it through one or two a semester. I think that did no harm either. If I had kept my high school habit of reading one or two novels every week, that would likely have took so much time to greatly harm my academic performance.
I could see in others what my Dad had feared about videogames. Some students I saw did sink into a time trap of videogames. However, I saw even more sink into a time trap of excessive television watching, so I am not sure how much blame videogames really deserve on their own.
At any rate, there was much less temptation to spend too much time with the games available on the Vic-20 compared to what later came out for the Commodore 64 when the games took truly advantage of the features of the new computer that Alan was telling me about. Some of the Commodore 64 games that came out a few years later were incredible!
However, Alan then let me know that yet again, I was not seeing the big picture. I was still missing the main advantage of the Commodore 64 over the Vic-20.
It turns out there really is one important but subtle difference between the Motorola 6510 processor in the Commodore 64 as compared to the Motorola 6502 in the Vic-20. The 6502 was also in many other personal computers of the eight-bit era.
Something was done inside the 6510 so that while the processor initially addressed a ROM chip, it could be switched to address RAM instead in the same address space.
Let me start with a simple example. The character set was loaded in ROM. Each letter was on that machine made of a grid of pixels that was eight-by-eight. A capital letter I might be made as below. Imagine everywhere there is a 0 it is empty and every place there is a 1 is a dark square. Can you see the figure I?
00111100
00011000
00011000
00011000
00011000
00011000
00111100
00000000
Therefore, to define what the “I” looks like takes eight bytes. The pattern of ones and zeros gives the letter its shape.
On the Commodore 64, you can copy the character ROM over to RAM that is in exactly the same address space! Then, by setting something else, you can switch the microprocessor from reading the ROM to reading the RAM at the same address space instead. It took the 6510 microprocessor to do that.
If all you did was copy the ROM to the RAM, then things still work exactly the same way. Nothing has yet changed. Each “I” will still look like an “I.”
You cannot change a ROM without physically changing the chip itself in the circuit board. RAM can be easily changed with software. You can make the “I” turn into any shape you want by changing what is in the character set after you copied it from ROM to RAM.
This can be done on the Commodore 64 without any sacrifice at all in the amount of RAM that the BASIC computer language sees. When a letter gets put to the screen, it just puts up what the character set map tells it to put up. Because of the neat feature of copying the ROM to RAM then the microprocessor using the RAM in the exact same address space, no sacrifice in memory has to be made to redefine the character set.
The character set in the Vic-20 could be redefined as well, but the crucial difference is it will sacrifice already scant RAM memory space! What one would do in the Vic-20 is copy the information in the area of address space where the ROM sits to an area of address space where there is RAM. Then, one sets some pointers that tells the microprocessor were to find the character set to the new space off in RAM. RAM and ROM on the Vic-20 could not be at the very same address space.
So, it works to do this on the Vic-20, but it eats away your otherwise available RAM. You cannot have RAM and ROM sit at exactly the same address space, then switch the microprocessors between them like on the Commodore 64. The 6502 simply will not do that, although the 6510 will.
So, on the Commodore 64, you could if you wanted switch the included character set for, say, an italics font that you created, without any apparent cost to you in available RAM.
Alan excitedly explained that this did not just apply to the character set. The same technique could be used for the included BASIC language and for the operating system.
Although I could be thick-headed, I felt I finally followed what Alan was so excited about for the possibilities of his new computer.
On the Commodore 64, the operating system, the language, and the character set could all be changed without losing access to other RAM. That meant one could upgrade and change the system. In contrast, the only way to change those in the Vic-20 was to change the chips themselves, which was unlikely to ever happen.
Alan was happy that I finally got it. He explained that other languages would come out for the Commodore 64. He talked about how soon he would be able to get Pascal (which I had heard about already, but did not know) and C (which at that time I only knew as a letter of the alphabet). Not only would other languages come out, but Alan confidently predicted other operating systems would come out for the Commodore 64. He predicted some of those would be multitasking!
(I want to break in with a note from 2006. For most people who know about the Commodore 64, even for those who owned them, what Alan was predicting in 1982 did not seem to have ever happened. Actually, it did. Multitasking operating systems, versions of C, FORTRAN, and Pascal, and so on did appear. There was even a system called GEOS that made an interface and screen for the Commodore 64 that looked somewhat like an Apple Macintosh! Unfortunately, this was years later and by then, the eight-bit computer era with machines like the Commodore 64 and Apple II was in its death throes. The sixteen-bit computer era with machines like the IBM PC and its clones, the Apple Macintosh, and. the Commodore Amiga had really taken off. So, those who wanted things like Pascal, C, and so on generally did it on an IBM PC or clone, not on any eight-bit style machine like the Commodore 64, even after the Commodore 64 really could finally do it.)
Alan had something else to be excited about with the new languages that he correctly claimed would come out for the Commodore 64. This had as much to do with Alan’s assumption, also correct as it turned out, that most Commodore 64 purchasers would spring for a disk drive as it did with the internals of the Commodore 64 itself.
For personal computers of the late Seventies and early Eighties, a version of the language BASIC was included, usually internal to the machine in a ROM chip. An important point is it is what is known as interpreted BASIC, not compiled BASIC.
In the early 1980’s, it seemed students were not allowed to major in Computer Science unless they took an eternal pledge against the language BASIC! Yet, it was this same BASIC language that gave most of the momentum to personal computers taking off in the late Seventies and early Eighties.
It turns out there really is much to dislike about BASIC and especially about interpreted BASIC. The Computer Scientists were not just hating it for the sake of hating it. They could see deficiencies in it.
Interpreted BASIC made great sense, though, for the highly limited technology that was available in an inexpensive personal computer in the late Seventies and early Eighties. What made sense for a personal computer system with 16 kilobytes of RAM and a tape drive for storage would not make sense for a mainframe computer with hundred of kilobytes of RAM and a 20 megabyte hard disk.
Let me explain what is meant by interpreted versus compiled. Let us assume I wrote a four line program. Let me number the lines from one through four. Most lines are not numbered by one, but let us ignore that. Then, in interpreted BASIC, I run the program. The first line is read in, the meaning worked out by the microprocessor, and the instructions executed. Provided no error occurs and there is no jump to a different line, the second line is read in, the meaning worked out, and the instruction executed. Let us assume there is an IF-THEN statement that jumps over the third line to go to the fourth. The fourth line is read in, the meaning worked out, and the instructions executed.
What if the third line was filled with gibberish? Even if it had statements that had no meaning for the computer, these would not be seen if the line was not part of the sequence that we went through. Bad code might not be found if it is not a line that happens not to have been run yet.
Now let us assume instead this same program was run through a compiler. All the lines are read through and checked for syntax errors. If there were gibberish on the third line, this step would have found it.
It is fairly common that if you take code that appears to work fine in an interpreted BASIC and run it through a BASIC compiler (many BASIC languages are available as compiled today, but that was very rare and very expensive back in the early Eighties), a number of errors in lines that were not hit in the previous runnings in the interpreted BASIC are found by the compiler.
This is one big advantage of the compiled program. Let us assume the gibberish is fixed in the third line, then consider another advantage of compiled programs.
Most compilers deal with one file that has the source code. That is, a file that has the commands and so on that a human can read and follow. When asked to compile the program, another file is created called an object file. If the object file is made without error, then from the object file, an executable file is made.
When a user runs the program, they are really running the executable file.
That creation of an object file and the executable generally creates far speedier code then working out each line one at a time as is done with an interpreted language. With the compiled program, the executable file has already been put into the format the computer really understands. Therefore, most compiled programs are much speedier than those run in an interpreted language. For the same program, the compiled code can be hundreds of times faster than the interpreted code.
All the languages I used on mainframe computers in 1982 were compiled languages. However, most of the time, the mainframe was so overloaded that I would see the output faster on the Vic-20 with an interpreted BASIC program than I did on the mainframe with a compiled program! I definitely could get an output on paper with my own printer on the Vic-20 system much faster than I could on the mainframe!
Another big issue in the very early days of personal computers is the compiled program deals with three separate files: source code, object file, and executable. An interpreted BASIC program generally involves only one file, which is the source code. When the interpreted program was run, the code was interpreted (hence the name interpreted) one line at a time internally in the computer.
If one has a hard disk, it is easy to work with three different files at the same time. If one has a floppy disk drive, it involves more delay and grinding on the drive, but still not too bad. If one only has something like a cassette tape for storage, as I did on my Vic-20, it would be very painful dealing with three separate files. Would I use one cassette for the source code, swap it out and use a second cassette for the object file, then swap that out with a third cassette for the executable? That would be a nightmare.
There were other issues with the language BASIC being worse than other languages. It was easy to write what was called spaghetti code. That is, code that is as hard to follow as it would be to follow noodles in a plate of spaghetti. A common command used in BASIC was GOTO. That means go to some other line.
From a theoretical point of view, there is no reason one should ever have to use a GOTO. Conditional statements are different. The code might have good reason to jump somewhere else if some condition is met. There is no theoretical reason to ever have an unconditional GOTO, yet they are common in many BASIC programs.
Therefore, BASIC does not force good programming habits. It really does not prevent good programming either, but it does not force it like a language like Pascal.
Imagine being a teacher trying to grade a computer program. Computer code in BASIC can be so snarled up with GOTO’s that it is hard to figure out what is going on. While bad and confusing code can be written in other computer languages as well, it is not as easy to make it messy as it is by tossing in some GOTO’s in BASIC.
For the BASIC in the Commodore Vic-20 and Commodore 64, there was also a problem of a garbage collection cycle that could lead to unexpected delays if a program used many string variables. I think I will just say that problem exists and leave it at that. By then, the PET computers had a new version of BASIC that I think eliminated the garbage collection problem. That is, the PET had CBM BASIC 4.0 by then, while the Commodore 64 had BASIC 2.0.
What Alan was explaining to me is that the BASIC language in the Commodore 64 would be changed quite easily just using software and data on a floppy disk.
I had much difficulty understanding all this in 1982, even though Alan explained it well.
Alan’s main point seemed to be that by owning a disk drive and given how BASIC could through the ROM to RAM swap be changed into entirely different language without the memory penalty of losing the space where BASIC had been. This made it seem that compiled languages would soon be out for the Commodore 64 with the computer still having enough RAM free to be useful. Unlike the Vic-20, Alan believed the Commodore 64 would soon do what a Computer Scientist believed a computer must do to have value.
The only problem with Alan’s ideas is it took years for them to happen. Most people in the meantime coded the Commodore 64 in BASIC about the same way I was doing it already on my Vic-20. However, given Alan’s enthusiasm at the time, I thought these new languages for the Commodore 64 might be out within the next month! Thinking Alan might be right, I felt foolish about squandering my fortune on the obsolete Vic-20!
However, I simply could not have gotten into the personal computer game with a Commodore 64. Not given what Alan paid. Just a Commodore 64 ($595) and a black-and-white television as monitor ($60) would have cost more than my entire Vic-20 system, including the television, the tape drive, the memory expansion, and the printer.
. So, although I now knew my system was already hopelessly obsolete and limited, it had gotten me into the personal computer game. By all rights, somebody of my weak finances should not have ever been able to afford a personal computer in 1982! Also, despite the limitations, which I admit were great, my Vic-20 system was doing things for me that I badly needed a computer to do.
I suppose it would be like having a Model T Ford after the newer Model A came out. Drum brakes on all four wheels in the new car, while the T used the transmission to brake. Much faster overall speed, smoother ride, and so on in the new car. If the alternative was to walk, the Model T would look pretty darn good, even if the new cars are definitely superior!
From that viewpoint, my Vic-20 system still looked useful to me. I did not want to go back to typing on my manual Royal typewriter rather than a word processor and a printer!
As another example of what I did back then, I was taking a class called EE 224: Electric Circuits taught by Paul E. Gray. He had written or collected a series of FORTRAN programs to do various tasks in the class. We made graphs called Bode plots, for example. This was not pixel-level graphing, but using an astrisk, *, for the dot, but since that was what we were doing on the mainframe as well, it was easy to do on the Vic-20. We solved complex number matrices. One program even solved polynomial matrices.
(Most of what we did is in 2006 built into my HP scientific calculator, as well as most modern scientific calculators, but this was certainly were not in calculators of 1982!)
I found it easy to convert these FORTRAN programs to BASIC and run them on my Vic-20. A little debugging and testing, then they worked. I showed my printouts to Dr. Gray, who was delighted! He encouraged me to do my homework that way.
So, despite what the Vic-20 could not do, what I was doing with it...needing my printer and memory expansion to manage it as Dr. Gray’s converted code would not fit in 3.5 kilobytes but most of it would fit in 19 kilobytes...worked wonders for me. By my Junior year, some of the computer programs we were doing for class were too large for the memory of my Vic-20, but in my Sophomore year, nearly everything fit.
I was also typing up my physics lab reports in the word processor. My physics teacher loved that!
So, the Vic-20 paid off in spades for me that autumn semester of 1982. At least, in terms of academic performance.
Another thing that consoled me about my purchase is that despite Alan’s lofty and in the long-run accurate predictions of what the Commodore 64 would eventually do, there were almost no Commodore 64 specific software programs available in the autumn of 1982! A mountain of such software would come out soon, but it was not there yet. The machine was just too new.
While there was almost no Commodore 64 specific software for Alan’s new machine because he bought it so soon after its introduction, that did not mean he had no software at all to run on it.
There were many programs written in a generic form of BASIC. These only used the alphabet as characters with no special graphics whatsoever. Most of these produced no sound, not even a beep. There were magazines and books of these programs. The advantage is they with only minor modifications would work on any system that used a version of the language BASIC.
Those programs worked fine on Alan’s new computer. Some took a little tweaking on how to input keystrokes, but then most worked.
Machine language programs for the Vic-20 did not work on the Commodore 64. For example, a clone of Pac-Man that was very nice on the Vic-20 did not work at all on the Commodore 64. There was just far too much that was different. Location of video memory, amount of video memory, parameters the sound chip needed, and so forth all differed drastically. Converting any of those programs would have been a monumental undertaking. For most of these programs, it would be easier to start over!
In contrast, programs for the Vic-20 written in BASIC generally did work or could be made to work without too much effort on the Commodore 64.
The bulk of the programs Alan had that first semester that he had his Commodore 64 came from another source. With my Vic-20 with the memory expansion, I benefited from what he found in this new source.
My Vic-20 was the predecessor of the Commodore 64. Commodore had a machine that was the predecessor of my Vic-20. It was the Commodore PET. The production of the PET did not stop when the Vic-20 came out, but the PET did get much more sophisticated. The early PET and the later PET are quite different machines.
The Physics department of Platteville had an early PET. For the PET, the idea was to sell a complete computer where it only had to be plugged into the wall like an appliance. (Years later, Apple would successfully sell a similar appliance-like system with their early Macintosh computers. The PET was far earlier that than, though. It came out as a contemporary to the Apple II.)
The PET the Physics department had a white, angular box made of sheet metal. It covered a black-and-white monitor, a keyboard, and a tape player. Thus, it was a complete system with monitor, computer, and keyboard all in one box. No cables had to be connected. All that needed to be done was to be plugged into a wall outlet.
This was in contrast with the Vic-20 that needed the tape player plugged in and the video cable plugged in as well, then some sort of television or dedicated CRT monitor connected for the other end of the video cable.
The intention of the early PET seemed to be to sell it to something like schools or business as a complete system. Just plug it in and go.
The Vic-20 was designed differently. It was designed to be rock bottom in terms of price, using a television as a monitor since many people already had a television.
Something I hated about the early PET that the physics department had was the keyboard was nearly impossible to touch type on. I did some physics project on it, so I did use that early PET for something, although for the life of me, I do not remember what the project was.
The keys were a little too close together. The keys were not lined up like they are on a typewriter either. This was called the Chicklet keyboard, nicknamed after a type of rectangular shaped candy. I really, really hated the Chicklet keyboard. It was only slightly better than the membrane keyboard on Alan’s Sinclair ZX-81, on which I had learned the language BASIC the previous semester.
Commodore did not repeat that mistake with the keyboard. The Vic-20 and the Commodore 64 had nice keyboards, excellent for touch typing. The later PET computers had nice keyboards as well. It was only the very early PET models that had that dreadful Chicklets keyboard.
I think the Commodore PET would have done far better against the Apple II if Commodore had just put a usable keyboard on the PET in the first place! History would likely have been much different. They did not, though.
Various versions of the PET had been around since around 1978 or so. This meant there was a good selection of PET software that existed by 1982.
The Vic-20 had some things going for it over the PET. The name Vic is not just supposed to be a cute name, but an acronym that stands for Video-Interface-Chip. The Vic-20 could do high resolution graphics. That is, at the pixel level. (The Vic-20 had monsterously large pixels by the standards of 2006! The screen was about 176 pixels by 160 pixels. I am using 1024 by 768 on this Windows XP computer.)
The early PET could not create pixel level graphics. The hardware simply was not there. Consider the example from above of redefining the character “I” to some other shape made of an eight-by-eight matrix. In the Commodore 64, that could be done by a ROM-to-RAM copy in the same address space, then the change to read the RAM, with not loss in other addressable RAM. With the Vic-20, it could be done, but only with a loss of useable RAM as the address space for ROM could only ever see that ROM. In at least the early PET computers, changing the character set simply was not possible at all unless one physically replaced the ROM chip itself. The “I” would look like an “I” on the PET and that was that.
On the Vic-20, which was launched in 1980, it was common to change just some of the letters for videogames. One would make a few letters look like flying saucers and others like rocket ships for a space videogame, for example. One did not have to convert every letter. That was how games with redefined characters could be written but still leave enough RAM for other things like the code itself.
Vic-20 also could use bright colors on the monitor or television while the early PET only did black-and-white. Not shades of gray like a black and white television either, such as if a Vic-20 where hooked to a black-and-white television like I used mine.. The PET had pixels either on or off. Nothing else. No shades of gray. Just black-and-white thinking.
Furthermore, the Vic-20 had a sound chip with four sound registers while the PET could do little more than make a beep through its internal speaker. As I mentioned above, the Commodore 64 had even more sophisticated sound than the Vic-20.
Alan once informed me that the PET computer could produce sophisticated sounds, even synthesized speech, through clever machine code programming. I never saw that done, but I guess it is possible. Through BASIC, about all the PET did for sound that was easy was BEEP. By contrast, the Vic-20 manual included code to make the sounds of ringing telephones, explosions, gunfire, engine noises, and various other things.
The PET did have one great advantage over the Vic-20. The early PETs had a 40 column display. The later PETs had an 80-column display. The Vic-20 had a 22-column display. Many tasks are much easier with more columns in the display.
Unlike the Vic-20, the C-64 had a 40 column display. What this meant was that with little or no changes, the C-64 would run almost all the early PET software properly with no changes whatsoever!
Alan acquired a couple floppy disks full of programs from a PET Users Group.
Some 80 column software, Alan was able to kludge and adapt to work on the 40 column Commodore 64. Other 80 column programs he never got to work. As far as I know, everything on those disks for the PET written in BASIC in 40 columns worked perfectly on the Commodore 64.
I realize 80 columns are much easier to work with for tasks like word processing. I have seen and used some software programs for the Commodore 64 that give it 80 columns by making all the letters 4 pixels wide rather than 8 wide. Some of the characters look a little funny, but most can be read. With a dedicated monitor on the Commodore 64, the 80 columns created this way are easily readable. When I used a television as a monitor, it often was not. I suspect part of the reason the Commodore 64 had 40 columns even though the Commodore PET model by 1982 used 80 columns is the PET forced the use of a dedicated monitor, as it was part of the same box the computer was encased in. I think the idea was many Commodore 64 users would use a television as a monitor. As it turned out, nearly everybody I knew with a Commodore 64 also spent the money for a dedicated monitor. As with the choice of the unusable Chicklets keyboard on the early PET, I wonder how much more seriously the Commodore 64 would be thought of today if Commodore had put an 80 column display on it.
Despite the 22 column limitation of my Vic-20, I got some of the PET programs to work on it. The biggest factor was memory. I found most of the programs did fit in 19 kilobytes of free RAM accessible by BASIC. Almost nothing would have worked on my Vic-20 from the PET disk if I did not have that 16 kilobyte memory expansion card, though.
While the internal electronics of the PET computer did not have the capability of doing pixel-level graphics on the screen, this did not mean that it had no graphics capability at all!
The IEEE and some American Standards committee had come up with a computer “alphabet” called ASCII. In contrast, the IBM mainframe used a system called EBCDIC. IBM owned and controlled EBCDIC, while anybody who wanted could use ASCII for free.
Somewhat inexplicably with the previous fanaticism the IBM company had for keeping firm control of everything, the IBM PC came out using not EBCDIC, but ASCII like the rest of the world used! It proved to be a brilliant decision, opening the IBM PC up to easily use all sorts of software and hardware, like many pre-existing printers.
Commodore at that time did not use ASCII, at least in internal memory! What it used was sometimes called Commodore ASCII. It really was not ASCII, but it was easily translatable to actual ASCII.
An interesting historical aspect of true ASCII as defined by the standards committee is that it is a seven-bit code. Many people know that early personal computers typically stored one letter in one byte, where a byte is eight-bits. Two raised to the eighth power is 256. So, each byte in a computer could store a value between 0 and 255. That is 256 values because 0 has to be included.
With a seven-bit code, that gives 128 values as shown by taking two to the seventh power.
Yet, that is certainly enough to have both the upper and lower case alphabet, many symbols and punctuation, as well as various control keys that did various things like tab or carriage return.
The reason for true ASCII being a seven-bit code was that the eighth bit was relegated to be used as a parity check. By the time I got into personal computers, this never seemed to be done. That is, use of a parity bit was not uncommon, but it was tacked on as an extra bit to make nine. It was not wedged in with the other eight bits.
If one uses the full byte giving 256 values, that doubles the numbers of symbols possible. Thus, IBM computers used what was called IBM Extended ASCII, which filled up the rest of the space. These were chose to be a mixture including some of the most common Greek letters, some additional math symbols, some letters with umlats or apostrophes used in various foreign languages, and a few box and lines. Before word processing programs allowed switching between many dozens of fonts, these extended symbols greatly affected what could be done with a word processor.
At one time, I found it very important to know this. In the word processor I am typing this on in 2005, it has about a hundred different fonts available through a pull-down menu. I no longer have to get cute and remember extended ASCII symbols if I want the Greek letter sigma or something. (I used Greek letters often when I was at MIT Lincoln Laboratory from 1986-1991, which is why I had a table of IBM Extended ASCII by my computer at all times. In 2006, IBM Extended ASCII is still buried in the machine I am typing this on somewhere, even if I never see it when using Microsoft Word.)
That is what IBM did. I liked that IBM included many Greek letters, although it did not have all of them. What Commodore did instead was different. Commodore seemed to have the intent of easily creating a good amount of graphics on a machine like the PET that did not allow pixel-level graphics. The Commodore ASCII...remembering it does not really deserve the title of ASCII at all...was filled with graphical characters. It had lines of varying thickness. It had circles and quarter-circles. It had triangles and crosses. It had boxes of varying size.
The Commodore also did something significant with its extended not-quite-ASCII. It allowed every symbol to be reversed in color. That allowed the various lines, triangles, and so on to do much more when using them to compose pictures.
Using Commodore’s character set, many complicated screens that appeared to be made using pixel level graphics could be written. These really came from artistic use of the extended graphics characters, not from pixel-level redefined graphics.
Even though the Vic-20 and the Commodore 64 could do pixel level graphics, it was often faster and easier to do them with the extended Commodore character set.
This made it so that some of the programs and especially games on the disks Alan got with PET programs were considerably better than I would have expected for a PET machine that did not do pixel level graphics. Because of the 22-column screen, most of these would not work on the Vic-20 without extensive modifications or perhaps not at all ever.
The early PET programs back when PET’s came with a 40 column display worked flawlessly on Alan’s new Commodore 64 with its 40 column display. The C-64 had inherited essentially the same Commodore letter and symbol system that the PET and Vic-20 used.
Some of the programs on Alan’s disk were text only. With a few adjustments, I got some of those to work on my Vic-20. It would only work on a Vic-20 with significantly extended memory. Many of the programs were around 16 kilobytes long, more or less.
An example of one that worked was called Dogstar. It was a text adventure game that involved running around the Deathstar from the Star Wars movie. The first screen showed a Darth Vader mask created very well using the Commodore symbols that I mentioned above. That was the only graphics in the game, though. After that, it was pure text.
I trimmed out the entire Darth Vader mask to get the game to work on my Vic-20. It simply could not be fixed to look right in 22 columns, although it looked slick on Alan’s C-64. The game played on my Vic-20 after that, though. It always worked fine on Alan’s Commodore 64 without Alan doing a thing to it.
Text adventure games of that era tended to be terrible at interaction with other characters. What tended to happen if your character ran into another character were simple messages like, “You are captured,” “You died,” “You were blown up,” and so on.
Another text game that I got to work on the Vic-20 involved roaming around what was supposed to be King Tut’s tomb.
There were some others as well. I soon found I did not care for these text adventure games. I spent far too much time trying to get the syntax just right so the parser could understand what I wanted to do. Many games were also of the type where if you could not figure a puzzle, and some were far from obvious and even outright silly, one was simply stuck.
One game I particularly liked, though. It was called Castle. I have no idea who the original programmer was. Alan was to do something interesting with that game the next school year, but I will skip that story for now.
So, although the great software that Alan knew the Commodore 64 was capable of did not exist, he was at least up and running with the PET software and as well as the type of Vic-20 software that was written in BASIC and that did not require fancy graphics so was easily adapted.
However, then tragedy struck. Alan’s computer, only a few weeks old, broke.
I was to learn later that the early Commodore 64 computers were notoriously unreliable. The video chip blew. The power supply overheated, seemingly just if you sneezed. If you have a carpet in the room or wear a fluffy sweater and touch the computer, you can kiss the joystick port chip goodbye.
The Commodore 64 was a notoriously delicate machine. Some worked forever flawlessly. Many others died very early deaths. As confirmation of this, magazines reported on videochip trouble (Compute!, Issue 38, July 1983, p. 10.) and on complex interface adapter or CIA chips blowing. (Compute!, Issue 55, December 1984, p. 10.).
There are various reasons why the Commodore 64’s were so delicate. It includes things like at one point in an attempt at cost reduction, instead of sheet metal inside the plastic case to do radio frequency (RF) shielding...to prevent neighbors from complaining of interference on the televisions or things like that...cardboard with a metallic coating was used. The cardboard held the heat.
Most of the Commodore 64 power supplies were encased in a solid brick of epoxy. Those were essentially impossible to fix, including not being able to simply replace a fuse in there! What good is a fuse if you cannot get to it?
As a counter-example, a friend of mine once unplugged a cartridge or modem when my Vic-20 was on. The instruction manual says not to do that with the computer on. It turns out the copper trace can short two pins on the socket, zapping the power supply. That happened to me...well, to my computer when my friend did this. However, the Vic-20 power supply has a fuse in it. I removed four screws and put in another fuse, then put it back together. In minutes, I was back in business. On the Commodore 64, at least in one stage of its production, you could not replace the fuse in the power supply unless you were willing to chip away for hours at a solid block of epoxy! Not only that, the epoxy retained heat, contributing to the overheating.
In the mid-Eighties, there was a booming trade in alternative manufactured power supplies for the Commodore 64, designed with things like a fuse that could be reached! The power supplies included with Commodore 64 itself were just that bad!
Buffering just could not have been what it should have been for the joystick ports to blow with just the slightest static electricity.
For Alan, his computer did not work much at all that autumn semester of 1982. I think he was hit by both a bad video chip and by a bad power supply, as well as some other problems.
Each time, the repairs were still under warranty. Still, it was horrible for him because he had to travel to Madison each time, which was about sixty miles from Platteville. Every time his computer went in the shop, it was another month or so before he got it back.
In later years, the Commodore 64 was a commodity item. If one had similar problems as Alan had just after buying it, most places would just swap it without comment. Whereever it was that Alan bought his from in Madison, though, they were intent on actually repairing it rather than replacing it.
The end result was his system was in the shop more than it was out of the shop the entire autumn semester of 1982 and perhaps the start of the spring semester of 1983.
One time when he knew the Commodore 64 itself would be in the shop for another three weeks, he lent me the disk drive. Using it with my Vic-20, I could appreciate why he valued having a disk drive so much, although I still loved having a printer too. I would not want to replace the printer with a disk drive, but having a disk drive was very nice! I returned the disk drive when the three weeks were up, of course. It converted me to the value of a disk drive. If I had any way of getting the money for one, I think I would have. I did not, though, and that was that.
As it got far along into the school year with Alan’s Commodore 64 yet again having an extended visit at the repair shop, Alan read amazing news in various computer magazines. That is, this news was in several magazines, not just one. I believe it was this amazing news that turned the Commodore 64 into such a cultural phenomena.
In terms of hardiness, my opinion was that the Commodore 64 was a piece of junk! Besides Alan’s experience, other early owners seemed to have a huge number of dying machines. (I later owned a Commodore 64...actually a portable model called the Commodore SX-64...myself. My opinion in 2006 is still that in terms of hardiness, the Commodore 64 was a piece of junk!)
The amazing news was that less than a year after being introduced, the retail price of the Commodore 64 was being dropped from $595 to about $250! That is, less than half the original cost, only months after the machine was introduced!
This news shook me too. I had previously thought if I got into financial trouble, I could sell my Vic-20 to regain some funds. Due to the unexpected scholarship and the tutoring job, I had avoided that so far. I was glad because I was finding the Vic-20 and printer so useful for my classes. It was nice to think I could fall back on selling it if necessary, though.
Before this price change, the retail price of the Commodore 64 had been $595 while the Vic-20 had been $295 or thereabouts. That seemed about right given the comparative capabilities of the machines. If the Commodore 64 was being dropped to a retail price of $250, though, what would that do to the price of Vic-20’s? Commodore might as well give them away for free! Commodore was not going to do that, of course, so what really happened was the Vic-20 was done, finished, over. No matter how much use I personally got out of my Vic-20, it was to be an orphan machine very soon. I had backed the wrong horse.
(In 2006, I have grown accustomed to computer prices plummeting while speed and capabilities soar. For example, in 1998, I bought a laptop for $1,600. In 2006, a laptop for $600 would be at least five times faster with ten times as much hard disk space. This seems normal now, but I never dreamed of such rapid changes in price and performance in 1982!)
Alan had backed the right horse, but his Commodore 64 had been so overly delicate that it had spent much of the school year in the shop getting repaired. Alan was furious.
Alan told me, “It would not bother me nearly so much if I had use my computer. The extra three hundred and fifty dollars would have been the price of having it before anybody else. It was broken almost the entire time, though!”
I said, “At least you did not have to pay extra for the repairs. Everything has been covered under warranty.”
Alan complained, “That’d be a reasonable if they had fixed it right in the first place! It’s in the shop for the third time! I’ve hardly gotten any use out of it all semester. What did I pay all that money for?”
I said, “What about my money? This news is going to make my Vic-20 nearly worthless.”
Alan countered, “Look at all the things you did with you Vic-20 this semester in Dr. Gray’s class. You got plenty of use out of it. I could have gotten similar use out of my Commodore 64 for my Computer Science courses, but couldn’t because most of the time, it wasn’t even here!”
Nothing I said seemed to make Alan feel any better.
Looking at those articles he had shown me about the price drop in the Commodore 64, I tried to imagine how the world would change with a computer that powerful for so little money. My imagination was not up to the task. Although I knew immediately after reading those articles that my Vic-20 was obsolete and about to be orphaned (that is, no longer supported), I felt fairly good about having bought it anyway. As Alan had pointed out, what it had accomplished for me that semester had been incredible. As he had also pointed out, I had been using it steadily since late May, and it had not failed me once. It had exceeded all my expectations.
As for Alan’s experience that semester with his Commodore 64, I finally understood what he meant when he said that the cutting edge of technology would often more accurately be called the bleeding edge. I suppose one could say that I was on the bleeding edge as well in regard to the re-sale value of my Vic-20 system if I had had to sell it, but I was so satisfied by how it performed that I was not too upset by that.
THE END
If you want to talk to me, I can be reached at arendtj@att.net
Last Modified January 24, 2006