What’s the killer app for FPGAs? For some people, the allure is the ultra-high data throughput for parallelizable tasks, which can enable some pretty gnarly projects. But what if you’re just starting out? How about 1980s style video games?
The MiSTer FPGA project created a bit of FPGA hardware that makes it easy to build essentially any old school video game or computer platform. That’s a massive clean slate. Of course, you can simply download someone else’s Atari ST or Commodore 64 setup and load it up, but if you want to learn FPGAs while recreating old-school video game machines, you’re going to want to get your hands dirty.
[Mister Retro Wolf] started up a video series last winter (trailer embedded below) where he’s embarked on a project to recreate a classic video game machine from the ground up using the MiSTer FPGA platform. In particular, he’s going to recreate the Namco Tank Battalion arcade game, from the schematics, in Verilog.
This is literally building a 6502-based video game machine from scratch (in gateware), so if you’re interested in retrocomputing or FPGAs, you’ll have something to learn here. He’s gotten through the CPU, screen, tilemap graphics, and memory so far, but it’s not done yet. To follow along, get yourself some hardware and you can probably catch up.
We’ve covered the MiSTer FPGA project before, of course, because we think it’s cool. And if a video game arcade machine is going to be your gateway drug into the seedy world of programmable gates, then so be it.
My Problem with FPGAs there are very few reason to use them for private project, especially in these days when it is easy to use fast MCUs like RP2040. Of course, I know that there a things you can only do with an FPGA, but this only happens in industrial use.
Industrial use like retrocomputer and arcade emulations?
This are the “very few reason” :-) And even than, did you not think it is easier to do an emulation of old hardware now with an RP2040 or another fast beast?
Do you want an emulation or do you want to learn to use FPGAs using old video game machines as a finger exercise? (I think I know your answer. You do not have a problem that wants an FPGA as a solution. I don’t use nail guns for carpentry either.)
This said, I went looking for some RP2040 emulations, and found a few! This one is amazing:
https://github.com/Jean-MarcHarvengt/MCUME
All it needs is hardware. Oh wait…
https://hackaday.io/project/184965-picomputer-zx-pocket-zx-spectrum
Synthesis can be a lot more accurate then emulation. I lot of the MAME game emulation uses sound samples as they don’t emulate sound.
MiSTer FPGA also synthesise Retro computers and sound samples can’t for there.
Olaf, there are literally HUNDREDS if not thousands of hobbyist projects online that use FPGAs, and would likely be nearly impossible to build using a general purpose MCU at a similar price point. For example, I’m a Ham radio operator and I built a Software Defined Radio with a $6 FPGA as its heart. My $55 BOM cost receiver performs as well as every commercially available HAM receiver that I have ever owned. While virtually all amateur-level SDRs are built using a microcontroller as the heart, the amount of processing you can do in a very small FPGA is really quite incredible. I have a friend who built a drone controller using a Xilinx Spartan 7 FPGA and a dozen or so additional components. He was able to put a CPU and all of his control logic into the FPGA, with gates to spare. The IceStorm open source development toolchain for Makers using the ICE40 FPGA has existed for quite a few years. Lattice does not officially support IceStorm, but a number of their field applications engineers have suggested that it can be used as a very simple way to get started using FPGAs.
Check out the many Hackaday blog entries on FPGA-based projects, for a better understanding of what FPGAs are actually capable of. I agree the RP2040 is a great little chip, however, a $0.95 CPU can’t even begin to compete with the smallest FPGA in real-timer parallel performance. Check out some of these websites to learn how powerful FPGAs really are for hobby projects. https://www.nutsvolts.com/magazine/article/July2015_Clarke https://www.hackster.io/news/the-coming-of-the-age-of-the-maker-fpga-board-52a29572549e
Hopefully, seeing a few of FPGA projects on the web will change your mind about how useful, and cost-effective an FPGA can be in a hobby project.
Cheers,
Darnell
W6GAD
Darnell,
I worked as an embedded software engineer and digital design engineer. But I don’t have any proper knowledge about RF and SDRs. I worked for SDR project once and got interested in. Could you provide me the resources you find usefull so that I can learn and design one by myself?
Thanks in advance,
Ahmet Kaan
Buy this book! It is the ONLY complete, readable, and easily reproducible Software Defined Transceiver that I have ever read.
https://www.amazon.com/Software-Defined-Radio-Transceiver-Construction/dp/B09WYP1ST8/ref=asc_df_B09WYP1ST8/?tag=hyprod-20&linkCode=df0&hvadid=564687481800&hvpos=&hvnetw=g&hvrand=11865875759768125387&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9031543&hvtargid=pla-1653048851461&psc=1
Darnell,
I was really busy so I forgot to reply. Thank you so much! I saved it and I am going to start reading it as soon as possible.
Best Wishes!
@Darnell Gadberry: Very interesting – thank you. Is there any documentation of your SDR publicly available? What are you exactly doing on the FPGA? What’s your receiver architecture? 73 IN3EDA
+1
I too would like to know more about your project!
If you want to mix different CPU cores, chances are it’s easier to use an FPGA.
Z80 and 6502, for example.
X86 clone plus ARM clone ? Tricky, but possible. Would make for an interesting Android device, able to also run x86 code when needed.
I would think that implementing a Pentium or better class CPU in a FPGA would need a rather expensive one, out of the reach of the average hobbyist. A 486 on the other hand is simple enough for cheap FPGAs.
In other words, if you want to run something modern either check on Risc-V or at least some ARMv7 core.
I want low latency control not harmed by interrupts and all the other MCU shortcomings in my private projects too. And there are cheap FPGAs these days that are quite suitable for such projects, in particular Lattice ECP5 and iCE40 lines. I cannot think of any good reason to prefer an MCU over an FPGA in a personal project, after all, I do not care about mass manufacturing and shedding every tiny cent off a BoM at a cost of quality. FPGAs are easier to program than MCUs, easier to reason about, marginally harder to solder…
“Of course, I know that there a things you can only do with an FPGA, but this only happens in industrial use.”
This is a really silly statement. Very few reasons to use them for “private project”? What project? That’s the question.
RP2040s are neat. They have absolute garbage data throughput to a computer. FPGAs are one of the very few devices out there that can actually completely saturate the data input to a computer and bring modern processors to their knees. You’re talking about a $50 device that can generate and transfer gigabytes/sec (not bits) without breaking a sweat.
“Fast” is relative. FPGAs can resolve and control things to small fractions of a nanosecond with very little effort.
There are *lots* of projects that you can only do with an FPGA for “private project” use. You just don’t happen to have any of those private projects.
For industrial use you’re more likely to use a FPGA just for development and then move to an ASIC.
I don’t think that is all that true anymore – FPGA for anything other than huge production runs will work out so much cheaper, as a small FPGA isn’t expensive and is so mass produced because its so versatile that availability is (usually) high.
ASIC probably only make sense when you need a giant FPGA as those are both power hogs compared to how the ASIC they pretend to be should end up, and rather expensive enough its worth spinning up an ASIC.
It’s not even that – the hard cores inside FPGAs aren’t something you can directly translate to an ASIC. It used to be you could just design something in HDL, verify the logic in an FPGA, then build the ASIC. That’s decades ago at this point.
FPGAs show up all over the place now whenever you need to move data in large volumes. Frame grabbers, networking, etc.
Industrial use only? You really don’t understand FPGAs or their application.
I’m going to showcase my ignorance: if you are going to emulate an old system, why would you prefer using a FPGA hardware “re-implementation” rather than software emulation on much cheaper hardware? Surely any cheap PI can emulate many old hardware. You might think “but software emulation is prone to software bugs”. But surely hardware emulation is prone to implementation bugs as well, and if anything, is more tedious to debug and “recompile”?
For instance I’ve seen people re-implementing Amiga on FPGA, still unsure how it’s easier to recreate the whole chipset on one FGPA then software emulate it. I can’t imagine it’s faster either? And there are some emulators that are focusing on cycle accurate emulation, so again, what more do FPGAs offer?
You can get very close to the original using software emulation, however it’s unlikely that a software emulation will be a perfect match for the original experience. A lot of old arcade games rely on specific implementation quirks and behaviors of the chipset that are not trivial, or in some cases even possible, to accurately reproduce in software running on a different architecture.
An FPGA can be programmed to behave much more similarly, if not identically, to the original chips. This is because you’re not trying to emulate the entire state of the system in code that your CPU that has tick through, trying to match all of the electronics of the old hardware.
https://www.howtogeek.com/783770/why-fpgas-are-amazing-for-retro-gaming-emulation/
“A lot of old arcade games rely on specific implementation quirks and behaviors of the chipset that are not trivial, or in some cases even possible, to accurately reproduce in software running on a different architecture.”
It’s not just a quirk or behavior issue. If you’ve got a system with 2 clock domains – say, for a CPU and an APU or video processing or something – unless those clock domains are synchronously related, trying to emulate that system accurately using a single clock domain (emulation) will be impossible. In most cases you can just kludge around it, since sub-cycle differences are generally going to be small.
With an FPGA all of that goes away because you just… operate in both domains. You can still have accuracy issues if the original designer was a dope, but then it becomes a question of “what does 100% mean.”
My take for 100% is when the user and the software can’t discern weither it’s running on the old iron or in a FPGA reimplementation or even an emulator.
As an example i would say that most C64 emulators, especially VICE, and FPGA reimplementations come pretty close. People worked on C64 emulations since the early nineties and i would think they got it right that even most demoscene coders can’t break it. And if they do i can see the VICE dev team pouring over the demo that broke their emulator and fix it. ;)
Well, software emulation is almost always taking shortcuts to achieve usable performance. It just isn’t feasible, even today, to fully simulate even the SNES circuitry without taking some liberties. This results in fine playable performance, but at the cost of accuracy. An FPGA implementation can sidestep these issues as you can (depending on chosen platforms) actually ‘create’ hardware to do the tasks, effectively creating a new hardware implementation of the chosen target platform. No simulation necessary, and perhaps not even pushing the FPGA to its limits. This results in more accurate reproductions of the targeted systems, and probably done more efficiently, both performance-wise and power consumption-wise.
Does that mean that if the original hardware can run all its instructions in 1 clock cycle, you will be able to configure the FPGA to “emulate” all those instructions in 1 clock cycle too?
And if these instructions set flags to certain values before/after instructions, with no overheads, then again, you can configure the FPGA to have this behaviour too?
Well, yes, that’s the thing – the FPGA doesn’t really “emulate” the HW, it implements it. (Well, in some sense the generic logic in the FPGA has to “emulate” the specific gates and logic needed to e.g. decode a CPU instruction, or generate some sound or pixels, but I wouldnt call it emulation really)
But yes, the key thing you’ll get with an FPGA implementation is massive, massive performance benefit compared to a SW emulation. And also, FPGA logic is inherently parallel, so your soundchip implementation is “executing” in full parallel with the graphics engine generating its pixels, and the CPU decoiding the current instruction. In an emulator, you’d need SW to emulate everything; first call some routine(s) to decode current instruction, then call into the sound emulation state machine to calculate a few audio samples, then call into the graphics engine emulation to process a bunch of pixels and output to the “screen” (a bitmap/window representing the emulator screen)
The problem is, of course, the massive amount of work needed to properly reverse engineer the original HW, implement an as-close-as-possible FPGA equivalent, and debug it all.
But it’s also massively fun. Of course, it’s also fun to implement and optimize a SW emulator.
In fact, it would be a really good start to get a good emulation going before you’d attempt an FPGA implementation; or reference an existing one.
> Well, yes, that’s the thing – the FPGA doesn’t really “emulate” the HW, it implements it.
Except for some specific cases. This is a lie. Unless you have accurate gate level data, you’re still emulating. Even for the classic gameboy, the gate level information that is known from decapping chips, isn’t 100% accurate.
And even if you have 100% gate level accuracy, there are analogue effects and gate timing effects discovered that affect the gameboy.
Now, that doesn’t make FPGA emulators invalid. They are valid valid solutions, and a good one. But IMHO, the advocates of them have a tendency to overstate their accuracy.
It’s not really an emulation. I would call it a ‘re-implementation’, where we ignore the original gate level design, and replace it with a more or less equivalent implementation on new hardware.
For instance, in this particular project, the 6502 core is an instruction level re-implementation of the NMOS core, but fully synchronous (including memory), using single clock edge.
“Except for some specific cases. This is a lie. Unless you have accurate gate level data, you’re still emulating.”
It’s not emulating. It’s implementing. You’re creating a version of the hardware which acts the same.
And yeah, you’re right, the accuracy bit’s overstated: “100%” is silly. Nintendo doesn’t even reach 100% accuracy in their own hardware implementations. For something like the GameBoy you’d need what, 20-30 different implementations if you really wanted to be nuts?
Important to note that modern FPGA can’t implement certain things like tri-state buffers or true analog logic at a gate level (not really). So while FPGA-based emulation does have the advantage of being able to be cycle accurate in real-time in 99.999% of all use-cases, there will still be exceptions. The analog FM synthesizer recreations for MiSTer FPGA for instance are recreations of the registers and behavior, and the output matches to a certain degree, but it will never be 1:1 because you cannot implement a perfect noise channel algorithm or a perfect sine wave on an FPGA. You can get measurably extremely close.
Similarly for the tri-state buffers, when you describe them in hardware description language, the synthesis tool will hook up the LUTs in a configuration that should make the inputs achieve the same outputs, but this is not gate-level recreation.
Also, pretty much every single core has the Quartus fitter options turned on that will restructure muxes, create additional buffer logic, etc… so it’s not a gate-level simulation to a T, it’s (ideally) a cycle-accurate, real-time, re-implementation of the digital logic. Nothing about that is impossible for software except for the real-time aspect, because a cycle accurate PS1 software emulator that is cycle accurate will not run in real-time on any PC today, as far as I understand the requirements.
You should do a bit of research and find out what an FPGA actually is, they are essentially a grid of blocks of different components, RAM, Flash, Look Up Tables (LUTs) that are connected together by interconnects that are defined by the design that is programmed into them. You could almost think of it as having a board of digital chips and to program it you connect wires between the individual chips.
Due to the nature of an FPGA and how it works you can do things in parallel, as in something happening on one part of the FPGA doesn’t effect the speed of something happening on another part, so they can both run at full speed at the same time, unlike with a CPU where it splits its time between doing different tasks. A common use for FPGAs is to create CPUs, usually RISC-V either for development or testing purposes. The best way to think about it is you aren’t writing code to run on an FPGA you are writing information about the hardware you want to create using the FPGAs resources.
Well, if Near hadn’t been bullied into suicide by Kiwi Farms we could have had a perfect software emulation of the SNES by now. Why that forum is still up and running is beyond me.
But transphobic people do what they apparently have to do and make trans peoples lives awful.
You might want to create your own VGA graphics chip for a retro computer, or create a USB device with 20 UARTs or I2C bus masters. You could do this sort of thing with software on a SBC and GPIO but the performance per watt would likely be lower, and you’d have to wait for your chip to “boot up”.
Thanks to everyone who answered to clarify this for me!
All optical FPGAs is where things are headed.
Can this platform emulate a TI-99/4A *and* the FPGA upgraded version of the TMS9918A Video Display Processor? https://dnotq.io/
Nice writeup on the SDRAM controller have used always SRAM myself, mostly a 32kx8 and a 16kx8 EPROM on a 8051 system. (The one who needs UV to be ereased :)
DRAM gets unfairly maligned because most of the stock implementations on an FPGA (from the vendor) are completely inappropriate for mocking up constant-access time emulation.
The really unfortunate issue is that in general most dev boards just have standard DDR, whereas LPDDR can entirely hide refresh cycles by using per-bank refresh and ping-ponging between the banks. I mean, it’s not like most applications like this actually *need* the full memory space.
Actually using DDR to its full potential on an FPGA requires you to *really* go far down in the weeds, where you find documentation that was obviously written primarily for internal use where you can go and just ask the guy.
Just received one of these over the weekend as a gift from a friend who is cleaning out their dad’s basement post-retirement. Was thinking that implementing a VGA adapter (as mentioned above) for the video port would be a good excuse to finally get some real expeirnece working with an FPGA platform.
Why FPGA for Hobby/Personal??? Same reason as (some) people climb mountains: Because it’s there, challenging and FUN!
My Hobby passion for most of my life had been Ham radio until I discovered FPGA hacking. I’ve been amusing myself with surplus Pano Logic devices for several years now and still have a big set of possible projects I haven’t even started.
Mister is amazing, but the boards and not cheap and they are currently out of stock everywhere.
Unbelievably there are still loads of Panos on Ebay. 147,443 K equivalent Logic Cells for < $30 with Dram, Ethernet, audio and dual monitor output!
See The Pano Logic Hacker's wiki for more info: https://github.com/tomverbeure/panologic-g2/wiki
Fifty quid all in for a 140k LE FPGA with a built in 22inch monitor is quite good :-) didn’t realise that was even an option until I clicked on your link.
Indeed I’d never even heard of Pano Logic till this post, though probably because they never seem to have really made it out of the USA, not so available and cheap here, and adding in shipping not worth it probably.
Still damn cool looking little things.
Well some did, but you have a point. I had been looking at this: https://www.ebay.com/itm/193893883297?hash=item2d24f9dda1:g:WDkAAOSwFG5ckMYM from Germany and I had the same issue with shipping.
Skip
I recently brought a De10-Nano for the reasons mentioned in the article, justifying it for playing retro games, but hoping to learn a spot of FPGA stuff along the way.
I’m case anyone interested, the main chip has dual arm hard cores, and there is software available to integrate the programmable logic straight into Linux applications running on the arm via opencl.
Hi – I’m Mister Retro Wolf, the author of the Youtube series. First I want to say a real heart-felt thanks for covering my work on Hackaday. I’ve followed lots of projects on this site, so to be featured myself gives me a lot of pride.
Second I’d like to expand on a few of the items in this comments section.
The first intent of the channel is to understand how these arcade games work, by reviewing the hardware schematics and then building them in Verilog on the DE10-Nano / MiSTer. One thing is that, at least for the first 10 or so episodes, I’m building the circuit on a breadboard too. I’m afraid I’m too dumb to go straight to the verilog and so needed to understand the hardware first. At the end of the day, it’s a hardware description language and you can’t describe something you don’t understand. I got to a point where the actual electronics became too difficult, using old memory chips. I would need to overhaul the entire power distribution to get it working. Anyway the great part is, knowing how much time you need to put in connecting physical wires, it is so much quicker and more convenient to connect ‘virtual’ wires. I believe FPGAs offer an amazing way to get into learning digital electronics. The other point is that old technology is failing and we need to preserve these hardware systems before they do. By making FPGA versions we are securing as close as possible their futures, to be used for generations to come.
Thanks for the coverage again, and stay tuned for the next episodes.