• Loadstar, a friendly community under construction 🚧, join now for free!
  • The Loadstar Compleat archive is still available for purchase and download including a new custom menu selector!

    You can place your order to download the entire collection for $15 USD --> here <--, and please tell Fender LoadstarCE sent you!

The Art and Science of the Commodore 64

Rev. Dave

Member
Loadstar OG
The Knowable Computer

You – especially YOU, Loadstarite Alumni – have witnessed a thing that happens very rarely in history. You watched as the Greatest 8-bit Computer slipped into obsolescence and obscurity. You witnessed the unending ballyhoo of progress and an ever-accelerating acceleration of technological wonders. And you were told, perhaps convinced, that you were guilty of Luddite foot-dragging because you remember something that was, in fact, glorious.

You witnessed the end of the truly Knowable Computer. There was a moment in history when one determined person really could comprehend almost the entire Commodore 64. We didn't merely operate the machine; we could form a mental model of it.

A single person – a smart, inquisitive, probably driven person – could understand the machine deeply enough to hold its essential logic in mind. I am not that person. I know many people who know and understand much more than I ever will. In fact, I have been away from programming for nearly 20 years now, and have forgotten more than I ever knew. But I had some sense of the logic of this thing. For this is a technological artifact that continues to exceed its own limitations.

Modern computers (by which I mean those of the 21st century) are vastly more capable. But no individual understands the CPU, GPU, operating system, firmware, drivers, networking stack, browser, display system, compiler, memory controller, security subsystem, and billions of transistors that collectively produce the little blinking insertion point (we used to call it a “cursor”) in front of them.

And the result is an incredibly sophisticated utility. We have something like the whole world in our pockets. We can acquire most any information or factoid by just asking a question out loud. And we can participate in elaborate simulation games with people from all over the world. All of this is really important – and fun.

But since I got my first computer, what it could do for me was never as important as what I could do with this tiny world of bytes and pure logic. The best thing about the computer was the built-in BASIC that was a gateway to accomplishing anything imaginable.

True, modern computers make getting things to work vastly easier. On the other hand, our machine was a marvelous milestone at the time. It had very real limitations. It had laws. 65,536 addresses. A finite number of registers. The VIC-II and the SID behaved according to their laws. The 6510 did exactly what you told it to – even when what you told it was idiotic. Nothing inside that world was supernatural. Yet, marvels appeared because somebody made the machine do it.

Perhaps that is what we lost when computers ceased to be knowable: a little world small enough for one human imagination to explore. And that world had boundaries.

It had real limits:

  • A megahertz clock. Only a million cycles a second.
  • Sixty-five thousand five hundred thirty-six bytes. And not one more.
  • Sixteen colors. No more. No less.
  • Eight sprites. Just 8 – covering only 24 by 21 pixels.
  • Three voices. Four waveforms. Primitive sound.
  • One Accumulator. Two Index Registers.
And therefore somebody kept asking: “How can I do it anyway?”

That's where knowability turns into creativity.

But the C64 was more than a place of utility. It was – and still is – a place of exploration.

And the joy of the explorer is discovering how little you actually needed to make something work.
 
This is very true! The C64 is fully understandable, but it still seems to take a full lifetime to understand every last corner of it. There's so many ways we can explore it, and still a seemingly infinite way of being creative even within those bounds. Thanks Dave!
 
[This is the second essay in a six-part look at what it all means.]

READY.

The Commodore 64 came right out of the box with a minimal operating system – the KERNAL – and BASIC 2.0. Plug it in, turn it on, and moments later you were greeted with:

**** COMMODORE 64 BASIC V2 ****
64K RAM SYSTEM 38911 BASIC BYTES FREE

READY.

And a friendly blinking square. It was called the “cursor,” and was involved in a fair amount of cursing – at least in my computer room.

Most 8-bit home computers came with some form of BASIC. By 1982, this modest language had traveled a remarkable distance.

In the early 1960s, Dartmouth mathematicians John Kemeny and Thomas Kurtz believed that computers should not belong only to scientists and specialists. They developed a time-sharing system that allowed many students to use Dartmouth’s computer through teletypes, and devised a language simple enough for ordinary undergraduates to learn. In May 1964, BASIC came to life.

The original Dartmouth BASIC was compiled. When a student typed RUN, the source program was quickly translated into machine language, executed in the user’s allotted space and time, and the results returned to the teletype. The computer was enormous, expensive, and shared – but BASIC made a little piece of it personally accessible.

A decade later, computers became small enough to belong to individuals. In 1975, Bill Gates and Paul Allen produced a BASIC interpreter for the Altair 8800, squeezing one version into as little as 4K. Instead of compiling an entire program before execution, the interpreter examined BASIC statements as they were encountered and dispatched machine-language routines to perform the requested work.

Microsoft adapted BASIC to many of the new 8-bit machines. Commodore acquired its 6502 version for the PET, and that BASIC V2 eventually found its way, virtually unchanged, into the ROM of the Commodore 64.

Perhaps too unchanged. BASIC V2 had no commands specifically designed for the C64’s remarkable VIC-II graphics or SID sound chip.

But the chips were there.

Waiting.

READY.

BASIC 2.0 was the doorway, the machine just waiting for whatever you typed in. The first thing I had to learn was how to spell the commands with absolute accuracy. A huge number of neophytes typed in programs from the consumer magazines, in the process learning how the commands worked together.

The important thing was discovery. Some things were obvious. A FOR-NEXT loop had to have the repeated action between the FOR and the NEXT. Some things were frustrating mysteries. For example, if you jumped out of the FOR-NEXT loop without completing it, you would eventually get an OUT OF MEMORY ERROR! What gives? Only later might you discover something called the processor stack was filling up. At first, you simply learned the protocol.

Like everything on the C64, BASIC 2.0 had its limitations. The INPUT prompt was so worthless, we devised our own input routines in BASIC itself. And commands to alter the screen or sound were not there. PEEK and POKE could reach through BASIC and touch the machine itself – but the road was long, and results were slow.

Ultimately, READY meant the computer was waiting patiently for me to learn how the KERNAL and the 6510 worked – and how to use the native numbers of machine language to create miracles.

Our motto became: “Make it work in BASIC. Make it fast in ML!”
 
The Medium

The Commodore 64 was a medium computer. Not large. Not small. Medium.

Of course, that depends on when you looked at it. In 1982, 64K seemed enormous. Before long, it wasn't nearly enough.

Not enough memory. Not enough colors. Not enough sprites. Not enough voices. Not enough registers. Not enough processor time.

Anyone who seriously worked with a Commodore 64 eventually ran into the walls. There was always something we wanted to do that the machine was not quite capable of doing.

Or so it seemed.

Artists have always worked within limitations. A sonnet has fourteen lines. A haiku is squeezed into an even tinier space. A string quartet has only four instruments. The artist does not regard these limitations as technological defects waiting to be corrected. The limitations define the form.

Of course, limitations do not guarantee art. I recall hundreds of high-school haikus that provide ample evidence for the prosecution. Limitation does not create creativity. It merely gives creativity something to push against.

In 1982, the limitations of the Commodore 64 were imposed upon us. Sixty-four kilobytes of memory was all there was. VIC-II could display only so many colors and sprites. SID had three voices. The 6510 had only so many clock cycles available before the raster beam came around again.

So somebody inevitably asked, “How can I do it anyway?”

Eight sprites were not enough, so programmers learned to reuse them farther down the screen. Three musical voices were not enough, so musicians rapidly arpeggiated notes to create the impression of chords. Forty-eight open kilobytes were not enough, so programmers discovered RAM hiding underneath ROM and found ways to use it. Character sets intended for displaying letters and numbers became building blocks for elaborate graphics. Precise manipulation of the video hardware produced effects that probably never occurred to the engineers who designed it.

The machine’s limitations became part of the creative process.

And something rather strange has happened in the forty-some years since then. The Commodore 64 is hopelessly obsolete as a modern computer. The machine on my desk today has memory, speed, graphics, and sound capabilities that were just plain unimaginable in 1982. Technological progress has removed almost every C64 limitation.

Yet people are still creating new things for it.

In 1982, we accepted those limitations because we had no choice. Today, someone who sits down to create something new for a Commodore 64 is choosing them.

And that is exactly what artists have always done.

A photographer chooses black-and-white. A composer chooses a string quartet. A poet chooses fourteen lines. The limitation is no longer merely something standing in the way. It becomes part of the form.

The C64 could become almost anything precisely because it could not become everything.

Perhaps that is one reason this obsolete computer refuses to disappear. Somewhere along the way, it stopped being merely a piece of technology.

It became a medium.
 
One Bit

Grace Hopper, computer pioneer and icon, gave attendees at her lectures pieces of wire exactly 11.8 inches long – roughly the distance light travels in one nanosecond. Electrical signals are speedy things. So the problem for computers – especially computer memory – is almost the opposite: how do you get One Bit to stand still long enough for the machine to use it?

The first electronic digital computer was built at Iowa State College before 1941 by John Atanasoff, assisted by his graduate student Clifford Berry. Appropriately enough, it became known as the ABC – the Atanasoff-Berry Computer.

Vacuum tubes performed the calculations, but memory presented a different problem. Atanasoff and Berry used capacitors mounted on rotating drums, with electrical contacts bristling around them. A charged capacitor represented one value; an uncharged capacitor the other.

But capacitors leak. The charge – the bit – gradually fades away.

Their solution was wonderfully clever. As the drum rotated, each bit was read and then refreshed before it had time to disappear. The memory did not have to remember forever. It only had to remember until the machine came around and reminded it.

The ABC was abandoned when World War II drew Atanasoff away from Iowa State. Eventually, most of the machine was dismantled simply to make room.

During the war, machines like ENIAC used vacuum tubes both to calculate and to hold numbers in electronic accumulators. But tubes were expensive, hot, power-hungry, and prone to failure. Building thousands upon thousands of them simply to remember bits was impractical. ENIAC could hold numbers needed for its calculations, but it had nothing resembling the large, general-purpose memory we now take for granted.

Another clever way to hold on to a bit was the cathode-ray tube – rather like an old-fashioned television picture. An electron beam created a tiny electrostatic charge on the face of the tube. That charge could represent a bit, be detected before it faded away, and then be refreshed. But Williams tubes were persnickety things, difficult to calibrate and sensitive to changes in operating conditions, including temperature.

Once again, the bit would not simply stay put. The machine had to keep reminding it.

Another solution was to keep the bits moving. An electrical signal representing each bit was converted into a sound pulse at one end of a tube of mercury. The pulse traveled slowly through the mercury, was detected at the other end, converted back into an electrical signal – and sent around again.

A tube could hold a whole string of bits as pulses moving one behind another. But unlike the Williams tube, this was not random-access memory. To retrieve a particular bit, the machine had to wait until that bit came around.

Once again, nothing really stayed put. The bits survived only because they were continually detected, regenerated, and sent around again. And because the speed of sound through mercury changes with temperature, the apparatus required careful temperature control.

By the early 1950s, engineers had finally found a way to make a bit stay put. Magnetic-core memory used thousands of tiny doughnut-shaped rings of ferrite, each threaded with wires. A core could be magnetized in either of two directions – one meant 0, the other 1. Unlike capacitors, cathode-ray tubes, or pulses racing through mercury, the magnetized core simply stayed that way, even when the power was turned off.

Clever arrangements of wires allowed the computer to select and change one particular core. But there was a delicious catch: reading a bit destroyed it. To discover its value, the machine had to force the core into a known magnetic state and detect whether it flipped. If it did, the original value was gone and had to be immediately written back.

Finally – a bit stayed put. Until you asked it what it remembered.

But...

This method had a very practical problem. Threading all those tiny wires through thousands upon thousands of cores was tedious, precise, almost microscopic work, much of it performed by armies of skilled women. Core memory worked beautifully, but it had to be physically assembled, bit by bit. A significant part of the cost of computer memory was quite literally the human labor required to weave it all together.

Then, wonderfully, computer memory almost came full circle.

Recall the rotating drums of the ABC. Atanasoff had stored bits as electrical charges in capacitors, then refreshed those charges before they could fade away. Now capacitors and transistors could be fabricated together by the thousands on tiny pieces of silicon. The drum disappeared. The contacts disappeared. The hand-woven cores disappeared. But the old idea returned: store a charge, and refresh it before it fades.

This was dynamic random-access memory – DRAM.

Never mind making the bit remember forever. Just remind it before it forgets.

Putting memory on an integrated circuit offered one enormous advantage. The labor cost of hand-wired core memory was irreducible. But with computer chips, the economics are reversed:

The first one costs a million bucks. Each copy thereafter is almost free.

We call it memory. Yet much of computer memory works not because it never forgets, but because it continually reminds itself before it does.

Don’t forget.
 
I think that limitations are a good thing.

I was reading about how Ron Gilbert had to cut out and trim down dialogue from the original Monkey Island due to storage constraints... So that only the funniest and best dialogue remained.

That's something that is lost in our age of practically unlimited storage space for a game.
 
One Path to Discovery

When I bought my first computer, everyone had to wait about a month for it to arrive at the store. During that time, I used a couple books about BASIC programming and hand-wrote programs. When the machine arrived (July 3, 1979), I thought I was ready. I had walked, step by step through all the commands and knew them inside out.

What I did not know was the SYNTAX ERROR! BASIC is kind but firm. The program comes to a complete stop when an error is encountered. And on that night (and into the morning) it came to a complete stop many, many times. The experience was BASIC Boot Camp – and I was enthralled.

Several years later, as I was needing to move beneath the layers of BASIC into the real of machine language, a strange fellow came through town and gave me a book: The Complete Commodore Inner Space Anthology. It was the size of a notebook and spiral bound so laid flat on the desk by my machine. All the opcodes of all the Assembly instructions were presented on two facing pages. And, unlike other reference guides I had encountered, the machine language byte value was offered in both hexadecimal and decimal.

That was sweet for me, because I did not have an Assembler – that program that turned three-character mnemonics into the processor’s native language. So I could again write my code out on paper, double-check it, then put the decimal values into a BASIC program, which read them and POKEd them into memory. With a lot of work and frustration, I was able to create short routines that did what I wanted the machine to do. At full speed.

I got a Musical Instrument Digital Interface that connected my computer to a couple of synthesizer keyboards. The program that came with them was called a “sequencer.” Pitch values and durations were to be listed in a text file and the sequencer would play them. I wanted to see the music staff and put the notes on the screen.

So I hand-wrote the Assembly code to do just that. It ran to over 1,000 bytes – and I knew writing down all those values in BASIC would lead to nothing but frustration. I had to wait for an Assembler to be published in a paper magazine, and spend a week typing meaningless numbers and letters into my machine.

I was surprised that it worked. My code had flaws, but with the Assembler, I could rework the routines until it actually played music. The user interface was written in BASIC, of course.

With access to machine language (we called it ML), I could explore many other wonders built into the machine – thanks to that book and suggestions and tutorials from Loadstar. I got fairly good at it and even sent a program to Loadstar.

Three moments define my life. Make that four:

Getting Married.

  • Watching the birth of my son.
  • Graduating from Seminary.
  • Fender Tucker paying me money for my own creation.
When I told a friend about my program being published, he asked, “So when are you going to program a real computer?”

From his culturally curated perspective, it was a good question. But I had barely scratched the surface of the possibilities of the C64. Moving to the up-and-coming world of the PC or the Mac would have consumed all my time just keeping up with the ever-growing capabilities of the modern machines.

I knew I would need 20-25 years to find the horizon of knowledge of the Greatest 8-Bit Computer ever created.
 
What a blast out of the past! I barely remember this song. Did I write it?

PRESTO was a "music processor," written because the MIDI interface I bought came with just a text-based sequencer. Just a list of pitches and durations. I wanted to write music on something like a real music staff. This came out the month before the Processor (I think). Anyway, I really don't remember this - or how I got those slides and glissandos.

Thanks for reminding me.
 
Show and Tell

I need to apologize. Throughout these short essays, I have gone on like everyone who ever had a Commodore 64 actually knew the knowable computer. Of the 17 million machines that spread themselves in homes all around the world, only a fraction were actually “known” by their owner.

This wasn’t a culture-shaking movement. It was a little eddy, a whirlpool by an anomaly in the river of change. Some of this little culture arose from something less philosophical: Commodore didn't provide much hand-holding. The C64 was an extraordinarily capable consumer machine sold at an increasingly aggressive consumer price. That didn't leave room for a bevy of specialists waiting to explain how to make the VIC-II behave.

Like automobiles at the beginning of the 20th century, a ragtag infrastructure arose to help new owners and users enjoy their purchases. Retail computer help and repair shops dotted strip malls as user groups formed informal networks through meetings and tele-computer bulletin boards. Consumer magazines sprang up, offering helpful articles, type-in programs, and new products to a new market.

During those early days, the lack of software was a problem. Computers need programs the way automobiles need gasoline – only more so, because without software a computer has almost no purpose at all. In 1981, an intrepid couple decided to do something about that. They created a strange new product – Softdisk, a software periodical delivered on disk for the Apple II. Three years later, as Commodore 64s were exploding onto desks everywhere, their company launched Loadstar.

Then came Fender Tucker – a bar-band musician who didn't even play a Fender. He submitted a couple of clever little programs, and Softdisk discovered that this fellow understood both their strange new product and the people who were buying it. They needed somebody to manage Loadstar. And apparently editing a disk magazine paid better than playing bars.

Unlike the consumer magazines, Loadstar was not supported by outside advertising. It supplied software, programs that made the C64 do the things it could do – balance a checkbook, organize recipes, assist with taxes, make mailing labels with post office bar codes. And it offered games – all sorts of games. Board games, solitaires, puzzles, adventures.

Fender called the computer “the egoless companion,” and in his Diskovery editorials he included the reader/user into the world of “Loadstarites.” He was more of a club leader than a club owner.

Though it was often called “a great game machine,” the C64 had something all the home arcade systems lacked: a keyboard. And while the games were often quite fascinating, I – for one – knew that the greatest game of all was creating new miracles with BASIC and all the magic inside.

The whole magazine respected the reader/consumer's intelligence. Fender assumed that if we didn't know what he was talking about, we could find the missing parts in a tutorial elsewhere in one of the issues. We were treated like we were the smart people in the room.

The issues contained tutorials from getting started with BASIC, to tricks to print anywhere on the screen, to making your own custom fonts, to lifting BASIC ROM to use the RAM underneath.

Loadstar offered plug-ins and add-ons. Modules (in ML) offered powers and abilities far beyond BASIC 2.0! A module gave BASIC a multi-color Etch-a-Sketch. Another module made any sort of sound - with just a few software "knobs." A whole suite of modules copied and restored screens, put boxes and menus where you wanted them, and gave an only slightly advanced BASIC programmer the power of a MOUSE!!

Some programs offered those who didn’t want to become master code makers the ability to design their own screens and levels for their favorite games. And some of these people went on to become contributors.

These weren't distant professionals producing commercial software for consumers. They were other Loadstarites.

Someone like you made this.

My first submission was a huge railroad game called Sea to Sea. It included a 20,000-byte map of the US – which had no chance of being published as a type-in program in a paper magazine. But a disk could offer it up with just a Return on the menu item. I was thrilled when Fender called to accept my game and said they would pay me $500 for it. It was a big game; later programs received more modest royalties.

The amount didn't really matter. I was never going to generate enough material to make a living at this. The money was more of a “Thank you” – and a useful incentive to stop endlessly perfecting the thing and finally put it in the mail!

The great difference between the world of Loadstar and the emerging world of consumer computing was summed up for me in a Microsoft advertising slogan from around 1995:

“Where do you want to go today?”

In my world, the question was:

“What do you want to DO next?”

I wanted to explore the depths of this Knowable Computer, push beyond its limitations, and create something. Then I could go back to the world of the Loadstarites and Show and Tell!
 
That song is part of the Presto Jukebox on LS #146 - you have two other songs as part of the jukebox.
 

Attachments

  • Screenshot (1268).png
    Screenshot (1268).png
    68.9 KB · Views: 1
  • Screenshot (1266).png
    Screenshot (1266).png
    71.4 KB · Views: 1
Back
Top