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!