Possibility of building a retro arcade machine WITHOUT a Raspberry Pi

[Strider]

Late to the party. ?

The short of it is, I would echo what others have said and use something like MiSTer if I wanted to avoid a Pi or emulation in general. Going FPGA would be your only  feasible modern option, for the reasons listed by others. Original hardware is hard to find and expensive, and most arcade machines were all different. Using an FPGA solution solves both problems and gets you as close to original metal as possible, with no software emulation.

[Purple Lady]

Various comments here.

Some do use the RPi for modern retro-like arcade consoles. I love watching Lyon's Arcade's videos on YouTube, and on one machine, the system board was damaged and had problems with most of the sound. Likely, the 100-pin SMD chip was the problem. Ron fixed a few things on the board, but most of the problems was likely the 100-pin chip. I read how someone managed to import one of those chips from China (they lucked out that it wasn't fake or a dud). It took them some work, but they fixed theirs. It wasn't for the same game, but I am fairly certain that could have fixed the machine. But Ron ended up getting a board that required a RPI-4B, and that fixed the machine and as a side-effect, turned it into a multi-game.

Another option is to use a Parallax Propeller. Yes, I know that the X16 will never use that. The speed and the timing issues would be a problem, plus there are cheap FPGAs that can do more. However, all that said, the P2 is actually a good solution and one can implement an entire computer/console/arcade on that. The P2 is rated for maybe 280 Mhz, but most who use that chip clock it at 300 Mhz and faster. Now, while the P2 is much faster than a P1, it does have its limitations. Like the P1, its best feature and largest bottleneck is its concurrent hub RAM. The P2 has 1 MB of hub RAM to work with, and unlike in the P1, the hub RAM operates at the same clock rate as the cores. The P2 uses more of an eggbeater access to memory as opposed to accessing it like a revolver. So other cogs can freely use hub RAM that is in a different bank without contention. Yet, the hub memory access is still highly variable. A strategy in using that is to base your clock rate on the worst case scenario and add code to govern things when it goes faster than intended. I might build a retro-like computer around the P2. It is a good controller to use to emulate a 6502 (and likely the 65C02, and the '816, though that hasn't been proven yet). For me, I'd like to use it to design my own ISA that is closer to what I wish would have been available back in the day.

Unlike in the P1, the P2 has no inherent video features. It has no character set. That isn't to say you cannot produce video with it, just that you'd have to do more work. If you want a character set, you'd have to add that in the ROM, and you don't even have to put that in the hub. The P2 has 2K of LUT memory in every cog as well (in addition to the 2K of registers, or 512 doubleword registers), and that can be shared with 1 other cog.

On sourcing a 6510, that really isn't an issue. I mean, the 6510 just uses the first 2 bytes of memory to control the port lines. You can use external circuitry to read (or just snoop) those 2 addresses and emulate the port that way. A RAM snooper is go in that you don't have to deal with bus contention. It just monitors when those addresses are changed. So if you are only writing from the port, then passive bus-snooping is good enough.



And really, folks have added features to the 65C02 by using a wrap-around coprocessor that intercepts the NOPs to add features. And while it would be simpler and more efficient to use a 6502 FPGA core and mod it, folks have been known to implement this using ROMs and PALs. If you add new CPU modes externally to the CPU, then you'd need to monitor everything the CPU is doing to form the context of what to do. Extending the CPU itself means you already know these things and you don't have to shadow the CPU's activities to know what to do. And intercepting the CPU this way also means that for instructions you cannot do externally, that you replace the NOPs you use with means to affect the CPU in the way you want. I mean, if you want to read from a 3rd index register (a latch on your board) and put that in the accumulator, then you'd intercept the instruction stream and change the instruction to an immediate to emulate the CPU reading your extra register. Your board reads the register, puts it on the bus, and tells the CPU to treat that as an immediate load into the accumulator.

For a project like the X16 or the Foenix, I'd like to see someone use an FPGA modification of the '816 and directly bring out 8 new dedicated memory lines. And not just that, but have it boot in native mode, not 6502 emulation mode. That would simplify projects such as the Foenix by not requiring latches on the board and would simplify the ROM when you only want to run '816 software. Being able to support both modes actually complicates things since you'd have to have your ROM in the first 64K and if you run both 6502 and '816 software, you may require 2 sets of interrupt handlers and running those that match the current mode. That, of course, makes the ROM larger and requires more code to test things.

On video chips, there are very few of the legacy video chips available. You might find the old ones from TI, but not the others. An Apple I clone uses the Propeller 1 chip to replace the video chip that isn't available anymore, and yeah, for a simple terminal mode display, the P1 is good enough.

On replicating rare chips in FPGA, it is possible, and you may not need 100% compatibility, but one thing that helps is decapping old chips if you have access to some (preferably dead ones) that you'd be willing to sacrifice. Then you can look at the transistors and see how things are wired, and if you are willing to pay big bucks, you can even have schematics made.

Another relevant topic to arcade design is what to do if you need a monitor type that doesn't exist. For instance, the original Asteroids used a vector monitor. Sure, the easiest solution would be to design your own Asteroids board to work with a raster monitor (or LCD). But I've been playing with an idea. If you had an FPGA, you could find a way to convert vector data to pixel locations and use a custom frame buffer. Then you gradually decay what is stored in your framebuffer. So the framebuffer emulates the long phosphor times of vector monitors and allows other monitor types to emulate a vector screen.

Restoring existing arcade cabinets is interesting. No, you won't find all the parts you need, but you can use substitutions for most semiconductors, and when you need rare chips with common functions, you can made header boards using discrete components. For instance, if you need a chip with 6 Darlington transistors that isn't made anymore, you can build a board with 6 Darlington transistors or 12 regular transistors of the same polarity (such as NPN). On things like the "Big Blue" capacitor, there are modern ones (that are black), and if you cannot find the exact value, that doesn't matter since using larger values will work for power filtering applications (and may actually make things more stable, and that is more true of pinball machines). On HV diodes for rebuilding old monitors, if you can't find those you need, you can improvise. If you need the inline diodes that go in the 2nd anode lead, you can get one of similar specs, clip the leads some, and bend what is rest to fit the "cartridge" form factor that some of those used. Even rebuilding existing boards is an option, and even when they are in really poor shape. One common problem was edge connectors, and yet, with some copper foil tape and some solder, you can replace the missing traces. And that reminds me of another thing. When rebuilding arcade and pinball PCBs, it is helpful to make some mods. For instance, some had redundant grounds and power wires, and you would do good to jumper and merge those to make the power more reliable. And really, if you deal with bad connectors, replace those, don't bodge around them, as you'd be making more work for the next person to service it. A good amount of time restoring these old machines is undoing other people's repairs and making things closer to factory condition.

[neutrino]

One way to replicate unobtainium chips is to wire it to an FPGA (or CPLD). Then write code to snoop on signals to it using the FPGA, in essence as a bus analyzer. While also using the same FPGA to write a model for the chip which is compared in real time to the real thing.

Arcade monitors can likely be accomplished by modifying a CRT. Ie controlling the deflection coils. They seem to be electrically like a speaker. Though the horizontal and vertical deflection coils have different impedance. And of course there's the high voltage to zap you for any mistakes.

Another way to image chips without decaping them is to use a radioactive source and a photographic film. (old radio tubes can be used for this)

 

 

[martinot]

Tend to agree with most answers in this thread; basically the best and two most powerful/flexible options:

* MiSTer FPGA based solution with DE-10 Nano
* Intel x86 PC based solution with emulation software