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

101–110 of 111 posts

Re: MiSTer, an open-source FPGA gaming project

#101

Post by rbanffy »

zokier wrote: post #92
rbanffy wrote: post #91

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…

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

Re: MiSTer, an open-source FPGA gaming project

#102

Post by kbenson »

klodolph wrote: post #77
kbenson wrote: post #76

Earlier quoted context omitted.

Your comment seemed to be positioned as a refutation of the prior comment (it could have been meant as an aside, but without something to indicate that it can be hard not to assume it's a counter). Unfortunately, if it was meant as a counter to the prior argument, countering just the example put forth does not actually address the argument put forth, so it it looks like a straw man argument itself (that is, addressin…

> ... countering just the example put forth does not actually address the argument put forth ... The particular example put forth was a good example, and it's worth responding to. If you can come up with a better example, I'd love to hear it. My argument is that the timing of inputs and outputs to consoles is heavily quantized, which gives you a lot more freedom if you want to create an accurate software implementati…

> If you can come up with a better example, I'd love to hear it.

I don't have a side in this discussion. I just stepped in to note one reason why you might have gotten the reply you did, since you specifically noted "Don’t know what you’re getting at." I was merely attempting to illustrate why I thought you might have received the response you did.

> My argument is that the timing of inputs and outputs to consoles is heavily quantized...

That's probably a good argument. That's not what you replied with though. If you had, I don't think you would have gotten the response you did.

>> > Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.

That's as much a point against your comment as against the person that responded to you. Responding to a specific example instead of the position is not responding to the strongest possible interpretation. Then you get responses like you did.

Again, I'm not taking a position on this. I only bothered to comment at at because you seemed to indicate you didn't know why you got the response you did. Honestly, I thought you were likely presenting it as a slight tangent, not an argument, since it's fairly common here for people to view any response as someone arguing the other side once they get slightly heated in an argument.

Re: MiSTer, an open-source FPGA gaming project

#103

Post by mikepurvis »

boomlinde wrote: post #99
mikepurvis wrote: post #56

Earlier quoted context omitted.

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 t…

> but correct essentially for free. Definitely not. Per your example, "what happens if an interrupt gets raised between prefetch and the data load" is not a question that the type of emulation can answer. You can implement hardware as well as software that gets details like this right or wrong. In both cases you usually need an extensive catalog of observations or a full description of the original hardware to correc…

Okay, sure— that was sloppy. Obviously you're going to have bug fixes and unexpected side effects, behaviours, whatever which need to be tracked down in both cases.

But at least in the FPGA case you're directly simulating the behaviour of the discrete components such that their parallel, real-world interactions should tend toward accuracy. It should be similar to the step from HLE to LLE, where LLE is simpler, more accurate, and less hacky, but way less performant. LLE to FPGA would be a similar transition but without the performance penalty.

Re: MiSTer, an open-source FPGA gaming project

#105

Post by duskwuff »

mindentropy wrote: post #78

By any chance is the AMD acquisition of Xilinx also targeted towards emulation market for their gaming processors? In the future would they have the emulated bitstream present for different iterations of the gaming consoles?

> By any chance is the AMD acquisition of Xilinx also targeted towards emulation market for their gaming processors?

Not even a little bit. Retro gaming emulation accounts for basically zero revenue compared to other markets that Xilinx serves, like HPC, networking, and computer vision.

Re: MiSTer, an open-source FPGA gaming project

#106

Post by astrange »

Uberphallus wrote: post #96
astrange wrote: post #65

Earlier quoted context omitted.

FPGA cores are based on CPU emulators, so they aren't more accurate than the emulator, and decapping a chip doesn't help. FPGAs are written in languages like Verilog that are still high-level and do some probably misguided tricks to make it look like you're programming them with a vaguely C syntax.

> FPGA cores are based on CPU emulators FPGA cores are literal CPUs.

Meant to say "FPGA emulators" there, the last emulator project I worked on called them cores.

Re: MiSTer, an open-source FPGA gaming project

#107

Post by bcrl »

astrange wrote: post #65
bcrl wrote: post #23

Earlier quoted context omitted.

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.

FPGA cores are based on CPU emulators, so they aren't more accurate than the emulator, and decapping a chip doesn't help. FPGAs are written in languages like Verilog that are still high-level and do some probably misguided tricks to make it look like you're programming them with a vaguely C syntax.

No, they are not generally based on CPU emulators. FPGA emulators are more accurate than software based emulators, in part because they don't have to do gymnastics to awkwardly emulate things that are easily done in hardware. For example, the documentation for Amiga's custom chips specifies which cycles various DMA activity takes place. Replicating that in hardware is quite easy (just a few comparators wired up to a counter), but it's hugely expensive in software which leads to all kinds of nasty hacks to replicate behaviour games rely on.

It's similar with CPUs. CPU manuals from the 1970s and 1980s often specify the exact cycle counts for instructions while having simple bus interfaces and no caches. Coming up with cycle accurate hardware for these CPUs is not all that hard.

The Amiga is the last machine I ever had for which I was able to get complete specifications and schematics for and understand completely. Once the 386/486 came along, documentation of SMM mode and other internal details became restricted. Modern computers have so much hidden firmware that understanding the entire system is virtually impossible. In contrast vintage 8/16 (and some 32) bit machines can be completely understood by a single determined individual.

Re: MiSTer, an open-source FPGA gaming project

#108

Post by hrvach »

fooblat wrote: post #10

I love my MiSTer build! 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!

Thanks for mentioning the PDP-1 among other amazing cores! :)

Re: MiSTer, an open-source FPGA gaming project

#109

Post by astrange »

pjc50 wrote: post #85
astrange wrote: post #65

Earlier quoted context omitted.

FPGA cores are based on CPU emulators, so they aren't more accurate than the emulator, and decapping a chip doesn't help. FPGAs are written in languages like Verilog that are still high-level and do some probably misguided tricks to make it look like you're programming them with a vaguely C syntax.

> FPGAs are written in languages like Verilog that are still high-level and do some probably misguided tricks to make it look like you're programming them with a vaguely C syntax. This is either incredibly badly explained or wrong. Verilog compiles to gate level.

The difference between Verilog and gates is larger than the difference between C and assembly?

Also, I think most decapping is done to read data tables out of ROMs, not to figure out what all the gates in a chip do.

Re: MiSTer, an open-source FPGA gaming project

#110

Post by klodolph »

kbenson wrote: post #102
klodolph wrote: post #77

Earlier quoted context omitted.

> ... countering just the example put forth does not actually address the argument put forth ... The particular example put forth was a good example, and it's worth responding to. If you can come up with a better example, I'd love to hear it. My argument is that the timing of inputs and outputs to consoles is heavily quantized, which gives you a lot more freedom if you want to create an accurate software implementati…

> If you can come up with a better example, I'd love to hear it. I don't have a side in this discussion. I just stepped in to note one reason why you might have gotten the reply you did, since you specifically noted "Don’t know what you’re getting at." I was merely attempting to illustrate why I thought you might have received the response you did. > My argument is that the timing of inputs and outputs to consoles is…

> I was merely attempting to illustrate why I thought you might have received the response you did.

Oh, that's completely unnecessary. When I said, "Don't know what you're getting at," I was hoping that the commenter understood something that I didn't.

> That's probably a good argument. That's not what you replied with though. If you had, I don't think you would have gotten the response you did.

This is a good illustration of why the guidelines are there in the first place. Comment #1 was the weaker argument, comment #2 was the stronger comment. If you have a discussion with someone, you can get from comment #1 to #2 and beyond.

Telling me that if I had written comment #2 first is... not helpful! Because the process of writing comment #2 involved reading replies to comment #1!

Post reply on HN