I understand that early arcade machines, at the beginning, were totally solid state boards, containing all of the game logic. Later they moved to a more modular setup, where you could plug in additional boards containing specific game logic onto a universal base, and this was the same technology used for home console ROMs.
Still, these needed to be pressed. While I understand that programming wasn’t the easiest back in the day, on-the-fly programming with punch cards and hardware switches existed. It seems a bit daft given that those things existed that you’d have to factory press a solid state board just to test anything. So I assume (perhaps incorrectly) that, even if it wasn’t good enough for shipment, something else had to have been done.
It almost certainly wasn’t hardware emulation, since that’s difficult even nowadays. Were there ways to spoof the ROM component? Like, have some connect the pins to a device that’s really mapped to some volatile memory like RAM on a different machine that pretends to be a ROM?
I know that ROMs can be burned, but I thought (could be wrong) that until recently that was a one-way process. Erasable ROM wasn’t that common or easy until recently, though I suppose if it existed as all it could be distributed with development kits.
I’m finding a lot of info on how ROMs work in a physical sense, and their history, but not a lot of info of how exactly the development design/QA setup worked. Certainly it’s not like the rapid-fire way it is now where a developer can pull from the source control repository, type “make” and then run the game on a dev kit if they need to, but I doubt (again, perhaps wrongly) that it was as difficult as sending something to a factory press and waiting for the order to come in.
When these games came out, they were all Masked ROM’s.
They did this for cost reasons, since masked ROMs were very cheap in quantity.
During development, there were ROM emulators that could be downloaded with the code, and then used in place of the masked ROM. Also, for short runs, there were UV-eraseable EPROMs. These could also be used to do late development, and testing of the code.
FWIW, I used to work at the world’s largest supplier of game ROMs, and I made many a mask for Intellivision…
UV-erasable EPROMS have been around since the 1970’s. You’d program it with a special programming board, and it would then act like a ROM as far as the game system is concerned. To erase it you’d then put it under ultraviolet lights for a hour or so to clear out the old program and make it possible to program again.
Back in the day, there were three types of ROMs that we used to use. You’d have UV erasable ROMs, which were expensive, but you could easily erase and re-use them. We also had OTP (One Time Programmable) ROMs, which were cheaper than UV EPROMs, but as their name implied, once you programmed them, that was it. You couldn’t erase and re-use them. For relatively small production runs, you’d develop your code on a UV EPROM (or maybe a VERY EXPENSIVE emulator) and then you’d ship the production units with OTP ROMs.
If you were doing a larger production run, you’d use masked ROMs. Masked ROMs cost a lot to set up, but were very cheap to produce. If you only made a hundred of them or so, then they’d cost a lot more than UV ROMs or OTP Roms. But if you were making thousands of them, they were by far the cheapest option.
ROM emulators were very expensive. I used a couple of them over the years. They sped up development time quite a bit but they were sometimes a bit finicky. Most of the time I would use UV PROMs. I would have a bunch of them in the “cooker” (a small UV eraser) and would rotate them out as I developed code. Programming them was slow and erasing them was slower.
Development tools in those days was an assembler. That’s it.
UV erase Eprom may not have been available for Nuttle to develop 8080 powered pinball machines. He may have saved the file using the serial port, perhaps to and from tape…
Later on they may have had floppy drives, as Altair had CPM on floppy drive
None of the previous suggests how Midway(Nuttle) Taito / Nishikado (“Space Invaders”) did it…
Nishikado was a university electrical engineering graduate who made video games using discrete logic… state machines…
The Nuttle brothers each have a first.
One Nuttle did the SOLD the first video game.
The other (contractor for Midway)
1.Advanced pinball machines by using the 8080 cpu … before UV erase eproms…
2. copied Nishikado’s discrete logic “Gun Fighter” game but used an 8080 CPU to do it.
Nishikado then goes on make his own 8080 games, soon making Space Invaders.
Well he took a year to develop the hardware and software for space invaders on his own, including writing development tools… Space Invaders was high res and strained the 8080 cpu. His other 8080 games were just simple pong games, more like ascii art.
Early arcade games were programmed using ladder logic.
I think the OP means early arcade video games.
Ladder logic is way cool, though. It’s how we programmed logic back in the 30’s for things like automatic elevators. (Some of us are old enough to remember riding in elevators that required an operator.) It’s how electromechanical pinball games worked.
The real nifty thing about it is that all you really need to understand is parallel versus serial circuits, to devise remarkably complex logic, all of which could be implemented using hard-wired relays (you need to know a bit more in order to wire the relays.) It’s the kind of thing any clever hobbyist could master, much more quickly than learning a programming language, especially for people who like hands-on and think visually.
Cartridges could also have co-processors on them. I seem to recall a game (Starfox maybe?) being advertised as containing an extra graphics co-processor. A coprocessor could help the game run faster by calculating some things on the cartridge itself without needing to involve the console CPU. Then, when the console is ready to refresh the screen, the data is already available.
In the late 70’s, I worked on a project using a “nanocontroller” (that’s what the manufacturer called it) which was intended for signal processing but which we used as a network interface. It was a very rudimentary processor, but ran at the blinding speed of FOUR MEGAHERTZ! One full instruction every cycle! It required what were unusually fast PROMs for the time, and for development we used this OTP type. They started out all 1’s and you could program a 1 to a 0 at any time (using the PROM programmer device) but not vice versa.
We also had one (very expensive) emulator that used RAM, which we could load from paper tape (same way we loaded the programmer). So, we could make changes on the fly at low cost on the emulator, but we’d often need to test with the same code running on both ends of the network. Burning a new set of ROMs cost hundreds of dollars; they weren’t cheap. So, we got good at patching by turning 1’s to 0’s. Fortunately, the jump instruction was all zeros, so you could turn any instruction into a jump, and you could usually find an instruction with enough other 1’s in it to turn it into the address of an unused location. (There were lots of holes, thanks to a paged memory architecture.)
Ugh. Be very glad we rarely need to do stuff like this any more!
