en able to do and how we've tried to make hacking around with the Pandora's Box 6 a bit easier to deal with.
For those of you who have been following, you're likely aware by now that there is a script that is responsible for setting up the Pandora's Box initially. /usr/myinit sets up some default paths and runs /usr/emu/emulotar. Emulotar is an application that sets up the /tmp ramdisk and extracts files from some secret vault in the SD card's unallocated space. The exact method and sectors of the disk that it takes these files from are still currently unknown. Once everything is set up, it extracts app to /tmp and runs app. App appears to be a combination of the Final Burn Alpha emulator and a QT v3 based emulator frontend. There are a total of 8 "apps" that the Pandora's Box uses, numbered app1 through app8. Each of them are a combination of an emulator and the emulator frontend in one executable. The odd man out here is app8, which appears to be a PCSX ReARMed, version r22. (I had previously speculated blindly that the PS1 emulator would be PCSX ReARMed, purely because it's the only PS1 emulator that can run as well as it does on hardware so limited.) However, this PCSX ReARMed version does not have any of the QT frontend embedded in it. app8 is the only copy of PCSX ReARMed that we found, whereas the others are either MAME or FBA with the frontend embedded with it.
A listing of the various apps as embedded in emulotar:
My current theory for the various apps is that there are versions of MAME and FBA that have image optimization permanently turned on and others that have it turned off and it decides which version to use based on the image optimization setting. I also noticed that regardless of image optimization being turned on, PlayStation 1 games always run unfiltered, so it makes sense within that context that there is only one PCSX ReARMed app to be found. When you run a specific game from the frontend, it will replace /tmp/app with the proper app for the game you have selected and the image optimization setting and then run the game. When you quit the game and go back to the menu, you're still within the same app. It's only when you pick a game that has a different emulator needed that it replaces app with a fresh copy matching what you've picked and then launches. We are currently unsure how the frontend is communicating with the app to inform it what game was selected at this point as it does not appear to be passed through the command line. We know this because of some of the data gathering we've been able to do.
One of the things that is a big pain in the ass up to this point is that any changes we've wanted to make need to be made to an SD card that needs to be pulled out of the Pandora's Box and replaced again and again. The SD card holder is rather flimsy and annoying. I decided to try to fis this by editing myinit to have it call a script that is stored on my USB stick. This script - userscripts.sh - is copied to the /tmp directory and executed by myinit after it runs emulotar. With some funky bash scripting, we've found ways to replace files used by the Pandora's Box on the fly. (This is the real reason that we aren't as concerned about where the magical file vault on the SD card is - if we control /tmp, we pretty much can hijack anything we want and copy our own edited versions in before they get executed by the Pandora's Box.)
The addition of userscripts.sh on the USB stick means far less screwing around with popping out the SD card and less wear and tear hopefully. However it does seem like there are still some things we're trying that absolutely need to be in myinit instead of userscripts.sh. It's something we're still trying to figure out at the moment. But now that we have this flexibility, let's try something different to see if we can pull it off. Let's try playing our own music in the frontend, a feature that the frontend does not currently have. Let's find out how that weird music track is played in the settings screen. Within the various apps, we find the following snippet:
So it's using mplayer to play music on the settings screen. Kind of heavy but no big deal. Let's add some code to our userscript.sh to try to do the same thing and see what happens.
So, when I first wrote up this script to play music, I just used /tmp/vdt to play the mp3. I learned that this is a problem because emulotar sends a killall -9 vdt when the frontend is about to start which is intended to stop the videos that are playing normally during bootup, but also kills my music player. I went the heavy route - just copying the file to /tmp/mplayer and playing the mp3... which... works!
There were a few side effects:
- Playing music means not being able to hear any sound effects or game audio until the mp3 is done playing.
- Some heavier games crash on boot up while the mp3 is playing, likely because of less RAM being available because I made a full copy of mplayer in /tmp.
I'm sure we can improve on this and get it working a bit better without the crashes, perhaps pausing the music when a game is started, that sort of thing. Or even using mpg123 instead so that we can do playlists and stuff like that. Hmm.
So this is a nice little example of the kind of things that are possible here with some creative bash scripting. Once we've broken into everything, we'll have far more control so consider this a taste of the kind of customization you will be able to have eventually.
And even with me posting these blogs as quickly as I can, our progress just keeps advancing faster than I can keep up. Stay tuned, we've got a lot more to go and I've got a lot more ideas to try.