A Game Dev’s Story, Part II – The Kilobyte

Posted by Rampant Coyote on February 13, 2012

Because of the binary nature of computers, they tend to handle things in twos – especially powers of two. The fundamental states used repeatedly by digital machines to represent everything is “on” (or one), or “off” (zero). Now, by itself, that doesn’t seem to be a lot of information. But then you can combine bits to increase the amount of information represented.

For example, let’s say you wanted to count to three instead of just to one. You can add a second bit that modifies the first bit, which gives you a possibility of four combinations of values: “00” for 0, “01” for 1, “10” for 2, and “11” for 3. Each additional bit you add doubles the effective range. With three bits, you get eight total values (zero through 7): 000, 001, 010, 011, 100, 101, 110, and 111.  And so forth and so on.

Someone decided to designate a bunch of these bits together like that as a “word.” But the actual number of bits in a word varied from machine to machine in the early days. So somewhere down the line they standardized terminology a bit, and decided eight bits was a pretty good collection, and labeled it a “byte.” Interestingly enough, another useful grouping was four bits, which was called a nibble (sometimes spelled “nybble”). And on x86-based architectures (and many others), a “word” has now been standardized enough to mean two bytes.

A single byte can have a total of two to the power of eight, or 256 different combinations.  That’s a pretty useful range for a lot of purposes. It was often used to represent a character of text in the English language – uppercase, lowercase, punctuation, and a little left over. The old machine-language code for these old machines were usually parings of two (or more) of these bytes together – one as an “opcode” (the instruction) and one as the operand (the value to be acted upon).  So you might have a very simple program that stores the value of five in the accumulator (part of the central processing unit or CPU), adds one to the value in the accumulator, and then stores the resulting value from the accumulator into memory at a particular location. That ridiculously simple program would use up six bytes of memory. Well, seven, actually, because you need that one extra byte left over to store the results.

So as you can see, even simple programs – written in pure machine code – use up memory fast. In order to be useful, home computers in the 1980s had to have lots of bytes of memory. In 1981 or so, this was measured in kilobytes – a thousand bytes. Although in reality, a kilobyte was actually 1024 bytes (or 2 to the power of ten). And while a thousand of anything sounds like a reasonable amount, a single kilobyte (or “K”) is really not very much memory to work with.

And that’s what I had to work with when I first got started programming. Not that I had any clue what a bit or byte was when I started. I was about to learn.

My father brought home one evening a Sinclair ZX80. These never really caught on here in the United States (or anywhere else, for that matter), but it’s later version – the ZX81 (distributed in the U.S. as by Timex – the watch-maker – as the Timex Sinclair 1000).  They retailed for just under $200, but I think he picked it up for half-price at a show of some kind.

The Sinclair Zx80 was a tiny little computer with a membrane-covered keyboard. It ran on the underpowered Z80 microprocessor, with 1K of memory (RAM), and a low-resolution black-and-white display that plugged into a television.  You could plug a tape recorder into it to (try) and save or load programs, but it was an iffy affair at best.

The Zx80 ran an extremely simple version of the BASIC computer language, which consumed some of that precious 1K of RAM. It was slow, tiny, underpowered, and not really useful for much of anything other than learning how to program. To save memory, it wouldn’t “remember” what was on the screen – it would recalculate the screen output every frame. It could only do this when the CPU was idle, not doing anything else. This meant that when you pressed a button on the membrane-keyboard or ran any calculations, the screen would blank out until it was done.

To save memory, it didn’t store all BASIC commands in their complete form. Instead, it tokenized the commands. You hit the “O” button and it would display the entire word “PRINT” on the screen. But in memory, by my understanding, it really just stored a single byte representing the BASIC instruction “PRINT.” While limiting, it was a pretty clever way of taking advantage of extremely limited memory space.

Although I had the manual which explained (kind of…) the BASIC language – or the subset offered by the ZX80, my textbooks were really Creative Computing’s “BASIC Computer Games” and “More BASIC Computer Games.” You could type in the game programs directly from the book and then run them to play the games. Then you could modify the program yourself to change the game, which was always more fun.

My problem was that very few programs in the books were (A) small enough to fit on the ZX80, and (B) Used only the subset of BASIC used by the Zx80. In the latter case, once I learned more about the language, I could figure out ways around the language subset restrictions, but the memory restrictions were another matter. Quite simply, only the tiniest, most useless little games would fit on my little computer. Even then, I had to cut some bits to get it all to fit. Since I was just entering the games for my own use, I could dispense with the prompt that said, “Enter your move (1-8):”, as that would save me around 26 bytes right there.

There was only one (count ’em: one) action video game to my knowledge for the Zx80. It was a Space Invaders clone written in machine language that used some kind of a trick to alternate between reading input, processing game logic, and displaying the visuals on the screen, so you wouldn’t get the ‘screen blank’ problem (at least not as bad). I don’t know for sure, and I never played it. The dinky little game was something like $30 ($60 in today’s dollars). However, I was intrigued by this programming language called “machine code” or “machine language,” which sounded like it could do something that BASIC clearly could not. I had no idea that it was something fairly similar to those confusing books on programming I’d checked out of the library a few months earlier.

But in the meantime, I learned BASIC, and the fundamentals of computer programming, and learned to work under some pretty tight restrictions. I wrote tiny little games, and dreamed of having a better machine on which to make games that would rival my favorites in the arcade, or emulate that Colossal Cave Adventure game.

Meanwhile, I heard about other computers with no small amount of jealousy. The Apple II, or the Atari 800 (or even 400). Heck, even the TI-99/4A, TRS-80, and new VIC-20 were quite a bit beefier than my little Sinclair. A friend of mine had a cartridge for his Atari video game system that let you program in BASIC. It was even more underpowered than the Zx80, but at least it had sound and color. But all-in-all, it did have one decent use, and that was to learn the basics of programming (and BASIC). And I did. After a couple of months, I’d gone from knowing almost nothing about computers to really doing all there was to do within the confines of BASIC on the ZX80.

Filed Under: A Game Dev's Story, Game Development, Retro - Comments: 4 Comments to Read



top