Mednafen

[Enverex]

Kinda limited what I can do without a Pandora but I've been scouting out for possible software that should work, another that came up was Mednafen. Basically it's a Atari Lynx, GameBoy (Color), GameBoy Advance, NES, PC Engine(TurboGrafx 16), SuperGrafx, Neo Geo Pocket (Color), PC-FX, and WonderSwan (Color) emulator. It works on ARM as it's already in the Debian ARM repo (http://packages.debian.org/search?suite=default&section=all&arch=arm&searchon=names&keywords=mednafen).

How much work would a package need done on it to work from a .deb (to then be installed on a Pandora and work)? (I know that's a horribly generalistic question but assuming it's not too picky about libraries in place...).

Seems like it may fill in some more emulator gaps and would be interesting to test performance wise (although only the GBA on that would really act as a benchmark I'd imagine, the rest should fly anyway).

Source is here - http://mednafen.sourceforge.net/

Although the "OpenGL" issue is something that I can see being a problem as it's expecting OpenGL, not OpenGL ES. Is there any likelyhood that there will be some form of general translation layer in place so that OpenGL applications can -try- and run on the Pandora without any actual code conversion prior to compilation? (Pretty much the same way Wine does Windows OpenGL >> Linux OpenGL translation, although that's mainly pass-through, there are undoubtedly some things that have to be modified).

Just a few thoughts anyway.

 

[dflemstr]

I don't actually know if it's going to be possible to install DEBs on the Pandora... Even though the devs have said so in the past, the system currently in place indicates that this will not be the case.

Also, nanoGL should be possible to use for GL → GLES translation, but I don't know which status quo it has (Google it or something).

BTW, many of the systems mentioned already have working emulators on the Pandora, so no need to port a new one for those systems.

 

[Enverex]

I don't actually know if it's going to be possible to install DEBs on the Pandora... Even though the devs have said so in the past, the system currently in place indicates that this will not be the case.

Also, nanoGL should be possible to use for GL → GLES translation, but I don't know which status quo it has (Google it or something).

BTW, many of the systems mentioned already have working emulators on the Pandora, so no need to port a new one for those systems.

Yeah, the Deb thing did make me wonder if it would be possible due to how it works.

The thought of another emulator was just mainly for curiosity; comparing speeds, some games may run better (or games may run that didn't before) and lastly to fill in gaps if any of those systems weren't yet emulated (or emulated well).

So say you have an app that you want to install/run on the Pandora, how would you do it? (as you're avoiding writing to /) How will the applications or libraries actually be found?

 

[dflemstr]

So say you have an app that you want to install/run on the Pandora, how would you do it? (as you're avoiding writing to /) How will the applications or libraries actually be found?

Look at pandora-libraries; basically, PND packages contain the apps you want to deploy, and you simply put them in a folder, whereafter the PND discovery daemon finds them and mounts them in an overlay kind of fashion. It's not really clear how this will work, or if it will be possible to create any kind of app using this system (for example, how would you create a PND for screensavers if you can't modify /usr/bin etc? PND packages can't change the system but must instead use only it's contents directly during operation.)

 

[Vorporeal]

It's always possible that PNDs could unpack to a UnionFS/tmpfs (combo?) partition at boot, and could overlay themselves on top of the base NAND file system.

 

[dflemstr]

It's always possible that PNDs could unpack to a UnionFS/tmpfs (combo?) partition at boot, and could overlay themselves on top of the base NAND file system.

tmpfs would be kinda bad, since you never know how big PNDs can be.
But yeah there have been plans to use unionfs, but no one has found a sustainable solution yet. I'll let skeezix handle that, however; my low-level PND days are over I think (and they didn't last long, I tell you ).

What I think would be nice is that you'd have 1 folder inside of the PND (say, "overlay/") that can contain symlinks to files elsewhere in the PND (and only symlinks, nothing else), so that when the PND gets mounted, the PND discoverer takes all of the symlinks in the overlay folder, puts them either directly on the NAND itself (the NAND writes are not so limited that we can't afford to write 20-byte files) and resolves the symlinks to point to the location where the PND is mounted.
If we were to use an UnionFS, that main unionfs would be overlain over the NAND, and not SD-cards, combined with a RAM-disk overlay, and all of the symlinks would be created in the overlay (of course also with checks that files don't already exist etc)
So, let's say that you have a PND like this:

foo.pnd/
|-- libfoo.so
|-- myfile.png
`-- overlay/
    `-- usr
        `-- lib
            `-- libfoo.so -> /libfoo.so #In the PND, the "/" dir means the root dir of the PND since it's isofs

...and it becomes this when mounted:

/
|-- mnt/
|   `-- pnd019283/
|       |-- myfile.png
|       `-- libfoo.so
`-- usr
    `-- lib
        `-- libfoo.so -> /mnt/pnd019283/libfoo.so

That way you'd only ever need one unionfs, or alternatively none at all, and you could mount it on boot and add/remove symlinks from it when needed. The pnd daemon would keep track of deployed symlinks and, if it discovers that a PND has been unmounted, it removes all symlinks related to that PND. This system follows the standard "hooks" paradigm.

Oh well, I digress.

 

[Exophase]

Seems like it may fill in some more emulator gaps and would be interesting to test performance wise (although only the GBA on that would really act as a benchmark I'd imagine, the rest should fly anyway).

Most of the emulators in Mednafen are compiled from other emulators, and for most of these we have someone on board already willing to port. Much of what Mednafen emulates may run fine, but it'd be good to have more ARM optimized standalone emulators as well for better battery consumption.

The GBA emulation is using VBA and won't run well (Pickle confirmed that VBA doesn't perform well on Pandora, even overclocked).

The PC-FX emulation will also definitely not run well, the requirements are much higher than Pandora can muster.

Mednafen doesn't use OpenGL for anything outside of video resizing, which I'm sure will be pretty easy to adapt to ES. I don't even think OpenGL support is mandatory to compile the emulator; as far as I'm aware you can leave these scalers out.