[Jason Whiteman]

“I feel your pain.” To an extent.

As a general rule, the Pi in its current form does not make the best emulation platform available. The resources are limited – and some of the resource limitations come from the less-than-open source chipset, limited on-board memory, number of cores, core frequency.

I do like that Retropie is a project with two distinct paths – one that downloads binaries (even if not the most up-to-date) and one that compiles source. Although I do not always “need” to compile from source – I like all packages that allow me to. Now Retropie simply facilitates this as the original source can always be found and compiled yourself. However, sometimes patches are made or configurations to run better on Pi – and this is useful.

There are other emulation platforms out there for Pi – it never hurts to take a look at what’s available.

Emulators are mostly installed in /opt/retropie

I agree that the naming convention could be better for the directories to ease finding an emulator. As not everyone knows that “osmose” is a Sega Master / Gamegear emulator (I have to look it up) — and it would be easier to label the directory as the platform(s) plus original name — or maybe just another nesting of the directories so multiple versions can be installed:

/opt/retropie/emulators/Sega_Master-Gamegear_osmose-0.8.1+rpi20121122
or
/opt/retropie/emulators/Sega_Master-Gamegear/osmose-0.8.1+rpi20121122/

Also if there are two different emulators that cover Sega Master/GameGear – they’ll show up here. … just a proposal. Plenty of ways to organize data.

Back to the N64:

Looks like mupen is most likely what’s going to lead to success.

http://www.raspberrypi.org/forums/viewtopic.php?t=58395

On my system, something must have went wrong because I do not have /opt/retropie/emulators/mupen64plus-rpi/

I’ve previously stated build issues I encountered and this may have been one of them. Actually, looking at my retropie-setup.sh options, I do not see Mupen64 in the build-from-source options although I do see a script for it.

The basic steps in the script:

1) make/enable a 512 meg swap file
2) download (git pull) from https://github.com/ricrpi/mupen64plus
3) run ./build.sh from mupen src destination dir
4) run ./install.sh from mupen src destination dir

The mupen github site has the following instructions:

A set of utilities for automatically installing mupen64plus on the Raspberry PI

Before installation: Set the GPU memory to 64mb in raspi-config.

Set CONF_SWAPSIZE to 512 in /etc/dphys-swapfile and run ‘sudo dphys-swapfile setup; sudo reboot’

Users should run the following to install: git clone https://github.com/ricrpi/mupen64plus cd mupen64plus ./build.sh sudo ./install.sh

mupen64plus will be installed into /usr/local/bin and /usr/local/lib/mupen64plus.

Developers should do the following: git clone https://github.com/ricrpi/mupen64plus cd mupen64plus modify the ‘defaultList’ file to point to repositories you want to use. run ./dev_build.sh to download and build into ./test/. run ./cfg_developer.sh to set username/email for pushing updates, setting ‘upstream’ remotes and creating symbolic links. optionally, run ./cfg_ssh.sh if you want to use ssh keys to push/pull from github

Regards,
Jason

[Jason Whiteman]

Not sure what you are experiencing – CPU sluggishness, video-stage “lag”, controller lag – or exactly what part of the experience time-chain is/are giving you the problem(s).

Regarding KMS/DRM – as far as I can tell, there is an emerging driver is in development by Broadcom to enhance the performance as they, Broadcom, have a new asset in the form of an Intel former employee Eric Anholt. ETA for the driver is first half of 2015 as of today (source: article). Eric may quote something different.

His blog is here:

http://anholt.livejournal.com/

And I originally found out about his contribution potential by reading this article:

http://www.phoronix.com/scan.php?page=news_item&px=MTc0Nzc

Using a CRT is something that you can try using the composite out instead of HDMI while not at work. Although I have my doubts any differences will be seen.

… not to say there isn’t existing KMS work. I would suggest you focus on Raspberry Pi sources as the link you provided focuses on Windows primarily. Presumably why you asked here – but there are existing Raspberry Pi discussions on the topic (insert search engine address here).

Regards,
Jason

[Jason Whiteman]

One of the issues I ran into is a common issue using gcc 4.7.2 and MESS/MAME (… and other packages) – on more limited hardware, gcc runs out of memory and the result manifests itself differently depending on the memory left over for the compile.

Therefore, when compiling MESS or MAME – the compiler will error out on tms57002.c

The fixes (pick one), as are widely published:

1) Add more memory (not possible with Pi – although can use a cross-compiler and do that. This is not the architecture of RetroPie – so I am compiling everything on the Pi itself) See epilogue for more info.

2) Try an older/newer gcc g++ package. The buzz seems to indicate that 4.7.2 eats up more memory although too old and there are problems – some claim 4.8 fixes these issues. I did not test – although a 4.8 toolchain would be the most clean suggestion

3) For Pi the suggestion is already to give the GPU the minimum memory (16M) although this did not fix the issue.

4) Optimize less. Default for MESS/MAME is -o3. I tried -o2 for this issue and it did not help. (translates to OPTIMIZE=3 and OPTIMIZE=2 in the MESS/MAME makefile). OPTIMIZE=0 is the prevailing fix for this tms57002.c issue

The best fix is only to use less optimization on the target .c file(s) required. In the lab here, the fix was manual – patch makefile to OPTIMIZE=0, compile only tms57002.c (break out of makefile after output is generated) and patch the makefile back to OPTIMIZE=3 until the next failure if any.

—–

My fix happened to be a combination of #3 and #4 only because of the order of operations in attempting to fix. #3 requires a reboot as I have not found a dynamic way to force lower memory utilization (ignoring the option for dynamic – which is an “alpha” feature and not sure how it operates during this operation). Before generating a script, I’d have to validate that the OPTIMIZE=0 fix works with a higher GPU memory split then decide how to handle the target(s) that need OPTIMIZE=0 assuming this works with a more aggressive split (meaning less memory for the CPU).

Regards,
Jason

Epilogue:

… note to the search engine hits that find this for the memory issue (more detail on why RetroPie solution cannot involve cross-compile:

The RetroPie project entails a script to compile emulators native on the Raspberry Pi device. This script has a mode to pull sources from the net and compile from source using the limited 512MB memory minus the GPU allocated memory. Therefore, in the case of these constraints – using a cross-compiler on non-raspberry hardware would entail using precompiled binaries which is not the function of the script for this option.

There are possible alternatives that are currently out-of-scope for the project. But the constraints for this thread are assuming bare-metal Raspberry Pi compilation of MAME/MESS (and any other emulator for that matter).

[Jason Whiteman]

Note:

Currently working MESS.

Regards,
Jason

[Jason Whiteman]

When you do, it would be helpful to know what was loaded before the prompt and what you were attempting to load. Since retropie has a slew of environments – and environments inside of environments sometimes – narrowing down the issue a bit would help.

[Jason Whiteman]

It’s taking a while – mess (latest version) is still compiling.

In parallel, I decided to kick off a TRS-80 compile which is a much smaller project. Following the guide (cd src/Linux ; sudo make) using sdltrs_1_1_0.tar.gz seems to be working fine.

For sdltrs:

I had to add “-lX11” to the library switches. Otherwise, everything worked fine. I’m not sure how well it works, but it does load into graphics mode from a console and F7 brought up a configuration menu.

Regards,
Jason

[Jason Whiteman]

trs-80
http://sdltrs.sourceforge.net/index.html

odyssey 2
o2em.sourceforge.net/

… also Magnavox Odyssey 2 is part of MESS along with the Atari systems requested.

One of the guides on MESS for Raspberry:

http://www.raspberrypi.org/forums/viewtopic.php?f=78&t=23113

MESS emulated systems:

http://www.mess.org/mess/driver_status

There is also Kaypro IIx support in MESS according to various sources although it is not listed in the above link.

It’s a start.

Regards,
Jason

Afterthought:

Note that AdvanceMESS is circa 2005 while the MAMEdev.org sources are actively developed with changes ongoing. I’m not sure what led previous work down the AdvanceMESS path vs. the latest.

[Jason Whiteman]

unfortunately I have no idea on how to issue a pull request :( For sure I could describe and detail the installation steps, this is what I’m doing hereafter!

When I was asked to generate a pull request, I had the same reaction. The best I could do was some research to figure out how to generate my own install script although there are still open questions.

In order to facilitate collaboration, it would be useful for the Wiki to have sections on:

1) You’ve been asked to generate a pull request – what does this mean, and how do I get started?

2) Format, conventions, etc. [i.e. documentation] of the required script(s) in adding a new emulator. Templates with comments and a skeleton of the various sections for each template would be best.

3) Any conventions of what to do after generating a new script. Announce on the msg board? Leave it up to github entirely? etc.

Then your “pull request” comments can include a link to the Wiki and guide the potential collaborator through the process.

Regards,
Jason

[Jason Whiteman]

I have suggested some items in the comments section. In addition:

1) Revision the primary script(s) (comments) or perhaps some version text for the major releases. I looked through my directory looking for the version and did not readily see anything in order to be sure I communicated version release when citing script issues/improvements.

2) Perhaps provide a template for the install scripts with comments on what all the fields mean and how they affect the outcome. I realize the scripts are flexible – but there are some standard conventions that could be self-documented in a template. It would even be great to post-process the scripts contributed by members to ensure the comments are in every released script so that “cut/paste” from another project would carry the self-documenting comments. However, at a minimum (unless I missed it) a “fully” documented template would work as well.

Regards,
Jason

[Author]

Posts