Bootable Emulators (Discussion)

[youxia]

MAME takes few seconds to launch. This is #firstworldproblems territory, seeing as then you have aaccess to the entire history of arcade gaming (and more if you wish).

[zzip]

3 minutes ago, youxia said:

MAME takes few seconds to launch. This is #firstworldproblems territory, seeing as then you have aaccess to the entire history of arcade gaming (and more if you wish).

I think the point is it takes a few seconds to launch on modern hardware with SSD..  think of what that translates into on low-end hardware with slower I/O.    Think of the memory footprint.   The old MAME codebase doesn't have these issues on that hardware.

[leech]

1 minute ago, zzip said:

I think the point is it takes a few seconds to launch on modern hardware with SSD..  think of what that translates into on low-end hardware with slower I/O.    Think of the memory footprint.   The old MAME codebase doesn't have these issues on that hardware.

My current MAME set up takes about 5 min to start when it first is set up.  Second start up is quick.  But I also have like 3tb of mame/mess ha

[mr_me]

3 hours ago, leech said:

Ha, my Benchmark for MAME is Gauntlet: Legends.  The VCS can't quite do that one.  I should try Cruisin' USA.  Still a 3dfx based game but requires a but less oomph in the CPU.  First system I have had that could do that Gauntlet game was my i7-6700k though...

What speed percentage are you getting with gauntlet legends on the atari vcs?  My fifteen year old cheap PC gets about 40% on current mame.  I don't normally play games with chd files; everything else runs fine.

[+x=usr(1536)]

The point that seems to be being overlooked is that MAME doesn't target a specific performance goal.  If a system has the beef to run a particular game at 100%, great, but if it can't, it'll need to be upgraded and/or stand by for driver improvements.  And while everyone talks about 'bloat', the reality is that nobody (in the wider picture, not specifically here) has defined that term in such a way as it would permit a solution to the perceived problem being forumlated - yet the emulator continues to work in its present state just fine on not-up-to-date hardware.

 

Additionally, one of the problems with specifically targetting low-end hardware is that it makes it difficult to break with the past.  MAME running on a 486 is an excellent example of this, and one that I have experience with so can remember how well it performed.  But that was at a time when the demands of the drivers were much lower due to the far lesser complexity of the emulated systems: there was a time when Galaga was believed to be unemulatable because it had - *gasp* - two Z-80s.  There were also a lot of inaccuracies not just in drivers, but also in things like CPU cores and discrete audio, and improving accuracy over time in some cases required more cycles.  There's a reason why 32-bit builds are no longer distributed and are generally discouraged.

[leech]

4 minutes ago, mr_me said:

What speed percentage are you getting with gauntlet legends on the atari vcs?  My fifteen year old cheap PC gets about 40% on current mame.  I don't normally play games with chd files; everything else runs fine.

I'll have to check again.  I usually judge by frame rate / audio popping.  Like my previous build to that i7-6700k would run at a good framerate, but the audio would pop in and out. 

The VCS was at the level where the framerates were like 15-20, and the audio was barely working.  That means probably 90% of all of MAME would run fine.  it's just that 10% that had 3d hardware in the cabinet that'll run like garbage.  If they did a MAME release that used GPU acceleration, it'd be a different story.

[leech]

5 minutes ago, x=usr(1536) said:

The point that seems to be being overlooked is that MAME doesn't target a specific performance goal.  If a system has the beef to run a particular game at 100%, great, but if it can't, it'll need to be upgraded and/or stand by for driver improvements.  And while everyone talks about 'bloat', the reality is that nobody (in the wider picture, not specifically here) has defined that term in such a way as it would permit a solution to the perceived problem being forumlated - yet the emulator continues to work in its present state just fine on not-up-to-date hardware.

 

Additionally, one of the problems with specifically targetting low-end hardware is that it makes it difficult to break with the past.  MAME running on a 486 is an excellent example of this, and one that I have experience with so can remember how well it performed.  But that was at a time when the demands of the drivers were much lower due to the far lesser complexity of the emulated systems: there was a time when Galaga was believed to be unemulatable because it had - *gasp* - two Z-80s.  There were also a lot of inaccuracies not just in drivers, but also in things like CPU cores and discrete audio, and improving accuracy over time in some cases required more cycles.  There's a reason why 32-bit builds are no longer distributed and are generally discouraged.

Yeah, MAME is at it's core, simply a set of drivers for different chips.  It's not even an emulator in the traditional meaning of the word.  Like it doesn't emulate a single system/board.  It has various drivers for each 'chip' or sometimes they bundle system boards together.  Like the aforementioned Congo Bongo issue is because they updated the Zaxxon board, which uses the same setup, but it broke the music of Congo Bongo.  Crazy how big of a project MAME is.  Getting a nice setup of MESS was always a pain, still sort of is, but MAME at least now has a decent native front end, before it was a CLI program and everyone else made front ends for it.  So that might also be where the 'bloat' is from.

[+x=usr(1536)]

4 minutes ago, leech said:

Yeah, MAME is at it's core, simply a set of drivers for different chips.  It's not even an emulator in the traditional meaning of the word.  Like it doesn't emulate a single system/board.

Ehhh... We may be getting into hair-splitting territory on this one.  I'd argue that it does qualify as an emulator, just one where the machine being emulated can be defined by its driver rather than the emulator as whole.  Think LKMs vs. monolithic kernels as a parallel.  Still, I get what you're saying.

4 minutes ago, leech said:

Crazy how big of a project MAME is.  Getting a nice setup of MESS was always a pain, still sort of is, but MAME at least now has a decent native front end, before it was a CLI program and everyone else made front ends for it.  So that might also be where the 'bloat' is from.

Part of that is just down to the fact that it now supports over 35000 different machines - and that's an arcade-only build.  But that brings us back to the question of, "what is bloat?", which still needs a decent answer before trying to see if there's a problem that needs to or can be solved.  I don't know that there's necessarily a good answer to that question simply because 'bloat' may mean something different to different people: one may consider the UI wasteful, or another advocates ripping out support for all of the mahjongg, hanafuda, and fruit machines.  To someone else, it may be an inefficient or redundant routine in <insert emulator element here>. ?‍♂️

[youxia]

52 minutes ago, zzip said:

I think the point is it takes a few seconds to launch on modern hardware with SSD..  think of what that translates into on low-end hardware with slower I/O.    Think of the memory footprint.   The old MAME codebase doesn't have these issues on that hardware.

Yes, which is why we use Mame 2003 on RPi, for example, and which was my earlier point, about why it makes sense to use some earlier builds on weaker machines.

 

51 minutes ago, leech said:

My current MAME set up takes about 5 min to start when it first is set up.  Second start up is quick.  But I also have like 3tb of mame/mess ha

Same here, but how often people do first setups?

 

 

[zzip]

26 minutes ago, x=usr(1536) said:

The point that seems to be being overlooked is that MAME doesn't target a specific performance goal.  If a system has the beef to run a particular game at 100%, great, but if it can't, it'll need to be upgraded and/or stand by for driver improvements.  And while everyone talks about 'bloat', the reality is that nobody (in the wider picture, not specifically here) has defined that term in such a way as it would permit a solution to the perceived problem being forumlated - yet the emulator continues to work in its present state just fine on not-up-to-date hardware.

 

Additionally, one of the problems with specifically targetting low-end hardware is that it makes it difficult to break with the past.  MAME running on a 486 is an excellent example of this, and one that I have experience with so can remember how well it performed.  But that was at a time when the demands of the drivers were much lower due to the far lesser complexity of the emulated systems: there was a time when Galaga was believed to be unemulatable because it had - *gasp* - two Z-80s.  There were also a lot of inaccuracies not just in drivers, but also in things like CPU cores and discrete audio, and improving accuracy over time in some cases required more cycles.  There's a reason why 32-bit builds are no longer distributed and are generally discouraged.

I've always struggled to understand the MAME development philosophy.   I seem to recall that Mame started out as a set of emulators that ran different families of arcade games.   But then it all got rolled into one thing.

 

But why do all those disparate systems need to get rolled into a single monolithic binary?  Couldn't the various emulators been turned into shared libraries or plugins, with a single loading program that only loads the plugins needed at the time?   Does emulating Space Invaders and the Simpson's arcade game really share that much code?

 

The scope of what it does always seems to expand, it didn't stop with arcade game, it re-merged with MESS, even though MESS is full of many sub-par emulation implementations, that no-one can actually use, it gets rolled into the binary anyway.   This is why it has a reputation for bloat.

 

I think the solutions for the bloat problem

1) less monolithic binary, load shared objects/modules for what is actually needed

2) slimmer builds - it's great that it supports 35,000 systems, however the average user probably needs less than 200 of them.   Make it easier to make builds that eliminate the stuff you will never use.

[leech]

1 hour ago, x=usr(1536) said:

Ehhh... We may be getting into hair-splitting territory on this one.  I'd argue that it does qualify as an emulator, just one where the machine being emulated can be defined by its driver rather than the emulator as whole.  Think LKMs vs. monolithic kernels as a parallel.  Still, I get what you're saying.

Ha, yeah.  Like it's more a blob/front end that then uses all the little bits and pieces to emulate stuff.  So you can update say the z80.c file and it'll effect whatever systems use the z80, but not things that use m68k emulation.

1 hour ago, x=usr(1536) said:

Part of that is just down to the fact that it now supports over 35000 different machines - and that's an arcade-only build.  But that brings us back to the question of, "what is bloat?", which still needs a decent answer before trying to see if there's a problem that needs to or can be solved.  I don't know that there's necessarily a good answer to that question simply because 'bloat' may mean something different to different people: one may consider the UI wasteful, or another advocates ripping out support for all of the mahjongg, hanafuda, and fruit machines.  To someone else, it may be an inefficient or redundant routine in <insert emulator element here>. ?‍♂️

Ha ha, yeah a large majority of the games are unplayable unless you use a keyboard, or somehow have one of those weird mahjongg controllers.  There are various forks out there that I think do clean all that stuff out.  The beauty of open source! 

 

1 hour ago, zzip said:

I've always struggled to understand the MAME development philosophy.   I seem to recall that Mame started out as a set of emulators that ran different families of arcade games.   But then it all got rolled into one thing.

 

But why do all those disparate systems need to get rolled into a single monolithic binary?  Couldn't the various emulators been turned into shared libraries or plugins, with a single loading program that only loads the plugins needed at the time?   Does emulating Space Invaders and the Simpson's arcade game really share that much code?

 

The scope of what it does always seems to expand, it didn't stop with arcade game, it re-merged with MESS, even though MESS is full of many sub-par emulation implementations, that no-one can actually use, it gets rolled into the binary anyway.   This is why it has a reputation for bloat.

 

I think the solutions for the bloat problem

1) less monolithic binary, load shared objects/modules for what is actually needed

2) slimmer builds - it's great that it supports 35,000 systems, however the average user probably needs less than 200 of them.   Make it easier to make builds that eliminate the stuff you will never use.

What would be nice is a modification to the build system so it works like the modern one for the Linux kernel.  So you could for example include just Atari games, or Atari games from 1977 to 1995.  Select which non-arcade systems too, etc. 

 

I mean there definitely is a separation between say Space Invaders and the Simpson's Arcade, but like Space Invaders and... something else I can't remember at the moment, share the same hardware.  But all of that gets built into the binary making it bigger.  An approach like RetroArch where you can install individual cores is more along the lines of what you're asking.  There are advantages to both methods, along with disadvantages. 

[zzip]

11 minutes ago, leech said:

What would be nice is a modification to the build system so it works like the modern one for the Linux kernel.  So you could for example include just Atari games, or Atari games from 1977 to 1995.  Select which non-arcade systems too, etc. 

It's been awhile since I built a Linux kernel.   Last time I tried, there were a mind-numbing number of options.  Many I wasn't sure how to answer.   Have they revamped it to make it easier?

 

For mame, I was thinking something along the lines of a configuration script that scans your rom library and figures out which components you actually need to build.

 

13 minutes ago, leech said:

I mean there definitely is a separation between say Space Invaders and the Simpson's Arcade, but like Space Invaders and... something else I can't remember at the moment, share the same hardware.  But all of that gets built into the binary making it bigger.  An approach like RetroArch where you can install individual cores is more along the lines of what you're asking.  There are advantages to both methods, along with disadvantages.

Yeah each arcade system would support multiple games, and the Mame precursor emulators would emulate those systems and support maybe 4-6 games each.   But if you keep going along that line, it could get confusing (which emulator do I need to run to play Galaxian again?),   so I understand the desire to unify things like Mame did, but I don't understand why it needed to be a single large binary

 

Yes Retroarch is more along the lines of what I was thinking, although I wouldn't necessarily implement the download system they have.   The MAME build would build all the cores/shared objects/libraries (whatever you want to call them) and install them on your system.   You could eliminate the ones you don't need from building.   No internet required.

[Matt_B]

I'd think that if MAME were started from scratch now, they'd take the same model as RetroArch/LibRetro in that you'd have a common front end and just could just download the individual emulation cores you need.

 

Even as things stand now, the monolithic MAME LibRetro cores are no bigger than a relatively modest indie game, so not that much of a pain to download. You just have to resist that gotta-have-everything impulse that'll mean you'll spend more time setting it up than you'd actually get to spend playing anything.

[leech]

5 minutes ago, Matt_B said:

I'd think that if MAME were started from scratch now, they'd take the same model as RetroArch/LibRetro in that you'd have a common front end and just could just download the individual emulation cores you need.

 

Even as things stand now, the monolithic MAME LibRetro cores are no bigger than a relatively modest indie game, so not that much of a pain to download. You just have to resist that gotta-have-everything impulse that'll mean you'll spend more time setting it up than you'd actually get to spend playing anything.

Ha, that's my problem with everything these days.  When you have scores of retro stuff, and even close to 3k games on steam, you end up sitting there thinking 'I want to play a game' and then not being able to decide what game you want to play, or even what kind... and then end up watching something on Netflix

[+x=usr(1536)]

6 hours ago, zzip said:

I've always struggled to understand the MAME development philosophy.

Well, it really hasn't changed a whole lot over the years.  Basically, playability is secondary to documentation and preservation.  Not saying that to be glib or dismissive - that's just what it has pretty much always been.

 

Based on that, what are the areas that aren't making sense to you?  This is something I'd really like to help to clarify if I can.

6 hours ago, zzip said:

I seem to recall that Mame started out as a set of emulators that ran different families of arcade games.   But then it all got rolled into one thing.

Sort of.  Nicola Salmoria wrote a couple of standalone emulators for (IIRC) Pac-Man and Ms. Pac-Man.  That led to combining them into the Multi-Pac emulator, which also supported other versions on similar hardware.  From there, MAME sprang up, adding support for Space Invaders and Phoenix.  It all snowballed from there.

6 hours ago, zzip said:

But why do all those disparate systems need to get rolled into a single monolithic binary?

Good question.  More:

6 hours ago, zzip said:

Couldn't the various emulators been turned into shared libraries or plugins, with a single loading program that only loads the plugins needed at the time?

Potentially, yes.  However, MAME's current architecture really isn't designed to handle things in that way.  Starting over from scratch to implement the 'pluggable' architecture being proposed would pretty much be necessary.

 

One thing that is important to understand, though, is that doing so really only reduces MAME's memory footprint.  The amount that it's reduced by could likely be significant, but that doesn't necessarily equate to performance gains in emulation since those are tied to the underlying hardware.  A monolithic MAME build will run at the same speed as a pluggable one, given the same cores, ROMs, drivers, etc.

 

The last arcade-only build of MAME that I compiled on this machine (which, being completely honest, was probably from last November - updating has been low-priority for the past couple of months) shows a file size of 233516340 bytes; let's call it 233MB for easy reckoning.  That's not even a quarter of a gigabyte in an era where even the lowest of low-end PCs can be had with 4GB of RAM.  Could a pluggable architecture reduce that?  Sure, but for what return?  Convincing a dev or devs of the benefits is going to be a difficult task when there's no clear overall benefit to the project as a whole.

6 hours ago, zzip said:

Does emulating Space Invaders and the Simpson's arcade game really share that much code?

In terms of original game and/or driver code, I'm willing to bet that very little to none is the answer.  But what is definitely shared between machines is emulated hardware.  Cores, discrete components, controller types, and so on and so forth.  Sure, we can go back to the pluggable architecture idea, but that also comes down to a cost/benefit analysis as to whether or not it's worth implementing.

6 hours ago, zzip said:

The scope of what it does always seems to expand, it didn't stop with arcade game, it re-merged with MESS, even though MESS is full of many sub-par emulation implementations, that no-one can actually use, it gets rolled into the binary anyway.   This is why it has a reputation for bloat.

Points taken, but should MAME have just frozen in time, never branching out in other directions?  There was a time when something pretty close to that idea was guiding the project, and it didn't work well for a number of reasons.  It all comes back to the earlier question of what does and does not bear inclusion, and who makes that call.

 

As regards MESS, it follows the MAME philosophy of documenting the hardware as far as is possible so that someone with the inclination to improve emulation can do so.  I'd argue that that's not bloat; it's providing a starting point to continue from.  Opinions may differ, but again it comes back to the question of who decides what counts and doesn't.

6 hours ago, zzip said:

I think the solutions for the bloat problem

1) less monolithic binary, load shared objects/modules for what is actually needed

2) slimmer builds - it's great that it supports 35,000 systems, however the average user probably needs less than 200 of them.   Make it easier to make builds that eliminate the stuff you will never use.

OK, those are fair points.  Taking them in order:

 

Regarding 1) above: how would you propose re-architecting the existing emulator to accommodate that change?

 

WRT 2) above: is this meant to be something that an end user can build, or that is part of an official release?  I ask because the majority of users aren't rolling their own, and what an average user may or may not need is different from person to person.

 

Finally, what is the cost/benefit analysis on both of the above as regards overall improvement to the project?

 

Note that I'm not asking the above to be difficult or combative - it's just that these are the terms that need to be considered when some pretty massive changes are being proposed.

[leech]

By the way...

https://github.com/stilett0/mame

 

[justclaws]

Nice, but sad all this MAME discussion could not have been in the "emulation on VCS" thread,
or even been in a dedicated "getting MAME working on VCS" thread, so people can find it later.

[zzip]

 

12 hours ago, x=usr(1536) said:

The last arcade-only build of MAME that I compiled on this machine (which, being completely honest, was probably from last November - updating has been low-priority for the past couple of months) shows a file size of 233516340 bytes; let's call it 233MB for easy reckoning.  That's not even a quarter of a gigabyte in an era where even the lowest of low-end PCs can be had with 4GB of RAM.  Could a pluggable architecture reduce that?  Sure, but for what return?  Convincing a dev or devs of the benefits is going to be a difficult task when there's no clear overall benefit to the project as a whole.

Yes and that's arcade-only,  a full build is what?  400MB?   That might not be a huge deal for a PC,  The original Pi's had either 512Mb or 1GB, and many phones and old consoles had similar amounts of memory.   That's why the old versions lived on.

 

12 hours ago, x=usr(1536) said:

Points taken, but should MAME have just frozen in time, never branching out in other directions?  There was a time when something pretty close to that idea was guiding the project, and it didn't work well for a number of reasons.  It all comes back to the earlier question of what does and does not bear inclusion, and who makes that call.

Most emulators have a limit scope of machines they support, and updates focus on making emulation more perfect and the emulator more usable.   Mame seems to have an ever increasing scope-  I believe it now emulates things that aren't technically arcade systems or home computers/consoles?,  at the same time many of the systems it emulates are broken and never get fixed.   At what point does the focus shift from finding new things to add, or does that never happen?

 

12 hours ago, x=usr(1536) said:

Regarding 1) above: how would you propose re-architecting the existing emulator to accommodate that change?

At this point you probably can't.  There's 25 years of work put into it.  But I'm curious as to how it didn't start to become unwieldy years ago, forcing a design change

 

13 hours ago, x=usr(1536) said:

WRT 2) above: is this meant to be something that an end user can build, or that is part of an official release?  I ask because the majority of users aren't rolling their own, and what an average user may or may not need is different from person to person.

Depends on your platform.   Windows builds are easily available.   I'm on Linux, so I end up building from source.   I have a pretty decent machine, but it still took two hours to build an arcade-only build from the latest source.

 

13 hours ago, x=usr(1536) said:

Finally, what is the cost/benefit analysis on both of the above as regards overall improvement to the project?

I'm not really proposing a change.   I was more explaining why people still hold on to outdated versions of Mame.

 

[+x=usr(1536)]

2 minutes ago, zzip said:

Yes and that's arcade-only,  a full build is what?  400MB?   That might not be a huge deal for a PC,  The original Pi's had either 512Mb or 1GB, and many phones and old consoles had similar amounts of memory.   That's why the old versions lived on.

Sure, and that's understood.  But this brings us back to the point that MAME has no performance target as a build consideration.

 

I understand that people want to run MAME on their older hardware, and that's certainly their prerogative.  But anyone doing that also needs to accept that they're doing something that is inherently contrary to the nature of not just MAME's development, but hardware and software development in general.  To my mind, it's not reasonable to expect the project to adapt itself to what are corner-case desires in relation to its stated goals.

2 minutes ago, zzip said:

Most emulators have a limit scope of machines they support, and updates focus on making emulation more perfect and the emulator more usable.   Mame seems to have an ever increasing scope-  I believe it now emulates things that aren't technically arcade systems or home computers/consoles?

Correct - there are electromechanical devices, calcuators, and others that it emulates.  But remember that its scope has evolved over time, and that MAME is, as stated on the front page of mamedev.org, "...a multi-purpose emulation framework."  It's no longer just an arcade video game or home computer / game console emulator, and hasn't been for quite some time.  That's part of the evolution of the project.

2 minutes ago, zzip said:

at the same time many of the systems it emulates are broken and never get fixed.   At what point does the focus shift from finding new things to add, or does that never happen?

Anyone is free to contribute whatever they may that is relevant, much as anyone is free to improve any included driver.  There is no requirement to submit a 'working' driver - and even 'working' in this case is a somewhat nebulous term.  There are games that are playable, but have the wrong colours, or sound.  Are those working, or imperfect, or broken?

 

I realise that that question opens up a serious rabbit hole, and it's not one I really intend to go down.  But sometimes, for the sake of documentation and preservation, it's necessary to submit and include drivers that are quasi-to-non-functional.  If that didn't happen, there would be no opportunity for anyone looking at the project to contribute to them.

2 minutes ago, zzip said:

At this point you probably can't.  There's 25 years of work put into it.  But I'm curious as to how it didn't start to become unwieldy years ago, forcing a design change

Again, unwieldy is a matter of perspective.  There have been significant rewrites to major components of MAME over the years - video, audio, discrete component handling, driver structure, the UI, etc. all serve as examples.  By and large, these (and other) changes have all brought definite improvements over the years.

 

The reality is that if it was unwieldy, nobody would want to contribute to it because nobody wants to have to slug it out with the software that they're developing just to make those (voluntary) contributions.

2 minutes ago, zzip said:

Depends on your platform.

Which is a good point, and one worth mentioning.  MAME has only three official build targets: Windows, Linux, and macOS.  Windows and macOS are pretty self-explanatory, but Linux opens up an interesting set of cases due to the source's high portability between hardware architectures: the same source that builds on x64 will also build on ARM, RISC, and others.  This has led to a lot of complaints about MAME's performance on low-end hardware, which overlooks the 'just because you can doesn't mean you should' aspect of running on those platforms.

2 minutes ago, zzip said:

Windows builds are easily available.   I'm on Linux, so I end up building from source.   I have a pretty decent machine, but it still took two hours to build an arcade-only build from the latest source.

macOS user here, and I also build from source.  This is something I do mainly to ensure that the libraries MAME is linking against match the ones on my system - it's an old habit, and probably no longer necessary, but old habits die hard.  Thing is, you and I are in the minority: most end users just want to download a binary and go.

 

Believe me, I get the long build times.  On a recent-ish (3 years old) MacBook Pro, just an arcade build takes around 45 minutes; can't really say how long a full build takes as I don't use the MESS side of things for computer / console emulation.  But that's the tradeoff for emulating a broad swathe of machines.  This is one reason why using low-end hardware doesn't make sense from a development point of view

2 minutes ago, zzip said:

I'm not really proposing a change.   I was more explaining why people still hold on to outdated versions of Mame.

Understood.  I'm mainly just sharing my perspective as someone who has contributed financially and materially to the project for quite some time, and has a certain degree of insight into it as a result.

 

And no, my views are not ones officially endorsed by the MAME project, its developers, contributors, or users.  It's just my opinion based on what I've seen over the years.

[leech]

12 minutes ago, x=usr(1536) said:

Which is a good point, and one worth mentioning.  MAME has only three official build targets: Windows, Linux, and macOS.  Windows and macOS are pretty self-explanatory, but Linux opens up an interesting set of cases due to the source's high portability between hardware architectures: the same source that builds on x64 will also build on ARM, RISC, and others.  This has led to a lot of complaints about MAME's performance on low-end hardware, which overlooks the 'just because you can doesn't mean you should' aspect of running on those platforms.

I still want to know MAME performance levels on a RISC-V.  Was actually thinking as the community SBC build that a RISC-V board may be an interesting target!

[CPUWIZ]

13 hours ago, leech said:

I still want to know MAME performance levels on a RISC-V.  Was actually thinking as the community SBC build that a RISC-V board may be an interesting target!

 

Go.

 

https://hackaday.com/2021/01/14/risc-v-comes-to-the-beagleboard-ecosystem-with-upcoming-beaglev-sbc/

[leech]

7 hours ago, CPUWIZ said:

 

Go.

 

https://hackaday.com/2021/01/14/risc-v-comes-to-the-beagleboard-ecosystem-with-upcoming-beaglev-sbc/

Ha, yeah been waiting for a board.  I may even put it in my Atari Arcade setup.

[youxia]

I know nothing about Risc-V / Beagle. Why would it be a better option than Pi4?

[zzip]

On 2/14/2021 at 11:09 AM, leech said:

Wonder how much effort would be involved in setting up a USB stick that would boot directly to a Stella interface for an activision collection.  Not that anyone could sell that without their approval.

I've created USB sticks that do just this.   Boots into an emulator front-end.   It could go straight to Stella too.   My opinion is it's best to put it on a lean Linux distribution to minimize boot time, but I know VCS has that signed kernel restriction that limits what distros can be used.

[leech]

7 minutes ago, zzip said:

I've created USB sticks that do just this.   Boots into an emulator front-end.   It could go straight to Stella too.   My opinion is it's best to put it on a lean Linux distribution to minimize boot time, but I know VCS has that signed kernel restriction that limits what distros can be used.

Well, it is possible to turn off, but AtariOS won't load.

My suggestion started with the idea of being able basically to 'put up or shut up' for the people bashing Atari.  Basically a 'let's see you do better'.

Also the idea of other companies to have an ability to sell a USB key that you can boit to a game / emulator.  Like the olden days when you would put in a floppy disk and boot straight up. 

I may have a play with the seed list to make a Debian liveusb for such a thing.