[petrockblog]

Mupen64plus (romdir n64-mupen64plus) now has working video out on the rpi2 builds (need to update from binary or source from menu 5)

[petrockblog]

you can adjust the video mode of most emulators and even per rom by pressing M or X before the emulator loads

[petrockblog]

None of the main devs have a rpi2 yet afaik, so please wait until we have ours and can look into this further. I built the optimised versions in an emulated environment so have not been able to test anything properly yet.

[petrockblog]

Well, basically you do this

http://www.openframeworks.cc/setup/raspberrypi/Raspberry-Pi-Cross-compiling-guide.html

and once it is working, you just need to make sure all the makefiles and so see the distcc gcc on the pi (or chroot – which is even quicker, since you can have 8 emulated cores on a fast ssd then).

Something like

sudo PATH="/usr/lib/distcc:$PATH" MAKEFLAGS="-j4 PATH=/usr/lib/distcc:$PATH" __platform=rpi1 ./retropie_setup.sh

I use -j8 or more in my chroot but for a real pi, this will need to be a bit less, due to io speed, and the fact the pi is still doing the preprocessing.

Note some emulators may fail with -j8 as they don’t have makefiles that play nicely with parallel building. But most will build.

as an example. I just did

time sudo PATH="/usr/lib/distcc:$PATH" MAKEFLAGS="-j8 PATH=/usr/lib/distcc:$PATH" __platform=rpi1 ./retropie_packages.sh advmame

completes in 8m45s.

[petrockblog]

install linux within your current OS using something like virtualbox ? Then you can do all the image conversion you need.

[petrockblog]

What are the specs of your wall power supply? Have you swapped in another to rule it out ? Anyway, try that image and let me know. Thanks.

[petrockblog]

get this image

https://drive.google.com/open?id=0B_knGioK16E6TlVpa3hmRi1PRHc&authuser=0

or do as herbfargus suggested, update the script, and then re-run the usbromservice. There was a bug with this in the 2.4.2beta image that has since been corrected.

[petrockblog]

I would get a pi2.

[petrockblog]

you can download the latest image from my google drive – https://drive.google.com/open?id=0B_knGioK16E6TlVpa3hmRi1PRHc&authuser=0

[petrockblog]

please download retropie 2.5.0 – 2.3 is very old now and a lot has changed since then.

disable overclocking with raspi-config and see if that helps (maybe will narrow down the problem) ?

Check your power supply – what are you using to power ? have you tried another psu ?

[petrockblog]

It’s not designed to launch disks from emulationstation but rather just to launch “Start” and then insert disks etc from inside the emulator. The extension is just .txt so we put a “Start.txt” in there to give something to launch. It actually just launches the emulator though (via script as it needs to launch from a specific folder)

This probably could be improved to work in the same way as emulators like vice etc, but requires some working of the launch script to handle loading of disks etc.

[petrockblog]

this was due to the project moving server. It’s working now, but there might be further issues due to the migration progress etc.

[petrockblog]

if you mean manually outside of retropie, then yeh those would work, we are using -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard (plus optimisation flags like -O2)

if you mean compiling retropie components, if you are running it on a pi2 with the latest code, it will automatically do this. You can override the platform manually by doing

sudo __platform=rpi1 ./retropie_packages.sh (or retropie_setup.sh)
sudo __platform=rpi2 ./retropie_packages.sh (or retropie_setup.sh)

[petrockblog]

and mupen64plus (from source as I can’t update binaries currently due to the retropie site move)

[petrockblog]

you may want to update mupen64-libretro (from binary or source – if from source update retropie-setup first) as that has been updated since the image was made.

[petrockblog]

not sure exactly as still checking/going through. Possibly jzintv. mupen64plus has some optimisations, but may be able to use an additional change or so. there may be others too.

[petrockblog]

[quote=86787]Buzz,
One issue using your latest image:
-I seem to be getting a segfault in some games that I believe previously worked in Mame4all… MK2/MK3 for example.
[/quote]

mame had some hardcoded optimisations in the makefile specifically for the rpi1, which may have caused some incompatibilities. These have been removed now. It was also being compiled with the older gcc 4.6 compiler too due to the way the makefile was written, so I have now corrected that. This could mean we get a speedup on the rpi1 too with the newer gcc (or not).

I have now built an image specifically for the rpi2 with most (not all) emulators optimised for the cortex-a7. It won’t work on rpi1 machines. You can try it here and see if mame4all works for you

https://drive.google.com/open?id=0B_knGioK16E6bkZ1M1VrQjZuR1E&authuser=0

[petrockblog]

new image (for both rpi/rpi2 owners)

https://drive.google.com/file/d/0B_knGioK16E6TlVpa3hmRi1PRHc/view?usp=sharing

This image should be released officially shortly. It includes the sdl1.x fixes – so hopefully less problems with black screens.

I will provide an image with rpi2 optimised binaries for testing soon.

[petrockblog]

[quote=86727]What emulators are you all using for snes and mame? I’ve only tried a few times but I can’t get snes games starting using snes9x, I only see a black screen and have to abort it with ESC, I tried change the default video mode with “m” at the startup but it doesn’t seem to matter what I choose. Should I use another emulator perhaps, which one is currently the best for Pi2? And Mame, advmame runs very slowly on Pi2 for me unless I have the settings all messed up. I always used mame4all-pi with perfect result on PiB, is that working on Pi2 yet?[/quote]

read further back in this thread.

[petrockblog]

To fix the black screen issue with the latest firmware I have now built sdl packages with pssc’s fixes in it (see https://github.com/raspberrypi/firmware/issues/354)

While you wait for an updated image/retropie-setup with this included (Working on that currently), you can manually install this patched up sdl, and scummvm/dosbox etc should work again. It should I believe make the sdl stuff a lot more reliable on the pi also (some info in the link above)

to update

wget http://malus.exotica.org.uk/~buzz/pi/sdl/libsdl1.2-dev_1.2.15-6rpi_armhf.deb
wget http://malus.exotica.org.uk/~buzz/pi/sdl/libsdl1.2debian_1.2.15-6rpi_armhf.deb
sudo dpkg -i libsdl1.2debian_1.2.15-6rpi_armhf.deb libsdl1.2-dev_1.2.15-6rpi_armhf.deb

[petrockblog]

It may help some audio glitches, but it may not as some are down to the video sync/timing etc, emulation accuracy, and other things. The fact that the pi2 is quicker will be the main benefit I think.

RetroArch is already built with thread support. What specific setting are you referring to ? If there is a specific setting for some cores then please give more details. thanks.

[petrockblog]

Sorry about that.

I don’t actually know off hand any that do. if some do have two threads say audio/video, it doesn’t necessarily mean that the audio emulation would be done in the audio thread as you will know – maybe just the sending the buffer to the hardware etc. I read that retropie has some software filters than work with multicore which might be of use.

The biggest speedup is going to just be the fact that each core is quicker – and perhaps something will be gained from building for the armv7, and maybe some speedup if/when we move to gcc 4.8 from 4.7 as our default compiler too.

anything that has armv7 assembler in is going to work nicely too. I believe ffmpeg has plenty of arm optimisations.

[petrockblog]

you can’t just rebuild something to take advantage of multiple cores automatically – it has to be written in a way to support it. Most emulators are single threaded by design. if they have more than one thread, its likely just maybe sound or having rendering split out, so you don’t get 2x performance exactly. Stuff that benefit from multiple cores are applications / compiling / video decoding (where a decoder can decode future frames on multiple cores – ffmpeg / xbmc supports this)), multitasking/desktop apps etc,

I will provide some binaries compiled for the cortex-a8 for testing – they may offer better performance. Some can be rebuilt out of the box, but some like mame4all need the makefile adjusted since its hardcoded for armv6.

[petrockblog]

something isn’t working then. no idea if kernel issue or firmware though or something else. try it with the latest raspbian image perhaps to check.

[petrockblog]

I don’t sorry. what does dmesg say when you plug it into the pi2 ? (Maybe should start a new thread for this)

[petrockblog]

those who don’t have a pi 2 – can run

rpi-update 9ae54e3

to downgrade their system to a point that should work. This won’t work on the pi2 since it is before support was added.

[petrockblog]

I have opened a ticket here

https://github.com/raspberrypi/firmware/issues/354

hopefully something comes of it. Looks like it all broke at the 3.18.4 update – the previous 3.18 kernel was fine. so either something in the kernel, or a configuration change or something else (there are firmware changes too). Impossible to know as there are only binary changes here and no sources to reference.

[petrockblog]

I believe it’s all related to the new kernel/firmware update – I’m going to test by downgrading the kernel on my pi and see.

Hopefully this will be sorted soon, but I’ll get back when I have further info. enabling dispmanx for those emulators may help (in supplementary config)

[petrockblog]

no, although I’m building some right now, and you can see if you get any performance difference when they are complete. but if you want to test a single emulator you can build with the instructions given earlier.

[petrockblog]

not sure what you are asking sorry. that image has no emulators optimised for the armv7 – you can test compiling yourself though.

[petrockblog]

Those of you lucky enough to have a rpi2, who want to build from source (either everything or individual emulators to test performance), you can do

sudo MAKEFLAGS="-j4" ./retropie_setup.sh

which will use 4 workers for building – so your additional cores will be utilised.

if you would like to see if building for armv7 gives better performance, you could do something like

sudo CFLAGS="-O2 -mfpu=neon -march=armv7-a -mfloat-abi=hard" MAKEFLAGS="-j4" ./retropie_setup.sh

instead of retropie_setup.sh you can also use retropie_packages.sh to build with the commandline interface.

note that some emulator build scripts/makefiles may override your cflags. some may also not build correctly when using -j4.

I build on an emulated arm chroot, with a cross compiler on a fast pc, using -j8. The emulated chroot does the preprocessing, and the cross compiler does the compiling. With such a set up it is possible to build everything in an hour or so.

[petrockblog]

Mostly stuff that used to work that isn’t is useful.

A user reported the other day about a black screen on scummvm. I am now getting that myself. I suspect it might be connected to the last firmware/kernel update, but I need to do more testing.

There has been work done by Vanfanel though on scummvm https://github.com/vanfanel/scummvm so we can probably switch to native pi output for that, but I hope other stuff isn’t affected.

keep your working images/install handy though just in case :)

[petrockblog]

Here is an updated RetroPie image for those wanting to test. I’m hoping it will boot fine on the pi 2.

I rebuilt all the emulators from source today so all the binaries should be up to date. Should there be no major problems this will become the next beta 2.4 image, and maybe the 2.4.x release image after that.

https://drive.google.com/file/d/0B_knGioK16E6c0d4MDZCRUlqclU/view?usp=sharing

[petrockblog]

[quote=86538]
I’m not trying to start a fight:) But to each there own. I love the RetroPie project, but I love the Pi Foundation’s goals even more. I think the charitable, education-centric basis of the Pi is why there’s so much support. Otherwise, we have been able to buy more powerful, not much bigger MicroATX boards from any number of corporations for years.
[/quote]

I don’t disagree generally, but we have only been able to buy boards with this spec/size/price in recent years. The Pi seemed to start the trend / and certainly triggered these other boards that are around the same price range.

The Pi certainly has some honourable goals. It also has the best community.

I like the Pi, but I also like to experiment. I’m considering getting some faster boards for testing. I’m also keen to perhaps improve the basic multi-platform support in the retropie script. I would be interested in seeing some benchmarks for single core performance for an overclocked pi2 vs something like the odroid (which is 600mhz quicker per core by default).

Ram speed will make a difference too for some stuff I guess.

I do software for a bunch of (what I think are interesting) devices, from the O2 Joggler, to the original Xbox. So if I am getting some new bits, it doesn’t mean I am going to ditch my old stuff :)

[petrockblog]

The new pi looks nice, but a little bit of a shame that the cpu is only clocked at 900mhz by default, and that the ethernet is still 100mbit. But still a big improvement – will be interesting to see how much overclocking can be done.

I’m somewhat tempted to get an odroid-c1, which has 4×1.5ghz and gigabit ethernet. Sells at $35 but seems to translate to close to £35 once it gets to the uk which is a shame.

[Author]

Posts