Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MiSTer, an open-source FPGA gaming project

github.com

Post reply on HN
Print view View original

51–60 of 111 posts

Re: MiSTer, an open-source FPGA gaming project

#51

Post by tverbeure »

phendrenad2 wrote: post #46

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…

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.

Re: MiSTer, an open-source FPGA gaming project

#52

Post by tverbeure »

tinybear1 wrote: post #50
phendrenad2 wrote: post #46

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…

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. [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 bei…

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.

Re: MiSTer, an open-source FPGA gaming project

#53

Post by andrewcchen »

tinybear1 wrote: post #50
phendrenad2 wrote: post #46

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…

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. [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 bei…

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.

Re: MiSTer, an open-source FPGA gaming project

#55

Post by xigency »

Interesting.

I have a couple of FPGA boards on their way to me in the mail which I intend to use for some homebrew video game projects. Besides getting the development environment working, it can be tricky outputting video from an FPGA because of the precise timing involved. I will have to look through these resources to see if there are any good tricks to use here.

Re: MiSTer, an open-source FPGA gaming project

#56

Post by mikepurvis »

klodolph wrote: post #40
tediousdemise wrote: post #24

Earlier quoted context omitted.

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…

Most game consoles don’t do any of this, though. The gamepad is polled by software. On the NES and SNES, the buttons are connected to a shift register (e.g. 4021). The CPU triggers a latch and then reads out the shift register one bit at a time.

This would be less about a user peripheral like the gamepad (which is obviously going to be read out exactly once per frame anyway) and more about getting subtle interactions between the CPU, memory/DMA, and specialized systems for graphics/audio correct. And not just correct after thousands of hours of work to smoke out the exact sources of specific title bugs, but correct essentially for free.

See for example the tale of an absolutely wild mGBA investigation that was posted here a while ago:

"What happens if an interrupt gets raised between prefetch and the data load? Will it start prefetching the interrupt vector before the invalid memory access? I quickly mocked this up in mGBA, turned on interrupts in the test ROM, and sure enough it broke out of the loop. So I tried the same test ROM on hardware and…it did not break out of the loop. So there goes that theory. Eventually I realized something. You saw that asterisk earlier I’m sure, so yes, there is one thing that can happen in between prefetch and the memory access, but only if the memory bus gets queried by something other than the CPU between the prefetch and invalid memory access."

https://mgba.io/2020/01/25/infinite-loop-holy-grail/

Re: MiSTer, an open-source FPGA gaming project

#57

Post by valec »

TillE wrote: post #16
Jorge1o1 wrote: post #5

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. So…

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.

you can find it here https://archive.is/fWosI

Re: MiSTer, an open-source FPGA gaming project

#58

Post by tyingq »

TillE wrote: post #16
Jorge1o1 wrote: post #5

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. So…

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.

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.

Re: MiSTer, an open-source FPGA gaming project

#59

Post by Graziano_M »

xigency wrote: post #55

Interesting. I have a couple of FPGA boards on their way to me in the mail which I intend to use for some homebrew video game projects. Besides getting the development environment working, it can be tricky outputting video from an FPGA because of the precise timing involved. I will have to look through these resources to see if there are any good tricks to use here.

It can be tricky outputting video from FPGAs? Quite the opposite, this is where they shine.

Re: MiSTer, an open-source FPGA gaming project

#60

Post by blihp »

klodolph wrote: post #40
tediousdemise wrote: post #24

Earlier quoted context omitted.

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…

Most game consoles don’t do any of this, though. The gamepad is polled by software. On the NES and SNES, the buttons are connected to a shift register (e.g. 4021). The CPU triggers a latch and then reads out the shift register one bit at a time.

Sure, and for hardware this old the FPGA could re-implement the CPU (which ran at <4MHz) and the shift register at almost the exact frequency (or whatever frequency is necessary to reproduce the original behavior) of the original as necessary. Then you can run the original software without modification and get much closer to identical behavior and performance characteristics with much lower resource utilization. Granted, it won't be nanosecond perfect, but it will be a lot closer than you'll get on any current CPU.
Post reply on HN