20

How were the 70's and 80's coin-op programmed? What tools did a programmer use? Nowadays a programmer can use a PC, an IDE to program, test, use breakpoint... but in the 80s? How could a programmer test the graphics, the algorithms and so on?

  • 3
    Do you mean arcade games, such as Space Invaders, Asteroids, Pac Man, etc.? – Fred Larson Feb 28 at 17:20
  • 2
    Yes, I do exactly this. – bassaidai0 Feb 28 at 17:26
  • 10
    In reality, not so different from the way mainframe software was written and debugged in the 1970s. The most efficient way to find bugs was to read the source code. Since you probably wrote the source code with a pencil on paper, you had more thinking time than typing the first idea that came into your head into an IDE. If the program crashed, you got a printed memory dump - several hundred pages of hexadecimal numbers. You learned how to find the information you needed from that, and nothing else. With two or three test runs per 24 hours, there was time to think, not experiment! – alephzero Feb 28 at 19:27
  • 7
    +1 for the idea that we reviewed our own code. Personally, after I felt like the code was all done and tested, then I'd take it home on green-stripe lineprinter paper, spread it out on the floor after dinner, and thoroughly read it. Inevitably there were improvements that could be made. – another-dave Feb 28 at 19:30
  • 4
    I want to make an embittered comment about emacs and 80-column source code limits. But I suspect it wouldn't contribute much. – Tommy Feb 28 at 22:09
12

Of course, there were hundreds of different standup arcade games, utilizing different hardware, and different developers creating software for them using different tools. So, there's no "one-size-fits-all" answer to your question. Rather, there were some general-purpose low-level ways of doing development back then that were fairly universal.

First, early arcade games were programmed using machine language. The only "offline" tool that might have been used to free the developer from encoding opcodes by hand would be a simple assembler. It was not unusual for early processor vendors to provide a cross-assembler for their processor, and that could run on common mini or micro computers of the time. Therefore, editing of the initial assembler source, and automatic conversion to machine code, could be done on a more advanced computer than the processor used in the arcade game.

Second, the developer needed to be able to test their code. In some cases, they may have done that in a simulator while they were still working to finalize the custom hardware that would go into the arcade game. More likely, they tested their code on a prototype of the arcade game hardware. This meant that hardware and software were being developed and debugged simultaneously, which is hard. Thus, it was common practice for arcade game vendors to settle on a specific hardware platform, and then use that same hardware for as many arcade games as possible. This was common practice at least as far back as Pac-Man in 1980.

Getting the machine code onto the hardware for testing could be a minor challenge. In some cases, EPROM's might need to be burned and plugged into the arcade board. More likely, the prototype development hardware would include a mechanism to download the target code using something simple like an RS-232 port or JTAG connected to a development computer. It's not that different, at least in concept, to how embedded software development is still done today.

In most cases, besides having extra development aids like RS-232 ports, prototype hardware could also include special software on ROM to provide a monitor program. This would allow the developer to do things like insert breakpoints in the code and examine memory in order to track down bugs. If the prototype was more advanced, then an In-circuit emulator (ICE) may be available to simplify the debugging process by relying on additional hardware besides just the target CPU abilities. But even simple 8-bit CPUs of the time, like the MOS 6502, supported break point (BRK) instructions that could invoke a resident monitor program.

All in all, the process was not very different than the bootstrapping of any software onto any new hardware that was done for other computers of the time. And, to a pretty large extent, the same techniques are still employed today. It's just that off-the-shelf components are much more available and advanced now than in the early days. This frees modern developers from having to reinvent the wheel on such low-level tooling for compiling, assembling, downloading code, testing, and debugging.

| improve this answer | |
  • 1
    "It was not unusual for early processor vendors to provide a cross-assembler for their processor, and that could run on common mini or micro computers of the time." Same as nowadays, except that it's now a cross-compiler instead or as well. – TonyM Feb 29 at 8:58
  • 2
    Admittedly I was not working on video game development back in the first half of the 1980s but on other embedded applications. There was no JTAG programmability for the hardware, FLASH did not exist. Programs were stored in UV-EPROM or we used special hardware with RAM in place of the EPROM to allow loading a built image for testing or we used an ICE plugged in place of the processor. This could be halted and variables examined much like the JTAG debuggers used today. – uɐɪ Mar 2 at 13:45
16

The assembly (or, more rarely, compilation) was generally done on a minicomputer, such as a VAX 11. The tools were often written in-house. They might have some sort of simulation software to help test some of the code, but in the end you'd use a PROM burner to burn your code on to EPROMs (EEPROMs were not widely available in the '80s) and plug them into a development board to see how well they worked.

Jed Margolin, a hardware engineer for Atari in the '80s, did a lot of work on several of the classic arcade games from that period. A while back he published his email archive from that period. Reading it will probably give you, as it did me, a lot of insight into the coin-op development process.

| improve this answer | |
  • 3
    That email archive is really interesting! And very nostalgic for me to see VMS MAIL -style headers. – LAK Feb 28 at 18:00
  • 4
    Not to mention the specific intro page at jmargolin.com/vmail/vmail.htm — "When I arrived in 1979, software for the games was cross-assembled on two DEC PDP-11/20 ... We had two computer operators who would take your marked-up listing, do the edits, and run the program. If it actually ran ... it would produce a listing and a paper tape. ... You then took the Paper Tape to your emulator ... Programmers could load the program from paper tape, run it, set breakpoints, and examine memory as well as write to it. It was all done in Hex code ..." – Tommy Feb 28 at 23:20
5

How were the 70's and 80's coin-op programmed?

Not much different from today. But most definitely in a more hands on manner.

Of course, all of this depended quite a lot on the company (size), target platform and most of all the time you're asking. Development changed extrem over just a few years from the mid 1970s to the mid 1980s. Where the very first developers had to use had coding and/or mini/mainframe computer for crossdevelopment and guesswork for debugging, developed the tool landscape fast into quite sophisticated hard and software tools during the 80s.

What tools did a programmer use? Nowadays a programmer can use a PC, an IDE to program, test, use breakpoint...

Much the same back then.

Around 1975 to the mid 1980 a dedicated development system would be used like a PC today. These development systems were specialized modular systems like Intel's Intellec MDS (running the ISIS development environment) or Motorola's Exorciser. These systems provided integrated development. Maybe not as point and click as today, but incredible cool for back then.

Test didn't happen on virtual hardware, as hardware simply wasn't fast enough to do so, but using the the 'real thing' and hardware debugging tools. An arcade board would be hooked up as a slave system using an In Circuit Emulator (ICE). The development could stop at any condition within the (hardware) emulated CPU as well as external conditions. This was complimented by ROM-simulation hardware.

but in the 80s?

Now, that's a big jump. In general the 80s continued this, but now standard PC type machines replaced CPU vendor specific machines, with the added help of specialized developer versions of arcade boards. The same happened BTW for console development, except here the development hardware was made available to external developers as well.

How could a programmer test the graphics, the algorithms and so on?

Usually by loading ROM emulation units, plugged into the arcade board, from the development system and running the board as before. Tests happened in real time on the real hardware - with the ability to insert hardware breakpoints from the development system, or changing ROM content on the fly.


Hardware based development was used way into the 2000s until either standard hardware became fast enough for real time emulation or, more important, console systems (like X-Box or PS4) became more like PCs ths enabling the same development cycle as for PC-Software.

| improve this answer | |
  • Given how much emphasis is put on the Exorciser using a "TTY" (as distingushed from a CRT terminal) interface, I'm having difficulty believing that the interface was anywhere near even the CP/M version of Turbo Pascal 1.0, much less a an IDE. – cjs Feb 28 at 18:44
  • @cjs And so it is hard from today's PoV to see Turbo pascal as integrated. After all there have been a few years of development inbetween, right? Compared to using a mini for assembling and doing everything else by hand, it's for sure high integration when tools are combined into one device with a consistent command line interface. In retrospect its not helpful to ask what a tool(set) can not do, but what it did offer in comparison at its time. Also, noone was stopped to use any (way more expensive) CRT terminal. Exorciser systems were as well offered with CRT support. – Raffzahn Feb 28 at 18:52
  • Well, I do see Turbo Pascal as an "integrated development environment." Would you like to re-examine my comment given that? And do you have any thoughts on why Atari in the mid-80s continued to use multi-hundred-thousand-dollar VAXen as their primary coin-op development systems when the systems you discuss were available at one tenth the price? – cjs Feb 28 at 19:18
  • @cjs Not sure what you want to have 'reexamined'. Did TP include hardware debuggers? Did it integrate cross compilation? Did it integrate handling of ROM emulation? For the Atari part, why should a company throw away a working system? That would be rather stupid, after crafting the tools they way they want it. In addition Further, Atari is not the only company that developed coin op - not even in the US. – Raffzahn Feb 28 at 19:19
  • 1
    Here is a quote from Owen Rubin, developer of Cannonball, a 1976 Atari arcade game. "I wrote my first (non-vector) game, Cannon Ball, while sitting in my small office at a Model 33 teletype connected to a Motorola MicBug 6800 processor, both of which were connected to simple videogame hardware. I hand-assembled the entire program--it was only 2K, but still took several months--including self-test, saving the code on punched paper tape." Atari only used 6800 for a short time in the mid-70s, before adopting the 6502. – Memblers Mar 1 at 14:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.