I'm not super familiar with arcade hardware, but it's always fascinated me how the Z80 and the 6502 dominated the market for reasonably-priced CPUs for about a decade. You'd just use one for everything. The 68k would eventually come into the picture, but even into the 1990s you still had a major console like the Super Nintendo using a 65816, which is essentially a 6502 with 16-bit extensions.
Games were getting really big in the 80s, but it took a long time for hardware R&D to kick into gear.
Main reasons for SNES was its last minute scrapped backwards compat had it pick that chip. They made up for it having a great audio chip and PPU and a bus that you could just bring your own CPU (like sa-1 which is basically a snes 1.5 cpu)
> but it's always fascinated me how the Z80 and the 6502 dominated the market for reasonably-priced CPUs for about a decade.
Only a decade? I would argue they had at least 15 years of dominance and were being used en masse for ~20 (the Genesis, SMS, NES, Gameboy, etc were using them well into the 90s, as you mentioned).
True… the Atari 2600 was released in Sept 1977 and used a 6502 variant. The 6502 was released in late 1975 by MOS Technology, but I don’t think any sold until 1976.
One of the reasons for this was the fact that there were so many home computers being made with them too .. so you could go to work and hack on the Z80 eval board/PCBA, then come home and brush up some code on telly, bring it back on tape and so on .. I made a lot of progress as a programmer in the 80's by building my own suite of home computers with the same CPU's as we were using in embedded projects at work ..
Can't really do that much these days, although a similar vibe can be had if you work in embedded linux and use ARM .. pretty nice to take code from an rPi home machine and run it on the industrial systems as well ..
It's weird for projects like this, that you become constrained by the modern hardware being "too good". The display, a fairly generic 320x240 LCD driven by the ILI9341 controller, is 16 or 18 bits per pixel. That gives 65,536/262,144 colors, and I guess Galaga would be fine with what, 16? 64?
The display is interfaced over serial SPI at maximum clock of 40 MHz, which means sending one screeenful of pixels takes (320x240x16)/40e6 = 0.03072 seconnds. That is where the 30 Hz update rate comes from.
I had to check the datasheet [1] but of course the display controller does not support any fewer colors, so you can't speed it up by scaling down. Too bad. :(
The display also supports partial updates, so you can just upload a few sub rectangles of what has changed onscreen. AKA "dirty rectangles".
You can get over 60fps depending on how much is changing, and since these games are on a static background, that's not much.
It's a pity that the Raspberry Pi Pico and the DVI sock together cost more than a Raspberry Pi Zero. Doesn't make a lot of sense to port Galaga to it other than to embrace the challenge.
Galaga is one of the most iconic arcade machines of all times. It has been remade and emulated many times. So far the cheapest and smallest system able to do a faithful emulation of the original arcade machine was the raspberry pi. But even the much cheaper ESP32 should be able to easily emulate a machine from the early 80's, shouldn't it?
The ESP32 is very roughly equivalent to a Pentium 90, right? So I would expect early 80s arcade emulation to be marginal to good. You could get DOS and Windows packages of emulated arcade games in the early-mid 90s.
The top level comment by msephton is taken directly from the first paragraph found in the link without attribution. Of course the text in the linked project goes on to explain further.
I'm not super familiar with arcade hardware, but it's always fascinated me how the Z80 and the 6502 dominated the market for reasonably-priced CPUs for about a decade. You'd just use one for everything. The 68k would eventually come into the picture, but even into the 1990s you still had a major console like the Super Nintendo using a 65816, which is essentially a 6502 with 16-bit extensions.
Games were getting really big in the 80s, but it took a long time for hardware R&D to kick into gear.