3 ms·

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 shorte

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: Steve's Tech Talk: Robotron and OOP http://www.atalasoft.com/cs/blogs/stevehawley/archive/2006/03/03/9632.aspx http://www.atalasoft.com/cs/blogs/stevehawley/archive/2006/0...

joezydeco 13y ago
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!
ChuckMcM 13y ago
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.
- alexk7 13y ago
  The original joke is "The determined Real Programmer can write FORTRAN programs in any language." It's from an essay written by Ed Post titled "Real Programmers Don't Use Pascal". It's before BASIC :)
  - Someone 13y ago
    Nitpick: it can't be from "before BASIC" if it mentions Pascal. BASIC is older than Pascal (1964 vs 1970, according to Wikipedia) Also, http://en.wikipedia.org/wiki/Real_Programmers_Don't_Use_Pascal http://en.wikipedia.org/wiki/Real_Programmers_Don't_Use_Pasc... (with links to the essay; look at the email address. That alone shows that we are talking of a real programmer) says it's from 1983.
bitwize 13y ago
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.
plinth666 13y ago
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.

joezydeco 13y ago

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!

ChuckMcM 13y ago

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.

alexk7 13y ago
The original joke is "The determined Real Programmer can write FORTRAN programs in any language." It's from an essay written by Ed Post titled "Real Programmers Don't Use Pascal". It's before BASIC :)
- Someone 13y ago
  Nitpick: it can't be from "before BASIC" if it mentions Pascal. BASIC is older than Pascal (1964 vs 1970, according to Wikipedia) Also, http://en.wikipedia.org/wiki/Real_Programmers_Don't_Use_Pascal http://en.wikipedia.org/wiki/Real_Programmers_Don't_Use_Pasc... (with links to the essay; look at the email address. That alone shows that we are talking of a real programmer) says it's from 1983.

bitwize 13y ago

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.

plinth666 13y ago

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.