Medwaypvb.com
The History of Llamasoft

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.

Part One – In The Beginning…

Part Two – Colour, Sound, Poking Around…

Part Three – Welcome To The Machine…

Part Four – The Joy Of ZX & Hex.

Part Five – Fur-Ther Education.

Part Six - Higher Learning.

First published at Way of the Rodent.
http://www.wayoftherodent.com/