 |
My Commodore C128D computer with Commodore 1084 color monitor had a metal chassis with built-in power supply and 1571 floppy drive, and an external, full-size keyboard (including a numerical keypad). It wasn't just the physical appearance that looked far more professional than the C64. To quote the Wikipedia article:
The system architecture of the C128, which in case of a C128D with memory expansion included three CPUs, five types of RAM memory, three operating modes, two system speeds, two graphics chips and two completely different low-level floppy disk encoding schemes was positively baroque and not at all orthogonal.
With the C128, I could run the vast amount of C64 software (ahem, mostly computer games) that floated around on the school yard and was copied from friends. (With a little persistence copy protection could typically be circumvented with special disk copy programs called Turbo Nibblers, but most games were shared as cracked versions which contained sophisticated cracker intros. Sometimes, those intros had better effects than the game itself.)
In addition, I had a powerful system with a vastly superior BASIC (including graphics commands, sprite editor and binary load for machine language libraries), twice the amount of memory and megahertz, and fast disk access. My monitor allowed me to switch to 80-column mode, which offered crisp, PC-like text processing. (I later implemented a personal diary program complete with pull-down menu, mouse pointer, encryption and personal metrics collection.)
Over time, I expanded the system with a datasette (as a cheap tape backup), various joysticks (first pilfered from my Atari, later I used a Joyboard with analog paddles before settling on the gold-standard Competition Pro), a system cartridge (to freeze, debug and modify the entire system) and a light pen (no, not a light saber, and optoelectronic input device that allows to control something like a mouse pointer when it touches the monitor's surface). Much later (after paying off the debt of that investment), I acquired a C64 for hardware experiments and connected both systems via a custom serial link.
| Wauzi Plot — graphing of mathematical functions | |
 |
 |
| original parabola plot printed on 9-dot color matrix printer Star LC10C |
excerpt from the BASIC V7 listing, overall ~ 150 LOC |
I also got a dot-matrix printer one birthday. As with my computer, my wishes had started modest, but I soon realized that my dreams and use cases could only be completely fulfilled with a color printer. The first ink-jet printers had arrived (HP Deskjet 500C), but were prohibitively expensive (2000 DM). I chose the Star LC10C, a 9-dot color matrix printer costing 600 DM (as with my computer, I had to forgo several future birthday presents for that one, too), which generated the different colors by lifting the 4-color ribbon and printing again over the same line (resulting in undulated paper, and bleary colors). By choosing standard Centronics over the alternative CBM interface, I was able to later re-use the printer on my PC. On the other hand, this meant that I had to program the printer driver myself, as the generic Centronics driver didn't support multicolor. Fortunately, back then all printer Escape commands were included in the printer's manual, and so I started exploring all codes for bold, italicized, condensed modes, and all the various font, quality and color selection commands.
BASIC programming was simple, but also very limited. Programming in 8-bit assembly was tedious and slow (with the type → save → compile → load → execute → crash → reset → load assembler → load program cycle), but one could achieve things that simply weren't possible in BASIC. Most of my programs consisted of the higher-level "business logic" (menus, configuration, etc.) implemented in BASIC, which would invoke short self-written machine code library functions for the time-critical stuff like memory operations or near-multitasking via an interrupt service routine.
My Wauzi Plot program perfectly adheres to this architecture: The menu and function plotting is written in BASIC, the program briefly returns back to the operating system prompt for its formula editor, and hard-copy rendering is delegated to a printer library in machine code. (I greatly accelerated the hard-copy by printing each color separately, commanding the printer tractor to rewind the endless paper in between each pass. This was much faster (and less noisy) than the default behavior, which would print all 4 color passes over each individual line.)
 |
| the C64 prompt |
 |
| mystical keys?! |
 |
| Bubble Bobble |
 |
| Giana Sisters |
 |
| Boulderdash II intro |
 |
| Boulderdash II gameplay |
So, what did I program? Well, after getting my computer at Xmas, I spent most of the Xmas holidays keying in necessary programs, as I only had the bare system, some blank floppy disks, and a stack of computer magazines with listings. I even had to bootstrap the type-writing, as the magazine used two text entry programs (one for BASIC, one for machine code; there virtually wasn't any other programming language) that automatically verified each input line via a checksum. One of the first programs I keyed in was SMON, an 8 KB machine code monitor / disassembler.
My initial programs were simple things trying to explore the capabilities and possibilities (graphics, sprites, fonts, sound, disk-I/O, joystick input, while simultaneously trying to induce a wow from my brother, my parents (who mostly didn't understand what I was doing all the time in front of that gray box), my schoolmates. I loved using a simple interruption routine (just one page of assembly) to change the border color when the monitor's electron beam approached a certain screen line. One could achieve a (16-color) "rainbow effect" while still working normally with the computer. Well, except for when there was disk I/O, then the timing broke apart. Being so close to the metal, one easily learned a lot about the inner workings of the system. These IRQ-experiments culminated in a desktop billiards emulator, a solid ball that moved around the screen and bounced off of characters, changing direction when it encountered /, \, or any of the funny extended characters that were printed on the front side of the keyboard, like mystical signs. One could still edit the program while the ball moved back and force, or chase it with the cursor.
After spending all day to type in a 3D Mandelbrot generator, then waiting the entire evening to draw the fractal pixel by pixel, I was hooked on this beautiful part of mathematics, and soon started writing my own generators.
My largest serious application was the aforementioned personal diary, a special-purpose word processor that was as much modern GUI application as that home computer platform allowed. I used it for a couple of years.
I also remember that I programmed more homework-support tools like Wauzi Plot, mostly for chemistry and mathematics. I once "cracked" a game (for my brother, who was stuck in an early level; I personally would never cheat at games ;-), i.e. I came up with a POKE (little machine code patch) and a SYS (re-entry memory address) so that one had an unlimited number of lives, or could start right in level N.
But first and foremost, I wanted to develop games. To prepare for that, I had an entire box full of games, and of course spent a lot of time playing them. My favorites were: Bubble Bobble, Boulderdash, Giana Sisters, Pitfall II, Wonderboy, Bruce Lee (jump-and-run games), Rally Speedway (which included a track editor) and Krakout (arcade action), the Summer/Winter/California games series, Test Drive, Grand Prix Circuit and Solo Flight (sport simulations), Pirates!, Kaiser, Oel, Oil Imperium and Sim City (strategy games).
With so many ideas, I sketched and designed dozens of games, actually implemented far less, and finished very few. One of those was Super Speed (I hadn't yet decided on a name, but that's the name of a later PC shareware game that essentially was the same idea implemented by somebody else), for which I had completed levels, game features, painted car sprites for each car angle, created sound effects, implemented track and car selection menus in BASIC and the game engine in assembly.
Development took so long because there were no software development kits yet, neither game editors (except for one from Activision in which Pitfall was implemented, but it mostly only created similar copies of the same concept) nor graphics engines. Everything had to be developed from scratch, which was time-consuming; even though (or especially because) the hardware didn't offer a lot. (Try writing some decent game music with 3 concurrent notes, and simply ADSR-envelope instruments; but that didn't stop geniuses like Chris Hülsbeck to create awesome music.)
 |
Due to the lack of abstraction layers, programming (especially game programming with its joystick input, sound and graphics effects) was very close to the hardware. There were no APIs, one had to directly read and write into the memory-mapped hardware registers of the various chips. I still easily remember the base addresses of the VIC video chip (53248 = 0xD000), SID sound chip (54272 = 0xD400) and CIA I/O chip (56576 = 0xDD00) — twenty years later. Especially due to the limited command set of the C64's BASIC V2, there were PEEKs and POKEs in almost every program. (Who would forget SYS 49152, to the start address of most assembly routines, or SYS 64738, the soft-reset command?) This also led most aspiring programmers soon into assembly language, where these memory modifications were actually simpler (and much faster) than in BASIC.
The C64 hardware offered many options for (even exotic) input and output devices. The simple hardware design also made it very simple to attach home-brew sensors to it: Just scavenge a cable and still functioning micro-switch from an old joystick, wire it together, plug it in, and you have a custom binary input switch! With its standard connectors, the joystick ports were easily converted to IO ports. If you needed more, there were 8 more flexible I/O lines at the user port, a connector to the printed circuit board. With full access to the processor bus, the expansion port could be employed to build memory expansions, ROM modules, even co-processors.
Thus, a new hobby was born; I invested the donations from my confirmation to build my own electronics lab.
Ingo Karkat, 15-Apr-2009