The year is 1983. At this point there is a clear separation
between computers used for business and those used for home computing, and one of those
defining differences was the number of columns of text on the screen. For example, the poor little VIC-20 only had
a 22 column screen. The ZX81, or Timex Sinclair 1000 had 32 columns,
the Tandy Color Computer also had 32 columns. The TI99/4a had 40 columns. Although, the Apple II series was originally
a 40 column display, by this time the 80-column add-on card was widely available. And most CP/M machines like the Kaypro were
running at 80 columns. Even the little 5" screen on the Osborne 1
was delivering 52 columns. And of course the IBM PC was primarily an
80 column machine from the beginning. But what about the best selling computer of
the time, the Commodore 64? Well, by default this is a 40 column machine. But I’m going to be showing you 4 ways to
get 80 column text out of this machine, and what the pros and cons are of each one. The first method, and probably the most commonly
used was to do it in software. This required putting the C64 into bit-mapped
graphics mode and using a software rendered 80-columns. You see, this is the typical character set
that was used on the C64, which is 8-pixels wide. In order to give 80 columns using the built
in video chip, it required cutting all of these in half, and using a 4-pixel wide font
instead. Still, it doesn’t look too bad, right? Well, I’m showing you what it looks like
from an emulator. But that isn’t really what it looked like
on the real thing. Most people were using a television for their
monitor, so take a look at how it would appear. Yeah, not very easy to read is it? And this TV is probably clearer than most
were at the time. So, lack of visual clarity was the biggest
drawback to this method, but other drawbacks included the fact that it would consume at
least 8K of RAM for the bit mapped screen, as well as additional RAM for the code itself. So for a machine that only has 64K to begin
with, that’s about 15% of the computers RAM just to operate with 80 columns. Another problem is performance. Besides the fact that the software could no
longer do direct CPU writes to update the video memory, everything had to be channelled
through the 80-column software package. Beyond that, the fact that it had to run in
bit-mapped graphics mode meant that there’s a lot more data on the screen to move around,
not to mention the overhead of drawing the characters in graphics mode. So you can see how slow this is when trying
to scroll information on the screen. So, without a true 80-columns mode, the Commodore
64 was doomed as a business machine. So, this device was introduced shortly after
the C64 came to market. The Data20 VideoPak 80. It plugs into the Commodore 64’s cartridge
ROM port. Now on the back, there are 3 connectors. One is for a pass-thu that takes the audio
and video output from the machine’s internal graphics chip and routes it through the device. And then the next port is for the usual cable
that goes to your monitor. This RCA connector here is actually for audio
output, even though I have no idea what purpose it would have served, as it is just the same
audio that you get from this port. If you take a look inside the device, it contains
a 6845 screen controller chip, almost identical to what was used in the Commodore PET series. What’s more interesting is that it is also
almost identical to the controller chip in IBM’s CGA graphics, only it is missing all
of the extra circuitry needed for doing color. So this thing will produce only monochrome
text. One thing you may notice right away when you
turn on the machine is that the video is noticeably degraded from normal. Just for comparison, here’s a regular screen,
and here’s going through the cartridge. So the idea is, under normal circumstances,
this will pass the normal video from your C64’s VIC-2 chip straight through to your
monitor. So you don’t technically lose any color
or graphics capabilities. if you want to actually activate the cartridge
in BASIC, you must type SYS 36864. This will activate it into 40 columns mode. I’m not sure what good this does, as there
is no significant advantage to this mode, being it is monochrome only. However, while we are in this mode I’ll
show you some interesting differences in operating. For one thing, the font is different from
the regular Commodore font. Also, SHIFT+Commodore does not work. For those familiar with Commodore machines,
all of the 8-bit machines from the PET all the way to the 128 use this key combination
to alternate between an upper-case only font, and a font that includes both upper and lower
case. However, you can press shift-F1 to go to lower
case, and F1 by itself to go back to upper case. And you can use F5 and F7 to alternate between
40 and 80 column mode. So the machine works pretty much as expected
in this mode. However, one thing you may notice is that,
while this is clearer than the software-only method of generating 80 columns, it’s still
pretty hard to read on this television. So, In this case, the blurriness is actually
the fault of the color television. You see, the composite video signal is actually
surprisingly sharp and clear, as long as it is monochrome. Once you shoehorn color into that, it greatly
degrades the signal. Now, in the case of this TV, it is a color
TV and even though it is a monochrome signal, it’s expecting a color signal. And so, the way the circuitry is designed,
it just doesn’t produce as sharp of a picture. If you think about it, an RGB signal such
as used on everything from CGA graphics, the Amiga, or even VGA.. In reality it is just 3 individual monochrome
signals… one for the red, one for the green, and one for the blue. So, if you think about it, there’s no reason
a single monochrome picture wouldn’t be just as clear… except lacking in color. So, let’s hook up this old Apple monochrome
monitor. This monitor was designed to go with the Apple
II system and is very good at displaying 80 columns. Wow.. So you can see this thing is super sharp and
clear. 80 columns is very readable on this. I can even hook it up to this tiny 5” black
and white TV and it is surprisingly sharp, even though my 41 year old eyes are having
trouble focusing on the tiny letters. Another option is this Commodore 1084 monitor. It is designed to take a variety of inputs
including RGB, composite, S-video, and monochrome. Because it is designed for higher resolution,
it is actually surprisingly clear as well. OK, so I think I’ve established that if
you want to do 80 columns you’re going to need a monitor that can support it. And if you’re going to be using a composite
video signal, then you’re probably going to want a monochrome monitor. Now, believe it or not, monitors like this
were actually extremely common back in the 80s, particularly when used in businesses
and schools. So I also wanted to talk about one of the
big disadvantages of using a cartridge like this. There’s almost no software out there that
actually supports it. I’ve managed to locate a spreadsheet program,
which I can’t entirely figure out how to use. and a word processor as well. I think both were made by the same company
that manufactured the device, which makes sense. The other issue is the slow performance. You might notice when writing a BASIC program
that scrolls the screen, that the scrolling seems sort of slow. That’s because of the way the CPU interfaces
with this video chip. You see, the regular Commodore 64 shares it’s
main memory with the video chip. So the CPU can re-organize information on
the screen memory and the video chip will just display whatever is there. It’s a very fast arrangement. This device, however, has it’s own screen
memory. So the CPU must send commands one at a time
to this device to tell it to put a character on the screen. This slows down the communication significantly. All right, so now I want to show you another
such device. This is the BI-80, made by batteries included. It’s a very similar concept, but it uses
an RCA input and output. If you take a look inside this unit, you’ll
see it is based on the 6545 video controller, which is almost identical to the one in the
previous unit I just showed you. However, this one is implemented in a very
different way. The first thing you might notice is that it
produces far less interference when passing through the signal from the internal graphics
chip. So, comparing two screenshots from each device,
I think it’s pretty clear which one does this function better. Another thing I noticed is that the BASIC
is reporting 8K less RAM than before. So, let’s switch it to 80 columns mode. This one requires a different command, SYS
33000. So, as expected, it is hard to read on this
television, so I’ll switch to another monitor. So the next thing I notice is that it is using
the standard Commodore 64 font. Also, the SHIFT-Commodore key combination
seems to work as expected. And when I do a scrolling test, I notice it
is nice and fast. The reason for this has to do with a different
way of implementing the screen memory. It is actually sharing screen memory with
the CPU, opposite of how the other device did. This does have several advantages, albeit
at the expense of loosing some RAM. OK so, I searched and searched, but was unable
to find any software that supports this thing. Now, I’m told that there was a version of
the Paperclip word processor that would work with it, which makes sense because they’re
made by the same company. But,I couldn’t find a copy of it that actually
has support for this on it. But I got to thinking about it and I wondered
how hard it would be to convert one of my own programs to run on this thing. So, a few years ago I wrote this program called
PETDraw. Now, all this does is allow you to use the
built in text characters, which includes the little graphics characters that Commodore
put on the keys. And lets you draw with them in a more convenient
fashion, as well as save and load your work. Also, one of the features it has is allowing
you to draw in a pseudo bit-mapped mode. What this is doing is actually using the little
block characters that are part of the character set, and automatically figures out which one
is needed in order to let you draw with them seamlessly. And you’d be surprised at some of the things
you can draw with just text characters. When I was done with this program, I thought
it would be neat to see if I could port it to the Commodore Plus/4, which I did. And it works, taking advantage of all 128
colors. And then I thought, “why stop there? let’s see if I can port it to the Commodore
PET.” Well, the PET has no color, so I had to remove
all of the code that involved color. Once I did that, I thought, “hey what about
the 80-column version of the PET?” So I did that one too. Of course, I don’t own a PET so I’ve only
ever seen this work in an emulator. But it occurred to me that the 80-column PET
version would be pretty simple to recompile for the Commodore 64 using the BI-80 adapter. After all, both systems use a black and white
80-column screen based on the 6545 CRT controller. All I really needed to do was change a few
screen memory addresses in the source code. And sure enough, it works. I didn’t change the logo, so it still shows
to be the PET 8032 version of the software. But otherwise, it works as expected on the
Commodore 64. So now, there is at least one software program
that is available on the Commodore 64 that supports this thing. So, I have even updated the Petdraw package
on my website to include support for the cartridge, along with all of the other platforms it already
supports. I won’t be able to support this one, at
least not easily. It would require doing a complete re-write
in order to handle the way data must be written to this thing. OK, so I promised to show you 4 ways to get
80 columns on a Commodore 64. Now, I’ve shown you 3 of those so far. Now, as much as I like this cartridge, the
problem is with either of these cartridges, is that they’re pretty rare, and they’re
pretty expensive when you do happen to find one. So they’re really not a terribly good option. The 4th option might surprise you, which is
just simply get a Commodore 128. I mean, it is basically a Commodore 64 inside.And
these are actually more common and cheaper to buy than one of these. And what’s crazy about the way the 128 is
made, is that it actually has 2 separate video chips inside. And the 80 column chip uses the RGB port exclusively
on the back for its output, where as the traditional graphics chip still uses the regular composite
video port. So, In many ways, its almost like they took
one of these cartridges and just kind of stuck it in there. Which, I always kind of thought was like a
hack and not really a proper way to introduce 80 columns to a machine like this. And ultimately, it wasn’t very successful
because of the fact it did require a separate monitor on an entirely separate video port. But that’s a story for another episode. However, the 8563 video chip inside the 128
does produce a very sharp and crisp 80 column display and has 16 colors as well, making
it much more pleasant on the eye. However, it does require an RGB monitor to
accomplish this. Or does it? It was never widely known, but if you take
a look a the pin diagram for the RGB connector on the Commodore 128, you’ll notice pin
7 says composite video. So sure enough, with the proper cable, you
can actually connect it to a composite monitor, however it will only be in monochrome. But if you have a monochrome monitor, it will
be just as sharp and clear as on the RGB. One slight advantage is that it will output
some shades of gray instead of just black and white. OK, so ultimately, I have to ask the question
of, “Why were these never very popular?” Well, I spent a lot of time asking myself
that lately and I think the real answer is more than one reason. The first reason is there’s kind of a catch-22
with these. You see, nobody really wanted to buy these
because there really wasn’t a whole lot of software available that made use of them. And, on the other hand, there wasn’t really
a lot of software development being put into these because nobody owned them. So, you see, that kind of chicken-and-egg
scenario there. But, that’s one reason. And I think there are some other reasons to
consider as well. So another problem is, there were at least
two and I thnk there was even a third unit. And they’re not even compatible with each
other. So, if a software developer were to write
80-column support, they would have to pick one of the cartridges or make 3 different
versions of the software. At least on the Apple II, they had the 80-column
card. And while Apple did officially make the 80-column
card, there were 3rd party products too, but they were all compatible with each other. So, if you wrote software to use 80-columns
on an Apple II, you could expect it would work on any of the cards. Another problem is the vast majority of Commodore
64 users did not have a monitor capable of properly displaying 80 columns in the first
place. So that was another additional expense that
the software developer would have had to expect. And when you think about it, even the 80-column
chip in the Commodore 128 was never really that successful. There were only about a dozen software titles
that were ever produced for it. These machines ended up being primarily game
machines. So there really wasn’t that much demand
for business software on them in the first place. All right, I am sad to say we have reached
the end of this particular episode, but as always, stick around because I have a lot
more coming!
