One of MVG’s issues is that N64 emulation just doesn’t cut it on portables like Anbernic devices.
And also that cores like those used in Mister or Analogues FPGA don’t cut it - they can start commercial games but can’t do homebrew software (which does work on 64 hardware). So again, have been built to target individual games microcode and not emulate the N64.
He’s definitely lamenting that it’s unlikely we’re going to see improvement in this space due to how much this emulation relies on HLE, but if 64 emu devs can get properly into LLE like PS1 and PS2 emulation did, then it can start to get better.
Decompilation is a solution of course. Those decompiled games can even be run as ports on portable devices (using software like Portmaster), but decompilations are few and far between.
That’s a problem with the current state of emulators, yes, but what are the technical barriers to implementing proper low-level emulation, including handling microcode as mentioned earlier? Imagine that I’m asking this as an embedded systems engineer.
It’s probably worth looking at what Ares is doing with N64 emulation in this case.
Ares aims for accurate emulation (as an overall project goal) and I understand their N64 emu is pretty good. So if there is as lesson to be learned it may be there.
As a hobbyist who’s profession is well outside of tech, this is about as good as you can get from me !
I’ve recently just dipped my toes into emulation, and spent a month writing a decent NES emulator from scratch (we’ll see how well it performs on a ULP ARM core, but I’m optimistic), so I’m starting to think about how far I can push the envelope.
I’d love to make something highly portable that could run N64 games alongside other retro consoles, so just buying old hardware wouldn’t quite cut it.
One of MVG’s issues is that N64 emulation just doesn’t cut it on portables like Anbernic devices.
And also that cores like those used in Mister or Analogues FPGA don’t cut it - they can start commercial games but can’t do homebrew software (which does work on 64 hardware). So again, have been built to target individual games microcode and not emulate the N64.
He’s definitely lamenting that it’s unlikely we’re going to see improvement in this space due to how much this emulation relies on HLE, but if 64 emu devs can get properly into LLE like PS1 and PS2 emulation did, then it can start to get better.
Decompilation is a solution of course. Those decompiled games can even be run as ports on portable devices (using software like Portmaster), but decompilations are few and far between.
That’s a problem with the current state of emulators, yes, but what are the technical barriers to implementing proper low-level emulation, including handling microcode as mentioned earlier? Imagine that I’m asking this as an embedded systems engineer.
It’s probably worth looking at what Ares is doing with N64 emulation in this case.
Ares aims for accurate emulation (as an overall project goal) and I understand their N64 emu is pretty good. So if there is as lesson to be learned it may be there.
As a hobbyist who’s profession is well outside of tech, this is about as good as you can get from me !
Thanks for the tip, I’ll take a look.
I’ve recently just dipped my toes into emulation, and spent a month writing a decent NES emulator from scratch (we’ll see how well it performs on a ULP ARM core, but I’m optimistic), so I’m starting to think about how far I can push the envelope.