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.orange808 wrote:'Scuse me?Jdurg wrote: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.
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.
FPGA discussion split from Analogue Pocket thread
Re: Analogue Pocket (FPGA GB/GBC/GBA/NGP/LYNX)
-
bobrocks95
- Posts: 3477
- Joined: Mon Apr 30, 2012 2:27 am
- Location: Kentucky
Re: Analogue Pocket (FPGA GB/GBC/GBA/NGP/LYNX)
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).
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).
PS1 Disc-Based Game ID BIOS patch for MemCard Pro and SD2PSX automatic VMC switching.
Re: Analogue Pocket (FPGA GB/GBC/GBA/NGP/LYNX)
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 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.
Last edited by Guspaz on Fri Oct 18, 2019 5:37 pm, edited 1 time in total.
Re: Analogue Pocket (FPGA GB/GBC/GBA/NGP/LYNX)
Nesticle.Jdurg wrote: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.orange808 wrote:'Scuse me?Jdurg wrote: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.
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.
You did exactly what I said you did.
Don't ever quote me again.
Last edited by orange808 on Fri Oct 18, 2019 6:20 pm, edited 1 time in total.
We apologise for the inconvenience
Re: Analogue Pocket (FPGA GB/GBC/GBA/NGP/LYNX)
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.Guspaz wrote: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.
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.
We apologise for the inconvenience
Re: Analogue Pocket (FPGA GB/GBC/GBA/NGP/LYNX)
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.
He's doing this stuff from scratch, not porting or deriving from C code.
Re: Analogue Pocket (FPGA GB/GBC/GBA/NGP/LYNX)
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.orange808 wrote:Truthfully, you can stick with C.
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.
-
- Posts: 707
- Joined: Sun Aug 21, 2016 5:18 pm
Re: Analogue Pocket (FPGA GB/GBC/GBA/NGP/LYNX)
Thank you, that was... literally the point I had made, if they had bothered to read it. Too busy proselytizing.Guspaz wrote: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.
Re: Analogue Pocket (FPGA GB/GBC/GBA/NGP/LYNX)
Wow, much off-topic. Must continue:
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.
Isn't BSNES runahead same as RetroArch runahead, meaning it's to eliminate software lag, which is only possible for software that has lag?orange808 wrote:Also, byuu has run ahead in BSNES and we can effectively match real hardware on our PC right now. So, you know, inaccurate again.
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.
Re: Analogue Pocket (FPGA GB/GBC/GBA/NGP/LYNX)
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.Wolf_ wrote: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.
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.
Re: Analogue Pocket (FPGA GB/GBC/GBA/NGP/LYNX)
I can't confirm or deny how it's getting done.Guspaz wrote: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.
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.
We apologise for the inconvenience
Re: Analogue Pocket (FPGA GB/GBC/GBA/NGP/LYNX)
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.
Re: Analogue Pocket (FPGA GB/GBC/GBA/NGP/LYNX)
Sure, you need a powerful gaming PC to get the best emu experience. That's always been true.ZellSF wrote:Wow, much off-topic. Must continue:Isn't BSNES runahead same as RetroArch runahead, meaning it's to eliminate software lag, which is only possible for software that has lag?orange808 wrote:Also, byuu has run ahead in BSNES and we can effectively match real hardware on our PC right now. So, you know, inaccurate again.
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.
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.
We apologise for the inconvenience
Re: Analogue Pocket (FPGA GB/GBC/GBA/NGP/LYNX)
The Lynx is also new!Guspaz wrote: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.
Re: Analogue Pocket (FPGA GB/GBC/GBA/NGP/LYNX)
I never implied a thing. I did say I haven't seen the source code and I have no idea how it was done.Guspaz wrote: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.
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.
Last edited by orange808 on Fri Oct 18, 2019 6:04 pm, edited 1 time in total.
We apologise for the inconvenience
Re: Analogue Pocket (FPGA GB/GBC/GBA/NGP/LYNX)
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?donluca wrote: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.Wolf_ wrote: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.
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.
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.
Re: Analogue Pocket (FPGA GB/GBC/GBA/NGP/LYNX)
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:orange808 wrote:Sure, you need a powerful gaming PC to get the best emu experience. That's always been true.ZellSF wrote:Wow, much off-topic. Must continue:Isn't BSNES runahead same as RetroArch runahead, meaning it's to eliminate software lag, which is only possible for software that has lag?orange808 wrote:Also, byuu has run ahead in BSNES and we can effectively match real hardware on our PC right now. So, you know, inaccurate again.
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.
And yes I read this:byuu wrote: A software emulator can reasonably expect to get within 30-50ms of the latency of a pure hardware approach.
Though I'm pretty sure no one's verified this yet.byuu wrote: The best software emulators claim to reach within 8ms of real hardware latency
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:
I don't think merely a 1 frame difference is enough to make him say that.byuu wrote:But indeed, if latency is your primary concern, I concede that FPGA devices are currently the way to go
Re: Analogue Pocket (FPGA GB/GBC/GBA/NGP/LYNX)
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.Guspaz wrote: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 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.
Re: Analogue Pocket (FPGA GB/GBC/GBA/NGP/LYNX)
@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 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.
We apologise for the inconvenience
Re: Analogue Pocket (FPGA GB/GBC/GBA/NGP/LYNX)
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.orange808 wrote: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.
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.
GCVideo releases: https://github.com/ikorb/gcvideo/releases
Re: Analogue Pocket (FPGA GB/GBC/GBA/NGP/LYNX)
Oh yes. I absolutely have not used an FPGA. I'm a dinosaur.Unseen wrote: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.orange808 wrote: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.
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.
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.
We apologise for the inconvenience
Re: Analogue Pocket (FPGA GB/GBC/GBA/NGP/LYNX)
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.
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.
Strikers1945guy wrote:"Do we....eat chicken balls?!"
Re: Analogue Pocket (FPGA GB/GBC/GBA/NGP/LYNX)
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.orange808 wrote: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.
Re: Analogue Pocket (FPGA GB/GBC/GBA/NGP/LYNX)
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:orange808 wrote:@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.
Is bullshit.orange808 wrote:Also, byuu has run ahead in BSNES and we can effectively match real hardware on our PC right now.
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.
Re: FPGA discussion split from Analogue Pocket thread
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:Wolf_ wrote: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?
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.
Re: Analogue Pocket (FPGA GB/GBC/GBA/NGP/LYNX)
RetroRGB has camera tests up right now.ZellSF wrote: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:orange808 wrote:@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.Is bullshit.orange808 wrote:Also, byuu has run ahead in BSNES and we can effectively match real hardware on our PC right now.
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.
Pretty close. In fact, maybe a little too little lag.
Google it.
We apologise for the inconvenience
Re: Analogue Pocket (FPGA GB/GBC/GBA/NGP/LYNX)
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.orange808 wrote:RetroRGB has camera tests up right now.ZellSF wrote: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:orange808 wrote:@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.Is bullshit.orange808 wrote:Also, byuu has run ahead in BSNES and we can effectively match real hardware on our PC right now.
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.
Pretty close. In fact, maybe a little too little lag.
Google it.
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
Re: Analogue Pocket (FPGA GB/GBC/GBA/NGP/LYNX)
Just wanted to quote you for others.ZellSF wrote: 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
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.
We apologise for the inconvenience
Re: Analogue Pocket (FPGA GB/GBC/GBA/NGP/LYNX)
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.orange808 wrote:The article actually has results that are below real hardware baseline measurements.
I did, but I'm not as bad at it as you are.orange808 wrote:I think you skim read.
Re: Analogue Pocket (FPGA GB/GBC/GBA/NGP/LYNX)
I'm sorry RetroRGB wrote an "absurd" article. (Not really. But, we'll agree to disagree.)ZellSF wrote: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.orange808 wrote:The article actually has results that are below real hardware baseline measurements.I did, but I'm not as bad at it as you are.orange808 wrote:I think you skim read.
FPGA is still emulation.
We apologise for the inconvenience