Part 2: 1980s Home Brew – Keeping up with the Commodore Carl Muller shares his remembrance of home coding
[ No comments yet ]
In Part 2 Carl tells us about finally getting his own computer, joining the local computer club and in how his interest in games design inspired him to learn Assembly language and dissemble games studying the works of UK designer Jeff (Yak) Minter.
During the final term the school bought a newfangled Commodore VIC-20. This was a colour computer that was aimed at the masses. I persuaded my parents to buy me one as a combined Christmas/Birthday present, complete with a cassette deck for saving programs and not one but two expansion packs.
Expansion packs were packaged circuit boards that plugged into the computer and had chips on them giving it extra power. The base VIC-20 had only 5Kbytes of memory. Compare that to a modern iPad which might have 64Gbytes – over 10 million times as much memory! The expansion packs were a plain 16Kbyte memory pack and a 3Kbyte “super expander”, which not only contained a little bit of memory but also some read-only computer code that enhanced the BASIC language, allowing the programmer to draw lines and circles directly instead of having to write routines to do so. The BASIC on the VIC-20 and later C-64 was rather limited due to Commodore signing a “one-off” deal with Microsoft that meant they got no royalties.
BASIC started to become limiting within a year. On the 8-bit machines of the time it was slow, and on Commodore machines it was also very limited. To make the computer do anything useful you had to use the “POKE” command which meant sending a number (0 to 255) directly to a memory address (another number, 0 to 65535), all of which could do something specific.
To do speedy things with graphics it was necessary to write some routines in machine code or assembly language. I did not have a machine with a built in assembler, disassembler or machine code monitors like the Apple 2 or BBC micro computers. These would make life a lot easier by letting you type in assembly language directly rather than machine code. The ones theoretically available for the Commodore machines would cost extra money which I was not willing to spend.
Using an assembler, you could for example change the border colour on a Commodore 64 to Red by using the commands:
Which was equivalent to the BASIC command:
Where 53280 was the memory address controlling the border colour of the TV display, and the number 2 meant red. LDA# meant load a number to the A register, STA meant store the A register and RTS meant return from subroutine.
The way I had to enter it though, without an assembler, was:
This was less easily readable I would have to admit.
Fortunately the programmers reference manuals for the VIC-20 and C64 had full explanations of how the CPU worked in machine code. The 6502 chip inside them happens to be one of the simpler
After learning about how machine code worked in general, I decided to investigate the games which I had access to by reverse engineering them.
I started with the game “GridRunner”, which I tried to disassemble by hand onto the large (desk-sized) piece of paper my dad used at his work. I got most of the way through it, working out how the programmer had written the logic for the game.
I would display the contents of memory one number at a time, look up the instruction in the reference manual and write down the assembly language for the instruction. This was somewhat time consuming but at the time I clearly had nothing better to do!
Later on I disassembled the game “Laser Zone”, which was rather larger and took three school notebooks, which I still have. Both these games were written by the legendary British games programmer Jeff “Yak” Minter, who I have subsequently met a couple of times.
In later life I have done many more disassemblies of games, but have found the benefits of using more sophisticated tools.
Home Computer Clubs
Another big influence in the 1980s were home computer clubs, such as the one that was in the city near my home town. Once a month I would get picked up and driven to a space lent by a local business, where a couple of dozen people who had home computers could exchange the programs they had written with each other, and talk about computers. One particular boy was quite keen on drawing the graphics for a game I was going to write called “Fire and Ice”, but I never got around to finishing it so that was a disappointment for both him (since his graphics and designs were not to see the light of day) and me. However since we were all local this didn’t raise the bar of what we were attempting as much as if we had been able to see some of the things being done with the machines elsewhere in the world.
By contrast in the United Kingdom they had computer networks such as Prestel and Compunet, which allowed people to collaborate remotely with each other, and see various “demos” as they were written. This was not to become affordable to me until much later, which made me rather envious when I got copies of an exciting demo on a floppy disk two years after it had been written, showing off an amazing technique. Of course the current situation where the sum of the worlds knowledge seems to be searchable from google and wikipedia is far more data-rich than previous times ever were. Any home-brew hacker with an internet connection now knows more about a machine such as the Nintendo Entertainment System (NES/Famicom) than the official developers knew during its heyday.
Not long after I acquired a computer we moved back to New Zealand. In our new house my father built an ingenious folding table that held the computer and tape deck on it that packed away into a cupboard, and plugged into the family television. The key was drilling the screw holes from inside of the computer into the wood, rather than the other way around!
This did mean that I could only program the computer when other people did not want to watch television programs though!
After a couple of years on the VIC-20, I begged to get the far superior Commodore 64, which had much better sound, graphics and memory size. They agreed to give me it as another combined birthday/christmas present, and I kept hold of it for my remaining two years at high school and three years in university.
8-bit computers in the New Zealand and the UK mostly used cassette tape to store programs. They were cheaper to run and easier to duplicate. The 1980s were the decade of cassette tapes for music as well, being the era of the Sony Walkman and clones thereof. There were exceptions of course. The IBM-PC originally came with a tape deck option, but I only saw them and Apple 2 computers with 5.25 inch disks. For other computers though, tape ruled.
When you had a dozen games stored on one tape, you needed to write down the tape counter for each game, and then you could fast forward to that point in the future. It seemed that each tape counter was slightly different.
Sadly tape is slow in general, and the Commodore format exceptionally slow in particular.
There was a solution though, called TurboTape – this was a small program that let you save a program in a fast format; that format including a small program that automatically ran and started loading the main program in a faster fashion – 5 to 10 times as fast as the standard load routine. I obtained the version I used from friends – I did not know where it came from, but now I suspect from the January 1985 issue of the US magazine “Compute”, explained in a later issue:
Several other programs followed for fast tape access, especially from Sweden and Germany.
When I converted the game Teenage Mutant Hero Turtles to a cassette version in 1990, I used a loader written by Jon Twiddy, who also created the fast loader for the disk version.
Floppy disks cost more money but were faster and allowed random access of data – no requirement to rewind tapes. It was another couple of years before I could get one though.
Image: Teenage Mutant Hero Turtles (1990) Commodore 64