Retrocomputing Stack Exchange is a question and answer site for vintage-computer hobbyists interested in restoring, preserving, and using the classic computer and gaming systems of yesteryear. It only takes a minute to sign up.
Sign up to join this community
How were the 70s and 80s coin-op machines programmed? What tools did a programmer use?
Nowadays, a programmer can use a PC with an IDE to program, test, place breakpoints. But in the 80s, how could a programmer test the graphics, the algorithms and so on?
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, EPROMs 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 or JTAG port 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.
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.
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 extremely over just a few years from the mid 1970s to the mid 1980s. Where the very first developers had to use hand coding and/or mini/mainframe computers for cross-development and guesswork for debugging, the tool landscape developed fast into quite sophisticated hardware 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-1980s 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 incredibly cool for back then.
Testing didn't happen on virtual hardware, as hardware simply wasn't fast enough to do so, but using 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 complemented 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 importantly, console systems (like X-Box or PS4) became more like PCs thus enabling the same development cycle as for PC-Software.
Here is an alternative answer to the same question, focusing less on the tools than the actual coding process.
You have to remember that the machines in question had seriously limited processing power, and even simple games like Space Invaders often required some rather clever programming to get the to work in the number of cycles available.
The best example of how difficult this was is in this video of the way Tempest worked. Because it was a vector system, the time needed to draw a line on the screen depended on how far the beam had to move. To reduce the time, the figures were designed to be compact and consist as much as possible of a series of lines end-to-end. This is why one of the characters is a spiral, it's a bunch of straight lines connected together. The hardware included a simple system for changing the scale.
The game was then written as a series of instructions stored in the video memory. This included commands to move the beam, draw a vector, and change the color or scale. Additionally, it included instructions for jumping to other locations in the list, and doing call/return, which allowed the vectors to be broken up into "subroutines".
The video ROM consisted of a series of hand-draw shapes, manually converted into a series of vectors, and then broken up by examining the resulting list for any redundancies, or even adding some if the resulting shape didn't change too much from the original design, and then placing those parts in subroutines.
The game engine running on the 6502 CPU included a small engine which copied these shapes into video RAM as required, and then looped over them while also handling collision testing and scorekeeping and similar tasks. However, the actual drawing was handled by custom hardware that looped over the "display list" independent of the CPU, going back to the start when it saw the HALT instruction. So the programmers were writing two programs, the game engine and the vector engine's custom code. All of this was in assembler, on another machine (a PDP-11 IIRC).
Curiously, and often forgotten in modern documents, the Apple II used a similar system consisting of a series of bit-fiddled bytes that described individual one-pixel vectors to the same end. The original ROMs did not include any form of bitmap manipulation, in spite of being a bitmap machine. The speaks to the sort of memory limitations people faced at the time, as the vectors were packed three-to-a-byte, a significant savings.
