1 Kilobyte of memory!
So how much is one KiloByte anyway? Just to emphasise how little this really is
take a look at this:
0123456789012345678901234567890123456789012345678901234567890123
0123456789012345678901234567890123456789012345678901234567890123
0123456789012345678901234567890123456789012345678901234567890123
0123456789012345678901234567890123456789012345678901234567890123
0123456789012345678901234567890123456789012345678901234567890123
0123456789012345678901234567890123456789012345678901234567890123
0123456789012345678901234567890123456789012345678901234567890123
0123456789012345678901234567890123456789012345678901234567890123
0123456789012345678901234567890123456789012345678901234567890123
0123456789012345678901234567890123456789012345678901234567890123
0123456789012345678901234567890123456789012345678901234567890123
0123456789012345678901234567890123456789012345678901234567890123
0123456789012345678901234567890123456789012345678901234567890123
0123456789012345678901234567890123456789012345678901234567890123
0123456789012345678901234567890123456789012345678901234567890123
0123456789012345678901234567890123456789012345678901234567890123
This is 1 KiloByte (1024 bytes) of memory where each number is one byte or 8 bits long. This is the amount
of memory the first KIM-1 had. This is the amount of memory that Peter Jennings was able to fit
Microchess, a full chessgame!
 |
| Microchess listing |
You start to understand how little this is when you also think that one instruction in the
6502 processor doesnt necessarily occupy 1 byte of memory, but up to 3 bytes (1 byte for
opcode and 2 bytes for address). In the KIM-1 case since the memory was at the start you could
store data in the "zero page" (first 256 bytes of memory) to shave this down to a maximum of 2
bytes per instruction. This is also why Peter Jennings could distribute his chess game
with the byte listing on one sheet of paper (a total of 924 bytes).
The VIC-20 had a whopping 5 KB of ram in it (from which you had 3.5 KB for basic) so five times
the amount shown in the illustration above. Although it was quite often necessary to
expand your VIC-20 with 3kb, 8kb or 16kb cartriges for many programs to load, quite
a lot of released games ran on unexpanded Vic-20. There really isnt much you can fit
into those 5 KB of ram (you could access most of with machine code programs), but still
it was good enough for many years during the VIC-20 success. It must be said however that
cartridge games was very popular simply because it didnt require any loading and it
solved some of the memory problems since the roms could be larger.
 |
| C64 ram chips |
You can then understand the gigantic success of the Commodore 64 having a full 64 KB of
ram. Programmers must have felt free as it opened up a whole new complexity of programs and
games. Although it became soon clear that as the standards rose, so did the expectations
of the games graphics and sound, eventually resulting in lenghty multi-load cassette and
disk games. One conclusion we can draw from this is that in spite of the C64's large
ram at the time, its VIC-II chipset had 8 multicolor sprites which could be "reused" during
a screen draw to actually show many more, custom charsets that could also be swapped
during redraw to display multiple charsets, and a beautiful SID chip with 3 channels
that could play lots of sounds with advanced effects and even samples to some degree.
The hardware in the C64 was capable of much more than what its 64 KB of memory allowed.
A typical game could use 8 KB of sprites (sometimes they used several single color ones
on top of each other to get a higher resolution and finer animation), 2 custom charsets
at 2 KB each, several songs occupying 8 KB or more. Perhaps it used double buffering
since a full screen scroller required a lot of data to be moved, and you have 3 KB
in screen data gone (2 screens, 1 colorinfo). Add a whole bunch of levels and it
is clear that getting the games to run in a single load was difficult if not impossible.
Some games had such high graphical standards that you simply had to load data
as required. Summer Games is a good example. Epyx set high standards with its
high framerate animation and excellent backdrop graphics. Each event is basically
a game in its own. Epyx was a US based company where disk drives where abundant, so
these games were often really designed for disk owners (although the C64 disk drive
was notoriously slow). You can imagine how this was for those playing it on tape!
The C64 tape drive transfers about 50 bytes per second, and unless the data was
compressed, filling the whole 64 KB of ram with data could take 21 minutes! The
real loading time was usually around 4-5 minutes since most games didnt require
the whole memory to be filled with data and often used compression.
With the Amiga 1000 you had 256 KB of ram, usually expanded to 512 KB and with the
very popular Amiga 500 this had grown to a 512 KB base ram, and most people expanded
it with another 512 KB breaking the 1 MB barrier. But as with the C64, the chipset
of the Amiga required so much more ram since you had higher resolution display,
more colors, sampled sound playback. Game creators soon met the same barriers in
these computers.
Well the history goes on... a typical 2008 Personal Computer comes equipped with
2 GigaByte of ram. Yes, you dont think much about it but we are talking 4096 times
more memory than a base Amiga 500, and 32768 times more memory than a Commodore 64!!!
There is no wonder why these computer still spawn a new interest in old computing
because it is absolutely fantastic to realise how much you can achieve even with
1 KB of memory. Which is actually the basis for a whole genre within the demo
scene, and indeed a challenge for even the best programmers. Once spoiled with
gigabytes of ram that is so easily mis-used it is hard to understand how they
can make a word processor in some kilobytes of ram. Your current OS even swaps
like a madman to a drive that reads thousands of times faster than the C64 drive
because it cant even fit its current software. Think about that for a while and
appreciate the days where programmers had to think about which opcodes to use
so they could shave off a byte (or indeed a execution cycle) to make their
game run fine within its boundaries.
|
