UME is the complete/combined version of the MAME / MESS project.
Official whatsnew texts for (MAME, MESS) provide full details of what has changed since 0.154, much of this has been covered in my ‘ex’ updates.
UME 0.155 Windows binaries – 32-bit, 64-bit and all tools
(source matches official mamedev.org source distribution)
Other Binaries (if you don’t know what these are you don’t need them)
MAME/MESS split 0.155 Windows binaries – 32-bit, 64-bit and all tools
Points of Interest
Not a great deal has changed from a user-visible point of view since the last ‘ex’ build, but I’ll cover some highlights, and anything interesting I missed from the entire cycle soonish.
One thing I was looking at shortly before the release is a Mario Bros. bootleg. Most bootlegs are quite dull, often changing nothing of note, or offering a significantly degraded experience. This Mario bootleg was said to be on ‘Ambush’ hardware by dumper Tirino73 and while some things differ enough to make me wonder if it’s really an Ambush board the sound system and a number of other details do seem to fit that profile quite well.
That’s what is most interesting about this bootleg, the sound. Right now in MAME the original Mario has terrible sound, the walking effect is far louder than everything else, and it need some serious attention by somebody more knowledgeable about discrete sound hardware than myself. This bootleg however has a completely different sound system to the original, utilizing 2 AY8910 chips for sound effects and music. If that wasn’t interesting enough the bootleggers based the melodies on Donkey Kong Jr, but they didn’t just rip things directly because Donkey Kong Jr. doesn’t use AY8910 chips either so it’s clearly been reworked for this hardware.
There was also a Donkey Kong 3 bootleg on basically the same hardware. Unfortunately when these were dumped the colour PROMs were not dumped at the same time, and it’s unlikely they’re meant to be 100% the same format as the originals, this has made progress on the emulation slower. I’ve uploaded a video of the Mario bootleg which you can watch below, the Donkey Kong 3 bootleg is currently in a worse state.
Frisky Tom is an interesting little game too, previously we had 2 sets in MAME, the parent set, which is presumed to be a World release is the most polished of the two, it has a full attract demo cycle showing gameplay, it shows the game level ‘Rank C’ before each round, it calls the player lives ‘TOM’ in test mode, and represents them onscreen with a little icon showing your guy in the top left corner. It’s also censored, because the game is actually an ‘adult’ game, believe it or not (probably easy enough to believe, it’s from Nichibutsu)
The other version in MAME was an older version, it’s uncensored, it lacks a full attract demo, or the level display, and uses a water tank icon for the player lives, calling them ‘TANK’ in test mode (which until you realise means water tank, is a little confusing)
Just before 0.155 Andrew Welburn dumped another set of the game, and it seems to be an even older set. One interesting thing about this game is that the graphic roms differ slightly between revisions, obviously in part due to one set having censored graphics, and the other not, but also details live the lives counter icon previously mentioned.
There were two things of note with this new set, first of all the tile the contains the lives counter symbol on the previously mentioned sets is a blank tile, second the part of the main CPU rom that the protection MCU runs is encrypted (all sets of the game use a weird setup where the protection CPU just runs code from the main CPU, more like a sub-cpu than a protection cpu) This was a simple bitswap on the opcodes only, but is still an interesting difference. Once that was all figured out and the game booted it was clear why the lives counter tile was blank, this set, instead of using a symbol in the corner, uses a graphic near the high score text made from existing tiles, indicating it’s probably an earlier set than either of the previous two.
It’s always nice when new clones have actual visible differences, especially like this where it gives a snapshot into how the game was refined over time.
I’m surprised Do-Don-Pachi Dai-Fukkatsu Black Label and Akai Katana haven’t been added to MAME yet.
Shouldn’t they be old enough for an inclusion by now?
can’t really add something without dumps of it, and nobody doing dumps wants to dump them (several do own both games tho)
I knew some people close to MAME were in possession of the PCBs, but I didn’t know they were refusing to dumb them though.
Thank you for the reply, I really hope those games will be preserved in time before the flash chips die (from what I’ve heard they aren’t particularly long-lived).
Sf2ce M9 looks awesome too, but has fadeout (when you end a round), this bootlegs not has this effect
indeed, very pleasant to listen to…
make this one parent set !
Saidaioujou as well.
The parent set should always be the original commercial release, in my opinion. Unfortunately, that’s not what happens. Thought about changing everything around for my own build, but there really is no benefit other than the satisfaction of having done it. Not sure how I would handle prototype sets.
Quite often we don’t know what the first official release was, we have early builds of a lot of games that might have been prototypes but we really don’t know, then take things like the Midway games where they called some of the most common widespread releases ‘prototype’ builds.
That’s why in the majority of cases we use the final known official version as the parent. I still think we should use ‘country of origin’ as the parent rather than ‘english language set’ but that’s another debate.
There are always exceptions, but a *known* bootleg should never be the parent, unless there’s no dump of the original at all.
YES，Danger Express have never been released and this is an interesting prototype game
That would not be added for another 3-4 years even if it was dumped.
Danger Express is not supported at the request of the board owner.
The missing MCU for Riding Hero and League Bowling (Neo-Geo) surfaced:
https://wiki.neogeodev.org/index.php?title=HD6301
I think it’d be better to consider the parent set on a case by case basis with a documented reason rather than blanket selection by country, first release, or language.
Take for example Xexex – the Japanese version is the original release and widely considered superior to the export releases.
Whereas if you used the original Japan release for Street Fighter 2 you’d end up with one full of bugs. For a continuously updated fighting game the correct choice should almost always be the final release – “sf2jl”.
I’ve been considering starting to tackle a list of superior parent sets for a while now, maybe I should get on with it.
I already know that. The date of each game tells when they gonna be released. Maybe 2017 or 2018.
since ume152ex3 plz help me, gameboy savestate .sta doesnt work anymore after ume152ex2
Could you be more specific about “doesn’t work”, and did you try it in 0.155? There were gameboy related fixes in the final that weren’t there earlier.
thx for help
when i try to load savestate give me that error: unable to load state due to an invalid header. make sure the savestate is correct for this game.
Which game and what version of UME did you use to create the savestate initially?
I just tried a few random games from the GB software list with 0.155, created a savestate, closed MESS, then re-launched said games and it loaded savestates successfully here.
pokeyellow on ume 0150
If Softlist loading (mess gameboy pokeyell) I ran and won the first battle then created and successfully loaded the state with 0.155
I don’t know where to get UME 150 from and if your full path loading different hashes of dumps than what’s expected in gameboy.xml (pokemon – yellow version (usa, europe).bin CRC32 7D527D62
Maybe that’s why you’re getting header issue?
actually, the savestate works fine too in ume 0152ex2, was the last after nvram fix…
before*
Speaking about save states for a moment, are they supported or unsupported for Genesis/Megadriv?
I notice with some games in the list such as btomato & zoopu upon loading a state you get gome GFX missing things like the Tomato is a black shadow etc.
I also find it weird if I’m playing a random game like sonic then save state to position 1 (say in a scenero you’re interrupted or must leave the computer)
Then some time later (could be days or weeks) if I’m playing a different game and save state to the same position 1, it completely overwrites the previous file without any kind of warning to the user.
I imagine for the average user it’s not force of habit to check how many positions you’ve used especially if you jump around to many different systems.
gameboy savestate .sta of ume 0152ex2 can be used in ume 0155??
The header errore might be due to newer versions saving more things than previous ones. As such there is no other solution than keep using the older version. Or load the state in the old version, reach a save point so to save on sram and then to load that sram into newer mess/ume
Concerning mega drive saves: there is a bug report on mt because something is wrong with vdp bitmap. I hope we can find a fix or we will demote the driver to no supported saves
finally, it’s up to the user to remember the save slot and to reload it with the same cart inserted. It usually helps to use the savename option to keep saves for different games separated
re: gameboy states not working in current version.
Save States are not guaranteed to work across different versions, too much changes in MAME / MESS all the time, they’re actively developed projects where we’re always striving to improve the code, the inevitably means the data that gets saved in one version has a low chance of loading in another.
re: overwriting of NVRAM (battery ram) when loading states
This isn’t a ‘simple’ problem. Keep in mind that part of the current state (snapshot in time) IS the NVRAM, and if a game was to be using that as work ram (instead of saving game data to it) then the save state wouldn’t work if we didn’t save it, so we save it. Most other emulators do not, which is a little more user friendly, but actually incorrect.
This is more of a problem when emulating computers etc. Technically a save state of a computer with HDD should include the entire content of the HDD (as it could contain temp files being used by the current application) This of course also means that if a user loads an old state the correct behavior would be to revert the hdd to the state it was at that point, so if they’d created other documents, or installed other software those things would be lost. Again however, not saving the full state could result in the very application you’re trying to save the state of failing because the files it was actively working with would vanish if not saved.
As you can see, it isn’t really an easy problem to solve. The guaranteed to work method is not always what the user expects. A state is literally taking you back to an exact point in time.
re: Megadrive not saving all graphics / audio etc.
I’ve noticed that too, even prodded people a few times about it, something must be missing from the state, but eta declared it working.
ah, nice, surprised he didn’t contact us directly, he contributed those very interesting Alpha Mission 2 and Burning Fight protos in the past :-)
no
btw, i have put forward a suggestion to micko that we
a) store save states as .7z files with a directory structure containing the various elements we saved
and
b) make a ‘best attempt’ at loading state files even if they don’t perfectly match – in some cases they’d probably still work fine (for example, cases where we add a variable to a state but a specific game doesn’t care about it, and so it can be left as it was. Right now it would fail to load the old state because we’re very strict, when really the old state would work fine because the game doesn’t care)
obviously none of this will help older states (it will render them all unusable due to format change) but it will make things easier going forward. Micko has made a note of this type of thing in his roadmap, so hopefully it’s something we can work towards. It would also mean that if somebody wanted to delete the ‘nvram’ file out of a save state (so that they could load that state without changing the state of the nvram) then they could simply delete it from the .7z state file, and MAME / MESS would load the state and simply not change the nvram content on load (instead put out a warning that it was missing from the state)
also no, I haven’t finished doing the writeup for 0.155, I still want to cover the new frisky tom set amongst other things because it’s kinda interesting (probably an earlier revision, and encrypted)
99% of the time it will be ‘newest version from country of origin’ (except in cases where we’re missing sets)
that’s kinda what I was saying, for most games I feel the parent set should be the newest Japan release, but obviously for things like Atari, the newest US versions.
however, making such a fundamental change is likely to piss people off, and there is sadly a large part of the population that won’t touch a Japanese original, even if it offers the more correctly balanced gameplay. For text-heavy RPGs on consoles they might have a point, but the number of arcade game where text / story is important to understand are in the minority, they’re usually kinda obvious ;-)
for our console emulation it’s actually more annoying, nobody really wants PAL (europe / world) as the parent because many games weren’t well adapted to run at 50fps, and there are inconsistencies in some of our softlists at the moment that confuse. Of course some of the PAL exclusives are actually rather good ;-)
I don’t know if this is possible or not, but it would be very nice if MESS gained the ability to create a folder with the name of the set you’re currently playing, then saved the .sta file in there, so save files can be organized based on the sets you launch instead of dumping everything in a root directory.
So if I ran *mess64/ume64 genesis sonic* then saved a state to position 1, the file would be located at sta\genesis\sonic\1.sta
again it’s a bit messy, because if a system had an internal RAM area that would be part of the system, not of the cart.. therefore associated with the system name, not the cart name. (SegaCD internal backup ram for example)
although purely for the sake of appearing how you want I guess it would be possible to use the primary / secondary software list name as the state folder (although deciding which is again tricky, for PCECD the primary cart is the CD adapter, the cdrom is a secondary device..) likewise for Megadrive games with the game genie, the main cart slot has the game genie, the secondary cartslot (created by the game genie) has Sonic in it… so the reality is that the save state is always the state of the Genesis, not the state of the game (which I can understand why people have a hard time understanding)
basically once you have something like MESS, a proper emulator trying to do things in a proper way Save States aren’t a simple user-friendly hack for saving your position in a game, they’re the state of a machine, and that entails a lot more.
I know this is why some people preferred the way I did things in HazeMD where every MD set represented a single completely independent genesis running a single game, but that was a bit of a hack really.
The only way MESS could do similar is if in addition to the softlists we had a list of aliases for preconfigured systems with carts etc. locked in – taking away any of the flexibility in those cases and treating each alias as a machine in itself, capable of running one game only, an instance completely independent from the base machine.
That doesn’t really scale beyond simple cartridge based systems tho.
Our desire to do things properly make it a more difficult problem than you would imagine.
MAME/MESS emulate machines, not games, although in places we have slipped into referring to things as games when they should not be, for example the GAME_NOT_WORKING flags which are still used even for terminal computers. I’ve already proposed we change our terminology to MACHINE_NOT_WORKING tho, because it applies equally to an arcade machine (aka an arcade game), as well as any other machine, and is more correct.
older versions does not support nvram, this is why i am trying to use newer versions, because since the repair of nvram my savestate no longer works…=/
That is what savename option allows
just use savename %d_cart
Am I just old and slow or does Frisky Tom cheat like a son of a bitch? That pink mouse often hurls himself at me within the first three seconds of the game. It also sometimes teleports a few pixels over when I’m about to get out of the way. :)
I think the problem you are running into is a poor definition of what is ‘best’ and because of a side effect of where MAME merged roms came from. That definition works very well for v1->v2->v3->and so on. But it fails badly when games become custom for a particular region. There are particular versions for each region but no one ‘best’ version or even multiple ones. I think what you are describing is really a display issue (though it can have uses in the ‘merged’ area). Perhaps ‘grouping’ would be a better choice with a language and region tag on the game? This problem is especially noticeable in the MESS area. Where there may be 5 different versions of a game. But each one is just regionalized. Which one is ‘best’? They all came out on the same day and have the same bugs…
Like for me I know there are tons of very good games in japan. I can not read the language. So I have little interest in them. So I may use an ‘inferior’ version. But does that really mater? I dont mind that data is there. But it would help immensely to filter data such that only english/usa/latest shows .
I think there is missing information making picking ‘best’ for the end user a struggle. Even my suggestion may be the wrong addition for tags. But it would not hurt and is at least not ambiguous like some tags (like game type). At least it is more clear and would let you do things like ‘best for a region’? Even that may not work as you get ‘tournament editions’ which really are derivatives many times. Right now also you see it in the rom collections and even in the soft-lists. They are trying to do it in the file name where it does not really belong. As it is meta data. It is setting off my ‘reusing a field for something it is not meant to do’ sense. Tagging 32k in titles though would not be for the feint of heart.
Thanks eta, that’s a bit better. How would I alter %d_cart to include the genesis folder?
If I run *mess64 genesis sonic* it puts a sonic folder in the root of sta directory.
Having just set name folders thrown into the root of sta is still a bit messy, especially for someone running many different systems.
Hi haze,
really surprised to see all these bootlegs added to latest MAME release. I know adding bootlegs is not the most interesting part for a dev as most of them are just crappy bootlegs with offering nothing…But i’m happy this time to see one dev according some attention to them.
Best regards,
JacKc.
sometimes it’s worth digging through them to see what you find. most are uninteresting, but it’s good to get them out of the way so that nobody else ever has to waste their time on them. others, like this mario one, are more interesting and make the process feel a little more worthwhile ;-)
> I’ve noticed that too, even prodded people a few times about it, something must be missing from the state, but eta declared it working.
erm… have you considered the possibility that I had tested saves with several games without problems before adding the GAME_SUPPORTS_SAVE flag? ;)
I had tested Sonic 1, Sonic 2, Robocod, FIFA, Sparkster, VR, Madden, Thunderforce IV, OutRun and a couple of others in many levels and creating a dozen of saves for each, everything re-loaded with no problems at all
however, such a test was not enough, obviously. for instance because in Sonic 2 I had always reloaded the states after getting in-game, while reloading it at the very sega logo would have produced a glitch
since you are the one who best understand the Genesis VDP code (being the one who wrote it), I was hoping to have some support by you about what is not being saved/restored properly, before demoting the game to not supporting saves…
it uses the same syntax as -snapname, so you just do
%g/%d_cart
to get a sta/system/*game*/ forlder
of course, you might want to replace %d_cart with %d_flop1 or %d_flop2 for home computers with disk games, etc.
> again it’s a bit messy, because if a system had an internal RAM area that would
> be part of the system, not of the cart.. therefore associated with the system
> name, not the cart name. (SegaCD internal backup ram for example)
the reason why everything has to be kept in a single game-based save state is that if you alternate playing between game1 and game2, which both write to the system RAM, you’d want such a RAM to be reverted to the state expected by game1 when you load the save for game1 and to the state expected by game2 when you load the save for game2
this is where the -savename option comes into help, by allowing to store save states in separate folder for separate games, including the changes to the internal RAM
then we can change the container from .sta to .7z or whatever else, but most of the flexibility is already there…
things are different instead for NVRAM/SRAM saves, which stores separately the system nvram vs the cart ram, because those are typically independent
yeah, I fully understand WHY it’s done, and our behavior is correct.
The problem is if a user plays a game, uses the internal RAM of the SegaCD to save game data, then loads another game, and loads an old save state they created a few weeks back, all that game data will be gone for good.
It’s correct behavior because we emulate *machines* and the save state represents the entire state of the machine at the time they made it, but it isn’t the behavior they expect, which is unfortunately a broken behavior for the reasons we’ve stated.
What I would propose is actually we have a concept of ‘titled machines’ or ‘numbered machines’
Right now MESS emulates 1 machine called ‘segacd’, every game you run is running on that 1 SegaCD. It’s the same for every system in MESS, and sometimes this isn’t the behavior somebody would want.
If you could add a “-machinentitle andy”, “-machinetitle dave”, or “-machinetitle testrig” to the commandline then you have a named alias for that machine, effectively owning 3 segacd units instead of one, each of which could have an independent internal state.
of course that isn’t perfect, in some cases maybe it’s a plug in device (or even just cartridge) that has internal RAM, you might want to be able to ‘own’ multiple copies of the device too and likewise have each save out it’s own internal NVRAM (I own 2 physical cartridges of Sonic 3, each has it’s own battery, playing one does not alter the other).. so I’m not sure how you’d do that in a clean way.
so i will lose my .sta savestate without ume that supports .nv file sram?
That is extremely useful. Thank You so much eta.
Always learning something new everyday, that’s why I continue to stay fascinated with the projects.
Thanks again!
It’s been interesting to follow the discussion about parents and about save states. How exactly does the parent concept work? Are idividual files that are identical to the ones of the parent omitted or are files diffed and only the diff included? If not, would there be any reasonable gain if diffs were used? Would it be useful to use diffs for save states?
It depends if you have a ‘full merged’ or ‘split merged’ or ‘full set’. Full merged every thing is in one file with duplicates between child/parents omitted and contained in one file. Split merged is the same thing but the child sets are split out and still do not contain the duplicate. Full set is split out and the duplicates are contained in the child set.
They will all work if you name everything correctly. With a merged set any roms that are the same between the child set and parent set can be omitted in the child zip/7z file. It will get them from the parent set. The devs pick a ‘parent’ set. Usually they try to pick the latest version or best for the original release region. Depending on the developer. Hence the discrepancy about what is parent. As releases can be either a straight line dependency or a tree. When it turns into a tree what is ‘parent’ gets muddy depending on who you are personally.
Diffs on save states only come into play with chds. As it those are hard drives which in theory the software can write back to. Some of the other emus out there have the concept of save state diffing. This prog does not have that right now. It is usually useful if you are doing things like tool assisted speed runs (like finish super mario in 5 mins). There has been some hesitancy to add features like that to MAME/MESS. Each dev has their opinion on it.
The problem they are running into with the save states are 2 issues. First issue is they add and remove things from their internal structures. So what gets save changes sometimes from version to version. If it works from version to version is usually just luck that no one changed that area of the code. The second issue is how save states are associated back in mess. I have not tried it so I may have this wrong (as most of what I play has an nvram area). But apparently you can save a state only at the ‘machine’ level. So you save a state and you were playing game1. You load back up but load game2. The state would be restored but the game would likely just crash as the game does not match up and then erase the state. This worked very well in MAME as 1 machine is one game. But in MESS it is one machine with hundreds of bits of software. The effect would be much like yanking a cartridge out of an atari and jamming in a different game.
It sounds like whatever is in the state should also contain the command line params passed in. So it can match them up to the correct one (which may remove the need for the possible solutions suggested so far). They are considering ‘slots’ or ‘aliases’ to help mitigate the issue, does not look like they picked a way yet.
> The problem is if a user plays a game, uses the internal RAM of the SegaCD to
> save game data, then loads another game, and loads an old save state they
> created a few weeks back, all that game data will be gone for good.
only if they don’t save any state with the later game. otherwise
>
>It’s correct behavior because we emulate *machines* and the save state
>represents the entire state of the machine at the time they made it, but it isn’t
>the behavior they expect, which is unfortunately a broken behavior for the
>reasons we’ve stated.
I’m not sure I fully get what you mean, probably because I have different use cases in mind.
Save data contain *both* machine and cart data, not only machine: users should keep in mind that the save state contains data for the combination “hardware+software” they are currently playing and, if they change anything in such a configuration, the save state might well misbehave at reloading (for instance, the current rom bank for large carts is always contained in the save, but if a different game is loaded, the bank number could be an invalid one for the new game)
this is exactly the way other console and home computer emulators work, and I don’t believe it can confuse anyone who had any previous exposure to console emulators, if not for the fact that they have to choose the -savename option
in this case, it’s possibly MAME doing a bad service conveying the idea that saves are machine-related when they actually are (machine+software)-related
what we could do (and I hope we will do) is to avoid crashes at reload, e.g. by separating as you suggested the machine data from the game data, and only reloading the matching part… but in this case we would be doing something non-standard that most other emus don’t and that could possibly confuse users if we don’t provide enough explanations about which cases each behavior is more useful in
however, the -savename option does fairly its job to match other emu’s behavior, pairing the saves with the current loaded games, and the only case where things can go wrong is when a game requires multiple media to be setup (e.g. a cart + some floppy) and all media devices have to continuously access the media during gameplay, because in such a case if you load the state without the exact disks inserted game could not be restored properly (OTOH, if e.g. disks are only accessed at start, restore would work because the data in RAM would be recovered)
>of course that isn’t perfect, in some cases maybe it’s a plug in device (or
>even just cartridge) that has internal RAM, you might want to be able to
>‘own’ multiple copies of the device too and likewise have each save out it’s
>own internal NVRAM (I own 2 physical cartridges of Sonic 3, each has it’s
>own battery, playing one does not alter the other).. so I’m not sure how
>you’d do that in a clean way.
if the game does not support multiple SRAM slots, your only way out is to have two copies of the game with two different filenames, so that nvrams are named differently and they don’t collide
>So you save a state and you were playing game1. You load back up but load
>game2. The state would be restored but the game would likely just crash as the
>game does not match up and then erase the state. This worked very well in
>MAME as 1 machine is one game. But in MESS it is one machine with hundreds
>of bits of software. The effect would be much like yanking a cartridge out of an
>atari and jamming in a different game.
sorry if I repeat myself, but by choosing the -savename option properly, you get the effect that different games put data in different folder and the scenario you describe works almost flawlessly after reload too, with some possible side effects only in combination to altered nvram files you might want to preserve (which is however not the “standard” scenario, since only a few systems save data on the main nvram, like segacd, saturn and n64)…
I think you’re kinda missing my point, but ok. I’ll try and think of another way to explain it.
Basically without some kind of ‘profile’ system MESS can only emulate one of each device / system because some bits are always shared between sessions etc. sometimes people would like more, something they know is completely independent from another session and that nothing they do is going to influence the state of a different named profile. (internal nvram etc.)
that can apply to whole drivers and individual devices.
like I said, right now MESS lets you ‘own’ one segaCD unit, what if you wanted to own two, each with it’s own nvram
yes, I know you could specify a different nvram directory, but I’m talking about not only nvram, but any config switches too, on a per-driver, per-device basis if the user wants..
and I think it’s fair to say MESS emulates machines, and saves the state of the machines, as does MAME. A save state contains the state of the machine, including the entire configuration of that machine, which includes the cartridge (aka game) state. Other emulators only save the state of the running game (ignoring internal backup ram of the machine etc. and just hoping things will work) because they emulate games. It’s one of the fundamental differences with our emulator, so I’m surprised you seem to want to deny it? I’m not saying we do it incorrectly, we don’t, MAME / MESS have always been machine emulators and tried to save the entire state of machines.
I’m not saying that we are doing anything wrong, I’m just trying to better understand you opinions on current support and possible desired features
and in the process to clarify a bit the -savename option that seems to confuse many (if it was not clear to B2K24 which regularly uses the emulator, I expect it to be even more obscure to new users)
>Other emulators only save the state of the running game (ignoring internal
>backup ram of the machine etc. and just hoping things will work) because
>they emulate games.
well, it depends on emulators: many save also each internal console RAM/VRAM/WRAM chip that could be needed to properly restore the emulation state, like MAME/MESS do…
also you talk about “different nvram directories”, but what -savename does is to setup separate sta/ folders for internal save states not for SRAM/NVRAM only
anyway, you are right: I had indeed misunderstood what you meant about a single unit.
so in conclusion yes, MESS only allows you to own a single console and a single copy of each game. if you want to emulate something different you have to set up your own workaround by keeping track of what files you used with the various games so to backup them when a different game risks to overwrite it
thanks for explaining what you meant :)