initramfs

[pmjdebruijn]

After discovering retropie, I thought of doing something similar with buildroot, and then I found your project, having done most of the hard work for me :)

However, my idea, was to have the entire rootfs in initramfs, so there would be no dependence on the SD card except for the ROMs themselves.

So I branched rpi-emulator-buildroot 0.3 and got to work, this is what I have so far:

https://github.com/pmjdebruijn/rpi-emulator-buildroot/commits/0-3-plus

It's not finished, but I thought I'd give you a headsup :)

[rmaz]

Hey Pascal. Nice to see someone making some use out of the project. TBH, once I saw how far Recalbox had gone I just stopped putting any work into this. With the updated hardware his work has basically added the necessary polish to make the whole thing usable enough for me.

I like the idea of an in memory FS, its not like the emulators are using much of the RAM anyway. If I ever get around to working on this again, I will bump buildroot to add default rpi2 support and merge this on top.

[pmjdebruijn]

I've cleaned up the commits a bit, and added some more polish.

I'm just left with an issue where some games (like F-Zero) have glitchy sound, but only during the first few minutes of the game. Once I do a full lap or so, the sound seems fine after that. Any clue what the problem might be?

[rmaz]

Which emulator are you using?

[pmjdebruijn]

armsnes (on rPi1B) of course :)

[rmaz]

ah ok. you might want to move the bug over to the ARMSNES repo, but most likely it is an underrun. what kind of frame rate are you getting? the mode 7 stuff is a bit more taxing to emulate as i recall, might be causing the issues. retroarch can also tell you how many frames are getting dropped as well as some other diagnostic info.

in general though the sound quality of that port is pretty horrible. the pi1 just doesn't have sufficient power to get the job done, not with a snes9x codebase anyway. was considering a pointless snes emulator greenfield project, but with the pi2 and some of the more recent cores like catsfc the quality is good enough for me, and the framerate just about full speed.

[pmjdebruijn]

So I have everything running on an rPi2, and I still have the audio issues with F-Zero and ARMSNES.

I never owned an original SNES, so the general audio quality didn't seem obviously bad to me, except for the artifacts (not sure how to qualify those).

BTW, I'd be happy to file an issue on ARMSNES, do you still consider it to be an active project?

(btw, doing some quick microbenchmarks on the rPi2, it seems -O2 is significantly faster than -Os, granted it might be less significant in real world code. Also gcc 4.8.4 seems to generate slightly faster code than 4.9.2, surprisingly).

[rmaz]

TBH, no, I am not going to do any more work on it. The code is so old and ugly it is painful to get anything done on it. So, I guess, good luck ;) Or just use CATSFC if you have a pi2, it is a much nicer core.

As for O2 being faster than Os, that depends very much on your application and its hotspots. Os optimises for smaller code size, which generally is faster for smaller devices because you keep more of the code in the instruction cache. On the other hand, if you are doing a lot of looped number crunching (ie an emulator) it could well be that unrolling loops and so on is well worth the increased executable size. I should probably have profiled that, I just assumed that Os would be better for such a constrained device.

[pmjdebruijn]

ARMSNES, fair enough.
CATSFC, thanks for the tip, I have it built via buildroot on the rPi2, and the sound is indeed much nicer. However still the sound glitches with F-Zero.

Though I just noticed the default buildroot kernel config, uses the powersave governor, which meant I was stuck at 600mHz. Switching to the performance governor seems to remove the glitches for ARMSNES, but not for CATSFC with F-Zero. Which seems to confirm it's cpu usage issue, however...

What drives me completely nuts is that when I quit the emu, and restart F-Zero, in the second run there are no glitches at all. And this seems reproducible. So somehow there is something funky going on...

With regard to the optimization, I know, that's why I explicitly mentioned the microbenchmarks, representativity is always an issue. I'll try -funroll-loops soon too.

BTW, sorry for abusing the issue tracker a bit here :)

[pmjdebruijn]

As a general FYI, here's my updated (I just started from scratch, copying select stuff over):

https://github.com/pmjdebruijn/rpi2-buildroot-emu/commits/master

It seems to work very well, except for the first-game-run-sound-glitches.

[rmaz]

Interesting that you still have the same issues even with CATSFC, I guess this means the issue lives in retroarch or the audio driver itself. Can't say I have the same problem, F-Zero is working fine over here.

[pmjdebruijn]

Well, I just made an embarrassing discovery, when I hook up my rPi to another TV, it's completely (and reproducibly) fine. So it seems my troubles are probably some HDMI audio quirk of the rPi in combination with my particular TV. Doh!

[rmaz]

Well, at least we were both wrong ;)