Solved No success with Nintendo emulators ports

I have tried to run different emulators on FreeBSD-Current (v. 14), and they all resulted in black screen while playing.
So I switched from i915kms to scfb, but that did not fixed anything.
I then tried to use a Python one with "pip install nes-py"... but anyway it never tried to install the nes emulator in python, because it was cycling installing a dependency, having an error, undoing change and redoing the same again.

So I tried in an other OS, where mesen did work very well with the two nes file (rom files for games... and I realize it is a bit a delicate subject).

So at this stage I begin to have a bad feeling for FreeBSD (except for having a lot of opportunities for improvement!).

The ports I have tried was among: mesen, nestopia, tuxnes, anesse, darcnes.

Sometimes, stopping the game would produce screenshots, but while playing, only a black screen with sometimes a lot of fps.
I must remember badly... I just can't believe they were all doing black screen. (Well I remember one was generating bad opcode (Nintendo CPU) errors... most of the time I had to ps, and then kill the emulator process)

I wonder if someone else have success with one particular emulators.
 
Hello,
I have tried to run different emulators on FreeBSD-Current (v. 14)

 
In the past I've ran NES Final Fantasy ROMS on FreeBSD with an emulator and it worked well. I'm not sure which one it was but I don't like installing Wine. I have all them all on PS2 disks though and prefer console gaming if I'm going to play.

One of my favorites, Disgaea: Afternoon of Darkness what I played last at over 1000 hours in, renamed for the PS2 from Hour of Darkness.

I'm your Demon Price, Hero, and Heir to King of the Under World, with a sexy Demon girl my bestie and an Angel who tags along as we slaughter our enemies in strategy-based warfare tiled battlefields.
 
Try games/retroarch, it's pretty much a frontend for emulators (it's more than that, but let's keep things simple). Retroarch needs "cores", in other words, the emulators itself (without all the fuzz of configurations, retroarch maintain a central point of configurations, so it's pretty much one rule for controller, retroachievements, etc for all cores). So for NES you have the following libretro cores: games/libretro-fceumm, games/libretro-nestopia and games/libretro-quickness. Try and see what is better for you.
Why more than one possible nes core you may ask. Well.. most emulators have different issues running things, some run one specific game better than others (specially if we throw other ARCHs to the table), Super Nintendo is a good example of console that there's no emulator that run everything perfect (no, bsnes doesn't do that, his accuracy is awesome but isn't 100%).
 
hum, well, for me (14.0 Current) retroarch does not compile from source:
Code:
/usr/ports/graphics/vulkan-loader/work/Vulkan-Loader-1.2.184/loader/generated/vk_layer_dispatch_table.h:837:5: error: unknown type name 'PFN_vkGetMemor                yRemoteAddressNV'                                                                                                                                                  
    PFN_vkGetMemoryRemoteAddressNV GetMemoryRemoteAddressNV;
    ^
1 error generated.

But installing the package and running the game with libretro-fceumm seems to work... until I tried to select a class of hero for my team... Enter does not work, nor any other keys I have tried. (I guess default is using a controller)

Using libretro-mesen as Core, and using Z key to select, I am able to play my game... Thank you!
A bit weird things works so well within retroarch... but not directly.
 
retroarch and bsnes (now higan) make the classic mistake of putting all their eggs in one basket and becoming a "multi-system" emulator. This ends up becoming too large to maintain and once the core breaks, you lose *every* system.

Unfortunately I only really spend much time with the mega drive (we have a very strong and simple emulators/dgen-sdl port).

You might have some success at compiling nestopia: http://nestopia.sourceforge.net/
One of our other members has forked and ported it to FreeBSD: https://forums.freebsd.org/threads/nestopia-nes-emulator.32062/#post-202808
 
retroarch and bsnes (now higan) make the classic mistake of putting all their eggs in one basket and becoming a "multi-system" emulator. This ends up becoming too large to maintain and once the core breaks, you lose *every* system.

Unfortunately I only really spend much time with the mega drive (we have a very strong and simple emulators/dgen-sdl port).

You might have some success at compiling nestopia: http://nestopia.sourceforge.net/
One of our other members has forked and ported it to FreeBSD: https://forums.freebsd.org/threads/nestopia-nes-emulator.32062/#post-202808
Retroarch isn't exactly a multi-system emulator, it depends on cores, you can have retroarch and a single core installed, even so, you can maintain a single core and not maintain retroarch itself (that's was happening with libretro and also in ports maintenance for freebsd). Using nestopia as a good example, the core for nestopia is exactly the same code of nestopia standalone emulator, the only difference is a directory with some files that will make it possible to use with retroarch (configuring controllers and such), the main code's still maintained by nestopia developers.

Also if a core breaks, it will never break the entire retroarch. You can even reinstall the single core or recompile this single core or doesn't use it at all.
 
Also if a core breaks, it will never break the entire retroarch. You can even reinstall the single core or recompile this single core or doesn't use it at all.
To an extent. But if the main retroarch system breaks, you lose access to *all* cores.

Looking at the code here: The main retroarch frontend is non-trivial and very heavy: https://github.com/libretro/RetroArch

One positive however is that there are a few frontends. There is a light one here (albeit written in Go which is annoying): https://ludo.libretro.com/
There used to be a tiny SDL one but I think it was abandoned.
 
To an extent. But if the main retroarch system breaks, you lose access to *all* cores.
I've never seen this happen and I've used it since very old versions.
And if it breaks for some reason, you can recompile yourself or use an older version, like many times this happening in many different operating systems and even on FreeBSD.
Looking at the code here: The main retroarch frontend is non-trivial and very heavy
it's just impossible to have all the features with a tiny code, unless you make huge sacrifices, as ludo.
You can also use kodi, or create one without the configuration options (which will kill the purpose). The libretro "connector" is really tiny.
Not to mention, it's way easier to port a core to another operating system than anything else, since the requirements and dependencies of a libretro core rarely needs something more (there's such cases like dolphin, citra, and probably others, of course).
Even so, retroarch usually offers more features to those emulators than the emulators itself, like using any controller supported by retroarch (not all emulators supports sdl or udev or whatever, if retroarch have the support (and of course the OS), all the cores will have it), retroachievements, live patching roms, and the list goes on.
Also, define "very heavy". Retroarch can run on the first version of Raspberry Pi and emulates everything this Raspberry Pi can emulate.
 
I'd have to ask about the base metal specs that OP is using... if OP is using something recent like Ryzen 5 (Not all Ryzen 3 generations even support virtualization... and even not all core i5, either). It also helps to enable specific instruction sets (like VT-x) in the BIOS of the base metal device. Once the base metal has adequate specs and proper config, then OP can worry about running an emulator.
 
define "very heavy". Retroarch can run on the first version of Raspberry Pi and emulates everything this Raspberry Pi can emulate.
Heavy in terms of size, dependencies and complexity (and that is before you even get to the cores plugin system). Compare the code to something like dgen-sdl (or even dosbox). That codebase is easily maintainable. RetroArch not so much. Its port Makefile is very complex in comparison.

If I was tasked to port an emulator to a new platform RetroArch would not be my first choice due to its size. This obviously becomes more of an issue if you move away from common platforms and architectures.
 
  • Like
Reactions: JAW
Heavy in terms of size, dependencies and complexity (and that is before you even get to the cores plugin system). Compare the code to something like dgen-sdl (or even dosbox). That codebase is easily maintainable. RetroArch not so much. Its port Makefile is very complex in comparison.

If I was tasked to port an emulator to a new platform RetroArch would not be my first choice due to its size. This obviously becomes more of an issue if you move away from common platforms and architectures.
The Makefile is complex because it gives you several choices, you can build with just make if you want, and you're comparing with dgen-sdl that it's just sdl with retroarch that have several options for different scenarios, which is good, it's like comparing netcat to links.
 
I'd have to ask about the base metal specs that OP is using... if OP is using something recent like Ryzen 5 (Not all Ryzen 3 generations even support virtualization... and even not all core i5, either). It also helps to enable specific instruction sets (like VT-x) in the BIOS of the base metal device. Once the base metal has adequate specs and proper config, then OP can worry about running an emulator.
OriginalPoster have an i3-8100 with virtualization set in BIOS, with 8 GiB memory. Although I was not really realizing (still have doubts) that most NES emulators would use VT-x. Mostly doubting VT-x can be used for very different CPU.
Code:
VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
 
Although I was not really realizing (still have doubts) that most NES emulators would use VT-x.
Yeah, that stuff only helps with virtualizing the same architecture.
That said, an i3 will be more than enough for most "retro" consoles. Both JITed or fully interpreted.
 
Back
Top