raspberry pi and emulation

[+Ksarul]

Thank you for the comprehensive test, Michael!

[+mizapf]

I thought it was about time to clarify that, even when the answer is not encouraging. It does not make sense to go on like "I suppose it is too slow" when it should be possible to provide numbers.

 

If you are interested, here is the discussion thread in the MESS forum with some comments from the other devs: http://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=98654

[+Vorticon]

Really too bad At least the issue has been put to rest, arguably until a faster version of Rpi becomes available Commendable effort for sure though!

[moocowmoo]

 

I am pretty sure Wine requires a intel processor.. not ARM so won't work on a PI.. DOSBOX maybe

 

Greg

Wine doesn't require an Intel processor, it requires an ARM build of Classic 99. As will Windows 10 for the Pi.

[+arcadeshopper]

Wine doesn't require an Intel processor, it requires an ARM build of Classic 99. As will Windows 10 for the Pi.

 

Ok well you say tomato..

 

intel based code running in intel based wine wont work on arm processors..

 

you'd need arm code and arm wine

 

Greg

[Tursi]

Wine is running on ARM already? that's pretty cool!

[+arcadeshopper]

Wine is running on ARM already? that's pretty cool!

 

was just reading a forum where they could only get notepad.exe working so far.. shrug

[Willsy]

Welllllllll.... If notepad is running then that must mean that a lot of the under-the-covers stuff is also running. Perhaps not as disastrous as it sounds. It's an ambitious project that's for sure!

[+mizapf]

So I'm reviving an old thread this time ...

 

I have a Raspberry 3 on my desk, and I tried to get MAME running on it. This Raspi version feels much faster than the previous ones; they even put the whole LibreOffice suite on the Raspbian distribution. And it can indeed be used. :-)

 

This time, compiling worked almost out-of-the-box, the libraries to add are the same as for any Ubuntu distribution (see details on Ninerpedia). However, I had a lot of trouble getting the compile job finished. The Raspberry became slower and slower, down to a crawl, once it reached the point where it built a particular library (luaengine). The reason was that compiling this library used up all memory space. And the Raspberry is configured to offer only minimal swap space (100M) in RAM; no space on the SD card. This is reasonable because a swap space would probably wear out parts of the flash memory in the SD card; wear leveling is typically used with SSDs, not with SD cards.

 

Since I'm not really keen of setting up a cross-compile environment, I tried to find ways to add swap space. The solution was to attach a (magnetic) USB disk drive and to configure a partition of it as swap space. This indeed worked, and MAME compiled!

 

I used the same driver selection for MAME as with my PC, where MAME builds in about 5 minutes. On the Raspi3, it took 10000 seconds, i.e. roughly 3 hours. This comparison is a bit unfair because I let it build in a single job, while I let my PC run four parallel jobs. However, the Raspi becomes too warm with several cores at work, hence I limited the build process to a single one.

 

The exciting point was when I launched MAME on the Raspi3. First impression: It comes up really quickly, much faster than I observed with the older Raspis. But still it is pretty sluggish with the TI emulations, and the benchmarks prove it:

pi@raspberrypi:~/mame $ uname -a
Linux raspberrypi 4.9.41-v7+ #1023 SMP Tue Aug 8 16:00:15 BST 2017 armv7l GNU/Linux
pi@raspberrypi:~/mame $ ./mame ti99_4a
Average speed: 8.48% (18 seconds)
pi@raspberrypi:~/mame $ ./mame ti99_4a -bench 30
Average speed: 81.38% (29 seconds)

The full run (with graphics) shows a performance of 8.5%; the bench run (without graphic output) delivered 81%. Compare this with the numbers I showed above; you can see that the Raspi3 is about 4 times faster than the previous ones.

 

(Mind that my current PC runs the same bench run with 877%, so my desktop PC is ten times faster than the Raspi3.)

 

So again, sadly saying, the Raspberry is not usable for running the TI emulations in MAME.

Edited September 21, 2017 by mizapf

[zzip]

Hi Chris,

 

this is difficult to answer. First, as I said in some occasions, the Raspberry Pi and other "small" devices are no target platforms for MAME/MESS. This essentially means that no efforts are spent to make it run smoothly on those platforms. As MAME and MESS are intended to achieve an emulation level close to the hardware, we grab any bit of performance that we can get. The only consideration is that it should run well enough on current, common PCs or laptops. (Well, there are other games for the PC that won't run smoothly on highest detail level on any platform you can get at this time running, so it's not that bad.)

 

Second, I'm not sure whether the required libraries (like for SDL2) are available on the Raspi. I already asked on the MESS forum whether someone tried to build it for Raspi, and the answers are similar: you won't like it. However, it's not a proof that it won't work. Only that people believe I won't like it.

 

There are versions around that are said to run on the Raspi or also on tablets. These are no official releases and are possibly far behind the current release level. This means that possibly none of the bugfixes of the last years are included, and the usage experience may be much different.

 

If you get it going on Raspi, I'd be strongly interested in your experiences.

 

Just get an image like Retropie or PiPlay. They have different versions of Mame pre-installed, including the older ones which run great on slower hardware like the Pi

[Sinphaltimus]

 

Just get an image like Retropie or PiPlay. They have different versions of Mame pre-installed, including the older ones which run great on slower hardware like the Pi

 

 

I was thinking the same thing when it occurred to me that I never actually tried using the TI emulation outside of playing games.

I wonder how good the emulation is in retroPi for using the TI in general for programs from DSK. I was planning to try these things out this coming weekend then read your comment.

[+mizapf]

 

Just get an image like Retropie or PiPlay. They have different versions of Mame pre-installed, including the older ones which run great on slower hardware like the Pi

 

 

Could be working. But as a developer of MAME, using old versions feels close to a sacrilege for me. I strongly discourage to use old versions, even if that means that MAME cannot be used on weaker hardware. (Well, you'll do what you like, anyway, but you should understand is as the "official" point of view.)

 

There are several reasons for this:

• The old MAME (MESS) releases have some bugs (check Ninerpedia for a comprehensive list) that were fixed later.
• ROM dumps have changed. If people continue to use old releases, we will have to maintain multiple sets of ROM dumps with a good chance that people get the wrong one for their emulator release.
• Invocation arguments have changed over releases.
• New cards and features have been added.
• The architecture has changed, particularly since 0.186. Specifically, the PEB must now explicitly plugged in into the "I/O port".

And I cannot really provide support for all past releases, maybe only for the current and the preceding one. So when you are in trouble, you may be left on your own.

 

Requiring to use the latest version is not that uncommon when you have a look at other projects or programs.

 

My interest to get it running on Raspberry is to see whether I can recommend to get a recent Raspi if someone really wants to run the emulator on such a platform. Me, I don't see much reason to use such a device.

Edited September 21, 2017 by mizapf

[zzip]

 

 

Could be working. But as a developer of MAME, using old versions feels close to a sacrilege for me. I strongly discourage to use old versions, even if that means that MAME cannot be used on weaker hardware. (Well, you'll do what you like, anyway, but you should understand is as the "official" point of view.)

 

There are several reasons for this:

• The old MAME (MESS) releases have some bugs (check Ninerpedia for a comprehensive list) that were fixed later.
• ROM dumps have changed. If people continue to use old releases, we will have to maintain multiple sets of ROM dumps with a good chance that people get the wrong one for their emulator release.
• Invocation arguments have changed over releases.
• New cards and features have been added.
• The architecture has changed, particularly since 0.186. Specifically, the PEB must now explicitly plugged in into the "I/O port".

And I cannot really provide support for all past releases, maybe only for the current and the preceding one. So when you are in trouble, you may be left on your own.

 

Requiring to use the latest version is not that uncommon when you have a look at other projects or programs.

 

My interest to get it running on Raspberry is to see whether I can recommend to get a recent Raspi if someone really wants to run the emulator on such a platform. Me, I don't see much reason to use such a device.

 

1. Yes old emulators have bugs. But the new ones have introduced new bugs too. Many of the old arcade games ran well enough on the old emulators anyway.

 

2. Multiple rom dumps- This has been a problem and major source of frustration with Mame for years, because the mame devs force new rom sets so often. It's not always easy to find the right versions. So no, running an older Mame is not going to cause a problem that didn't already exist for ages. In this case you just need to find roms for the 0.37 versions, it's similar to the rom sets used by many mobile versions of mame that are using for the same reason-- this hardware is simply not powerful enough to run the latest.

 

3. doesn't matter much a front-end is preconfigured in these PI distros.

4. doesn't matter much either, it just has to work on the pi

 

As for support, I never had to contact mame support people except for questions like "why the hell did the rom for xxx change yet again? Why can't I find the new set anywhere?"

 

And as to why people would want to run emulators on PIs, lots of reasons: cheap, quiet, don't consume much power, portable.

[+mizapf]

Please keep in mind that we don't change ROM dumps just to cause trouble. Honestly.

 

There are long-term goals of MAME that simply cannot be reached right from the start; thus, we are forced to approach the goals by intermediate steps - with the downside that things keep changing. Sometimes, things can only be achieved with higher processing power.

 

I understand that people consider using a Raspberry to build it into some cabinet and run arcade games from the emulation, and with the TI, to put it inside the console to make it look alike a real device, but this is not MAME's primary mission. This is not to say that we don't like it, but efforts go in a different direction.

 

As I said, anyone is free to do what suits best, including to use older versions of software, but I'd just ask for some caution when recommending to use older releases. There is no problem if recent releases just won't work, as in the case of the Raspi, and if there are actually bugs, but in general you may assume that work is progressing and improving.

[majestyx]

I still find it kind of bizarre that an RPi 3 can emulate an Amiga 4000 running around 7X faster than that machine's physical hardware, yet the TI runs at less than 10% of the physical hardware. Since I don't program emulators, I'm sure this is a case of apples and oranges.

[+mizapf]

I still find it kind of bizarre that an RPi 3 can emulate an Amiga 4000 running around 7X faster than that machine's physical hardware, yet the TI runs at less than 10% of the physical hardware.

 

In MAME? Or with another emulator, like UAE?

 

Even inside MAME, we still have very different depths of emulation. Take, for example, the GROM emulation. In earlier releases of MAME, we just had a memory area that was assigned the GROM address space, then a pointer to the current GROM address, and reading just meant to deliver the byte at that address, including incrementing the pointer.

 

With more recent releases of MAME, we have an emulation of the TMC0430, which is the GROM circuit. The VDP delivers a GROMCLK line which is fed into that circuit, letting the device go through the states as described in the specifications. When the GROM contents are loaded (one of the reasons that we now used split dumps), these circuit instances get their respective content, each one has its own address counter and identifier. Also, there is a prefetch buffer that is under control by this CROMCLK.

 

Or look at the 99/8. One of the circuits (Mofetta) creates a GROMCLK by dividing the CPU clock. In the emulation, CLKOUT is actually led into the Mofetta emulation where a counter is used to divide the rate, then the attached GROMs are served by that GROMCLK line.

 

What I wanted to illustrate is that the same effect could be created just by assuming that the GROMs are always ready to be read, and somehow forging a delay, or by setting up a timer that runs at the 441 kHz rate, thus pretending that there is a separate clock source. The user won't notice (in most cases). This is, however, not the way things should be done in MAME.

[majestyx]

I was referring to UAE which is of course a dedicated Amiga emulator as opposed to MAME/MESS which is a one-emulator-fits-all solution. Also, MAME's mission is different from dedicated emulators/simulators in that it's attempting to emulate exactly the original hardware. I don't know what the benchmark is of the Amiga emulation within MAME. Still, as a user it seems weird that the Amiga with all its custom chips and the 4000, having been released 11 years after the TI-99/4A, can be emulated at such a high speed while the TI is stuck at 10%. And based on your response which mostly went over my head, I'm guessing that is the reason why this is.

[zzip]

Please keep in mind that we don't change ROM dumps just to cause trouble. Honestly.

 

 

I don't think you guys are intending to cause trouble, but I think the dev team is just unaware of how much trouble it causes end users. I assume you guys have easy access to all the roms, but for the rest of us it isn't always easy to find replacement rom sets.. they are on shady sites that are sometimes blocked by ISPs/country and throw up pornographic pop-up ads.

 

I think there are a few small things the mame team could do to help users here.

 

1) when a romset changes, at least support the old code for a limited time, with a warning message that it will disappear in 6 months or whatever. This will encourage people to stay on current code, and give advance warning of the changes so they can update them at their leisure. Right now the experience is "download new mame, 1/3 of my games stop working!" this encourages people stay put on old versions because at least it works.

2) version the romsets! I might have 3 different version of dkong.zip, and none of them work with the latest version, but I have no way of knowing which version of mame they belong to. It would be easier to manage if they were named dkong_v2.zip dkong_v4.zip. And if the new Mame told me that it needed v7, then I would know not to try any of the romsets I have.

[Sinphaltimus]

 

I don't think you guys are intending to cause trouble, but I think the dev team is just unaware of how much trouble it causes end users. I assume you guys have easy access to all the roms, but for the rest of us it isn't always easy to find replacement rom sets.. they are on shady sites that are sometimes blocked by ISPs/country and throw up pornographic pop-up ads.

 

I think there are a few small things the mame team could do to help users here.

 

1) when a romset changes, at least support the old code for a limited time, with a warning message that it will disappear in 6 months or whatever. This will encourage people to stay on current code, and give advance warning of the changes so they can update them at their leisure. Right now the experience is "download new mame, 1/3 of my games stop working!" this encourages people stay put on old versions because at least it works.

2) version the romsets! I might have 3 different version of dkong.zip, and none of them work with the latest version, but I have no way of knowing which version of mame they belong to. It would be easier to manage if they were named dkong_v2.zip dkong_v4.zip. And if the new Mame told me that it needed v7, then I would know not to try any of the romsets I have.

 

 

This is precisely why I haven't upgraded MAME since the last MAME32 stand-alone (no MESS integration) in my Arcade cabinet. I have all the working roms I could ever hope for and no clue how to go about getting them all in a single package for any later versions of MAME or MESS. If it's not broke, don't fix it has gotten me by on a version of Mame that is probably 10 years old now.

[+mizapf]

I can well imagine this is a nuisance, yet I'm lacking a good solution. I always keep the appropriate ROM sets on WHtech for the TI systems; setting up some additional folder structure with MAME release numbers or "pre-xxx" could make sense.

 

(That is, to people who wonder about upgrading: You will always find the latest ROMs on WHTech, really.)

 

I do not expect any major changes in ROM sets from now on. I never said something similar before so you cannot say I'm always saying this. The target is to have ROM dumps that reflect the circuit contents. For example, the TI console has two 4Kx8 ROMs where the first ROM contains the even address contents, the second ROM contains the odd address values. The last change for the ROM dump was to split the previous common dump to two dumps with this structure. Also, the GROM dumps are now separate (6K for each GROM), where they once were a continguous dump file. That is, as far as I can see, there is no reason to change the ROMs another time. (Remind me of this statement.)

[+mizapf]

And based on your response which mostly went over my head, I'm guessing that is the reason why this is.

 

Maybe the shortest and most precise explanation is that MAME is not an emulator, but an emulation engine.