FPGA discussion split from Analogue Pocket thread

[Jdurg]

I'm willing to guess that the majority of people getting up in arms over "emulation" versus FPGA are those who are older and were around when console emulation really was brand new. At that time, there were a LOT of talentless hacks programming crappy emulators with accuracy and proper emulation thrown completely out the window. The main goal was to get the games to run period, not run accurately.

'Scuse me?
You just called one of my high school classmates (and the defacto inventor of emulation) a "talentless hack".

Better think about that one again. In fact, don't bother. Just piss off.

I'm opposed to "FPGA isn't emulation" because I have been writing software my whole life and I know enough to understand that it is emulation.

Woah woah, hold your horses. Don't be jumping to conclusions here. Show me where I said you and your classmates were hacks. I'm sorry, but a lot of the early shit emulators were that. Shit. I don't even know what emulators you and your "classmates" have written so I am not, and will not be, commenting on that.

[bobrocks95]

Kevtris is doing what any other emulator dev does- recreating the behavior of existing hardware in a different environment. He is not doing a transistor-level recreation of anything- as far as I know that's only been done accurately for Pong so far, in relation to games.

You look at the expected results, and you reproduce them. Its behavior is as close to 1:1 as Kevtris can get it, same as any other software emulator. These days, for games of this vintage, good luck noticing any differences, but it's definitely what I'd still refer to as emulation.

Not sure why this discussion has come up again though. To get back to the actual product, it looks great if the cartridge adapters are cheap and you're into portables. I'd buy it if I didn't think it would look stupid sitting on the dock (the Switch already fails as a home console imo, putting a cartridge in and feeling it wobble in the dock is unpleasant).

[Guspaz]

Apart from the platforms where he did most of the work before joining Analogue (remember that he'd been doing FPGA cores of game consoles for something like a decade before the Nt Mini), he's spent a full year of more than full-time work per system (how he does that at the same time as his day job is beyond me). He's gone pretty in-depth in the past about his process for implementing systems, and looking at emulators certainly never enters into it. With some of the secondary cores he's done, it's either stuff he's already done to a less polished state in the past, or stuff that was partially implemented by the primary core. You don't need to keep re-implementing the Z80 from scratch every time you do a new Z80-based system, for example, and every single system supported by the Mega Sg uses a Z80 processor in some capacity.

The idea that Kevin is just porting C emulators to verilog is absurd. Not only because that's claiming that he's a lier, but because such a thing doesn't even make sense.

EDIT: Case in point, of the systems supported by the Analogue Pocket, the GB, GBC and Game Gear already have existing cores running on Analogue consoles, the Lynx uses the same CPU as the Supervision and Game King (which have existing cores for the Analogue Nt Mini), leaving only the GBA and NGPC unimplemented. The Z80 part of the GBA and NGPC is already done, of course.

[orange808]

I'm willing to guess that the majority of people getting up in arms over "emulation" versus FPGA are those who are older and were around when console emulation really was brand new. At that time, there were a LOT of talentless hacks programming crappy emulators with accuracy and proper emulation thrown completely out the window. The main goal was to get the games to run period, not run accurately.

'Scuse me?
You just called one of my high school classmates (and the defacto inventor of emulation) a "talentless hack".

Better think about that one again. In fact, don't bother. Just piss off.

I'm opposed to "FPGA isn't emulation" because I have been writing software my whole life and I know enough to understand that it is emulation.

Woah woah, hold your horses. Don't be jumping to conclusions here. Show me where I said you and your classmates were hacks. I'm sorry, but a lot of the early shit emulators were that. Shit. I don't even know what emulators you and your "classmates" have written so I am not, and will not be, commenting on that.

Nesticle.

You did exactly what I said you did.

Don't ever quote me again.

[orange808]

Apart from the platforms where he did most of the work before joining Analogue (remember that he'd been doing FPGA cores of game consoles for something like a decade before the Nt Mini), he's spent a full year of more than full-time work per system (how he does that at the same time as his day job is beyond me). He's gone pretty in-depth in the past about his process for implementing systems, and looking at emulators certainly never enters into it. With some of the secondary cores he's done, it's either stuff he's already done to a less polished state in the past, or stuff that was partially implemented by the primary core. You don't need to keep re-implementing the Z80 from scratch every time you do a new Z80-based system, for example, and every single system supported by the Mega Sg uses a Z80 processor in some capacity.

The idea that Kevin is just porting C emulators to verilog is absurd. Not only because that's claiming that he's a lier, but because such a thing doesn't even make sense.

I pointed out that I have no idea what the actual source looks like and it's obviously based on C code. That's all.

Yes, he's doing a ton of work on the bench to get things as close as possible.

I never said he wasn't.

I did point out that an FPGA doesn't have the magical inherent properties that people believe. And, these myths got started with Analogue's marketing.

[Guspaz]

They're not based on C code, though. Do you mean that Verilog kind of looks like C? Sure, but it doesn't work remotely like C, it's a hardware description language, a way to describe circuits.

He's doing this stuff from scratch, not porting or deriving from C code.

[donluca]

Truthfully, you can stick with C.

Take this with a huge pinch of salt because I've never programmed an FPGA, just high level software, but I'm pretty sure that when you "code in C for a FPGA" it actually gets translated to another language with a pretty big performance impact.

C has libraries for CPUs like x86, ARM, MIPS and others, but it cannot compile for an FPGA as the two (FPGA and general purpose CPUs) are completely unrelated.

[thebigcheese]

PC cart readers don't operate in real-time. You dump the rom in advance and feed that into the emulator. One of the advantages of an FPGA is, since the emulated hardware can simulate the IO of the original hardware on an electrical level, you can run off the carts directly, including using any additional hardware that might be in the carts, such as enhancement chips.

You couldn't use an SD2SNES on a PC via a cartridge reader, for example. Not that you'd have any reason to.

Thank you, that was... literally the point I had made, if they had bothered to read it. Too busy proselytizing.

[ZellSF]

Wow, much off-topic. Must continue:

Also, byuu has run ahead in BSNES and we can effectively match real hardware on our PC right now. So, you know, inaccurate again.

Isn't BSNES runahead same as RetroArch runahead, meaning it's to eliminate software lag, which is only possible for software that has lag?

The random compatibility sheet I found says quite a few games only have 1 frame of software lag, so to use it to compensate for host lag the host would can't lag more than 1 frame over the real console.

[donluca]

After getting incredible negative backlash for how inaccurate it was he took that down and put up this new response which was much less incendiary and blatantly admits several times no matter what emulators do they can never equal fpgas regardless of emulator quality.

Cmon man, that was a PR move because he got himself into trouble with that statement and had to find a way out to avoid legal actions, to the point that he even blocked the web archive and google cache from saving that post.

His post was spot on and if you had a little bit of knowledge about coding and how FPGA work you'd definitely appreciate his time spent on educating people about what FPGAs are and how they work.

[orange808]

They're not based on C code, though. Do you mean that Verilog kind of looks like C? Sure, but it doesn't work remotely like C, you can't port between them, even on a logical or functional level.

He's doing this stuff from scratch, not porting or deriving from C code.

I can't confirm or deny how it's getting done.

First, there are C compilers for FPGA platforms, so I could use C.

Second, there aren't "one click" automated solutions to port C over, but it's very manageable.

[Guspaz]

You keep implying that Kevin Horton is a liar, when we've never had any reason to doubt his claims as to his process. I think you should refrain from slinging around that sort of baseless accusation.

[orange808]

Wow, much off-topic. Must continue:

Also, byuu has run ahead in BSNES and we can effectively match real hardware on our PC right now. So, you know, inaccurate again.

Isn't BSNES runahead same as RetroArch runahead, meaning it's to eliminate software lag, which is only possible for software that has lag?

The random compatibility sheet I found says quite a few games only have 1 frame of software lag, so to use it to compensate for host lag the host would can't lag more than 1 frame over the real console.

Sure, you need a powerful gaming PC to get the best emu experience. That's always been true.

Of course, none of this changes the fact that FPGA is convenient emulation and not a complete 1:1 hardware reproduction. Love the consoles, but I hate the marketing.

[Wolf_]

Apart from the platforms where he did most of the work before joining Analogue (remember that he'd been doing FPGA cores of game consoles for something like a decade before the Nt Mini), he's spent a full year of more than full-time work per system (how he does that at the same time as his day job is beyond me). He's gone pretty in-depth in the past about his process for implementing systems, and looking at emulators certainly never enters into it. With some of the secondary cores he's done, it's either stuff he's already done to a less polished state in the past, or stuff that was partially implemented by the primary core. You don't need to keep re-implementing the Z80 from scratch every time you do a new Z80-based system, for example, and every single system supported by the Mega Sg uses a Z80 processor in some capacity.

The idea that Kevin is just porting C emulators to verilog is absurd. Not only because that's claiming that he's a lier, but because such a thing doesn't even make sense.

EDIT: Case in point, of the systems supported by the Analogue Pocket, the GB, GBC and Game Gear already have existing cores running on Analogue consoles, the Lynx uses the same CPU as the Supervision and Game King (which have existing cores for the Analogue Nt Mini), leaving only the GBA and NGPC unimplemented. The Z80 part of the GBA and NGPC is already done, of course.

The Lynx is also new!

[orange808]

You keep implying that Kevin Horton is a liar, when we've never had any reason to doubt his claims as to his process. I think you should refrain from slinging around that sort of baseless accusation.

I never implied a thing. I did say I haven't seen the source code and I have no idea how it was done.

However, it's clear that he's looking at the C code from other emus to find direction. A person has to start somewhere! Although, if you're telling me the entire library that he uses and the emus are all "new project" coding from blank screens, a cursor, and a scope: I don't buy it.

Most emus are open source work. When we contribute to these projects, it's supposed to inspire new improved innovations.

That's how this works.

I'm not mad about it. I just hate Analogue's marketing and the misleading impressions it creates.

[Wolf_]

After getting incredible negative backlash for how inaccurate it was he took that down and put up this new response which was much less incendiary and blatantly admits several times no matter what emulators do they can never equal fpgas regardless of emulator quality.

Cmon man, that was a PR move because he got himself into trouble with that statement and had to find a way out to avoid legal actions, to the point that he even blocked the web archive and google cache from saving that post.

His post was spot on and if you had a little bit of knowledge about coding and how FPGA work you'd definitely appreciate his time spent on educating people about what FPGAs are and how they work.

You think Analogue threatened to sue him over what he wrote in a random forum post so he wrote the same damn thing a second time only a little nicer with some of the information corrected?

Alternative theory: He didn't like all the flak he was getting because of his inaccurate statements about fpgas and accurate statements about the limitations of emulators and as a result did his best to delete it and put it behind him.

[ZellSF]

Wow, much off-topic. Must continue:

Also, byuu has run ahead in BSNES and we can effectively match real hardware on our PC right now. So, you know, inaccurate again.

Isn't BSNES runahead same as RetroArch runahead, meaning it's to eliminate software lag, which is only possible for software that has lag?

The random compatibility sheet I found says quite a few games only have 1 frame of software lag, so to use it to compensate for host lag the host would can't lag more than 1 frame over the real console.

Sure, you need a powerful gaming PC to get the best emu experience. That's always been true.

I wasn't talking about host lag caused by a slow PC. I'm talking about the inherent lag of a modern OS stack, which according to byuu:

A software emulator can reasonably expect to get within 30-50ms of the latency of a pure hardware approach.

And yes I read this:

The best software emulators claim to reach within 8ms of real hardware latency

Though I'm pretty sure no one's verified this yet.

So the question is, is this inevitable host side lag more than 1 frame (I believe it is), if so FPGAs can have less lag for a lot of games.

Even byuu says:

But indeed, if latency is your primary concern, I concede that FPGA devices are currently the way to go

I don't think merely a 1 frame difference is enough to make him say that.

[donluca]

You keep implying that Kevin Horton is a liar, when we've never had any reason to doubt his claims as to his process. I think you should refrain from slinging around that sort of baseless accusation.

It doesn't necessarily him, that's all marketing, maybe there's someone on their team who decided to jump on the FPGA bandwagon and wave the "not emulation" flag all over.

I don't know how much Kevin knows or cares about how his products are marketed, honestly, so I wouldn't call him a liar, but saying that "FPGA IS NOT EMULATION" in big, bold, all caps font is 100% false or, anyway, plays on the ambiguity of the definition of term "emulation".

I mean... it's common marketing gimmicks.
Remember back in the days when "FullHD" TVs were all the rage and several brands sold TVs which were capable only of 1080i as "FullHD"?
Were they really FullHD? Well, yeah, by interpolating they could display fullHD content but not a progressive 1080 lines.

[orange808]

@ZellSF
You realize that other emu devs questioned some of byuu's statements and he has worked through the stubborn audio issues that led him to say those things?

You're quoting the guy from over a year ago, right? You're also quoting statements that he made regarding Higan. You're also quoting a guy that dismissed Mark Rehjon with sarcasm when he suggested a beam racing implementation that works very well in WinUAE.

You're also quoting a guy that would have to do a lot of "reinvent the wheel" churning to recode areas of his prized emulator to improve performance--when he was targeting accuracy.

So, I'm not sure that old comments from one particular human being really explains what's possible and not possible.

[Unseen]

First, there are C compilers for FPGA platforms, so I could use C.

Second, there aren't "one click" automated solutions to port C over, but it's very manageable.

It is pretty obvious that you have never used any of these "compilers". While it is true that there are so-called high level synthesis (HLS) tools that can take C or C++ and convert it into a module that can be used on an FPGA, they come with a lot of strings attached. This is because the programming model of an FPGA is very different from a procedural/object-oriented language like C or C++ - these languages are based on abstractions of a sequential processor while an FPGA is closer to a data flow machine.

C/C++ code that takes data, runs calculations on it and spits out a transformed version is an excellent match for these HLS tools, so they tend to be demonstrated using DSP number crunching code or audio/video codecs. You won't see much code like that in emulators though, they are more state-driven and not very suited for use with HLS tools.

[orange808]

First, there are C compilers for FPGA platforms, so I could use C.

Second, there aren't "one click" automated solutions to port C over, but it's very manageable.

It is pretty obvious that you have never used any of these "compilers". While it is true that there are so-called high level synthesis (HLS) tools that can take C or C++ and convert it into a module that can be used on an FPGA, they come with a lot of strings attached. This is because the programming model of an FPGA is very different from a procedural/object-oriented language like C or C++ - these languages are based on abstractions of a sequential processor while an FPGA is closer to a data flow machine.

C/C++ code that takes data, runs calculations on it and spits out a transformed version is an excellent match for these HLS tools, so they tend to be demonstrated using DSP number crunching code or audio/video codecs. You won't see much code like that in emulators though, they are more state-driven and not very suited for use with HLS tools.

Oh yes. I absolutely have not used an FPGA. I'm a dinosaur.

You are correct, coding in a C dialect would be inefficient, but it is possible.

However, porting over some implementations and strategies for emulating is certainly possible and probably the best way to go about doing it.

Finally, Horton is a genius. It really doesn't matter if he mined other emus to get legs underneath his projects. That's how it's supposed to happen.

[Xyga]

OS lag: where are the measurements ?

Emulators lag VS. real hardware: where are the measurements ?

Even if you're called byuu and you're probably right about on several levels, those claims need to be verified, thoroughly so and documented.

I'm betting the results would be full of surprises.

Anyway on the emulator's side there's the game software and how the dev coded the emulation of it, and stickied the shit together with rendering and how inputs are handled etc, that makes several things even just within what we call randomly the 'emulator lag', and oh boy how numerous and variable the claims are.

I won't believe it's impossible to get very accurate results on a PC with software emus until proven otherwise, again this requires thorough investigation, not just claims.

[shroom2k]

Although, if you're telling me the entire library that he uses and the emus are all "new project" coding from blank screens, a cursor, and a scope: I don't buy it.

Why is that difficult to believe? Some people just enjoy figuring stuff out completely on their own, and not just in electronics or software. It's a personality type, kind of.

[ZellSF]

@ZellSF
You realize that other emu devs questioned some of byuu's statements and he has worked through the stubborn audio issues that led him to say those things?

You're quoting the guy from over a year ago, right? You're also quoting statements that he made regarding Higan. You're also quoting a guy that dismissed Mark Rehjon with sarcasm when he suggested a beam racing implementation that works very well in WinUAE.

You're also quoting a guy that would have to do a lot of "reinvent the wheel" churning to recode areas of his prized emulator to improve performance--when he was targeting accuracy.

So, I'm not sure that old comments from one particular human being really explains what's possible and not possible.

You made a claim, it's up to you to support it (I'm being way too generous trying to discuss it logically and referring to an external source). As it stands now, this:

Also, byuu has run ahead in BSNES and we can effectively match real hardware on our PC right now.

Is bullshit.

It might be possible to match real hardware on PCs, but you can't state it's definitely possible like you did, unless you have something you're not sharing.

[donluca]

You think Analogue threatened to sue him over what he wrote in a random forum post so he wrote the same damn thing a second time only a little nicer with some of the information corrected?

My memory is getting a bit rusty as of late, so please feel free to correct me if there's something amiss, but here's Analogue context when the Super NT was released:

Back then they were a niche working only on CMVS (Consolized MVS, neogeo, that is) and produced one of the best looking and functional ones and charged a pretty hefty price.

SuperNT was their first product which would have rocketed their business into orbit if it went well and when it released, they used the "FPGA not emulation" cliché to attract as many customers as possible and byuu put them on blast on his own website, which coincidentally is the home of higan, the best and most accurate SNES emulator available (at that time, dunno about now). It was not some random post made in niche forums.

He also accused Polygon pretty heavily and they might have give him a call about "we didn't like that".
Besides, byuu and Kevin were (are?) friends so it makes sense that he decided to remove the post from as many places as possible in order to not hurt his business, because I clearly remember that post resonating in almost all videogame forums and subreddits of the time.
I mean, after all, byuu is the coder of the most accurate SNES emulator, not just some random dude with little coding skills, so his views had a pretty big impact.

If you want my own idea of what happened is that Polygon got mad, Analogue got mad and Kevin kindly asked him to tone it down a bit and hush the matter away so they could go on with their own thing and byuu accepted.

But what was stated in byuu's original post is 100% correct and now, thanks to new approaches in how video is displayed on screen (splicing, beam racing, etc...) we are seeing proof that a completely lag free emulation solution is possible which would put software emulation on the same level as FPGAs, so YMMV.

@mods, this should be in the Hardware forum, no matter what. There is important information and discussion and it's out of place in the "off topic" section.

[orange808]

@ZellSF
You realize that other emu devs questioned some of byuu's statements and he has worked through the stubborn audio issues that led him to say those things?

You're quoting the guy from over a year ago, right? You're also quoting statements that he made regarding Higan. You're also quoting a guy that dismissed Mark Rehjon with sarcasm when he suggested a beam racing implementation that works very well in WinUAE.

You're also quoting a guy that would have to do a lot of "reinvent the wheel" churning to recode areas of his prized emulator to improve performance--when he was targeting accuracy.

So, I'm not sure that old comments from one particular human being really explains what's possible and not possible.

You made a claim, it's up to you to support it (I'm being way too generous trying to discuss it logically and referring to an external source). As it stands now, this:

Also, byuu has run ahead in BSNES and we can effectively match real hardware on our PC right now.

Is bullshit.

It might be possible to match real hardware on PCs, but you can't state it's definitely possible like you did, unless you have something you're not sharing.

RetroRGB has camera tests up right now.

Pretty close. In fact, maybe a little too little lag.

Google it.

[ZellSF]

@ZellSF
You realize that other emu devs questioned some of byuu's statements and he has worked through the stubborn audio issues that led him to say those things?

You're quoting the guy from over a year ago, right? You're also quoting statements that he made regarding Higan. You're also quoting a guy that dismissed Mark Rehjon with sarcasm when he suggested a beam racing implementation that works very well in WinUAE.

You're also quoting a guy that would have to do a lot of "reinvent the wheel" churning to recode areas of his prized emulator to improve performance--when he was targeting accuracy.

So, I'm not sure that old comments from one particular human being really explains what's possible and not possible.

You made a claim, it's up to you to support it (I'm being way too generous trying to discuss it logically and referring to an external source). As it stands now, this:

Also, byuu has run ahead in BSNES and we can effectively match real hardware on our PC right now.

Is bullshit.

It might be possible to match real hardware on PCs, but you can't state it's definitely possible like you did, unless you have something you're not sharing.

RetroRGB has camera tests up right now.

Pretty close. In fact, maybe a little too little lag.

Google it.

I did. He said emulation is 0-2 frames slower than real hardware, and runahead can't always account for 2 or even 1 frame.

That doesn't support your claim.

That's reading this article, so others don't have to Google it:
https://www.retrorgb.com/bsnes-runahead ... ested.html

[orange808]

I did. He said emulation is 0-2 frames slower than real hardware, and runahead can't always account for 2 or even 1 frame.

That doesn't support your claim.

That's reading this article, so others don't have to Google it:
https://www.retrorgb.com/bsnes-runahead ... ested.html

Just wanted to quote you for others.

The article actually has results that are below real hardware baseline measurements.

I didn't get the same conclusions from the article that you did. I think you skim read.

FPGA is cheaper and more convenient, but that shows BSNES dangerously close to real hardware with no run ahead--and faster with run ahead on.

And, PCs will just keep getting faster.

Of course, none of this changes that FPGA is emulation and it doesn't reproduce the hardware 1:1. It's all emulation.

[ZellSF]

The article actually has results that are below real hardware baseline measurements.

Yes. When he started using a different display. I can say emulation is 10 times slower than real hardware if that's the standard of research you want to go by.

I think you skim read.

I did, but I'm not as bad at it as you are.

[orange808]

The article actually has results that are below real hardware baseline measurements.

Yes. When he started using a different display. I can say emulation is 10 times slower than real hardware if that's the standard of research you want to go by.

I think you skim read.

I did, but I'm not as bad at it as you are.

I'm sorry RetroRGB wrote an "absurd" article. (Not really. But, we'll agree to disagree.)

FPGA is still emulation.