What is the current state of cycle-accurate emulation? It seems like Blastem's on its way to becoming a KINO emulator.
What is the current state of cycle-accurate emulation?
What is the current state of cycle-accurate emulation? It seems like Blastem's on its way to becoming a KINO emulator.
Agreed. Blastem will have high quality cinema
Not only that, but Desert Bus finally works. (Which is a HUGE bonus.)
It's it supports only the base console, no 32x, no CD, no SMS?
I think it's supposed to support every platform. (32x seems to be a major roadblock atm.)
Try looking into the latest nightly builds, since they're far more up-to-date than the latest stable build.
Show one difference between Gens Plus GX and this
It can run Overdrive 2 properly.
Fair enough. How about games?
It's able to make use of extremely obscure peripherals that no other emulator implemented yet. (Outback Joey is a prime example.)
>fighting over software emulators
why are emukiddies like this
Probably because they don't use Emulation General Wiki on a constant basis?
>KINO emulator
So, it emulates movies? I don't understand. Why do you always type all fricked up?
Nah, you're thinking of Kino Lorber. When I say "kino", it means that I think it's "hella fricking dope, yo."
No, that means movie. Stop huffing paint.
Lol, my bad. What describes a good vidya?
Kino does (as well as anything else). Ignore that autistic newhomosexual.
>Nah, you're thinking of Kino Lorber. When I say "kino", it means that I think it's "hella fricking dope, yo."
Christ could this board get any more fricking gay
>operating system adding its own interrupts and latency in fricking things up in the background in other ways.
Stop being a moronic boomer.
Why do people care about cycle accurate emulation when they could never actually tell the difference even side-by-side examining the most minute detail?
Mainly so I can have a reliable way of doing nerdy tech stuff. (Without having to come across weird fricky stuff happening in real HW.)
Because of gnosis
The more accurate the emulation, the less likely there is to be a bug. Just drop a ROM in and get as close to the intended experience as modern hardware can allow.
It's usually the opposite actually. Some really obscure bugs require very accurate emulation. Pretty much none of the main emulators out there today (mesen, Snes9x, Genesis Plus GX, Beetle Saturn, Duckstation, etc.) are having any emulation bugs outside of maybe a couple titles out of thousands.
I can think of many reasons.
There's the theory of perfect emulation and implementation can mean most efficient and performant (at least for full coverage scenarios).
A lot of people care about input latency, whilst there will always be a degree of that in software emulation it's about how much you can minimise it. Ideally, playing on a cycle accurate emulator should *feel* identical to playing on real hardware (assuming no enhancements are applied)
Perfecting software emulation also better informs development of FPGA based hardware emulation.
Developers will need a perfectly reliable emulator so that any homebrew or ROM hacks they develop will work correctly on real hardware.
Cycle accurate also ensures that TAS recordings produced on an emulator should playback identically on real hardware. This is known as console verified TAS runs.
Cycle accuracy also means covering all of the edge cases that haven't been discovered in retail releases, especially since libraries are huge and full of games people just aren't interested in playing. This is valuable in preservationist efforts as there will come times when original hardware is inaccessible or no longer functional or serviceable.
Modern emulators are written in ways that they can run on multiple different processor architectures and operating systems, so we're not limiting the work completed to modern-day systems either.
There could be a future where nobody uses x64/x86 processors in desktop and laptop computers, for example. Apple are pushing this hard with their ARM processors, and Microsoft are taking notice.
i'm programming software for megadrive. emulators that aren't cycle accurate make software development much harder, especially when tracking down bugs. what looks fine in some old shitty emulator might look terrible on a real system or cycle accurate emulator.
>Developers will need a perfectly reliable emulator so that any homebrew or ROM hacks they develop will work correctly on real hardware.
yep. there's no shortage of hacked roms out there created by children with hex editors that don't even work properly or crash on real hardware because they were using some 25 year old emulator to test with.
What are you doing that requires perfect cycle accuracy? Some kind of fancy tech demo with raster effects?
NTA, but mostly yes. Demo4Life.
Hell, a lot of ROM hacks for SNES games were built around the capabilities of ZSNES, which is far removed from hardware accuracy and does things that are impossible on real hardware.
Many SNES emulators include a optional ZSNES-like setting specifically because of this bullshit.
You can't get cycle-accurate emulation on any CPU that doesn't run at the same exact cycle rate as the original hardware, and CERTAINLY not when you have operating system adding its own interrupts and latency in fricking things up in the background in other ways.
Does this mean FPGA is the answer?
Yes, the MegaDrive emulator on MiSter is made entirely from decapped chip information at a transistor level, so accurate you could use it to make new chips, plug them into real hardware and it would work.
I've heard Nuked does FANTASTIC work, so I'll give that core a try. (That is, if I have the money to get an FPGA kit.)
dunning kruger post
I'm not sure if I lean towards one way or the other. To be honest, I find all aspects of emulation to be quite fascinating.
They aren't wrong though.
I appreciate you and the other anon's critique.
FPGA is the future.
You're opening a can of shit, buddy
you have 10 seconds to name 1 difference between emulation and cycle-accurate emulation
The cycle-accurate emulator is free. What are you so insecure about?
can't do it, huh? I accept your concession
It’s okay if somebody uses something different from you. You’re h*cking cute and valid, anon.
>20 minutes
>unable to come up with an answer despite frantic googling
>anon has completely disappeared
I could answer that but first I would have to explain what an oscilloscope is
emulators won't be truly accurate until they do things on a transistor level. iirc the only such emulator is for the C64.
>emulators won't be truly accurate until they do things on a transistor level.
that's what fpga is for
> iirc the only such emulator is for the C64.
false
Isn't there a software version of Nuked-MD? (It's slow as shit, though.)
Yeah I think you can compile a software version but it's pretty pointless considering it's unplayably slow.
Perhaps the code could be interpreted via LLE. I've recently found out that there's a LLE 2612 core in the works based of Nuked's previous work.
https://github.com/nukeykt/YM2608-LLE