Mostly Random Technology Bytes

This is the second follow-up article (after Remembering the Commodore PET) in my nostalgia series talking about old Commodore computers - which was triggered by my reading of On The Edge: the Spectacular Rise and Fall of Commodore, and my comments on that book. In this article, I’ve decided to talk about the VIC-20 computer, and principally its video subsystem which I think was quite interesting, and in some ways (well two relatively minor ways really) was even better than the later and more familiar Commodore 64.

First of all, what was the VIC-20?

• It was Commodore’s first home computer, Commodore’s first computer to plug-in to your TV, Commodore’s first computer with color, and it was the first computer by any manufacturer to sell 1 million units.
• The computer was based around the MOS 6502 8-bit CPU, had 5K of RAM memory (that’s 5K as in 5,120 bytes), 20K of ROM (which included the BASIC interpreter and Operating System kernel), and a graphics and sound subsystem powered by the 6561 (or 6560) VIC chip.
• Programs could be stored on cassette tape (using a special cassette unit that Commodore sold), or on floppy disk - using the 1540 disk drive, which was also sold separately. The computer had a cartridge slot, which could be used to plug-in cartridges which contained extra RAM and/or ROM programs - but since there was only 1 slot - you could only plug-in 1 cartridge at a time unless you got a special expansion unit.
• Here’s a picture of a VIC 20 surrounded by various goodies. The keyboard unit in the center is the VIC 20 computer, behind at the rear of the keyboard is the cassette unit, and the two silver things on top of the keyboard are cartridges.

The key thing that made the VIC-20 into what it was, was the VIC chip. The chip was made by MOS Technology, who were also the manufacturers and designers of the 6502 - and who were a Commodore subsiduary for most of their history. According to On The Edge: the Spectacular Rise and Fall of Commodore, the VIC chip was first developed in 1978, and MOS originally intended to sell it to video-game and electronics manufacturers - but it wasn’t very successful in that market. It wasn’t until after Commodore saw the success of the Sinclar ZX80 and a seminal meeting in London, that Commodore decided to build a computer around it.

When you switched on your VIC-20, it booted up the BASIC prompt, with the screen set to 22 X 23 characters. As with the PET, your programs could alter the contents of the screen from BASIC by using the PRINT statement, or by writing (using the POKE statement) to the locations in memory that corresponded to the screen content.

In the VIC-20, there were two chunks of RAM corresponding to the screen content. These began at memory locations 7680 and 38400 on the unexpanded VIC-20 (the locations could vary once you added memory to your VIC-20).

• The first chunk of memory, beginning at 7680, determined what was in each character cell of the screen. Thus location 7680 indicated what character (from a choice of 256) to display at the top left location of the screen, location 7681 indicated the character one cell to the right of the top left, 7682 indicated the character two cells to the right, etc., then, 7802 (which is 7680+22), 7803, 7804, etc., specified the characters on the second row, and so on.
• The second chunk of memory, beginning at 38400, had the same layout, but specified the color of each character. Thus 38400 indicated the foreground color of the character at the top left, 38401 the color of the character one cell to the right of the top left, 38402 was two cells to the right, etc., and 38422 (which is 38400+22), 38423, 38424, etc., specified the foreground colors of the second row of characters and so on. This memory was only 4 bits wide, and 3 of those bits were used for colors (allowing 8 foreground colors - black, white, red, cyan, purple, green, blue and yellow). The remaining bit, turned on multi-color mode for that particular character cell, which I’ll explain in a moment.

To determine how each of the characters looked on screen, the VIC-20 would look at a mini monochrome bitmap which was defined for each character. As the characters were normally 8X8 pixels, the bitmap definition of each character would only takes 64 bits (8 bytes), and an entire set of 256 characters took 2,048 bytes (8 bytes X 256 characters). The VIC-20 contained a 4K ROM which contained 2 character set bitmaps each of 256 characters, and you could switch between the two built-in sets, or tell the computer to get the character definitions from RAM memory (and thus create user-defined characters).

An important point to remember (one that might seem odd to people familiar with modern bitmapped screens), is that if you changed the definition of a character’s bitmap, any occurrences of that character on screen would immediately change. For example, if I changed the definition of letter ‘A’ bitmap to look like a musical note, all the letter ‘A’s on screen would immediately change. I myself used this technique in many of my programs - for example, I could create a user-defined character representing a space-alien enemy, put lots of them on the screen, and make them all wiggle their ears or legs by POKEing a single byte of their character definitions.

Okay, I promised I’d talk about multi-color mode. Remember each character cell’s color memory (38400 onward) had a bit determining whether it was in multi-color mode. If the multi-color bit was turned on for that character cell, the 8 byte character definition, would instead of being used as an 8X8 monochrome bitmap, would be treated as a 4X8 bitmap in 4 colors (2 bits per pixel). The four colors used for the cell, were the foreground color of the cell, the background color of the screen, and 2 auxilary colors (which were determined for the whole screen). Multi-color mode was pretty useless if you used the ROM based character definitions, because they weren’t designed to look like anything useful in this mode - but it was handy if you created your own character definitions. The fact that you could mix multi-color and the 2-color characters on the screen was also useful - for example - you could have create a chunky 4 color alien mothership, and have writing in higher-resolution 2 color text, elsewhere on the screen. (By the way, this ability to easily mix the higher resolution and multi-color modes on the same screen was one of the very few things that the VIC-20 did that the Commodore 64 couldn’t). The principle oddity of the multi-color mode, was that when in multi-color mode, each pixel was very much wider than tall.

I’ve mentioned, but so far glossed over, the background color for the screen and the auxilary colors. Where did they came from? They were stored on registers on the actual VIC chip itself. The VIC chip contained 16 registers which were mapped into memory at locations 36864 to 36879, and by PEEKing and POKEing these addresses, you could manipulate their values. Among these registers were the screen background color (from a choice of 16 colors), the auxilary color (also from a choice of 16), and the border color - which was also used as the second auxilary color (from a choice of 8 colors). There was also a bit you could set to invert the screen colors (because doing it in software would be too slow on a 1 MHz CPU), so as to make the explosion effects in your games really annoying.

As well as the color registers, the VIC chip also included quite a few other registers. These included:-

• Registers to control the pitch of four tone generators (three vaguely musical square wave generators, plus a white noise generator) as well as the volume for the whole set.
• Registers to monitor the position of a lightpen and game paddles.
• Registers to vary the screen origin and size (in characters) - to a fairly limited extent - which was the other main capability that the VIC-20 had which the latter Commodore 64 didn’t (note to 8-bit pedants: I know that the Commodore 64 had some capability to vary the screen size in hardware, and clever progamming tricks could be used to do it in software). I remember using these to make a wierd spacewarp effect in one of my games, that was supposed to make you feel like you or the screen (or something) was falling into a tunnel and then out again, in between levels.
• There was also a register to monitor the screen’s scanline (how far down the display, the refresh had got), so you could monitor this and change colors part way down the screen - but since you had to poll it rather than simply wait for an interrupt - and since polling would use most of the CPU’s power - I don’t think that this was vastly useful.
• And most interestingly, there was a register bit you could set to double the height of each character cell (giving you 8X16 characters - or 4X16 if multi-color - instead of 8X8 or 4X8).

So how could you do high resolution graphics on the VIC-20? Well, “high” might be a bit of an overstatement - but pixel addressable?

I’ve already given you more than enough clues in this article, can you figure out?

Okay, here’s how:-

1. Set the VIC chip to display double height characters
2. Set each location in screen memory to display a different double height character. For example, the top left cell displays character 0, the next cell displays character 1, the third cell, character 2, and so on. If you stick with 22 columns, you can fit 11 full rows of double height characters (that’s 242 characters), without having to duplicate any characters - this gives you a resolution of 176X176 pixels (or 88X176 if multi-color)
3. Now, when you want to plot a pixel at a given location on screen, you calculate which character is in that cell, then calculate which bit and byte of the character’s bitmap corresponds to that pixel, and change that.
4. And once you can set individual pixels, you can then using more math, draw lines, circles, etc.,

Of course, two were slight obstacles in the way:-

1. There are no BASIC commands for any of this plotting - you had to do all the math and then PEEK and POKE the right memory locations yourself.
2. There wasn’t quite enough memory in the unexpanded VIC to do this: The character definitions took 4K, the screen characters took about 0.5K, and the operating system used 1K = 5.5K, but the computer only had 5K in total! Work-rounds:
   • Get a memory cartridge
   • Reduce the screen size - remember those screen size/origin VIC registers - and do “high” resolution on an even smaller canvas

I myself took the memory cartridge route, getting a 8K RAM (yes 8 whole kilobytes!), and I remember the thrill of sitting in my bedroom, when all my PEEKs, POKEs and math, finally got a diagonal line and a circle to plot across the screen - very slowly - pixel by pixel.

Later, I got an “Super Expander” cartridge which included 3K of RAM and added extra BASIC commands for plotting. I didn’t use that much, because I couldn’t use it at the same time as the 8K RAM (remember only 1 cartridge slot), and lines and circles didn’t turn out to be very useful for making games (which was my primary interest at the time).

I would say is given the tightness of the memory at the time, Commodore/MOS did miss one rather obvious trick: They could have had added a mode where the VIC chip, using double height characters, dispensed with the screen character memory (allowing you to save a whole 0.5K!), and when in this mode simply assumed screen location 0 contained double height character 0, screen location 1 contained double height character 1, etc. I suspect, they either ran out of silicon, or decided adding a mode like this simply wasn’t worth the effort on the VIC.

I’m going to stop now, but before I do, here are two black rectangles. They are 176X176 and 88X176 pixels respectively. I’ve included them to give modern readers an idea of just how tiny, compared to today’s screens, the VIC-20’s maximum resolution was^*. And don’t forget the VIC-20 also had far less colors - 8/16 with significant limitations about how they could be combined in different parts of the screen - as compared to modern computers which typically have around 16,777,216 and allow any color to be used in any part of the screen.

---

^*Modern screens have more or less square pixels, however as mentioned previously, the VIC-20’s multi-color mode featured pixels that were much wider than tall - so although the overall screen was more or less square, the individual pixels weren’t - so the smaller rectangle represents the resolution, but not the shape, of the VIC-20’s multi-color mode. Phew… sorry!

I recently wrote an article about a must-read computer-history book: On The Edge: the Spectacular Rise and Fall of Commodore. Well, reading the book brought lots of old memories flooding back. I was a Commodore kid myself, progressing from Commodore PET (which was my dad’s), to VIC-20, to Commodore 64, so I figured it would be fun to wallow in a bit of nostalgia, and maybe talk about some of these old computers, and why they were in some ways better, from a learning point of view, than modern PCs. I’ll start with the Commodore PET, and if there is any interest, I’ll also write about some -other old computers as well as some of the projects that I made/wrote (including networking my PET and C-64 (well sort of), and handwriting recognition 1982-style).

Our PET was powered by a 1MHz 6502 CPU, had 32K of RAM, a 40X25 character display, and had the Operating System, BASIC and a machine language monitor (for entering machine language programs - in hex - (no assembler!)) in ROM. We also had a few commercial tapes including a primitive wordprocessor, and a few games and utilities. At some point, I remember that my dad got an incredibly loud Epson Dot Matrix printer. There were quite a few PET models over the years, but the one we had was a 3032 - like the one in this picture (it isn’t the actual one in this picture - our old PET has sadly died and long since departed to old computer heaven). You’ll notice from the picture that it had a full size keyboard, and not the ridiculous chiclet keyboard that earlier PETs had (shown in this picture). As you can see the PET was all in one integrated unit (except the cassette tape on ours sat next to the computer in the non-chiclet models), so you could say that in some ways the design anticipated much later computers such as the 1984 Macintosh) and later portable computers.

The first great thing about the PET was it was so easy to get started. You’d just plug it in to the electricity outlet (no other cables to connect!), switch it on, the READY prompt appeared immediately (because as mentioned BASIC was in ROM), and you could start using it straight away, and even begin typing in a program without waiting for anything to load, or having to install special software first. You could say it really was a programming appliance in a way that modern PCs aren’t.

Along the same lines, the second great thing about the PET was that everybody who had the computer had access to programming tools. This is in sharp contrast to most modern computers where you only get a programming language if you choose to install it, and probably not 1 in 100 computers has a programming language installed. Additionally since BASIC was interpreted and interactive, you could type in statements and immediately see results, and you could quickly modify your programs without having to go through a lengthy edit/compile/link/run cycle. Of course there are good reasons why modern computers are the way they are, and technically modern computers are of course infinitely better, but as a learning tool the PET’s approach had a lot going for it. Or put it this way - when I was 9, I would never have had the patience for edit/compile/link/run - but I was able to learn a fair bit about programming on the PET.

There were many other great things about the PET, but I think the memory-mapped character screen was definitely one of them, and so I’ll make that the third and final one for this article. Before I can do that, we need to take a slight diversion to explain how the PET’s screen worked.

As mentioned earlier, the PET had a 40X25 character display (some later models had a 80X25 display). There was a choice of two character sets that could be used, although not at the same time. Each of these character sets contained 256 characters images, although to be fair the top 128 characters in each character set were simply reverse video versions of the lower 128 characters. The default character set had upper case letters, numbers, punctuation characters, and a variety of graphics characters (line segments, card suit symbols, triangles, etc.), and the alternate character sacrificed some of the graphics in order to add lower case letters. There were no user definable characters, no high resolution graphics, no color, and no sound. As a kid, the main things I was interested in were programming games and animations, so I’d have to admit that at that time I wished for an Exidy Sorceror, an Apple II but these were way beyond my means. At some point, I saw ads for the Acorn Atom, and started to save for that - but in the meantime, the VIC-20 was released and so I got that instead (but that’s another story!).

Now there were two ways that you could write to the screen from BASIC on the PET.

1. You could use the PRINT statement, and whatever you PRINTed was displayed on the screen at the insertion point. For normal characters, the character would be displayed, and the cursor moved one space to the right after each character, wrapping around or triggering scrolling as necessary. Additionally, you could put special control characters (like Home, Clear Screen, cursor movement) in your PRINT statements (these tended to show up as reverse-video symbols in your program text - I think clear screen was a reverse video heart symbol, but my memory is a little hazy on this point).

   OR

2. You could use the POKE statement to directly write to the screen memory (and PEEK to read it). The screen memory was 1000 bytes beginning at address 32768.

   Thus for example:
   POKE 32768, 65
   would write character 65 (letter A) to the character cell in the top left corner of the screen.

   Or, for example
   POKE 32769,66
   would write character 66 (letter B) to the character cell 1 to the right of the top left corner of the screen (32769 is 32768 + 1 )

   Or, for example
   POKE 32848,67
   would write character 67 (letter C to the character cell 2 rows down from the top left corner of the screen (32848 = 32768+40+40)

I have to say this memory-mapped character screen was fantastic as a learning tool. A lot has been written (e.g. Perils of Java Schools) about how too many programmers today don’t really understand memory, pointers, etc., In fact, I’m ashamed to admit, even though I do understand memory, and have even written graphics applications, I’m a little hazy on the exact details of how my modern PC is representing my screen contents in memory (I think that I know how it works - but as it’s so many years since I’ve written code that accesses video card memory directly rather than using a high-level API, I can’t really be 100% sure that my assumptions are still correct). Anyway, the point is, because I could POKE the screen, see immediately what happened, and gradually work towards something that as a kid I really wanted to achieve (making a game) - I developed a mental model and a good basic understanding of how memory worked, which set me on the road to learning about more advanced topics. And I know I wasn’t the only one - many other programmers of my generation got their start, including a solid understanding of low-level topics, by POKEing around in the memory of Commodore PETs, VIC-20s, 64s, and other microcomputers of the era. I once suggested, half-seriously, that the solution to the Perils of Java Schools would be for somebody to introduce a modern version of a Commodore-type computer in schools - although obviously (but sadly), it ain’t going to happen.

Anyway, I’ll stop now. I could write a book about the PET - but I doubt anybody would want to read it! If you’re reading this article, and would like to see more, do post a comment or email me, to let me know what other similar topics I should post on - VIC-20? Commodore 64? Handwriting recognition on the PET? My PET to C-64 "network"?

On The Edge: the Spectacular Rise and Fall of Commodore is a must-read book for everybody interested in computers, programming or the history of the computer business.

I’m not going to write a full review of the book saying this bit is good, that bit is bad, etc., You can read that kind of stuff on the book’s Amazon review page. Instead, let me just tell you some of the reasons why you must read this book:-

1. If you grew up with the PET, VIC-20, Commodore 64, Commodore 128, Commodore 16, Plus/4 or Amiga (I grew up with the first three), then you’ll find out lots of interesting facts about them- things that you may have wondered about at the time:-
   • Why did the VIC-20 have only 5K of memory when by that time 32K or 48K was common in other computers?
   • Why did Commodore introduce the 16 and Plus/4, which weren’t compatible with the mega-successful Commodore 64?
   • Why did the VIC-20 and Commodore 64 have such poor versions of BASIC (no graphics or sound commands, and minimal disk commands)?
   • Why was the floppy drive so slow on the VIC-20 and Commodore 64?
2. History is written by the winners. Today for example, the 1984 introduction of the Mac seems a massive breakthrough. But, that’s in large part because we have been re-educated by things like Accidental Empires.

   If you go back to the mid 80s, the Mac was only one of a number of GUI computers and software-packages floating around at the time. The Commodore Amiga and Atari ST (both introduced in 1985) offered a lot more for a lot less money than the then current Macs . Especially the Amiga (and I can say that in fairness having never been an Amiga owner) - multi-tasking, color, better graphics, more memory, and for a lot less money.

   Also, remember, at that time, Apple’s most successful products were, by far, enhanced versions of the Apple II, such as the Apple IIGS. And while, in most of the popular accounts of computer history, you may find information about Apple’s 8-bit inception in the 1970s, you won’t find too much mention of Apple surviving through much of the 80s on Apple II sales.

   In any case, my point is that the Apple Mac eventually came through and defeated the Amiga. Engineers and programmers usually expect better products to succeed: the book will remind you that the world is more complex.
   

3. You will be amazed at the struggles engineers went through in the 70s and 80s. Especially in designing chips.
   
4. When you read how quickly the engineers worked at Commodore, often putting together new computers or chips together in short periods for tradeshows, you’ll have a new perspective on deadlines. Many engineers slip into thinking "do it right", should always trump "do it quickly" - and while they may be right some (perhaps most) of the time - these stories will show you that they aren’t right all the time - the best-selling computer ever was a rush job thrown together with an impossible deadline.
   
5. Most people in computing today are familiar with Moore’s Law and its consequence: Computers are constantly getting better at a faster and faster rate. Read the book, and you’ll find that applying Moore’s Law in the 8-bit and early 16-bit world was extremely difficult. The 1982 Commodore 64 was barely better in computing terms from the 1977 PET. The Commodore 128 (introduced in 1985) went through birth agonies as a result of its designers’ attempts to be backward compatible with the Commodore 64.

   Although the book doesn’t delve into this issue, you’ll have a new appreciation for the efforts and achievements of the software and hardware engineers who have managed to create the PC architecture, which allows full exploitation of Moore’s Law, while retaining a very high degree of backward compatibility.