The most amazing thing about this to me is the description of the internals of Robotron... Given a lot of the 8-bit machine code I've read it's simply astonishing to hear about a game of that era being so structured rather than the more typical approach of the day of hardcoding data all over the place (some games even used the on screen life counter as the actual "variable" holding the number of lives left, often full of bugs like not overflow checking the values) and using a basic event loop hanging off the irq. A lot of the time it was seen as necessary in order to fit everything in the small amount of memory, and so even on larger machines like the Amiga a lot of programmers kept manually laying out data structures for many years...
Compare the recently released Prince of Persia code to that description, for example. I found the Prince of Persia code very clean and readable for the period when I read it, but still relatively typical of the style of 80's 8-bit machine code programs even if it looks like it avoided the dirtiest tricks.
A game from that era using dynamic memory allocation, multi-tasking and an object oriented structure just sounds totally alien. Even Amiga games, running on a system with substantially more memory, and on an OS with substantial built in support for it mostly, - with some honourable exceptions - just disabled the multi-tasking entirely and often hung everything off a loop tied to an interrupt handler or at most an interrupt handler and a separate "main" thread.
That's a Eugene Jarvis and Larry DeMar game. He also co-wrote Defender, Smash TV, and other classics with DeMar. Eugene now teaches at DePaul in Chicago.
The 6809 is a very nice 8-bit CPU, designed with the intention of using higher level languages---it could generate position independent code, had four general purpose index registers (all 16-bit, one was also the system stack register), two 8-bit accumulators that could be used as one 16-bit accumulator, and had some rather advanced addressing modes.
One thing that I think that is important to understand is that these machines, and this code, is still out there, working. People are still playing these games (MAME) and the emulation scene that has arisen due to the fanboix fervour has really pushed a lot of the gems into the 21st century with new life and vigor. The "automatic game player"-coded-in-z80, i.e. hardware playing hardware, is a real hoot!
And last but not least, consider this: people are still writing amazing software for the older architectures, using modern principles, and learning astonishing new things about the "antique hardware", to boot! In my particular nook I have witnessed the Oric-1/Atmos machines (http://oric.org), typically considered a fairly "grotty" 8bit machine of the 80's, never enough decent software, died early .. yet now come to new life with the discovery of never-considered color-modes and graphics capabilities by some of the modern scenes very elite hackers, turning their eyes to the "old" machines and producing new hits!
I think a lesson in all of this is that the old machines still contain a lot of power. The robotron code could probably be refactored into something else, easily enough, if there was some intention behind doing it. There are a lot of 6809's out there, still, presumably in landfill its true, but nevertheless one could do worse than to re-discover old machines in the modern era, were one to want to sharpen ones skills ..
If you want to read a bit more about Robotron, there's another good write-up by someone who did the same thing: reverse engineered Robotron. It's a much shorter article, but includes some C# representations of the process management:
Having some insider knowledge of how Williams wrote their videogames, Steve's disassembly is the best presentation of how the Robotron architecture worked. This setup was used in almost all of the games that DeMar and Jarvis did for a decade or two to come, including the pinball operating system (which was pretty much this exact same process/task system). These guys always wrote in assembly. I don't think C came along at Williams/Bally/Midway until they switched to an X86/PC-based architecture sometime around 1998-1999.
Earlier on HN someone posted an article about a Tron-like light cycle game where the cycles would break out of the framebuffer and start to mess with program memory. What's cool about Robotron is that you are actually killing processes when you wipe out the robots. A true superuser!
Hey, nice of you to dredge that up. At the time that I owned a Robotron machine, I worked at Adobe and had easy access to a ROM burner so joe and I pulled the ROMs and joe wrote a disassembler. We spent the next few weeks idly reading and commenting code on a shared text file. One of the the really fun things was spotting the bitmap images the output. They were 4bpp, so 2 pixels per char - they were surprisingly easy to find and once I did, I dumped the raw data from one set into a file and managed to convince PhotoShop to open it. I set the colormap entries and I was looking at Hulks on a Macintosh IIci.
A year later, I wrote an emulator for the sound board and on the Mac I had at home it ran at about 60% real time (this was a 25MHz 68K based machine). That's a great number for code written in C because it means that with some careful attention, I could easily getting it running better than realtime, especially if I wrote some of the routines in inline 68K and took advantage of the condition codes of the 68K matching up nearly exactly to the 6800 (thanks, Motorola!). Before I started that task, I ported the code to a PowerPC machine at work and it was running 4x real time, so I decided that Moore's law just won and assembly was a waste of time.
The model of execution was, again, fairly decent for the task at hand. The sound board was set up with either 5 or 6 data lines (depending on the rev) coming in to a latch. When the host game wrote to the PIA, it would latch the value and cause an interrupt on the sound board. The sound board (which was a 1MHz 6808 with 128 bytes of ram) would be lodged in a WAI (wait for interrupt) instruction. When it got an interrupt, it read the latch and then ran an enormous switch statement to decide what sound to make. The output was an 8 bit D/A converter, but it looked like most of the time they treated it like a one-bit, by either writing 0 or FF. Most of the sounds were made by using frequency generators to drive other frequency generators - FM symthesis (more or less) - and the individual sounds would just set up parameters and kick off the sound generator. Most of them were designed to make sound forever (or close to it) or until they were interrupted by another request for a sound.
The two that really stood out in that set (and there are a ton of sounds on it that are not used in Robotron), was a crowd cheer, which was white noise with some envelope modifiers with some whistles mixed over the top, and a peal of thunder. You can hear each of these by dropping credits into a Robotron until they come up. IIRC correctly, Jarvis was particularly proud of these.
Eventually, I modded the code to run as a CGI script and had it running on my website as RobotrOnline, which would let you set up the hardware lines that modeled the lines going in, let you set how many seconds you wanted and when you submitted the form, it spat back a wav file meeting those parameters.
There is an old programmer joke that goes "I can write BASIC code in any language!" which is a lament about people writing spaghetti type code (which was normal for early programs in BASIC) even when the language supported much more elegant constructs. But the inverse is also true (although people rarely complain about it :-) since ultimately you're compiling into machine code, if you're writing in machine code you can write as elegantly as you could in the most beautiful high level code, its a function of the programmer, not the language.
There are people who write solid, supportable, code in any language. keep those people around as they will ultimately create the most code with the least technical debt.
I was tickled pink to find the core bits of SpriteCore, the game library I brewed up as a teenager, and have been hacking on idly ever since, implemented in a for-realz 1980s arcade game. In assembly.
I don't want to diminish what he did, but consider that this was one of the most common methods of learning assembler programming in depth in that era. Most books on the subject were relatively primitive in the context of games and demo programming, and so if you didn't want to lag behind, you needed to figure out techniques by studying disassembled programs.
(EDIT: Just to add that this is in reference to the disassembling bit. Pulling eproms to dump them and studying them so intently you start to fix bugs the game designers hadn't managed to solve is certainly dedication well above the typical level)
Many large demos at least for 8-bit computers, and quite likely some games too, were written even without a symbolic assembler, but instead entered using a simple machine code monitor (think just one step above debug.com on MS DOS, and decidedly more primitive than programming directly in gdb...) using hardcoded address references instead of labels.
I'd actually been programming on the C64 for a couple of years before I got an assembler that supported labels that was good enough to use (I had some before that, but they wasted too much memory and/or were too slow to seem worth it) and from people I met I gather that's a fairly common experience.
In the early days of game piracy on computers like the Apple ][, people hand-disassembled the copy protection schemes to understand how they worked and develop workaround patches.
Granted, it's a lot easier to get to the object code on an Apple ][ than it was on a Williams Robotron. Harder still when you don't have documentation about the specific I/O ports on the hardware and other things like the blitter chip.
Compare that to Tom Skelly, lead programmer at Cinematronics (80s vector games) who had to reverse engineer an abandoned custom CPU design while writing games for said CPU in machine code on legal pads.
That's how me and my brother learned to program graphics and games as 14-year olds. We disassembled over 50% of Manic Miner on the Sinclair Spectrum using an hex-to-opcode sheet, lots of pen and paper, and oh yes tracing lines along the jumps. Fun times! (I continued ripping apart many other Spectrum games, but with actual disassemblers)
All it required was: free time, motivation and, above all, a mind free of assumptions and structure, ready to learn and be filled no matter the effort.
(25 years ago) the first and hardest step was to get the hex memory dump printed (the amount of pages to be printed required escalating of one's permissions to "operator" level) and physically get the said printout into your possession - depending on the situation one could try to charm the girl "operator on duty" in the university department datacenter or one could divert her attention in some other way while one's partner will try get to the printer ...
I can remember using 'ddt' to rummage through the code for WordStar (I think) on my old Kaypro back in the early '80s. It really caught me of guard when somewhere deep in the middle of the disassembly I ran into some chunk of data that said "Nosey, aren't you?"
Incredible that he was working for minimum wage after completing this. And he is true on saying that we value too much a university diploma (but this is slowly changing).
There is an interesting bug which I think has been left even in the ROMs which fix the more annoying problems like the corner shoot crash.
The objective of the game is to dodge and kill all the Robotrons on each screen while "saving" as many humans as possible by touching them. One of the Robotron models is the Brain, which reprograms the humans and sends them chasing after you. On the first level with the Brains, though, there are a whole bunch of Mommies on the screen and one Mikey (a little kid dressed in red). It turns out that the Brains won't start reprogramming humans until you save Mikey, so if you avoid him and gather up all the Mommies, you can rack up a lot of points and make the level much easier.
So, kind of a bug that turned into a feature. It's a one-off thing and probably not too relevant to people scoring well over 2 million points, but for a guy like me (many heartbreaking runs ending in the 900,000s), a good score on that level could be make-or-break for a whole 10-15 minute run.
Some of the scores guys put up on the original machines in the early 80s are even more impressive when you consider they could end their game at any time by shooting into the corner the wrong way.
What an abrupt ending... no resolution or anything, just this random tidbit!
"Larry insisted to come back and drive us to the airport. When he aggressively honked at a city bus driver for trying to cut him, this felt like a life lesson for me"
There's another page that explains what happened after - they offered him a job after he'd finished college but the video game crash ended up stopping that.
In one of the later parts, he complains that employers only look at diplomas instead of what you can actually do. His prospects opened up a bit after he graduated.
It sounds like a messy translation of "mess of wires", like Christian had soldered on a bunch of extra wires to scope out various signal lines and interrupt the clock, etc.
[+] [-] vidarh|12 years ago|reply
Compare the recently released Prince of Persia code to that description, for example. I found the Prince of Persia code very clean and readable for the period when I read it, but still relatively typical of the style of 80's 8-bit machine code programs even if it looks like it avoided the dirtiest tricks.
A game from that era using dynamic memory allocation, multi-tasking and an object oriented structure just sounds totally alien. Even Amiga games, running on a system with substantially more memory, and on an OS with substantial built in support for it mostly, - with some honourable exceptions - just disabled the multi-tasking entirely and often hung everything off a loop tied to an interrupt handler or at most an interrupt handler and a separate "main" thread.
[+] [-] drzaiusapelord|12 years ago|reply
http://en.wikipedia.org/wiki/Eugene_Jarvis
[+] [-] spc476|12 years ago|reply
[+] [-] primitur|12 years ago|reply
And last but not least, consider this: people are still writing amazing software for the older architectures, using modern principles, and learning astonishing new things about the "antique hardware", to boot! In my particular nook I have witnessed the Oric-1/Atmos machines (http://oric.org), typically considered a fairly "grotty" 8bit machine of the 80's, never enough decent software, died early .. yet now come to new life with the discovery of never-considered color-modes and graphics capabilities by some of the modern scenes very elite hackers, turning their eyes to the "old" machines and producing new hits!
I think a lesson in all of this is that the old machines still contain a lot of power. The robotron code could probably be refactored into something else, easily enough, if there was some intention behind doing it. There are a lot of 6809's out there, still, presumably in landfill its true, but nevertheless one could do worse than to re-discover old machines in the modern era, were one to want to sharpen ones skills ..
[+] [-] EdwardCoffin|12 years ago|reply
Steve's Tech Talk: Robotron and OOP http://www.atalasoft.com/cs/blogs/stevehawley/archive/2006/0...
[+] [-] joezydeco|12 years ago|reply
Earlier on HN someone posted an article about a Tron-like light cycle game where the cycles would break out of the framebuffer and start to mess with program memory. What's cool about Robotron is that you are actually killing processes when you wipe out the robots. A true superuser!
[+] [-] plinth666|12 years ago|reply
A year later, I wrote an emulator for the sound board and on the Mac I had at home it ran at about 60% real time (this was a 25MHz 68K based machine). That's a great number for code written in C because it means that with some careful attention, I could easily getting it running better than realtime, especially if I wrote some of the routines in inline 68K and took advantage of the condition codes of the 68K matching up nearly exactly to the 6800 (thanks, Motorola!). Before I started that task, I ported the code to a PowerPC machine at work and it was running 4x real time, so I decided that Moore's law just won and assembly was a waste of time.
The model of execution was, again, fairly decent for the task at hand. The sound board was set up with either 5 or 6 data lines (depending on the rev) coming in to a latch. When the host game wrote to the PIA, it would latch the value and cause an interrupt on the sound board. The sound board (which was a 1MHz 6808 with 128 bytes of ram) would be lodged in a WAI (wait for interrupt) instruction. When it got an interrupt, it read the latch and then ran an enormous switch statement to decide what sound to make. The output was an 8 bit D/A converter, but it looked like most of the time they treated it like a one-bit, by either writing 0 or FF. Most of the sounds were made by using frequency generators to drive other frequency generators - FM symthesis (more or less) - and the individual sounds would just set up parameters and kick off the sound generator. Most of them were designed to make sound forever (or close to it) or until they were interrupted by another request for a sound.
The two that really stood out in that set (and there are a ton of sounds on it that are not used in Robotron), was a crowd cheer, which was white noise with some envelope modifiers with some whistles mixed over the top, and a peal of thunder. You can hear each of these by dropping credits into a Robotron until they come up. IIRC correctly, Jarvis was particularly proud of these.
Eventually, I modded the code to run as a CGI script and had it running on my website as RobotrOnline, which would let you set up the hardware lines that modeled the lines going in, let you set how many seconds you wanted and when you submitted the form, it spat back a wav file meeting those parameters.
[+] [-] ChuckMcM|12 years ago|reply
There are people who write solid, supportable, code in any language. keep those people around as they will ultimately create the most code with the least technical debt.
[+] [-] bitwize|12 years ago|reply
[+] [-] scrapcode|12 years ago|reply
[+] [-] gnosis|12 years ago|reply
Part 1 - http://www.robotron2084guidebook.com.nyud.net/technical/chri...
Part 2 - http://www.robotron2084guidebook.com.nyud.net/technical/chri...
Part 3 - http://www.robotron2084guidebook.com.nyud.net/technical/chri...
Technical information about the shot-in-the-corner patch - http://www.robotron2084guidebook.com.nyud.net/technical/chri...
Photo album - http://www.robotron2084guidebook.com.nyud.net/technical/chri...
[+] [-] DuskStar|12 years ago|reply
[+] [-] vidarh|12 years ago|reply
(EDIT: Just to add that this is in reference to the disassembling bit. Pulling eproms to dump them and studying them so intently you start to fix bugs the game designers hadn't managed to solve is certainly dedication well above the typical level)
Many large demos at least for 8-bit computers, and quite likely some games too, were written even without a symbolic assembler, but instead entered using a simple machine code monitor (think just one step above debug.com on MS DOS, and decidedly more primitive than programming directly in gdb...) using hardcoded address references instead of labels.
I'd actually been programming on the C64 for a couple of years before I got an assembler that supported labels that was good enough to use (I had some before that, but they wasted too much memory and/or were too slow to seem worth it) and from people I met I gather that's a fairly common experience.
[+] [-] kryten|12 years ago|reply
He watches DVDs for 7 hours a day on a laptop and goes for an amble the other hour.
That is the entire job.
If only he put some of that time to better use like that kid did. It's not amazing, but a good use of the time.
[+] [-] joezydeco|12 years ago|reply
Granted, it's a lot easier to get to the object code on an Apple ][ than it was on a Williams Robotron. Harder still when you don't have documentation about the specific I/O ports on the hardware and other things like the blitter chip.
[+] [-] sehugg|12 years ago|reply
http://www.dadgum.com/halcyon/BOOK/SKELLY.HTM
It's amazing what you can do when you're focused.
[+] [-] Jare|12 years ago|reply
All it required was: free time, motivation and, above all, a mind free of assumptions and structure, ready to learn and be filled no matter the effort.
[+] [-] VladRussian2|12 years ago|reply
[+] [-] mtm|12 years ago|reply
[+] [-] jackbravo|12 years ago|reply
http://www.robotron2084guidebook.com/technical/christianging... (cached: http://webcache.googleusercontent.com/search?q=cache:SOgJkJa...)
Incredible that he was working for minimum wage after completing this. And he is true on saying that we value too much a university diploma (but this is slowly changing).
[+] [-] AndrewBissell|12 years ago|reply
The objective of the game is to dodge and kill all the Robotrons on each screen while "saving" as many humans as possible by touching them. One of the Robotron models is the Brain, which reprograms the humans and sends them chasing after you. On the first level with the Brains, though, there are a whole bunch of Mommies on the screen and one Mikey (a little kid dressed in red). It turns out that the Brains won't start reprogramming humans until you save Mikey, so if you avoid him and gather up all the Mommies, you can rack up a lot of points and make the level much easier.
So, kind of a bug that turned into a feature. It's a one-off thing and probably not too relevant to people scoring well over 2 million points, but for a guy like me (many heartbreaking runs ending in the 900,000s), a good score on that level could be make-or-break for a whole 10-15 minute run.
Some of the scores guys put up on the original machines in the early 80s are even more impressive when you consider they could end their game at any time by shooting into the corner the wrong way.
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] 420vision|12 years ago|reply
"Larry insisted to come back and drive us to the airport. When he aggressively honked at a city bus driver for trying to cut him, this felt like a life lesson for me"
[+] [-] Untit1ed|12 years ago|reply
[+] [-] jongold|12 years ago|reply
[+] [-] sp332|12 years ago|reply
[+] [-] to3m|12 years ago|reply
http://captaincapitalism.blogspot.co.uk/2013/05/why-you-shou...
[+] [-] gojomo|12 years ago|reply
[+] [-] mathattack|12 years ago|reply
[+] [-] sgt|12 years ago|reply
[+] [-] healthenclave|12 years ago|reply
- which country was he from ? - Did he become a successful coder ??? - What is he upto these days ??
This story is incomplete !!
[+] [-] jackbravo|12 years ago|reply
- http://www.robotron2084guidebook.com/technical/christianging... - http://www.robotron2084guidebook.com/technical/christianging...
[+] [-] rasmus4200|12 years ago|reply
[+] [-] Ellipsis753|12 years ago|reply
[+] [-] sp332|12 years ago|reply
[+] [-] joezydeco|12 years ago|reply
[+] [-] cromwellian|12 years ago|reply