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?
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.
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 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.