I don’t really know much about game emulation so I was curious about what differentiates this FPGA game project vs traditional CPU emulation.
From their github page [1]:
>Traditional emulators on CPUs execute code sequentially. This is a tricky method of emulation because real hardware has many chips and all of them work in parallel...This requires a lot of CPU power to emulate even an old and slow retro computer. Sometimes even a modern CPU working at 100 times the speed of the retro computer is not enough, so the emulator has to use approximation, skip emulation of some less important parts, or assume some standard work of the emulated system without extraordinary usage.
> FPGA doesn't need high frequencies to emulate retro computers; it works at much lower frequencies than traditional emulators require. Since everything in FPGA works in parallel, it is no problem to handle any possible usage of the emulated system.
There was a good article from Arstechnica a decade ago that pointed out why you need so much more power to get perfect emulation. To get exact emulation takes a lot of power because there are a few games which use odd tricks that are hard to document and precisely reimplement in software. FPGA emulation gets around that by more directly emulating the hardware.
byuu wrote a good article about this, unfortunately it's no longer available, but basically it should be self-evident that there's nothing inherently more accurate about hardware emulation.
If you've actually decapped the original chips and duplicated them exactly in an FPGA, that's pretty cool. But otherwise it's just another approximation. The lower power requirements are nice, of course.
On FPGAs (depending on the hardware mapping), you get the benefit of lower latency. I consider this to be timing accuracy.
Say you have two implementations of an LED controlled by a switch: one which uses an FPGA and one which uses a microcontroller. The uC implementation must continuously poll peripherals connected to its GPIO pins at a set frequency; it must check the state of the switch, and then change the state of the LED. The FPGA, on the other hand, physically wires the switch to the LED; there is no lag when the state of the switch changes.
The FPGA implementation can be scaled to connect however many additional lights and switches you want (limited by the size of the fabric), with zero overhead lag. This is the parallelization benefit of FPGAs that you may hear about. For the uC implementation, you must add additional switches and lights to the polling loop, which brings down performance in linear time, O(n). This is the drawback of sequential processing.
Unless you have seen MISTer running (especially on an fixed HZ old school CRT monitor) vs running that same thing emulated on on a modern cycle-exact emulator. The difference is really noticeable.
This might come down to the emulator also running on a modern OS, which cannot guarantee at all times smooth framerates, whereas a dedicated FPGA can promise you that it's not running much more than the actual core needed to emulate that system.
Especially on a 50/60Hz CRT monitor the difference and latency from the controller to pixels to screen is noticeably faster and stuff like scrolling the screen and sprites are buttery smooth, just like in the original hardware.
That's exactly what's happening. There are loads of projects going on right now decapping old chips and reverse engineering them. From old CPUs like the 6502 to the Amiga Alice chip. It's just a matter of time before most of the retro systems are fully reverse engineered and documented.
Actually decapping the original chips is very much a thing. See for example Chris Smith's work mapping out the innards of the ZX Spectrum ULA - http://www.zxdesign.info/book/insideULA.shtml .
I think big differentiator is that it is easier to get predictable latencies with FPGA where you control almost everything, compared to general-purpose PC which is not really that well optimized for hard real-time operation. So I believe "race the beam" style things are more easily accomplished with FPGAs, and also having tight audio-video sync. Although the PC emulation scene has been also doing some fairly incredible things too.
Quite a few of the FPGA soft cores related to 8 bit gaming are reverse engineered from either schematics, decapped chips, or both. Or they take pains to at least use the same number of cycles for each instruction, access SRAM or DRAM in the same way, etc.
I like to emphasise that this is about much more than gaming. This is hardware emulation of old computers. I would love to see it emulating other machines - if it can do an Atari ST, it'd probably be able to do a Xerox Star or an Apollo Domain.
One thing I noticed from owning a C64-Maxi is how much of the experience is the physical aspect - We interacted with these machines through keyboards of different designs and that was a very important part of the overall experience.
Running VALDOCS on an Epson QX-10 without a VALDOCS keyboard is not quite the right feel.
Nice thing about fpgas is that at least in theory it should be relatively easy to interface pretty much anything to them, so you could grab your favourite retro keyboard and connect it to MiSTer.
I wish we could have easier/cheaper ways to build keyboards like that could function with the emulation. A Symbolics without circle, square and triangle keys is not a Symbolics
The usb controllers made for the recent mini systems (NES, SNES, Genesis, etc) make great accessories for the mister. Add a couple of usb arcade sticks and you can really play almost any classic retro games as it was meant to be played.
And then there are all the classic computer cores even including the PDP-1!
Yup, same! Can wholeheartedly recommend it for those who want something between emulation and real hardware.
The Amiga core is fun, AGA, 2 MB chip, 384 MB fast. It supports hard disk images, so you can do a hard disk based Workbench installation and load games and demos practically instantly (and safely exit to Workbench) using WHDLoad.
Arcade cores are fun as well. Just like in childhood, but less hungry for quarters. :) Recently played with arcade Gauntlet core a bit for example.
This whole setup is a game changer for me, I got a complete WHDLoad setup done in under 5 minutes after a bit of sleuthing on Internet Archive. Now I just need to get the proper cables to connect my Commodore 1084s.
This isn't really new, right? I've heard of this years ago.
But it is an amazing project. Instead of emulating, they actually rebuilt the old custom ICs (which 8-bit computers were full of) in an FPGA. Really impressive.
It is indeed an amazing project, especially its open source nature. It provides some impressive power savings and latency reductions that are very hard to match with general purpose CPUs.
But in most cases, it is emulation, as the lead developer will attest.
"From my point of view, if the FPGA code is based on the circuitry of real hardware (along with the usual tweaks for FPGA compatibility), then it should be called replication. Anything else is emulation, since it uses different kinds of approximation to meet the same objectives. Currently, it's hard to find a core that can truly be called a replica – most cores are based on more-or-less functional recreations rather than true circuit recreation. The most widely used CPU cores – the Z80 (T80) and MC68000 (TG68K) – are pure functional emulations, not replications. So it's okay to call FPGA cores emulators, unless they are proven to be replicas."
But there's nothing wrong with emulation for preservation, until we get to a point where we can wide-scale clone these older chips down to the transistor level through analysis of delayered decap scans. And even then, emulation will be useful for artificial enhancements as well as for understanding how all those transistors actually worked at a higher level.
It's also not a total solution: by taking many more transistors to programmatically simulate just one, it limits the maximum scale and frequency of what it can support. N64/PS1/Saturn has not yet been fully supported and is still theoretical, but likely, to be possible. Going beyond that is not possible at this time.
Software emulation and FPGA devices should be seen as complementary approaches, rather than competitive. The developers of each often work together, and new knowledge is mutually beneficial.
Ah ok I wasn't aware of this. I thought it was spot on.
And yeah I hope we can easily order small batches of ICs (at big pitch of course) in a few years, in a similar way to how creating PCBs has become so simple now.
I mean I remember how much of a PITA it was in the 80s. Drawing on overhead sheets. All the acids and other chemicals. Drilling. And now we get super-accurate 10x10cm boards dual-layer, drilled, soldermasked and silkscreened for a buck a pop with a minimum of 10. Wow. I really hope this trend continues down to the scale of ICs (or that FPGAs simply get better/easier).
By the way, emulating a CPU is pretty easy and very accurate anyway. The big problem with accurate emulation is with some of the peripheral ICs which used hard to emulate stuff like analog sound generators.
> It's also not a total solution: by taking many more transistors to programmatically simulate just one, it limits the maximum scale and frequency of what it can support. N64/PS1/Saturn has not yet been fully supported and is still theoretical, but likely, to be possible. Going beyond that is not possible at this time.
The limiting factor here is the amount of stuff you can throw into a single FPGA, correct?
So in theory, shouldn't it be possible to tie a bunch of FPGAs together, with two beefy ones being responsible for replicating CPU / GPU functionality, a couple smaller ones for sound and other "helper" processors, and some bog-standard ARM SoC to provide the bitstreams to the FPGAs and emulate storage (game cartridges, save cards) and input elements (mainly "modern" controllers)?
Well, yeah, it's not replication if it's not an exact hardware replica, but the word "emulation" has very "software" connotations. I guess let's call it.. recreation? (That word is even in the quote above!)
Yeah, it really is an amazing application for FPGAs—preserving computing and gaming history.
The list of cores available for MiSTer is simply staggering:
> Computers - Classic
• Acorn Archimedes
• Acorn Atom
• Alice MC10
• Altair 8800
• Amiga
• Amstrad CPC 6128
• Amstrad PCW
• ao486 (PC 486)
• Apogee
• Apple I
• Apple II+
• Apple Macintosh Plus
• Aquarius
• Atari 800XL
• Atari ST/STe
• BBC Micro B,Master
• BK0011M
• Color Computer 2, Dragon 32
• Commodore 16, Plus/4
• Commodore 64, Ultimax
• Commodore PET
• Commodore VIC-20
• DEC PDP-1
• EDSAC
• Galaksija
• Jupiter Ace
• Laser 310
• MSX
• MultiComp
• Orao
• Oric 1 & Atmos
• SAM Coupe
• Sharp MZ Series
• Sinclair QL
• Specialist/MX
• TI-99/4A
• TRS-80 Model 1
• TSConf
• Vector 06C
• X68000
• ZX Spectrum
• ZX Spectrum Next
• ZX81
Interesting project would be to dig out some old cassettes from, let's say, commodore 64. Try to load them into a present day computer by patching wires/cables? - and see if they run in this system.
I remember writing for example:
a mining program, to calculate, overburden, volume and tonnage, at different slopes, different rock types, etc.
The science behind the calculations is still valid, but we could likely increase load times, and calculating times.
One really great way to think of MiSTer is as a living documentation project that results in documented and working system hardware vs MAME which is focused on documenting working system software. It just so happens if you have working hardware you can run the software meant for it (MiSTer) and from the other end if you want software to work you need a pretty good idea what the hardware is supposed to be doing.
They're basically similar efforts but approaching the problem from a different point of view.
Given how hard FPGA programming is, the work in MiSTer is quite magnificent.
MiSTer is an amazing phenomenon. The MiSTer itself is just an Intel FPGA devkit, which many believe to be sold at a loss (because it's a training tool and not Intel's main source of FPGA revenue). The amazing thing is the aftermarket for addons. There are many possible combinations of addon boards that add RAM with deterministic latency, USB hubs, cooling fans, cases, retro controller ports, etc. All custom-made for this ecosystem.
It is definitely being sold at a loss, the Cyclone V SOC being used costs more than the entire development board.[0] I wonder if Intel will ever take notice due to MiSTer's growing popularity and quit subsidizing the board.
Edit: it was erroneous of me to state the board was being sold at a loss, rather I meant that the board was being definitely being subsidized by companies such as Intel and their partners such as Panasonic. My mistake.
I also wasn't meaning to convey that the consumer Digikey pricing was the same as the large volume manufacturers such as Terasic. Rather I meant to demonstrate and agree with the OP on the astounding situation that MiSTer currently exists in, owning to the lack of economic viability for someone to produce a low volume commercial FPGA emulation machine for a niche audience without any subsidization.
There is absolutely no way they’re sold at a loss. Your DigiKey price of $245 proves this, because a factor of 10 is a good starting point as a ratio between volume and one-off DigiKey pricing of any type of complex silicon.
A better way to approach this is as follows: what’s the die size of an FPGA like this? What’s the production cost of the die? Then check the historic gross margin percentage of FPGA companies. Xilinx is around 68%, and that includes high-end products which carry the highest markups, unlike this cookie cutter thing.
That should give you a good ballpark number.
DigiKey charges what they do because nobody else is willing to sell these things in low volume, and they have very high inventory costs.
Digikey pricing is not indicative of actual volume pricing, especially for FPGAs where they are often many times overpriced when buying from distributors. I doubt the board is sold at an loss, probably sold at a small profit, not that's it's really significant for a low volume dev board.
The price of a DE10-Nano is $135 ($115 for academic use.)
Anyone who thinks that Terasic sells these at a loss doesn’t have a clue about volume pricing of FPGAs. And as a special Intel partner, there’s little doubt that Terasic has access to this kind of pricing.
Readit News
From their github page [1]:
>Traditional emulators on CPUs execute code sequentially. This is a tricky method of emulation because real hardware has many chips and all of them work in parallel...This requires a lot of CPU power to emulate even an old and slow retro computer. Sometimes even a modern CPU working at 100 times the speed of the retro computer is not enough, so the emulator has to use approximation, skip emulation of some less important parts, or assume some standard work of the emulated system without extraordinary usage.
> FPGA doesn't need high frequencies to emulate retro computers; it works at much lower frequencies than traditional emulators require. Since everything in FPGA works in parallel, it is no problem to handle any possible usage of the emulated system.
[1] https://github.com/MiSTer-devel/Main_MiSTer/wiki/Why-FPGA
(Edited for formatting)
https://arstechnica.com/gaming/2011/08/accuracy-takes-power-...
If you've actually decapped the original chips and duplicated them exactly in an FPGA, that's pretty cool. But otherwise it's just another approximation. The lower power requirements are nice, of course.
Say you have two implementations of an LED controlled by a switch: one which uses an FPGA and one which uses a microcontroller. The uC implementation must continuously poll peripherals connected to its GPIO pins at a set frequency; it must check the state of the switch, and then change the state of the LED. The FPGA, on the other hand, physically wires the switch to the LED; there is no lag when the state of the switch changes.
The FPGA implementation can be scaled to connect however many additional lights and switches you want (limited by the size of the fabric), with zero overhead lag. This is the parallelization benefit of FPGAs that you may hear about. For the uC implementation, you must add additional switches and lights to the polling loop, which brings down performance in linear time, O(n). This is the drawback of sequential processing.
This might come down to the emulator also running on a modern OS, which cannot guarantee at all times smooth framerates, whereas a dedicated FPGA can promise you that it's not running much more than the actual core needed to emulate that system.
Especially on a 50/60Hz CRT monitor the difference and latency from the controller to pixels to screen is noticeably faster and stuff like scrolling the screen and sprites are buttery smooth, just like in the original hardware.
One thing I noticed from owning a C64-Maxi is how much of the experience is the physical aspect - We interacted with these machines through keyboards of different designs and that was a very important part of the overall experience.
Running VALDOCS on an Epson QX-10 without a VALDOCS keyboard is not quite the right feel.
The usb controllers made for the recent mini systems (NES, SNES, Genesis, etc) make great accessories for the mister. Add a couple of usb arcade sticks and you can really play almost any classic retro games as it was meant to be played.
And then there are all the classic computer cores even including the PDP-1!
The Amiga core is fun, AGA, 2 MB chip, 384 MB fast. It supports hard disk images, so you can do a hard disk based Workbench installation and load games and demos practically instantly (and safely exit to Workbench) using WHDLoad.
Arcade cores are fun as well. Just like in childhood, but less hungry for quarters. :) Recently played with arcade Gauntlet core a bit for example.
But it is an amazing project. Instead of emulating, they actually rebuilt the old custom ICs (which 8-bit computers were full of) in an FPGA. Really impressive.
But in most cases, it is emulation, as the lead developer will attest.
https://github.com/MiSTer-devel/Main_MiSTer/wiki/Why-FPGA
"From my point of view, if the FPGA code is based on the circuitry of real hardware (along with the usual tweaks for FPGA compatibility), then it should be called replication. Anything else is emulation, since it uses different kinds of approximation to meet the same objectives. Currently, it's hard to find a core that can truly be called a replica – most cores are based on more-or-less functional recreations rather than true circuit recreation. The most widely used CPU cores – the Z80 (T80) and MC68000 (TG68K) – are pure functional emulations, not replications. So it's okay to call FPGA cores emulators, unless they are proven to be replicas."
But there's nothing wrong with emulation for preservation, until we get to a point where we can wide-scale clone these older chips down to the transistor level through analysis of delayered decap scans. And even then, emulation will be useful for artificial enhancements as well as for understanding how all those transistors actually worked at a higher level.
It's also not a total solution: by taking many more transistors to programmatically simulate just one, it limits the maximum scale and frequency of what it can support. N64/PS1/Saturn has not yet been fully supported and is still theoretical, but likely, to be possible. Going beyond that is not possible at this time.
Software emulation and FPGA devices should be seen as complementary approaches, rather than competitive. The developers of each often work together, and new knowledge is mutually beneficial.
And yeah I hope we can easily order small batches of ICs (at big pitch of course) in a few years, in a similar way to how creating PCBs has become so simple now.
I mean I remember how much of a PITA it was in the 80s. Drawing on overhead sheets. All the acids and other chemicals. Drilling. And now we get super-accurate 10x10cm boards dual-layer, drilled, soldermasked and silkscreened for a buck a pop with a minimum of 10. Wow. I really hope this trend continues down to the scale of ICs (or that FPGAs simply get better/easier).
By the way, emulating a CPU is pretty easy and very accurate anyway. The big problem with accurate emulation is with some of the peripheral ICs which used hard to emulate stuff like analog sound generators.
The limiting factor here is the amount of stuff you can throw into a single FPGA, correct?
So in theory, shouldn't it be possible to tie a bunch of FPGAs together, with two beefy ones being responsible for replicating CPU / GPU functionality, a couple smaller ones for sound and other "helper" processors, and some bog-standard ARM SoC to provide the bitstreams to the FPGAs and emulate storage (game cartridges, save cards) and input elements (mainly "modern" controllers)?
> Computers - Classic
• Acorn Archimedes • Acorn Atom • Alice MC10 • Altair 8800 • Amiga • Amstrad CPC 6128 • Amstrad PCW • ao486 (PC 486) • Apogee • Apple I • Apple II+ • Apple Macintosh Plus • Aquarius • Atari 800XL • Atari ST/STe • BBC Micro B,Master • BK0011M • Color Computer 2, Dragon 32 • Commodore 16, Plus/4 • Commodore 64, Ultimax • Commodore PET • Commodore VIC-20 • DEC PDP-1 • EDSAC • Galaksija • Jupiter Ace • Laser 310 • MSX • MultiComp • Orao • Oric 1 & Atmos • SAM Coupe • Sharp MZ Series • Sinclair QL • Specialist/MX • TI-99/4A • TRS-80 Model 1 • TSConf • Vector 06C • X68000 • ZX Spectrum • ZX Spectrum Next • ZX81
> Consoles - Classic
• Astrocade • Atari 2600 • Atari 5200 • Atari Lynx • AY-3-8500 • ColecoVision, SG-1000 • Gameboy, Gameboy Color • Gameboy Advance • Genesis/Megadrive • SMS, Game Gear • MegaCD • NeoGeo • NES • Odyssey2 • SNES • TurboGrafx 16 / PC Engine • Vectrex
> Other Systems
• Arduboy • Chess • CHIP-8 • Epoch Galaxy II • Flappy Bird • Game of Life • TomyTronic Scramble
They're basically similar efforts but approaching the problem from a different point of view.
Given how hard FPGA programming is, the work in MiSTer is quite magnificent.
[0] https://www.digikey.com/en/products/detail/intel/5CSEBA6U23I...
Edit: it was erroneous of me to state the board was being sold at a loss, rather I meant that the board was being definitely being subsidized by companies such as Intel and their partners such as Panasonic. My mistake. I also wasn't meaning to convey that the consumer Digikey pricing was the same as the large volume manufacturers such as Terasic. Rather I meant to demonstrate and agree with the OP on the astounding situation that MiSTer currently exists in, owning to the lack of economic viability for someone to produce a low volume commercial FPGA emulation machine for a niche audience without any subsidization.
A better way to approach this is as follows: what’s the die size of an FPGA like this? What’s the production cost of the die? Then check the historic gross margin percentage of FPGA companies. Xilinx is around 68%, and that includes high-end products which carry the highest markups, unlike this cookie cutter thing.
That should give you a good ballpark number.
DigiKey charges what they do because nobody else is willing to sell these things in low volume, and they have very high inventory costs.
Anyone who thinks that Terasic sells these at a loss doesn’t have a clue about volume pricing of FPGAs. And as a special Intel partner, there’s little doubt that Terasic has access to this kind of pricing.
[1] https://www.analogue.co/pocket
https://craigjb.com/2019/11/26/gameslab-overview/
MiSTer: Run Amiga, SNES, NES and Genesis on an FPGA - https://news.ycombinator.com/item?id=18721594 - Dec 2018 (30 comments)