FPGA discussion split from Analogue Pocket thread

[orange808]

"No emulation"

Their marketing drives me insane. Fuck.

[donluca]

"No emulation"

Their marketing drives me insane. Fuck.

^ This.

I'll wait for some chinese clone at $50 rather then giving my money to an organization capitalizing on people's ignorance and playing on the "Is FPGA emulation or not?" ambiguity.

For those uneducated: FPGA *IS* EMULATION

The benefit of FPGAs has been discussed ad nauseam, so you're very welcome to use the search function and look it up yourself, but it *IS* still emulation.

[DuxPrime]

I'll wait for some chinese clone at $50 rather then giving my money to an organization capitalizing on people's ignorance and playing on the "Is FPGA emulation or not?" ambiguity.

For those uneducated: FPGA *IS* EMULATION

The benefit of FPGAs has been discussed ad nauseam, so you're very welcome to use the search function and look it up yourself, but it *IS* still emulation.

You're being pedantic, here.

Hardware emulation is a sufficiently different beast than software emulation in terms of accuracy and performance to be considered separately. For all intents and purposes, the experience is identical to playing on original hardware, which can't be said of conventional emulation.

Are they technically both emulation? Yes. But to the non-enthusiast consumer reading Analogue's copy, they won't understand the nuances and—at best—only know about traditional (read: software) emulation. Analogue isn't being purposefully obtuse or duplicitous; they're just using the term "emulation" colloquially.

[nmalinoski]

For those uneducated: FPGA *IS* EMULATION

Since it's not executing the original software or chip functions in software, wouldn't an FPGA implementation be simulation, not emulation?

[fernan1234]

For all intents and purposes, the experience is identical to playing on original hardware, which can't be said of conventional emulation.

Not necessarily, at this point in time at least. It all depends on how well documented the targeted system is, to what extent it has been reverse engineered, the quality of the implementation, etc. Same goes for software emulation. There are systems for which software emulators, in the ideal setup, can still outperform the corresponding currently available FPGA cores.

[orange808]

I'll wait for some chinese clone at $50 rather then giving my money to an organization capitalizing on people's ignorance and playing on the "Is FPGA emulation or not?" ambiguity.

For those uneducated: FPGA *IS* EMULATION

The benefit of FPGAs has been discussed ad nauseam, so you're very welcome to use the search function and look it up yourself, but it *IS* still emulation.

You're being pedantic, here.

Maybe, but Analogue is the one throwing around silly marketing.

Hardware emulation is a sufficiently different beast than software emulation in terms of accuracy and performance to be considered separately.

How so? That's an inaccurate blanket statement.

FPGA implementations are not inherently more accurate. That's bullshit. You're assuming that the emulation is implemented at transistor level--and it *IS NOT*.

For all intents and purposes, the experience is identical to playing on original hardware, which can't be said of conventional emulation.

FPGA uses the same hacks as software emulation. The advantage is convenience and fewer layers of operating system and fragmented hardware headaches to deal with.

It's convenient emulation.

Are they technically both emulation? Yes. But to the non-enthusiast consumer reading Analogue's copy, they won't understand the nuances and—at best—only know about traditional (read: software) emulation. Analogue isn't being purposefully obtuse or duplicitous; they're just using the term "emulation" colloquially.

Well, to the non-enthusiast, is the mCable is a graphics card upgrade in a cable?

[thebigcheese]

Hardware emulation is a sufficiently different beast than software emulation in terms of accuracy and performance to be considered separately.

How so? That's an inaccurate blanket statement.

FPGA implementations are not inherently more accurate. That's bullshit. You're assuming that the emulation is implemented at transistor level--and it *IS NOT*.

Not to myself be pedantic, and maybe they aren't being truthful, but in the notes at the bottom of their product page: "Analogue Pocket is not designed using software emulation. It is designed using a specialty hardware chip called an FPGA, which operates on a transistor level implementation of its functionality." Sooooooooo.

[maxtherabbit]

you could implement an FPGA "simulation" at the transistor level of the original hardware for something like the 6502 that has been decapped and 100% mapped

that said, most FPGA cores are far from that accurate

[maxtherabbit]

Hardware emulation is a sufficiently different beast than software emulation in terms of accuracy and performance to be considered separately.

How so? That's an inaccurate blanket statement.

FPGA implementations are not inherently more accurate. That's bullshit. You're assuming that the emulation is implemented at transistor level--and it *IS NOT*.

Not to myself be pedantic, and maybe they aren't being truthful, but in the notes at the bottom of their product page: "Analogue Pocket is not designed using software emulation. It is designed using a specialty hardware chip called an FPGA, which operates on a transistor level implementation of its functionality." Sooooooooo.

I suspect they are massaging the meaning of that statement - an FPGA's behaviour can be defined at the transistor level, but that's contingent on the hardware that it is emulating being reverse engineered down to the transistor. Possible, but unlikely in this case

[orange808]

For those uneducated: FPGA *IS* EMULATION

Since it's not executing the original software or chip functions in software, wouldn't an FPGA implementation be simulation, not emulation?

In practice, the projects I have seen that were labeled as a "simulator" were programs that were intentionally incomplete--for instance, implementing a few key features of an aging legacy NCR terminal system. We rolled the sim out with a new backend, and added some fresh tools to replace some functions of the previous system--with the intention of completely replacing the terminal simulator later and shedding the former ancient terminal system entirely.

[Unseen]

you could implement an FPGA "simulation" at the transistor level of the original hardware for something like the 6502 that has been decapped and 100% mapped

Been there, done that, not 100% accurate =) Loading Wizball for the C64 picture took some patience because I couldn't get any fastloader to work reliably with the 6502-in-FPGA.

I do agree though that software emulation and FPGA-based reimplementation are two distinct approaches that should not be thrown into the same category. A software emulator is always constrained by the operating system and hardware it is running on when it tries to reach "sufficiently" exact timing and latency compared to the original hardware. An FPGA reimplementation has the intended timing designed in from the start.

If any reimplementation is considered emulation there is also the interesting philosophical question if later revisions of some consoles like the 1-chip SNES, the Mega Drive II or the various revisions of the PS1 are just emulators of the original ones.

[orange808]

There are no important gaming CPUs with a true transistor level FPGA implementation out there. It hasn't happened yet. (Although, the 6502 will probably be first. The photographs and research are there.)

AFAIK, the custom chips in the game consoles have not been properly researched and photographed.

Beyond that, we don't have affordable hardware to produce a true transistor level FPGA console.

The research hasn't been done and the hardware isn't affordable.

It's pure marketing.

[fernan1234]

If any reimplementation is considered emulation there is also the interesting philosophical question if later revisions of some consoles like the 1-chip SNES, the Mega Drive II or the various revisions of the PS1 are just emulators of the original ones.

I personally think of these as official clones, belonging in their own separate category from both FPGA-based clones/emulators and "software emulators".

[donluca]

A software emulator is always constrained by the operating system and hardware it is running on when it tries to reach "sufficiently" exact timing and latency compared to the original hardware.

True and that's the only convenience so far because...

An FPGA reimplementation has the intended timing designed in from the start.

...and limited by the FPGA hardware itself (raw power for one) and the quality of the code it is running.

You could have a way better emulator running on PC than one reimplemented on FPGA, it's all in the code.

Byuu made a fantastic post explaining this in exceptional detail back then when the Analogue SNES thing came up, but unfortunately couldn't find it anymore. It seems he deleted it at some point and this is all I could find: https://news.ycombinator.com/item?id=18722258

Unfortunately the google webcache expired.

Beside this, orange808 said everything which needed to be explained, so I won't reply anymore on the matter as I feel the topic has been sufficiently discussed and nothing more needs to be added until further developments.

[strygo]

The software emulation vs. FPGA debate seems somewhat odd to me in this context. In the broader market, nearly every other marketed reproduction device is software based and nearly every other device is flawed in large part due to the software emulation. To me, Analogue has earned the right to differentiate themselves and FPGA and "not emulation" is a reasonable shorthand to communicate the differences to the broader population (especially given their track record). Sure, it's imprecise and marketing-speak, but what they build is different than what else is out there.

To the extent that a jailbreak or the extra FPGA facilitates running some of the non-portable consoles, I'd personally love to see NES/SNES/Genesis running on this device.

[dr_myslihiiri]

Byuu made a fantastic post explaining this in exceptional detail back then when the Analogue SNES thing came up, but unfortunately couldn't find it anymore. It seems he deleted it at some point and this is all I could find: https://news.ycombinator.com/item?id=18722258

Unfortunately the google webcache expired.

Luckily Archive.today still has a working copy of the page.

[donluca]

Finally found byuu's post about FPGA/emulation: http://archive.is/ZxLGP

Props to Nem over at the Arcade Projects forum for the link. A very good read.

[thebigcheese]

Finally found byuu's post about FPGA/emulation: http://archive.is/ZxLGP

Props to Nem over at the Arcade Projects forum for the link. A very good read.

Interesting read, but not without it's own falsehoods.

-"higan currently has zero known emulator bugs..." IIRC, the Digital Foundry analysis of the Super NT pointed out one or two. Maybe they weren't known at the time of the article or have since been fixed, but that's a rather bold claim regardless.

-"...there is absolutely nothing an FPGA can do that cannot be done in software." If I'm not mistaken, one of the main benefits of a hardware-based approach (FPGA) is that it has direct access to the cartridge and can read from it in real time, which is critical for some games. Granted that Higan and the like don't need cartridges at all, so maybe that's a moot point, but technically it's still something a purely software-based approach can't do. He also goes on to talk about input latency and how technically software emulation could match FPGAs but for all practical purposes it can't and probably won't, so, arguably that's another thing that for all intents and purposes FPGAs can do that software can't.

I'm not trying to dis software emulation. I really don't care one way or another. I just don't understand all this butthurt about these FPGA systems when they come out. And when it comes to practical matters, when one is creating a device that is the physical size of a Game Boy Pocket, FPGA is going to be the only practical way (currently) to even approach an accurate representation of the original. So instead of beating a dead horse about how FPGA is still emulation and blah blah blah, maybe we can just evaluate the device for its own merits?

[nem]

Props to Nem over at the Arcade Projects forum for the link.

viewtopic.php?p=1383955#p1383955

Swiped it from here

[orange808]

Finally found byuu's post about FPGA/emulation: http://archive.is/ZxLGP

Props to Nem over at the Arcade Projects forum for the link. A very good read.

Interesting read, but not without it's own falsehoods.

Just like everything else.

-"higan currently has zero known emulator bugs..." IIRC, the Digital Foundry analysis of the Super NT pointed out one or two. Maybe they weren't known at the time of the article or have since been fixed, but that's a rather bold claim regardless.

Yes. Bugs are there. Just like all emulation, it's a clone and it's not real. Just like an FPGA. It's emulation.

Thanks for making my point.

-"...there is absolutely nothing an FPGA can do that cannot be done in software." If I'm not mistaken, one of the main benefits of a hardware-based approach (FPGA) is that it has direct access to the cartridge and can read from it in real time, which is critical for some games. Granted that Higan and the like don't need cartridges at all, so maybe that's a moot point, but technically it's still something a purely software-based approach can't do. He also goes on to talk about input latency and how technically software emulation could match FPGAs but for all practical purposes it can't and probably won't, so, arguably that's another thing that for all intents and purposes FPGAs can do that software can't.

Speaking of inaccuracies, there are cart drives for PC's out there.

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

[

I'm not trying to dis software emulation. I really don't care one way or another.

Sure you are. That's why you posted an unresearched lie about cart readers being impossible on a PC. The very nature of a PC leaves it wide open to building a device like that

You're right about the "you don't know" part

I just don't understand all this butthurt about these FPGA systems when they come out. And when it comes to practical matters, when one is creating a device that is the physical size of a Game Boy Pocket, FPGA is going to be the only practical way (currently) to even approach an accurate representation of the original. So instead of beating a dead horse about how FPGA is still emulation and blah blah blah, maybe we can just evaluate the device for its own merits?

You don't understand is right. The marketing takes things to extremes. It's emulation.

I'm sure this will do a nice job with emulation, but it's still emulation.

I am evaluating it on its merits. The device derives its advantages from emulation.

Looks like it will be the best handheld emulator portable on the market.

[Guspaz]

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.

[orange808]

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.

Fair enough. You can still get the experience of plugging it in and playing.

[Wolf_]

Finally found byuu's post about FPGA/emulation: http://archive.is/ZxLGP

Props to Nem over at the Arcade Projects forum for the link. A very good read.

To address what Byuu wrote:

Fpgas aren't magic:
1) I understand that fpgas are very similar to emulation but coding a chip to physically behave like another chip is different than coding a software layer to run over an operating system. While you could argue that emulation and simulation are synonyms and interchangeable I feel that it is important to distinguish the differences between the two processes (and there are significant differences) and feel that calling fpgas hardware simulation is the clearest way to describe them so they are differentiated from software emulators.

2) He's right that fpgas are not more accurate than emulation simply because they are fpgas, however because emulators run over an operating system and have to work with whatever hardware you have in your computer and an fpga runs directly "on bare metal" as he puts it that means if you perfectly map out a chip you will have a perfect recreation of the way it behaves meanwhile even if an emulator were to do the exact same thing it would still have many other factors in play that would make it slower (8ms by his measurement which doesn't account for controller and display lag on top of that which could add up to multiple frames of variable lag (sometimes 2 frames behind sometimes 3 which makes it impossible to simply adjust to knowing when to respond to things in the game so sometimes you would have to dodge when the enemy raises its sword directly above its head and other times you would have to dodge while the sword was almost above its head and it is random luck when you will have which amount of lag)) or less reliable depending on what hardware or operating system you are running. (To be fair the Super Nt still has to deal with display lag but it doesn't have any lag to simulate the snes or use a real wired snes controller)
tl;dr If a coder perfectly maps a chip it will be a flawless fpga core but a perfectly coded emulator can still have several issues.

3) He literally says that latency is caused by the operating system as one of his points here. So if you use an emulator unless you run it "on bare metal" (which 99.999% of people using emulators won't do) you are ALWAYS going to have variable lag to deal with regardless of how well the emulator is made. He was trying to make the point that fpgas and emulators are similar in how they are made and that is true but he made that point by admitting a critical issue all emulators have regardless of quality that fpgas simply never will have.

4) Yup, Analogue is trying to sell you something and they will make marketing claims. That is what stores do.

5) Yup, there were several bugs in the Super Nt when it came out and they were fixed and I'm sure the same process will happen with the Analogue Pocket.

Forward: (Skipping to the point about limitations)
1) Cost - If you factor in the cost of buying a SD2snes the Super Nt is a steal, let alone the cost of getting native hdmi out of a Super Nintendo... oh wait that doesn't even have a hdmi mod available for it. The same goes for the Analogue Pocket. If you tally up the costs of everdrives (I'm going to assume it gets rom loading in a future jailbreak because every Analogue console has and even if it doesn't it has an open ended fpga you can run your own code on so someone will likely put MiSTer cores on there which will read roms and play systems not even mentioned by Analogue), hdmi mods (for the handhelds that even have hdmi mods), and the handhelds themselves you are instantly spending incredibly more not buying the Analogue Pocket. A pre-installed hdmi modded gba alone without an everdrive costs $350. And in terms of pc cost just having a pc good enough to run his own emulator in run-ahead mode costs almost $2,000.

2) The clock speed has been altered at an imperceptible level to allow it to work on picky tvs and that only really affects speed runners who have two other options to get native clock speed out of the console. If that still isn't good enough it is an open ended fpga so perhaps someone will make it so the MiSTer cores will output at the slightly offspec timings over hdmi if that is a dealbreaker for tons of people.

3) The Super Nt did support color palette swapping and different scaling filters so this statement is inaccurate.

4) I'm pretty sure the jailbreak which was "totally not released by Analogue" supported most special chips eventually. Either way the Analogue Pocket once again has an open ended fpga on it so it could be possible to port the snes MiSTer core over to it which runs all but a single snes effect chip that is only used by a single Japanese only shogi game.

5) The Analogue Pocket can be used as a debugger.

6) This does take up additional space, a power outlet, and a hdmi port assuming you have it docked and plugged in all the time. But that's a price I'm willing to pay.

Emulation:
He's right, Analogue didn't use the very best emulators out there when they pointed out the flaws emulators can have. But given the fact there are literally hundreds if not thousands of different emulators the vast majority of which are abandonware and no longer being maintained I find it doubtful that someone getting into emulation would be able to figure out what the very best emulator was for each system. I find it far more likely that they would end up playing the Beaver Race in Majora's Mask on project64 and wondering why the hell it was unbeatable and maybe less than 1% of people would have the tech knowledge to figure out that the default clock speed of project64 is 1.5x in Majora's Mask and that makes certain timed events impossible to complete even on a perfect run where you hit 0 obstacles. (True story, happened to me. There was a fire, things broke, people died, ruined my day)

Latency:
He says that fpgas are not magic (this should be obvious) and that they beat emulators in latency hands down and even says to use fpgas if you care about the 8ms of latency the better emulators have. And once again while 8ms might not be much the issue is that it is variable and sometimes it could be 8ms and sometimes it could be 30ms and that is not even the fault of the emulator but the operating system you run the emulator on and nothing the emulator developers can do will change that unless you boot directly into an emulator with no operating system.

Preservation:
Here he claims that when the Super Nt goes out of production and eventually the last one stops working all of the code will be lost forever because it isn't open source. And that assumes that 50 years from now Analogue as a company won't release it to the public or that Analogue will even exist in 50 years. Point being just because it is closed source now doesn't mean it won't become open source in the future. Not to mention by then whatever encryption is on the code could probably easily be broken so one way or another I'm sure code with tens, possibly hundreds of thousands of downloads will live on.

Closing:
While the Super Nt is in the same top tier of accuracy as Higan the fact is it performs better for all the reasons Byuu himself stated like not having to deal with an operating system.

Byuu is once again right about fpgas in general not being born perfect and ideal but Analogue is not lying about the quality of their product either... now their shipping on the other hand...

[orange808]

Even if you did faithfully map a console onto theoretical FPGA hardware using your chosen favorite ecosystem, the pure transistor level mapping of your console wouldn't behave like real hardware.

We all get that, right?

Because, we are simulating the gates. We have a layer there. The simulation is only as good as the FPGA's ability to behave like real hardware--and that's incomplete. We need hacks.

Furthermore, you can code an FPGA in C.

Is Kevtris writing all these emus from scratch? That's a lot of emus.

Seems like there are plenty of emus out there to use as basis for development and they are written in C.

Hmm...

...

...

Seems like an awful lot of very high quality emus for one person to write from scratch.

...

[tomwhite2004]

To address what Byuu wrote:

yeah yeah, we know....

viewtopic.php?f=6&t=61037&p=1300605#p1300605

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

This made picking through all the options out there a complete minefield. Quality Control absolutely did not exist and coding inaccurately just to make it "good enough" became the norm. With regards to preservation and reproduction, that does more damage than good.

I think those that are opposed to the "FPGA is not emulation" stance are those who don't want to see the same mistakes that were made with software emulation repeated on the hardware simulation front. E.g. let's do it right and proper from the beginning so we're not cleaning messes up at the end. FPGAs ultimately will allow for the most accuracy at a level requiring the least end-user investment than software emulation can. Let's not ruin it.

[donluca]

Even if you did faithfully map a console onto theoretical FPGA hardware using your chosen favorite ecosystem, the pure transistor level mapping of your console wouldn't behave like real hardware.

We all get that, right?

Although I do agree with everything you wrote so far, I'm gonna stop you right here.

There's a line we draw where we can say "enough".
When you get an FPGA which is perfectly mapped to match the system it's reproducing, the outcome will be the same minus some picoseconds of inaccuracies due to the speed at which electricity flows into the various components (and still, we could just generalize this infinitely small amount and emulate it to close this argument as well) and, besides, that would be absolutely undetectable by human eyes due to how "slow" we are.

When we get differences down to the speed of electrons flowing through circuits, that's honestly enough.

Seems like an awful lot of very high quality emus for one person to write from scratch.

As I said elsewhere, he just got the sourcecode of the best emus out there and translated it into verilog/hdl/whatever and put that into the FPGA, just like he did with the Super NT and higan.

EDIT: apologies to dr_myslihiiri, I somehow completely missed his post.

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

[orange808]

Even if you did faithfully map a console onto theoretical FPGA hardware using your chosen favorite ecosystem, the pure transistor level mapping of your console wouldn't behave like real hardware.

We all get that, right?

Although I do agree with everything you wrote so far, I'm gonna stop you right here.

There's a line we draw where we can say "enough".
When you get an FPGA which is perfectly mapped to match the system it's reproducing, the outcome will be the same minus some picoseconds of inaccuracies due to the speed at which electricity flows into the various components (and still, we could just generalize this infinitely small amount and emulate it to close this argument as well) and, besides, that would be absolutely undetectable by human eyes due to how "slow" we are.

When we get differences down to the speed of electrons flowing through circuits, that's honestly enough.

Seems like an awful lot of very high quality emus for one person to write from scratch.

As I said elsewhere, he just got the sourcecode of the best emus out there and translated it into verilog/hdl/whatever and put that into the FPGA, just like he did with the Super NT and higan.

EDIT: apologies to dr_myslihiiri, I somehow completely missed his post.

Latches and flip flops? You sure that's gonna work out for me?

Also:
Translated to his chosen platform? Maybe. Maybe not. Truthfully, you can stick with C.

[Wolf_]

To address what Byuu wrote:

yeah yeah, we know....

viewtopic.php?f=6&t=61037&p=1300605#p1300605

Actually that was addressing what he initially wrote about the Super Nt. 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.