Author Topic: XMAME v1.0 release  (Read 74907 times)

Inertia

  • *
  • Posts: 157
Re: XMAME v1.0 release
« Reply #30 on: December 31, 2014, 03:40:25 pm »
Oh!!! 1 year after the original release of mame on GCW Slaanesh gives us XMame!!
AWESOME!!

THANK YOU SLAANESH!!!! :):)

zear

  • * Moderator
  • Posts: 2378
Re: XMAME v1.0 release
« Reply #31 on: December 31, 2014, 03:44:48 pm »
though now i'm only getting the option still for internal storage install.  a reboot didn't fix it, i'll try doing everything again.  i take it most of you had luck getting the external storage working?

After inspecting the OPK contents:
Code: [Select]
BASE_INSTALL_PATH_SD=/media/sdcard/appsThis is an incorrect directory for SD card mount point. The correct directory is /media/[card_name]/
With the current path, XMAME won't install on SD cards that contain disk labels.

Gab1975

  • ***
  • Posts: 1165
Re: XMAME v1.0 release
« Reply #32 on: December 31, 2014, 03:55:10 pm »
i take it most of you had luck getting the external storage working?

As Zear wrote, if your micro-sd isn't labeled "sdcard" the installer doesn't identify the external memory.

zephyrus

Re: XMAME v1.0 release
« Reply #33 on: December 31, 2014, 04:28:41 pm »
Quote
MAME4ALL supports the 0.37b5 ROMset while XMAME the 0.52, 0.69 and 0.84 ROMsets... a lot of new supported games! Moreover XMAME should have a better emulation speed ! ;)

well, slaanesh wrote:

XMAME v1,0 for GCW-Zero supports three versions:

MAME 0.37b16, 0.69 and 0.84.

so .37b16 or .52?  :)

pcercuei

  • ***
  • Posts: 1397
    • GitHub
Re: XMAME v1.0 release
« Reply #34 on: December 31, 2014, 05:01:44 pm »
Please, don't install anything else than OPKs in the "apps" folder, otherwise it will slow down the loading when starting gmenu2x. Any other location on the internal/external SD cars is fine.

Gab1975

  • ***
  • Posts: 1165
Re: XMAME v1.0 release
« Reply #35 on: December 31, 2014, 05:30:47 pm »
so .37b16 or .52?  :)

"0.52" is an alternative ID for the 0.37b16 ROMset... like 0.41 is an alternative ID for the 0.37b5 ROMset...
you can see a complete list of old MAME releases here:  http://mamedev.org/oldrel.html

slaanesh (OP)

  • *
  • Posts: 429
    • Slaanesh Dev
Re: XMAME v1.0 release
« Reply #36 on: December 31, 2014, 08:25:30 pm »
Yeah, there may a few games that don't work. One particular type of crash to look out for is one that reboots the machine, the screen will go black and then white and the machine will reboot.
Let me know if that is the type of crash.

As for other games that don't work, I'll look into them, just let me know what doesn't work.

Also would be interesting to know how many people are installing to internal or external storage.

During development I pretty much only used internal storage and only later on realized that people may want to install to SD card - that's why the installer has some restrictions. I'll look into those today and create a 1.01 installer that should fix these problems.

slaanesh (OP)

  • *
  • Posts: 429
    • Slaanesh Dev
Re: XMAME v1.0 release
« Reply #37 on: December 31, 2014, 08:36:16 pm »
Please, don't install anything else than OPKs in the "apps" folder, otherwise it will slow down the loading when starting gmenu2x. Any other location on the internal/external SD cars is fine.

I'll change this around for the 1.01 installer.

Nebuleon

  • Guest
Re: XMAME v1.0 release
« Reply #38 on: December 31, 2014, 08:36:27 pm »
Wait a minute here. Why do you have to create an installer? Can you not run the MAME executable(s) from the OPK itself, and let the user put it where he/she wants (/media/something/apps)?

codingcampbell

  • *
  • Posts: 25
Re: XMAME v1.0 release
« Reply #39 on: December 31, 2014, 08:58:58 pm »
Wait a minute here. Why do you have to create an installer? Can you not run the MAME executable(s) from the OPK itself, and let the user put it where he/she wants (/media/something/apps)?

+1

I appreciate your hard work slaanesh but I avoided this software because I felt uneasy about "installing" something in this way. I'd much prefer this project to follow GCW's standard OPK distribution practice. It is easier for me as a user to manage the apps plus you get the benefit of squashfs compression. You would probably also avoid the filesystem problems and having to assume an incorrect path for sd cards.

slaanesh (OP)

  • *
  • Posts: 429
    • Slaanesh Dev
Re: XMAME v1.0 release
« Reply #40 on: January 01, 2015, 12:16:23 am »
Well I thought it would be better to be installed. My reasons were:

* Have the entire application and it's data files in the one spot. Personally I find it annoying having files distributed around the filesystem for applications.
* Easily share resources between versions of MAME. ie. roms/ and snap/ directories are prime candidates as well as the history, hiscore and optional cheat dat database files.
* No need to "launch" an OPK to have the application available. Whilst this isn't much benefit for most users, as a developer having the application ready to go without launching the OPK is very useful. And I reasoned that it there would be not much difference to the end user between using an OPK or running the executables.
* Configuration of file paths to XMAME directories. Having everything in the one spot means this was easily done through the XMAMEROOT environment variable.

I nice conceptual model for the XMAME setup is that the directory containing the main executable has all it's relevant resources underneath.

-XMAME69
  |---MAME.SDL.69
  |---history.dat    <-shared
  |---hiscore.dat    <-shared
  |---cheat.dat      <-shared
  |---roms/          <-could be shared
  |---snap/          <-could be shared
  |---cfg/
  |---frontend/
  |---memcard/



Wait a minute here. Why do you have to create an installer? Can you not run the MAME executable(s) from the OPK itself, and let the user put it where he/she wants (/media/something/apps)?

+1

I appreciate your hard work slaanesh but I avoided this software because I felt uneasy about "installing" something in this way. I'd much prefer this project to follow GCW's standard OPK distribution practice. It is easier for me as a user to manage the apps plus you get the benefit of squashfs compression. You would probably also avoid the filesystem problems and having to assume an incorrect path for sd cards.

Well you already can put it where you want - to a degree - if you have EXT2 FS on your SD card.
But I will fix this today so that it can be installed to either internal or external storage for any filesystem, FAT32 or EXT2 or whatever.

If enough people want to run it from OPK only then I can change it but i really don't see any advantage in this over the current system. Please convince me otherwise :)

One question:
Why is the SD card mounted to /media/<LABEL>? Why is there no alternative, static mount point to the SD card? Having it mounted to the SD card's label name isn't a good idea IMHO. The SD card should be mounted to the same point regardless of it's name/label.
« Last Edit: January 01, 2015, 12:45:03 am by slaanesh »

AtariHERO

  • *
  • Posts: 351
Re: XMAME v1.0 release
« Reply #41 on: January 01, 2015, 12:30:57 am »
any special neogeo.zip file needed ?
, the one i had does not work anymore  ???
« Last Edit: January 01, 2015, 12:32:39 am by AtariHERO »

Elaphe

Re: XMAME v1.0 release
« Reply #42 on: January 01, 2015, 12:34:15 am »
Well, then let's see how it compares to upcoming version of MAME4All, which is supposed to be released very soon and support roms up to 0.74.

codingcampbell

  • *
  • Posts: 25
Re: XMAME v1.0 release
« Reply #43 on: January 01, 2015, 12:58:49 am »
Well I don't want to derail an otherwise enthusiastic thread but I'll share my point of view:

Well I thought it would be better to be installed. My reasons were:

* Have the entire application and it's data files in the one spot. Personally I find it annoying having files distributed around the filesystem for applications.

I disagree with this premise. Most (all?) of the GCW software ships its read-only storage as the OPK, stores userdata in a ~/.dotfolder/ and, in the case of emulators, you can load ROMs from wherever (I choose to store these in my home folder).

I think consistency is important and, while I don't fully understand the multi-version problem you're solving, I don't see why this emulator needs to deviate from the rest.

* Easily share resources between versions of MAME. ie. roms/ and snap/ directories are prime candidates as well as the history, hiscore and optional cheat dat database files.

I'll defer to you on this one, I'm not very aware of the multi-version setup. However, in other emulators, after I select a ROM the first time, it defaults to showing me the parent directory of that ROM the next time I need to select one.

* No need to "launch" an OPK to have the application available.

But OPK is a one-file distribution format and you get squashfs compression .. why not use it?

* Configuration of file paths to XMAME directories. Having everything in the one spot means this was easily done through the XMAMEROOT environment variable.

I don't have knowledge/opinion on this one.

Anyway, just my 0.2c. I think above all else you should be consistent with the platform you distribute to, unless there is a significant technical reason to deviate. And in your case you wouldn't have to worry about details like sd-card format etc. But again I don't want to derail this thread further. Congrats on shipping and thanks for giving to the community :)

One question:
Why is the SD card mounted to /media/<LABEL>?

+1 - /media/sdcard static mount would be great, like Android does.

slaanesh (OP)

  • *
  • Posts: 429
    • Slaanesh Dev
Re: XMAME v1.0 release
« Reply #44 on: January 01, 2015, 01:32:13 am »
Thanks for your feedback.

I have a confession to make - I'm not *that* interested in the installation/OPK side of the software; my interest is in porting and then optimizing the actual emulator and getting the games running as smoothly and as excellently as possible. I like solving problems when particular games don't work. I like making new games work. I like making things go faster.

However I do want to make it all work :)

The installation part of the project doesn't motivate me very highly. For this reason I tried solving the issue of the relatively complex file structure and various paths in easiest way possible from my point of view - which does deviate with the standard way other people have packaged their OPKs.

As for offering the user the exact ROMs directory location, this approach isn't really sufficient in this case - if you want to offer the user flexibility then it should be able to define exactly where everything goes.

For XMAME the following directories are used in each of the three versions of XMAME I've offered:

roms
snap
cfg
nvram
samples
memcard
inp
hi
sta
artwork
frontend
history.dat
hiscore.dat
cheat.dat

That's a lot to take care of and choose where everything goes, as that is multiplied by three.

Some of these contain content supplied by the user: roms, snap, samples, artwork
Some of these contain files which will be generated by XMAME: snap, cfg nvram, memcard, inp, hi, sta, frontend
Some may be a bit of both.
Some of these directories could be shared amonst versions of MAME: roms, snap
Whilst the remaining must be specific to the version of XMAME using it.

So how much user control do you offer?

Well be default, XMAME actually does offer full control - if you want. I haven't changed the way XMAME works - the user could in theory change where everything is.

However, and this is the big but, on a handheld console, lacking a keyboard, configuration of all these paths and files is difficult and tedious.

So, for simplicity, I decided on limiting the installation choice to either "internal" or "external" and XMAME taking care of the exact locations of all these paths/files I listed above. Whilst not consistent with the regular GCW approach, I felt that in this case this was an OK solution. After all, does it really matter exactly where the user content is placed on the storage? Do most users really care? I wouldn't think so in most cases, but there are of course always people who do.
That's why I created the XMAMEROOT environment variable concept so adopting the read-only OPK approach is feasible with not too much having to change.

I'll fix the current installer to work with FAT32 but after that for the next release I'll have to think about how things perhaps could be changed or if just kept as-is.



« Last Edit: January 01, 2015, 02:00:55 am by slaanesh »

 

Post a new topic