40 Columns on the Commodore VIC-20

Turns out there are several small programs to get 40 column text on the normally-20-column VIC-20:

Some interesting posts elsewhere on the site too…

(Edit: prompted by this post over on 6502.org)


I remember one of the terminal programs for the C64 was able to do a slightly less readable 80 column mode. I don’t recall if anything was available outside of that terminal program to be able to do it, but there probably was.


I recall a 80-col utility for the C64 published in Compute Gazette.
It was probably the one in the September issue of 1984 (Issue 15, Vol. 2, No. 9); a disk image of the type-ins is available here: https://www.atarimagazines.com/compute/gazette/

There are a few other implementations, including modern ones, e.g., see the following page (includes the Compute Gazette prg in various formats, as well):

This project has a nice explanation of how it is achieved:
(For the actual code see https://www.github.com/mist64/80columns)


Yeah, I used the 80 column utility from Compute’s Gazette, even if the text was not very readable on the Commodore 1702 color monitor (still not as bad as you might think on NTSC, thanks to the S-Video cable and the way the NTSC C64 models alternated chroma phase shift each field).

I see the VIC-20 utilities work the same way. A notable difference from the normal system is that switching fonts does not switch the characters already printed on screen. I mean, the reason is obvious - those characters are already “printed” onto a HIRES bitmap. The upshot, though, is that you could get a lot of interesting useful effects by switching fonts and printing stuff, letting you “print” more than 256 character glyphs on screen.

This was really useful for an RPG, or isometric graphics game. With isometric graphics, you need a lot of different tiles, because of the way the isometric tiles and tall objects overlap square/rectangular character tiles. With BASIC, a print statement was a pretty fast way to draw graphics compared to the alternatives, even with the extra overhead of the ML routines “printing” characters onto the bitmap.

So, I started working on an isometric RPG with a Nerds theme (I don’t know if you guys had Nerds candy, but they were popular in the USA and have cute cartoon creatures that I really liked back then). I never did figure out any actual game, but I had fun designing 80 column fonts for the graphics, and simple BASIC programs to test the graphics.

Oh yeah - I don’t remember whether it was documented or I just somehow figured it out myself, but the character fonts were stored in a similar way to the usual fonts. As such, it was easy for me to figure out how to make and save/load my own custom fonts.

My point is - you could switch to a pure “graphics” font for printing stuff to the RPG graphics region, and then switch to a mixed case text font for printing stuff to the right-side text input/output. You weren’t limited to just 256 glyphs.

Alas, I wouldn’t be able to take advantage of this on the VIC-20 since I never had an 8K memory expansion. Although the 3K memory expansion of the Super Expander could have been enough …

Oh - the standard VIC-20 screen was 22 columns, not 20 columns. The standard size was 22x23 characters. However, the graphics chip is limited to accessing 4K RAM, which is insufficient to bitmap the entire 22x23. The most convenient size for bitmap graphics was 20x20 characters (actually 20x10 double tall characters). My own dynamic graphics allocation routines didn’t need to bitmap the ENTIRE screen, so I used 20x12 double-tall characters (covering an area of 20x24, or 160x192 pixels). I could have done 22 columns, but it made the math less convenient for little practical benefit, so … shrug.


Oops! I had no idea.

I envy you guys having a C64… says the kid that grew up with the nintendo.

1 Like

There’s much romanticism and nostalgia around the C64. The C64 was more remarkable for how bad it actually was. Meaning, it had quite capable hardware, but almost all of the features beyond basic screen printing were inaccessible and hidden by a BASIC implementation, which had been rather basic even in the 1970s (basically the same as the early PETs, but without the machine monitor). Hence, the C64 forced users to go low level and figure out things (mostly on their own, no Internet), with nothing more than PEEK and POKE to start with. Even reading a second joystick was some of an achievement, since this port was shared by the keyboard logic and you had to write or adopt some utility for this. This typically resulted in most of the time spent in implementing basic functionality and interest lost as soon as you bootstrapped yourself to a level, where you could have implemented your project. I guess, a typical C64 owner’s disk stack was more of a boneyard of unfinished projects, than a collection of nifty demos, testaments of accomplishment, creative projects to show … So much productivity lost, where users became stuck at about the same point with their projects, which could have resulted in some real, creative output with, say, a BBC Micro. — For the most, the C64 was just a game console, much like the NES, but a bit more awkward.

E.g., in the case of a 80-column software solution, mind that this was slower than usual printing by quite an amount, since everything which would have been handled by hardware was now done by the CPU and involved masking and OR-ing, since any screen-byte was shared by two characters. It was actually too slow to be of much use in BASIC, which was already slow. (E.g., numbers weren’t tokenized, hence BASIC had to read an ASCII string and convert it to floating point every time a number was encountered in the program, even in a tight loop.) So you had to go low level again, but the 80-column utility came (necessarily) with some memory layout and memory management of its own (probably using most of the 30-odd zero page bytes which could be used by the user without messing with the OS), hence you had to accommodate to that and rather go with what the utility did, than with what you had figured out already. Therefore, it’s small wonder that this wasn’t used much in actual projects. (But, I guess, there are thousands of unfinished projects, which tried.)


Hey, don’t forget the C64 Programmer’s Reference Manual. It gave us an excellent reference with byte-by-byte detail of most everything … even circuit schematics. The VIC20 also had a Programmer’s Reference Manual which set the precedent. It even included an example of how to do HIRES bitmap graphics on the unexpanded VIC (limited to an 8x8 tile matrix for only 64x64 resolution).

Not only were the Programmer’s Reference Manuals excellent resources, they also showed you insight into how the hardware was intended to be used. And a ton of excellent C64 software used the hardware within the gamut of these intended uses.

The C64 magic, though, comes from how its quirky hardware could be used in bizarre unintended ways. The unusual abilities and limitations of the sprite hardware, in particular. Horizontally, C64 sprites could be HUGE compared to other platforms - including the Amiga. But vertically they were really weird because you couldn’t reuse a sprite until it fully displayed all 21 lines (well, not unless you’re really clever and combine multiple sprite images into a single glyph - but this is hard to generalize). The large width that could be covered by sprites meant that very weird unintended “graphics modes” were possible.

With the NES, of course, the inability to make your own programs meant that you couldn’t experiment at all. But even if you could, the hardware is designed in a way which kind of forces you down a single “lane” of how to do things. The sprites, while multi-color (nice!), are not very wide, so you can’t really use them for much more than … well … sprites. The multi-color aspect is nice, but you don’t have enough to do much overlapping sprite work for even more colors … the fact that they’re already multi-color means the benefit is lower. The tiles are great - multi-color and good resolution - but you don’t have separate “color memory”, limiting your ability to do various tile coloring effects. The graphics chip has excellent bandwidth to the graphics data memory, but the CPU’s bandwidth to the graphics system is extremely limited. As such, you can’t really do bitmap graphics at all (so - no Elite, for example).

The VIC20 is between those extremes. The tile graphics system is pretty rigid, but it does have enough flexibility to at least let you do things like bitmap graphics. Its level of flexibility is kind of typical of most 8 bit computers.

The C64 just happens to be exceptional in that regard. Its intended use abilities are bad enough that the unintended use abilities have a “wow” factor. And the crazy ways its unintended uses could work … well, that’s why it’s 2020 and we’re still discovering new weird ways to do things on it. That’s what has given the C64 Demo and “Homebrew” scenes so much longevity.


Indeed, good documentation is a great additional resource! (I think I might even have a VIC-20 programming manual, even though I don’t have a VIC-20.)

1 Like

Mind that the Programmer’s Reference Manual (or “64 intern” of the Data Becker series in Germany) didn’t come with the computer. (Also, these reference manuals were quite expensive for a kid. I think, I was the only one in my circle who had the Programmer’s Reference Manual, and I had to go to the national Commodore central outlet, where they had to order it. It turned out to be a German translation in hard binding, the original version wasn’t available.)

I didn’t want to lessen the virtues of the C64 and the creative exploring and programming, which came with it, but it’s also worth noting that this was essentially forced on the user. It was a forceful invitation. On the upside, lots of people learned about the internals of a computer rather thoroughly, on the downside, there were not as many finished programs as there could have been, because of all the time and energy spent on the low level. I think, it’s worth pointing this out.

(Just imagine, Commodore had spent another ROM at C000, with suitable routines for graphics, sound, etc, for everyone to be used in a general and common way. Or even a machine monitor, or a few disk commands. This wouldn’t have lessened the flexibility in any way, since you could always bank out the ROM, but may have provided a great head start for many.)

1 Like

Interesting about that difficulty getting the Programmer’s Reference Manual. Where I was (in the USA), the Commodore reference manuals were easy to come by in bookstores and home computer retailers.

FWIW, Commodore did put another ROM (at $8000, though) with suitable routines - the Super Expander cartridge, which was the same basic idea as the Super Expander cartridge for the VIC20. But I think Simons’ BASIC was more popular. Neither were built in, of course, and this would be an embarrassing point for C64 users compared to the competing home computers.

The C128 finally included graphics/sound/etc commands in its BASIC. I really like that, since I didn’t have to wait for loading Simons’ BASIC. It was also a lot more powerful than Simons’ BASIC and Super Expander, with interrupt driven sprite movement capabilities.

1 Like

Regarding the Programmer’s Reference Manual, mind that in German speaking countries “64 intern” was the go-to guide – and this was available about everywhere. However, this had a bit of a different scope and also used different labels for ROM routines (which is, why I became interested in the US-way of things as represented by the Programmer’s Reference Manual in the first place). The Programmer’s Reference Manual was much more inviting and broader in scope than “64 intern”, which was more EE-style hardware oriented, but also included ROM listings not found in the Manual (in fact, these contributed to about half of the book), but lacked for example an introduction or reference to machine language (meaning, you had to refer to yet another book to put this information to use).

There are actually some national differences, which influenced the image of the machine. E.g., I didn’t know anyone who used Simon’s BASIC. It may have even been that using any of these extensions would have been considered as “lame”, but I wouldn’t say so with certainty. But I’d say, there may have been a bit of C64-machismo involved. :wink:

Regarding the C128, as you may imagine, this was constantly floating in the back of my mind while writing these posts. Commodore could have easily come up with that kind of ROM for the C64, instead of repurposing the five years old PET 2001 ROM V2 less machine monitor, disk interoperability, and support for a second tape deck (mostly to make room for color support). – But, in the end, this rather awful decision of not providing a suitable ROM, which supported the particular machine at any length, became the C64’s story of success.

P.S.: For reference, the German edition of the Programmer’s Reference Manual is:
Commodore Suchbuchreihe Band 1;
Alles über den Commodore 64 — Programmierhandbuch.

Commodore Büromachinen GmbH, Frankfurt/Main, 1984.
(Which translates to “Commodore fact book series, Vol. 1; All about the Commodore 64 – Programming Handbook”. Yes, a somewhat verbous title.)


I think it was simply because they wanted to get the C64 out as fast as they could, without any expectation of it being a long term product.

The VIC-20 was rushed through in a panic that “the Japanese are coming” (they did not). It was a crude and inelegant design, with hilariously bulky text characters compared to the competition and a feature poor BASIC. But it still became the best selling computer to date, and the first to cross the 1 million mark.

To make up for the short-comings of the stock VIC-20, Commodore did release the Super Expander cartridge. Not only did it provide graphics commands like the competition, it boosted RAM by 3K. But of course … not that many people bought the Super Expander.

The obvious conclusion to draw would be that the Super Expander’s capabilities were unimportant to the success of the VIC-20. So why bother with altering this successful formula for the C64? Better to push the product out sooner than later!

Hmm … looking it up, I see that the TED machines had graphics and sound commands. The fact that I had to look that up, rather than knowing it already, is sadly indicative of the fate they had in the market…

Anyway, here in the USA, Simon’s Basic was popular enough to have type-in books and magazines in bookstores. I don’t remember ever seeing any type-in books for any other BASIC expansions.


Mind that the VIC-20 debuted in Japan as the VIC-1001 (including kana characters) and was introduced (I think) in Oct. 1980, This was even before the Sinclair ZX81 – and, while it may have been rushed, the feature set was quite ok for a home microPET. (As for the screen characters, well, either they have to big to work on a consumer-grade color TV, or you have to make the PET font bold as seen on the C64.) However, when it eventually hit Western markets, it was already a different story.

It may be interesting, how I received a demo of the VIC-20 – or, at least, how I remember it. This was late in 1981, about end of November / early December. The school hat set up an IT course, held by one of the physics teachers (a TRS-80 early adopter), as an extracurricular activity. Commodore held a small back office (no shop, no customers) around the corner of the school and the teacher had somehow managed to obtain a demo machine to show to us. (This was the last lesson before St. Nikolaus day, and, while the machine wasn’t in the shops at this time, it was definitely som exciting info for any of us kids, who wanted a computer. Mind that this was more than year past the introduction in Japan and more than half a year after the introduction in the US.) The machine came with some demo programs and, I believe, the teacher had also provided for a musical demo of his own, appropriately Christmas themed. (It may have also been an official demo by Commodore, but it was somehow separate from the rest, which may be, why I came under that impression.)

So, how did I feel about the VIC-20 (or, since Austria is a German speaking country, properly the “VC 20 Volkscomputer”)?

Edit: This was probably the single biggest marketing fumble by Commodore Germany: what teenager on earth wants a “Volkscomputer” (much like grandma’s Volksempfänger, which wasn’t particular good in any ways, as we had learned from our ancestors.)? Is there anything cool about a somewhat NS-themed people’s computer? (But they may have had VW, Volkswagen, in mind, instead, and failed to convey the message.)

First, graphics were in color, which wasn’t a standard then, but most of the demos were in block graphics, which was quite the standard. Given that the characters were quite big for the time and hence resolution low, this wasn’t much to write home about. (Mind that games weren’t much of a topic, just before the official availability of the machine.) So the demos were mostly about the sound capabilities – and this was quite impressive, out of the ordinary even. Memory wasn’t really remarkable – and provided that the V(I)C-20 was about three times the price of a ZX-81, you could get the same useable amount of memory for less on other systems. Which, by the way, shared the same hypothetical nature, since none of us had seen much of any of them in person (maybe at a fair for a few minutes, but not really). So there were some promises, but nothing too convincing, compared to cheaper options. Notably, a disk drive wasn’t available yet, so there wasn’t an advantage on the peripheral side of things either. Personally, I decided to go the other road and got a Sharp PC-1211 pocket computer (you could use this one in school!), until some more convincing options would show up. (Which became the C64, which showed up just a year later.)
Please mind that this isn’t a verdict on the computer, but the impression I got as a teenager after a short demo, just before the debut in local markets.