Part Three – Welcome To The Machine…
11
The biggest problem, as ever, was speed. Certainly, things were
much more efficient now that we could handle screen memory directly,
but for some things the machine simply wasn't fast enough. Moving
objects more than a single character in size was a chore using
POKEs, and you couldn't do it fast enough to achieve smooth animation.
You could go some way towards rectifying that by using strings
of graphic characters interspersed with cursor-positioning characters
- the old way was still the best when it came to big objects.
Even that was slow though, and my games were starting to get too
ambitious for the poor PET. I wrote a Battlestar Galactica game
complete with animations of the Viper landing in the mighty landing
bays and the Cylons swooping in on their attack runs, and although
it worked, the lack of speed was painfully evident.
With my games getting
more complex and ambitious, they were also getting considerably
larger, and beginning to tax the capacity of the PET's 8K of memory.
It even started to cut in to my allocated daily computer
time – the PET loaded and saved programs onto cassette tape,
and it didn't do so quickly. Precious minutes had to be spent
loading code into the machine at the start of your time, and saving
it back again after. Many times I would arrive at morning registration
or some class, breathless and late because I had been waiting
for my precious SAVE to complete.
The Viper, from off of Battlestar
Galactica. Like, real and everything.
I had one game I was working on that was pushing
the limits of memory - it may well have been the Battlestar Galactica
game, that was pretty large - and one morning I came in to college
to find the other geeks in a happy mood. They told me that the
college had had the 8K PET upgraded to 32K of memory. I was delighted
and impressed - in those days a 32K memory upgrade would have
cost you about £500, and the ones I had seen came in external
boxes almost the same size as the main PET system unit itself.
The guys told me that our PET had had an internal memory upgrade,
and so now we would have loads of space for our programs. And,
indeed, when I typed the BASIC command to query the amount of
free memory…
?FRE(0)
…the machine responded:
31740
Thus indicating that there was indeed nearly
32K of free memory in there. Filled with enthusiasm, I pulled
out the tape with my big game on it, loaded it up and began to
code with gusto, adding whole new modules that I hadn't thought
feasible inside the original 8K of system RAM.
After a while, something strange started to
happen. As I was typing in lines of code, garbage characters started
appearing at the bottom of the screen. The more I typed, the more
random garbage started to appear. I was puzzled, and was on the
verge of going to find a teacher to report that I thought the
new memory expansion might be faulty - when the guys let me in
on the joke. Someone had found a couple of locations in zero-page
memory from which BASIC read its information about how much memory
the system had. When you first turned the machine on, it would
self-test the memory and place a value here indicating the memory
size. When you typed the BASIC FRE(0) command to ask how much
memory was left, BASIC looked in this location for the maximum
memory size, and used that to calculate the answer.
However, that value was only set when the machine
was first turned on, and there was nothing to stop a mischievous
hacker - yes, I'm looking at you, Mr. Ruptured Rawlinson - from
using the POKE command to change that value afterwards, making
both the PET and some credulous fool - namely me - think that
there was more memory than there really was. That garbage appearing
on the bottom of the screen had been the poor PET overflowing
its memory into screen RAM as I'd gone merrily on my way adding
great wodges of code. I'd been had.
We laughed about that one all the way down to
Grigg's pie shop. Me a bit more sheepishly than the rest of them.
The bastards…
A Desperate Dan special. Probably
not from Grigg’s. Sorry, pie purists.
It was Rup, however, who showed me an entirely
new direction to take – one that would cure all of my speed
problems for the forseeable future, and which would finally lead
to my understanding exactly how the machine worked. He told me
what the SYS command did.
12
SYS was a command that had always been a complete mystery to me.
It consisted of the word SYS followed by a number, and its action
was unpredictable at best. On the PET it would often cause the
machine to hang up completely, requiring a power cycle to start
it again. On the TRS-80 it usually printed random strings of dots
and asterisks. I had no clue what it was for.
Rup explained that the number was a memory address,
just like for PEEK and POKE, but instead of reading or writing
a number there, the PET would start executing something called
"machine language" at that location. Machine language
underlay everything on the PET - BASIC itself, which was there
when the machine was turned on and seemed an intrinsic part of
it, was just a program written in machine language. Each machine
had a machine language type determined by the type of CPU inside
- our PET had a 6502 chip, so it used 6502 machine language.
The thing that really interested me about machine
language was that it was supposed to be fast. Very fast indeed.
It was hard to find out much about it at first
- at that time there would have been no question of anyone studying
machine language at sixth form (this was an establishment still
teaching CESIL, remember) so the library came up empty. In the
end, to get me started, Rup lent me a photocopy of a manual for
the 6800 chip – different from the one in our PET and so
nothing I could actually write any code with, but enough for me
to start to gain an understanding of how machine language worked.
It took a while poring over the 6800 manual
in the college library – looking at example code and following
through the steps of the programs by hand to see what was happening
and how – before I began to understand... Machine language
was both extraordinarily complex (in that to do the simplest things
that in BASIC took one command - like PRINT "HELLO, WORLD!"
- took hundreds of commands in machine language) and elegantly
simple (in that there were only a few basic types of command and
they all did simple, readily understandable things).
The insight I'd had when working directly in
screen memory on the PET - that everything simplified down to
being able to look at numbers and move them around - proved to
be absolutely general, with a couple of extensions. The CPU chip
was just a special kind of fairly simple calculator, and the memory
of the computer was just a big collection of numbers - 65,536
numbers was the most an 8-bit chip like the 6502 could ‘see’.
Those numbers could represent anything - letters on a screen,
variables in a calculation… and now, I understood, commands
to the CPU itself – ‘op codes’, they were called,
in machine language.
The CPU could look at any of the numbers in
any of the locations of memory. It could read them in to ‘registers’
- like the memory on a calculator - and do arithmetic on them.
Furthermore, the arithmetic it could do was far more simple than
even the most basic four-function handjob that we were used to
using in college. The poor thing couldn't even multiply and divide,
and it couldn't handle numbers bigger than 256, and it could only
handle whole numbers - no fractions. There were other functions
it could do – simple logic ops whose usefulness I had yet
to fully understand - only using a CPU myself would teach me those
aspects of it. But the basics were really simple. What the CPU
did was to examine numbers, modify them in a few simple ways if
required, and maybe move them around.
”Oho! The soul of the cpu
– right here in this titty bar…”.
From those simple building blocks grew... well,
everything. BASIC, biorhythms, games, databases, graphics on screens,
Space Invaders, word processors, mailing lists in the Reader’s
Digest database... it was all just numbers, and computers, fundamentally,
just took those numbers and moved them around, possibly molesting
them slightly on the way in a manner which even the most mathematically
challenged person could understand.
It was elegant and simple, and it was how all
computers worked. To me, it was such a fundamental insight that
I could not imagine why it wasn't being taught on every comp.sci
course in the land. Understand that, and it was like being able
to see the Matrix – no matter how complex the output or
behaviour of the machine, deep down, you knew what was actually
happening.
It holds true to this day - sure, CPUs have
got faster and a lot more complex, and they can ‘see’
a lot more than 65,536 numbers, can multiply and divide and even
handle fractional numbers - but fundamentally it's the same. The
windows you see on your screen, the porn on your hard disk, the
mp3s you downloaded last night… all of them are just numbers,
and your gigahertz CPUs are just looking at them and moving them
around, occasionally gently molesting them on the way. They’re
just doing it very, very quickly.
The word ‘digital’ is bandied around
routinely these days, and to most people it’s simply marketing-speak,
used to indicate a clearer sound or a sharper picture. Back then
it wasn't widely known at all, and this simple, pure understanding
was a revelation to me. I had finally seen the wiring under the
board, the atoms from which the forthcoming ‘digital revolution’
would be made.
I knew how it all worked.
13
But there was still the little problem of actually getting it
to work on our Commodore PET. I'd studied the machine language
of an entirely different chip, and although the same basic principles
ought to apply across any CPU, I needed to know the exact command
set of our machine's CPU if I was going to do anything other than
crash it, nastily.
Our college library was devoid of anything specific
about the PET, but I found out that one of the teachers –
a chap we called The Klute on account of a superficial resemblance
to a chess-playing alien out of Blake's 7 – had a copy of
the hallowed Rodnay Zaks programming manual for the 6502, which
was the CPU chip of our PET. A degree of Klute-hassling eventually
persuaded him to cough up the sacred tome for a weekend loanage,
with strict instructions that it must be back in his hands Monday
morning. I took it home and did a spot more poring – most
importantly, copying out the table which showed which numbers
meant what commands to the CPU.
The Gospel According To Rodders.
The PET itself wasn't set up natively to be
kind to anyone wanting to program it in machine language. There
was no ‘assembler’ - a program that allows you to
enter machine code programs by using more human-friendly strings
called ‘mnemonics’ to represent the commands. In an
assembler you could type LD A #8, for example, and the assembler
would know you meant a ‘load accumulator’ command
with the immediate data of value 8 and generate the right code.
Without an assembler you had to use your opcode table and work
out that the machine language command to load the accumulator
was represented by the number 169 followed by 8 for the immediate
value.
Because BASIC was always there, you couldn't
just randomly place your machine code program anywhere. BASIC
was likely to use bits of memory you might have code or data stored
in without asking politely, so where to put the code was an issue
in itself. Fortunately there was a tiny scrap of memory called
the ‘cassette buffer’, where information was stored
during the SAVE and LOAD operations that used the tape deck. At
all other times this piece of RAM was unused, and so it became
a good testing ground for my first faltering steps into the world
of machine language.
Naturally enough, I wanted to begin with something
simple, and I was reminded of the little BASIC program I'd written
to prove the existence of screen RAM. That simple loop had the
advantage of being extremely easy to implement in machine language,
and furthermore would give a good indication of how much faster
machine language was than BASIC, which we could plainly see took
three or four seconds to complete the task.
During the rest of my lessons at that time I
appeared to be particularly diligent, meticulously making notes
on my pad during classes. But had anyone looked closer they would
have seen that I was writing things like ‘A9 00 AA 9D 00
80 E8 D0 FB’ and drawing odd little diagrams. In an English
Lit class.
”Stoopid Jane Austen. I
want to shoot shit…”.
Eventually, I was ready to try out my program.
I had written it down in biro on a bit of paper, and an odd-looking
program it was. It consisted of nothing but a list of seemingly
random numbers, a loop which read those numbers and POKED them
into the memory at the start of the cassette buffer, and a single
SYS command which would hopefully cause the CPU to begin interpreting
those numbers as commands and have it do my bidding.
One lunchtime I sat down, entered my strange
program, and then saved it (so I wouldn't have to type it in again
if I crashed the machine, which seemed, under the circumstances,
highly likely).
I typed RUN – and was completely blown
away. It was a pure jaw-on-the-floor moment. As I've already mentioned,
the same program in BASIC took a few seconds to run - you could
see the characters appearing one after another in sequence as
they were POKEd into screen memory. But when I typed RUN, here...
...all of the characters appeared on the screen
at once. Instantly. They were just THERE. The same program that
the PET took several lazy seconds to complete in BASIC ran in
less time than you could measure in machine language. It was as
good as instantaneous. Machine language had to be at least a thousand
times faster than BASIC.
To confirm that was indeed true, I made my little
program into an endless loop and had it draw the characters in
white-on-black one pass and black-on-white the next. Running it
yielded a flashing blur of characters at the top of the screen
as the entire character set was redrawn again and again... far
faster than the eye could see.
A thousand times faster than BASIC? Now here
was a power worth the study to master...
14
I got a part-time job a couple of nights a week, cleaning offices
and toilets at Lansing Bagnell, a big forklift truck factory on
the edge of town. On work nights I'd take a packed tea with me
and spend a happy enough couple of hours Hoovering round an empty
office, with my can't-afford-a-Walkman-yet combination of cheapo
mono tape deck and some Sony MDR-5 headphones slung about me,
listening to the Pleasure Principle by our sainted Gazza...
I could get round the office and do what I needed
to do with a bit of time to spare, so I used to spend the last
twenty minutes or so sat in the directorial-looking chair in the
poshest of the offices on that floor, with my feet on the desk,
eating my packed tea. One time, I was emptying the bins in the
offices and found an entire book thrown away in one of the bins.
Naturally I fished this out and had a lookie - it turned out to
be a book of naughty stories by an author called Anais Nin. I
had a bit of a snigger thinking about the bloke who worked in
that office having a quick read of some naughty literature under
the desk during office hours, and wondered why he'd thrown it
away.
Dirty Anais. Fellow vicuna fan.
Too good for the bin, I decided, and filed it
away for ‘future reference’. Upon subsequent perusal
I found that the stories were indeed quite naughty, but actually
not badly written. One of them made fleeting mention of an animal
called a vicuna (in a context upon which I shall not elaborate)
and, intrigued because I'd never heard of such a beast before,
I looked it up in a reference book and discovered it was a member
of the South American camelids – vicuna, alpaca, guanaco
and llama, all unusual and striking-looking beasts.
I had no idea that a chance find of a book of
dirty stories in an office bin would indirectly and profoundly
influence a large upcoming chunk of my life...
15
The after-college job provided me with a small income, and I was
determined that I wanted to have at the very least some kind of
videogaming equipment at home. Us geeks had found a new haunt
to bunk off to in town – a place called ‘Videotime’,
which sold small home computers, videogames, and digital watches
(this being so primitive an era that not only did people think
that digital watches were a pretty neat idea, but also there were
specialist shops devoted to the selling of them).
We’d gather at Videotime to lust over
the likes of the Ohio Superboard, a ‘single board’
computer which consisted of one big circuit board without a case
which hooked up to a TV to display the output. It had BASIC and
graphics characters like the PET and was considerably cheaper,
but still way out of my price range, after-hours job notwithstanding.
So I concerned myself with the videogame consoles.
The Rolls-Royce of these was undoubtedly the eminently desirable
Atari VCS. We became regular visitors to the shop and wangled
many a session ‘evaluating’ the VCS by playing ‘Combat’,
trundling our little tanks round the screen and blasting one another
to oblivion. Once, I remember being in there when the very latest
game came in – ‘Superman’ - where you had to
fly the Man Of Steel round a multi-screen, Lego-like Metropolis,
catching criminals, avoiding Kryptonite satellites and, bizarrely,
Lois Lane who would, if inadvertently caught mid-flight, hang
from your neck standing on one leg and chiming (she was supposed
to be kissing you) and preventing you from picking up anything
else until you put her down. Cue mumbled curses and mutterings
of: "Gerrof, Lois!".
Early Yak-flavoured geek-porn.
But even the VCS was beyond my budget, then.
Although still relatively new on the market, and being by far
the most advanced console, and hailing from coin-op legends Atari,
it wasn't cheap (and although I couldn't afford one, I carried
with me at all times a copy of the game library catalogue –
an early example of geek porn). In the end I settled for something
a little less advanced - a machine called the ‘Teleng/Rowtron
Television Computer System’.
This was a big, angular, grey-and-black box
with analogue joysticks which had tacky button-pads underneath
the sticks - the keypads were an influencing factor in my decision
to purchase, because the catalog of ‘upcoming titles’
included a ‘Home Programmer Module’ which would supposedly
allow you to hack the machine in machine code using the keypads
to enter your code. Given what I was currently learning, the prospect
of being able to actually code a dedicated game console was hugely
appealing. Unfortunately the module never appeared, and it was
to be many years before I'd get my hands on the innards of a console.
The Rowtron. Yay – Dataset
font. It’s the fewcha.
Obscurity notwithstanding, it was the first
gaming system I ever owned, and it promptly took up residence
beside the family telly. Over the next few months as finances
allowed I acquired a small library of game cartridges –
none of them as good as the Atari games I coveted but all pretty
good fun. There was a reasonable clone of Combat, a bat-and-ball
cartridge with a lot of variants on Pong and Breakout, a maze
game, a pinball game with giant flippers made of huge pixels that
looked like crinkle-cut chips...
Pretty soon, the flimsy handles on the joysticks
broke off and I had to play by manipulating the little metal nubbin
that remained. Still, we had some fun with that machine, and it
was to last me for a couple of years.
But I still had the horn for Atari…
Jeff Minter,
April 2004.
Comment
Here.
Part
One – In The Beginning…
Part
Two – Colour, Sound, Poking Around…
____________________________________________________________________
|
