Savestate Support - Improvement and Requests

[mahoneyt944]

1799 #1433 Moving these issues to a dedicated section as they are essentially the same type of request. Savestate support in this core is basic, many drivers(roms) are not supported and must be fixed on an individual basis which is very time consuming. This can cause many issues such as failure to allow saving/ loading at all, unsupported auto_savestate features or incorrect behavior of, as well as jumbled graphics or audio failure when loading savestates.

This issue ticket does not guarantee support will be added for any particular game, but submissions will be considered on a case by case basis.

[mahoneyt944]

Request: segas32 savestate support fix https://github.com/mamedev/mame/commit/90152f33d5114828a53f38fc9a1913af71e683d6

[schmurtzm]

I understand that the diag of this issue is time consuming due to the number of drivers, however if your trigger the save state once the game (and all its assets) is totally loaded then the issue would be solved for all the games / drivers in one time.

Some solutions / Workaround were given in the #1433 and their implementation were not tested (probably due to the bad atmosphere between the interlocutors... so I think that it is a little a shame to close it for now but yes, why not testing the solutions previously proposed here). May be it deserve a more clean implementation but a temporary working workaround would be very welcome anyway while a cleaner solution is being put in place 🙂

(The impact of this issue on mame2003+ is major, many handhelds have auto save state enabled to resume at power one so many distribs are using mainly FBNeo just because of this problem... that's a shame)

[mahoneyt944]

@schmurtzm Each game has to describe specific variables in which to save from and load to each time. Miss even one of these and irregular things can happen when you save and load. Many drivers are missing these descriptions per game..... so there is no "one for all solution".

Auto savestates could be improved on as a feature, but until the above statements are true for all games, many games will still have improper behavior unfortunately.

[carlosefr]

If the savestate in this core is game-by-game, could the core refuse to save states unless the game is listed (somehow) as supporting them?

I probably wouldn't have opened #1799 if the core had refused to save. But since it did save, I was bummed that I couldn't restore it on restart.

Now, I understand that this would mean that, from one build to the next, a lot of games that might sort of work would suddenly refuse to save. So, it would need some sort of "enable experimental save states" core option to get the old behavior back (and also allow users to test save states with games yet to be marked as functional in that regard).

[mahoneyt944]

Problem is some games have partial support, enough to make and load a save, but not complete enough to actually work as intended and there isn't a list specifying the level of support in this core per game. Later mame added a savestate support flag in the driver for this, which we don't have. So it's a guessing game which are supported or not.

[carlosefr]

That's why I suggested putting this behavior behind a core option. Even if, at first, only a handful of games would be known to support save states[*], it would help build a list of working games slowly over time, while allowing anyone to just "enable experimental save states" and deal with whatever issues arise from that.

At the very least it would make the level of savestate support in this core explicit. It would also reflect the "game-dependent" status mentioned in the documentation quite literally.

[*] I could try to exercise some more those I mentioned as appearing to work in #1799, plus a few others.

[mahoneyt944]

Compiling a list of known working games is possible, through community work, sure. There's also the issue noted in #1433 where the savestate works fine when loaded manually, but not as an auto load state which is working and not working on a per game basis. So it would be quite the workload to record every game under several different circumstances but it's possible.

[mahoneyt944]

@schmurtzm Here's a hacky solution to add some delay for auto savestate loading. It works for 1941, 1942, and 1943. But no real way of knowing if it will play nice with other games or not. We basically penalize state loading by 1 second when it tries to load a state earlier than that.

See if you can find a state that works manually but not when using auto with this commit https://github.com/libretro/mame2003-plus-libretro/commit/244018ddec347ac23f7d25b8c01432ae6552ba96

[mahoneyt944]

Already found some games...pacman and mspacman are not auto loading with the latest commit but did prior. In this case 1 second is too long before trying to load the file. Fix one break another, likely no real solution to this....every machine is unique.

[mahoneyt944]

Here's an update https://github.com/libretro/mame2003-plus-libretro/commit/3ff70f104963b2c4522b714cca49d684caa792ae

Uses a 5 second delay for auto load states or states manually loaded before 5 seconds. Fail safe at 10 seconds. Note: this does not fix support for games that do not already have working support, but should improve many games that fail under auto load but not manual loading.

Tested working autostates:

• mspacman
• pacman
• 1941
• 1942
• 1943
• le2
• contra

Failing:

• crusnusa
• galaga

[mahoneyt944]

Reverted commit from above. I don't think there's anyway to predict the readiness of a machine in this core to reliability use auto load savestates..... @grant2258 how do you feel about just disabling auto load savestates in the core, can't see anyway to make this work.

[grant2258]

@mahoneyt944 not sure why your asking me but fwiw the core has done what is expected.

https://github.com/libretro/libretro-core-info/blob/50aa833e885e2132bad1e919ba2ebe687cf64b91/mame2003_plus_libretro.info#L19-L20

If a user overrides these setting its not a valid issue on our end. If basic savestates are allowing auto load/save to its a front end issue imho. It would be better clarifying it the "higher ups" whoever that may be. It should be able to be over ridden in the case someone wants to work on save states .

It might be better to include arcadez2003 as he is a core maintainer and might have thoughts on it.

[mahoneyt944]

Auto is considered a "basic" feature because the API requires the core to be "ready" by the end of retro_load_game(), which mame2003+ isn't. Some machines, like crusnusa, need to load to the title screen before a state can be loaded (many seconds into the game) and this is way outside the expectation. I see no real way to account for this in a workaround, you'd have to test custom delays for every game.....that's why I think disabling the auto feature is probably the most honest solution, this would still allow manual state loading of course.

I'm not sure if the frontend tries multiple attempts to load an auto state, but I suspect simply adding this to retro_unserialize would disable auto loading, maybe with a message notifying the user as well.

if (cpu_getcurrentframe() == 0 ) return false;

If there are no objections to disabling the broken feature, I'll go that route.

@arcadez2003 is included in this discussion too.

[grant2258]

@mahoneyt944 I dont really think it matters if its disabled or not. Your time would be better fixing the save states. I think libretro definition of save states lacks any consistency or even basic meaning. I would say its more of an after thought. Your examples of save states not working are just states that need fixed properly rather than finding a magic timer that might work sometimes.

[mahoneyt944]

Some states, even the ones that are working, won't work if loaded on the initial frame, like 1943, otherwise it works fine. How would this state be fixed?

[grant2258]

1934 clearly isint working properly just because it works after a frame doesn't mean it working somethings clearly missing have you checked the cpu soundcores /sound and gfx, or are you assuming because it works after a certain time its fine ? Im not sure how your evaluating the 1943 savestates are working.

I checked the driver I dont see any save state registers unless there hidden someone other than the driver at all in the so its one that could probably easily be fixed

[grant2258]

@mahoneyt944 i enabled auto load and save and it doesnt appear to do anything is there are you sure you over rides arent on? Just trying to see what the issue is for this game in particular.

Since the auto loads arent triggering for me

add this at the start in the 1943 video start. I think that should fix the issues

state_save_register_UINT8("1943", 0, "c1943_scrollx", c1943_scrollx, 1);
state_save_register_UINT8("1943", 0, "c1943_scrolly", c1943_scrolly, 1);
state_save_register_UINT8("1943", 0, "c1943_bgscrolly", c1943_bgscrolly, 1);

state_save_register_int("1943",    0, "chon", &chon);
state_save_register_int("1943", 0, "objon", &objon);
state_save_register_int("1943", 0, "sc1on", &sc1on);
state_save_register_int("1943", 0, "sc2on", &sc2on);

edit you need to add #include "state.h" as well

This does fix the issue the save state is working now. I had to over ride the core save state for it to work to basic doesnt auto save but auto load does work if a state is there I think that might be a bug. There is a an issue with the sound not picking up looks like the fm was updated youll need to add the save states from mame0127 or just revert the fm core updates to restore the old ym chip family savestates whichever one you think is a better. I checked with neogeo that ym chip is saving fine and it appeares save states are in order could be interrupt need saved you'll need to look into the sound thing more if you want to work on driver to deliver sound properly as well.

[mahoneyt944]

I'm sure there's hundred of games needing support fixed but the reality is no one of going to be able to fix all of them to make auto states work properly. Right now a lot of hand helds are using auto states as a default option, so this core generally is loading working games incorrectly. If we disable auto loading, at least the games won't crash on load when/ if savestate support isn't perfect per game.

2 games that are extra bad on load crusnusa and galaga

[grant2258]

Well if ther use never applies the core info override the issue will never happen as the auto saves wont happen with basic. The fact it works on auto load is in basic is a frontend bug for sure.

Changing settings to what the core shouldn't do causes the issue so its something that should be fixed properly for all cores in the fronted with basic save states. If you feel strongly about it do as you wish its not really the core causing the issue seems a pointless endeavor fixing it here and leaving the issue wide open to other cores. You would be better fixing RA itself to not auto load basic save states.

edit: for 1943 you would need to either hook up the mcu or the improved protection to hook up the sound properly. These things are fixable for sure but I simply have no motivation to since I don't use this core or RA. I wouldn't see any benefit from it. I dont mind fixing things that other ports will find useful or benefit from like adding games or updating audio/cpu cores as other ports would have some benefit from them updates.

[mahoneyt944]

I can verify if basic should be including features such as auto states or not with libretro. I know this isn't the default setting for RA as I use all default settings and it's off by default. However, if many handhelds are forcing this option on, users of this core will have bad experiences on handhelds. I'm under the impression that everything being "ready" by end of retro_load_game() is essential for many features to work properly, such as run ahead, rewind, savestates, etc. I don't believe there's a build flag to disable auto states specifically, just the menu option, so a workaround might be necessary. I'll see what I can find out.

[mahoneyt944]

Auto save and auto load both function for me. If I go to setting and toggle on both options then start a game like baluba, get into game, open Ra, close content. baluba.state.auto is created, then on load it auto loads

[grant2258]

Strange I have to goto setting->core and over ride core in for auto save to work. If your editing the core info make sure its not cached in core settings as well. Also check your core info file or update them. If its just an android issue you should open a ticket in RA and mention the load works in basic as well. Hacking a core for front end bugs is the last thing you want to do. Not sure what the correct behavior should be you should ask I re tested and auto save doesnt work on linux when save states are set to basic.

[mahoneyt944]

Retroarch 1.17.0

[grant2258]

@mahoneyt944 thats a really old version of RA at saying that, the save states work on the rasperry pi on the current retroarch master with basic saves like your getting.

The latest commit on manjaro linux wont autosave unless you set the core override. There is also a double setting for the core saves so something funky is going on with RA. Im sure Ra will pick it up sooner or later for the auto saves not working properly in manjaro linux.

I did look at the saving code and basic should trigger the auto load/save the solution is change the core info too savestate = "false" on the repo and use the override to enable it for testing.

you can see the duplicate setting the first two.

[mahoneyt944]

Hmmm I wonder if it designates a "save file" differently than a "savestate file"? That is odd.

[mahoneyt944]

Just installed 1.19.1 and auto state save and loading works still. Tested with cclimber

[grant2258]

not sure whats happening as it works on the pi and I peeked at the code basic saves should be auto loading/saving so its a bug in there somewhere that will effect all cores. Anyhow thats unrelated to our issue setting savestates to false should fix the issue https://github.com/libretro/libretro-core-info/blob/master/mame2003_plus_libretro.info is where you want to put the changes. No need to disable anything on the core level thats some good news.

[mahoneyt944]

I'll ask libretro if they want to set it false in the info file or disable auto loading from the core. This will effect mame2003 too. Doesn't matter to me as long as things work

[mahoneyt944]

So after talking to libretro, it seems if we set support to false, this will also ignore the basic, serialized, or deterministic option too...meaning it's disables all savestate features unless a user bypasses this under settings->core->bypass core info savestate features (advanced options must be enabled to see this). So setting false would not allow users to manually load and save savestates either. In this case if we want to preserve manual saving and loading, we'd have to disable auto load on the core side.

[mahoneyt944]

@schmurtzm this should prevent autoloading savestates even when the setting is enabled, https://github.com/libretro/mame2003-plus-libretro/pull/1812

Let me know if this behavior improves the handheld experience. Savestates can still be loaded manually, but not all games will have working savestate support.

[grant2258]

this will also ignore the basic, serialized, or deterministic option too...meaning it's disables all savestate features unless a user bypasses this under settings->core->bypass core info savestate features (advanced options must be enabled to see this).

All these states will be effected they wont work properly its makes sense to disable it on the front end level . There is also no way to this super option off., Unless someone is willing to work on the save states like the example I gave you on 1943 it would be best to disable them until they are worked on.

There is also the issue that it will save on exit and people will post issues that auto load is broke. Youll need to stop the auto save on exit as well to avoid issues.You might want to put a frontend notice up its disabled to avoid issues.

I dont use the core anyway so maybe someone will want randomly functional savestates who knows. It does seems a big effort to keep something that partially working that will open up issues that no one is willing to fix.

It you want people to work on save states you might want to make the function turn on if your not so bothered leave it as is. Its only a RA functionality so it wont really effect the core. A more sensible solution would be set auto load/save requirements to deterministic as thats whats needed for it to work.

Just for notes auto save is broken on manjaor x64 im not sure why though, so that caused some earlier confusion. It could be related to some of your delay changes because fbneo saves the state fine I know you where messing with this code so the good news not something that need reported to RA and the pi was using an older version of the core pre you changes.

[mahoneyt944]

All those delay changes were reverted.

For the time being auto load / save are basic features, the case is made that these should be at least serialized. But until then, there's no way to disable the feature so we need to disable it to still allow manual loading of states. A lot of savestates do work, so I don't want to totally disable them all.

No matter what it's a lose lose. It is what it is.

[grant2258]

At least RA has common sense to disable rewind and runahead. Its a shame they can apply the same logic to auto load. The thing is for anyone working on this the skipping the first frame could potentially cause issues in drivers like neogeo that do work. I doubt anyone is going to fix save states anyway is a really odd way to work around what is imho a front end oversight on the auto load.

@mahoneyt944 there is still work to be done 1943 still does the same thing if someone over rides the savestates it will cause the autofile to be created and load even after the override is disabled. The user will need to delete the auto file to function again so the fundamental problem is still there that only disabling the saves will fix. Unless you can find another solution its still problematic.

[mahoneyt944]

Overriding the savestate settings is experimental at best, and not supported. So I don't plan to cater to anyone trying to do that.

I'm not sure I'm following what you're saying. Using the default settings, Auto loading is disabled meaning the frontend shouldn't be able to load the state automatically, but that doesn't mean a user can't decide to manually load this file after the fact. We just don't want games to crash at startup automatically. What a user does after the game starts isn't for me to decide.

You can also file a ticket with RA to move the auto features out of basic, I know that affects many cores. Not just us.

[grant2258]

Overriding the savestate settings is experimental at best, and not supported. So I don't plan to cater to anyone trying to do that.

as is auto load/save you seem to cater for them.

I wouldnt waste my time on anything libretro because they are happier for people to make messes of cores instead you end up with situations like this. I dont see this going anywhere productive the issues still remains of auto loads being problematic. The frontend does supply a solution there is no need for a ticket.

mame can also handle states internally again doesnt need to be an issue at all just got through mame to load states.

[mahoneyt944]

I don't see how disabling the feature is problematic, it doesn't work anyway. The states shouldn't automatically load on their own using the latest commit. If you can get it to automatically load then document what steps you take to get it to and we'll take it from there.

[grant2258]

@mahoneyt944 they do load your fix prevents the saving not the loading if you override the and the state is there it will still load. I tested it. After all is said and done it is what it is half a band aid. People experimenting will still have issues of games not loading. Someone changing default settings should just disable them that or set savestate to false is the only real solution. If we dont meed RA basic states mame should handle the states in that case.

[mahoneyt944]

Idk what settings your using. Not a single game automatically loads a state when I have the option enabled to even when bypass info file is on.

[grant2258]

Idk what settings your using. Not a single game automatically loads a state when I have the option enabled to.

1)overide core states load 1943 or any game 2) exit and the autosave is stores 3) undo overide core states load 1943 or any game game has issues due to state existing (sometimes maybe more no that a frame is skipped)

reasons this could happen someone could enable for a game that works with states. Result the fix doesnt really fix anything in way that would keep the core stable with experimental options when disabled/enabled. I do think it something that needs addressed or just disabled and let mame handle states internally so the functionality is there without the headaches.

[mahoneyt944]

3) undo overide core states load 1943 or any game game has issues due to state existing

This doesn't happen for me. In fact the log tells you it fails to load. So unless you're on an old build or something it's your settings doing something different.

[MAME 2003+] Core is incompatible with automatic savestate loading.
[State]: Failed to load state from "/storage/emulated/0/RetroArch/states/mspacman.state.auto".

[grant2258]

I am at the latest commit for plus will take a sceen shot and post the log.

Commit 8ffa3c773640956c02dfbcd7d5dc8e3a12fc6773 (HEAD -> master, origin/master, origin/HEAD)
Author: mahoneyt944 <49591133+mahoneyt944@users.noreply.github.com>
Date:   Sat Jul 27 23:11:41 2024 -0400

[MAME 2003+] Core is incompatible with automatic savestate loading.does not activate here for some reason. Using RA RetroArch 1.19.1 (Git 33d9def3b3)

I added log at the start it doent even call the function on the latest RA. What version of RA are you testing on?

[mahoneyt944]

I'm using the latest stable build installed yesterday

[mahoneyt944]

Are you using the default info file? Setting support to false won't call this function at all

[grant2258]

yea im using the default info file its not that. Your commit is from the 5th of june ill test that version of ra

[grant2258]

still not getting a response with the same version of RA

troarch -L mame2003_plus_libretro.so /media/storage/Download/Emulation/roms/arcade/mame2003-plus/1943.zip -v                                        ✔ 
[INFO] [Config]: Looking for config in: "/home/grant/.config/retroarch/retroarch.cfg".
[INFO] RetroArch 1.19.1 (Git 427e3fa6f6)
[INFO] === Build =======================================
[INFO] CPU Model Name: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz
[INFO] Capabilities: MMX MMXEXT SSE SSE2 SSE3 SSSE3 SSE4 SSE42 AES AVX AVX2 
[INFO] Version: 1.19.1
[INFO] Git: 427e3fa6f6
[INFO] Built: Jul 28 2024
[INFO] =================================================
[INFO] [Input]: Found input driver: "x".
[INFO] [Core]: Loading dynamic libretro core from: "mame2003_plus_libretro.so"
[INFO] [Overrides]: Redirecting save file to "/home/grant/.config/retroarch/saves/MAME 2003-Plus/1943.srm".
[INFO] [Overrides]: Redirecting save state to "/home/grant/.config/retroarch/states/MAME 2003-Plus/1943.state".
[INFO] [Environ]: GET_VFS_INTERFACE. Core requested version >= V1, providing V3.
[INFO] [Environ]: GET_LOG_INTERFACE.
[INFO] [Environ]: PERFORMANCE_LEVEL: 10.
[INFO] [Content]: Content loading skipped. Implementation will load it on its own.
[libretro INFO] [MAME 2003+] Full content path /media/storage/Download/Emulation/roms/arcade/mame2003-plus/1943.zip
[libretro INFO] [MAME 2003+] Git Version  8ffa3c77
[libretro INFO] [MAME 2003+] Content lookup name: 1943
[libretro INFO] [MAME 2003+] Driver index counter: 1789. Matched game driver: 1943
[libretro INFO] [MAME 2003+] ==== BEGIN DRIVER CONTENT ATTRIBUTES ====
[libretro INFO] [MAME 2003+] * Supports 2 players with 2 distinct controls.
[libretro INFO] [MAME 2003+] * Supports 2 distinct button controls.
[libretro INFO] [MAME 2003+] * Uses multiplayer control labels.
[libretro INFO] [MAME 2003+] * Uses 8-way joystick controls.
[libretro INFO] [MAME 2003+] ==== END DRIVER CONTENT ATTRIBUTES ====
[INFO] [Environ]: SYSTEM_DIRECTORY: "/home/grant/.config/retroarch/system".
[INFO] [Environ]: SAVE_DIRECTORY: "/home/grant/.config/retroarch/saves/MAME 2003-Plus".
[libretro INFO] [MAME 2003+] content path: /media/storage/Download/Emulation/roms/arcade/mame2003-plus
[libretro INFO] [MAME 2003+]  system path: /home/grant/.config/retroarch/system
[libretro INFO] [MAME 2003+]    save path: /home/grant/.config/retroarch/saves/MAME 2003-Plus
[INFO] [Environ]: GET_CORE_OPTIONS_VERSION.
[INFO] [Environ]: RETRO_ENVIRONMENT_SET_CORE_OPTIONS_V2.
[ERROR] [Environ]: GET_VARIABLE: mame2003-plus_nvram_bootstraps - Invalid value.
[ERROR] [Environ]: GET_VARIABLE: mame2003-plus_four_way_emulation - Invalid value.
[ERROR] [Environ]: GET_VARIABLE: mame2003-plus_crosshair_enabled - Invalid value.
[ERROR] [Environ]: GET_VARIABLE: mame2003-plus_crosshair_appearance - Invalid value.
[ERROR] [Environ]: GET_VARIABLE: mame2003-plus_dialsharexy - Invalid value.
[ERROR] [Environ]: GET_VARIABLE: mame2003-plus_dial_swap_xy - Invalid value.
[ERROR] [Environ]: GET_VARIABLE: mame2003-plus_cheat_input_ports - Invalid value.
[ERROR] [Environ]: GET_VARIABLE: mame2003-plus_override_ad_stick - Invalid value.
[ERROR] [Environ]: GET_VARIABLE: mame2003-plus_use_alt_sound - Invalid value.
[libretro INFO] options.frameskip:0
[INFO] [Environ]: SET_AUDIO_BUFFER_STATUS_CALLBACK.
[ERROR] [Environ]: GET_VARIABLE: mame2003-plus_vector_resolution - Invalid value.
[ERROR] [Environ]: GET_VARIABLE: mame2003-plus_vector_antialias - Invalid value.
[ERROR] [Environ]: GET_VARIABLE: mame2003-plus_vector_beam_width - Invalid value.
[ERROR] [Environ]: GET_VARIABLE: mame2003-plus_vector_translucency - Invalid value.
[ERROR] [Environ]: GET_VARIABLE: mame2003-plus_vector_flicker - Invalid value.
[ERROR] [Environ]: GET_VARIABLE: mame2003-plus_vector_intensity - Invalid value.
[ERROR] [Environ]: GET_VARIABLE: mame2003-plus_neogeo_bios - Invalid value.
[ERROR] [Environ]: GET_VARIABLE: mame2003-plus_stv_bios - Invalid value.
[INFO] [Environ]: GET_LED_INTERFACE.
[INFO] [Environ]: SET_CONTROLLER_INFO.
[libretro INFO] [MAME 2003+] Opening ROM file: 1943.01
[libretro INFO] [MAME 2003+] Opening ROM file: 1943.02
[libretro INFO] [MAME 2003+] Opening ROM file: 1943.03
[libretro INFO] [MAME 2003+] Opening ROM file: 1943.05
[libretro INFO] [MAME 2003+] Opening ROM file: 1943.04
[libretro INFO] [MAME 2003+] Opening ROM file: 1943.15
[libretro INFO] [MAME 2003+] Opening ROM file: 1943.16
[libretro INFO] [MAME 2003+] Opening ROM file: 1943.17
[libretro INFO] [MAME 2003+] Opening ROM file: 1943.18
[libretro INFO] [MAME 2003+] Opening ROM file: 1943.19
[libretro INFO] [MAME 2003+] Opening ROM file: 1943.20
[libretro INFO] [MAME 2003+] Opening ROM file: 1943.21
[libretro INFO] [MAME 2003+] Opening ROM file: 1943.22
[libretro INFO] [MAME 2003+] Opening ROM file: 1943.24
[libretro INFO] [MAME 2003+] Opening ROM file: 1943.25
[libretro INFO] [MAME 2003+] Opening ROM file: 1943.06
[libretro INFO] [MAME 2003+] Opening ROM file: 1943.07
[libretro INFO] [MAME 2003+] Opening ROM file: 1943.08
[libretro INFO] [MAME 2003+] Opening ROM file: 1943.09
[libretro INFO] [MAME 2003+] Opening ROM file: 1943.10
[libretro INFO] [MAME 2003+] Opening ROM file: 1943.11
[libretro INFO] [MAME 2003+] Opening ROM file: 1943.12
[libretro INFO] [MAME 2003+] Opening ROM file: 1943.13
[libretro INFO] [MAME 2003+] Opening ROM file: 1943.14
[libretro INFO] [MAME 2003+] Opening ROM file: 1943.23
[libretro INFO] [MAME 2003+] Opening ROM file: bmprom.01
[libretro INFO] [MAME 2003+] Opening ROM file: bmprom.02
[libretro INFO] [MAME 2003+] Opening ROM file: bmprom.03
[libretro INFO] [MAME 2003+] Opening ROM file: bmprom.05
[libretro INFO] [MAME 2003+] Opening ROM file: bmprom.10
[libretro INFO] [MAME 2003+] Opening ROM file: bmprom.09
[libretro INFO] [MAME 2003+] Opening ROM file: bmprom.12
[libretro INFO] [MAME 2003+] Opening ROM file: bmprom.11
[libretro INFO] [MAME 2003+] Opening ROM file: bmprom.08
[libretro INFO] [MAME 2003+] Opening ROM file: bmprom.07
[libretro INFO] [MAME 2003+] Opening ROM file: bmprom.04
[libretro INFO] [MAME 2003+] Opening ROM file: bmprom.06
[libretro INFO] [MAME 2003+] Succesfully loaded ROMs.
[libretro INFO] [MAME 2003+] RetroArch will perform the rotation.
[INFO] [Environ]: SET_PIXEL_FORMAT: RGB565.
[libretro INFO] [MAME 2003+] 

CONTROLS: 

GAMEINFO: 1943 - The Battle of Midway (US)
1987 Capcom

CPU:
Z80 6.000000 MHz
Z80 3.000000 MHz (sound)

Sound:
2xYM2203 1.500000 MHz

Screen Resolution:
256 x 224 (V) 60.000000 Hz

[libretro INFO] [MAME 2003+] Preparing emulated CPUs for execution.
[libretro INFO] [MAME 2003+] 1943 hiscore memory map found in hiscore.dat!
[INFO] [SRAM]: Skipping SRAM load.
[INFO] [Core]: Version of libretro API: 1, Compiled against API: 1
[INFO] [Core]: Geometry: 224x256, Aspect: 0.750, FPS: 60.00, Sample rate: 48000.00 Hz.
[INFO] [Audio]: Set audio input rate to: 48000.00 Hz.
[INFO] [Video]: Set video size to: 504x672.
[INFO] [Wayland]: Compositor doesn't support zxdg_decoration_manager_v1 protocol
[INFO] [Wayland]: fractional_scale_v1 enabled
[INFO] [EGL] Found EGL client version >= 1.5, trying eglGetPlatformDisplay
[INFO] [EGL]: EGL version: 1.5
[INFO] [GL]: Found GL context: "wayland".
[INFO] [GL]: Detecting screen resolution: 1920x2160.
[INFO] [EGL]: Current context: 0x560189c8c670.
[INFO] [GL]: Vendor: AMD, Renderer: AMD Radeon RX 480 Graphics (radeonsi, polaris10, LLVM 18.1.8, DRM 3.49, 6.1.99-1-MANJARO).
[INFO] [GL]: Version: 4.6 (Compatibility Profile) Mesa 24.1.3-manjaro1.1.
[INFO] [GL]: Using resolution 504x672.
[INFO] [GL]: Default shader backend found: glsl.
[INFO] [Shader driver]: Using GLSL shader backend.
[INFO] [GLSL]: Checking GLSL shader support ...
[WARN] [GL]: Stock GLSL shaders will be used.
[INFO] [GLSL]: Found GLSL vertex shader.
[INFO] [GLSL]: Found GLSL fragment shader.
[INFO] [GLSL]: Linking GLSL program.
[INFO] [GLSL]: Found GLSL vertex shader.
[INFO] [GLSL]: Found GLSL fragment shader.
[INFO] [GLSL]: Linking GLSL program.
[INFO] [GLSL]: Found GLSL vertex shader.
[INFO] [GLSL]: Found GLSL fragment shader.
[INFO] [GLSL]: Linking GLSL program.
[INFO] [GL]: Using 4 textures.
[INFO] [GL]: Loaded 1 program(s).
[INFO] [GL]: Using GL_RGB565 for texture uploads.
[INFO] [Joypad]: Found joypad driver: "udev".
[INFO] [Wayland]: Enabling idle inhibitor
[INFO] [Video]: Found display server: "null".
[INFO] [PulseAudio]: Requested 24576 bytes buffer, got 18432.
[INFO] [Audio]: Started synchronous audio driver.
[INFO] [ALSA] Using ALSA version 1.2.12
[INFO] [Microphone]: Initialized microphone driver.
[INFO] [Display]: Found display driver: "gl".
[ERROR] Rewind unavailable because this core lacks serialised save state support.
[INFO] [Environ]: SET_INPUT_DESCRIPTORS:
[INFO] [Playlist]: Loading history file: "/home/grant/.config/retroarch/content_history.lpl".
[INFO] [Playlist]: Loading history file: "/home/grant/.config/retroarch/content_music_history.lpl".
[INFO] [Playlist]: Loading history file: "/home/grant/.config/retroarch/content_video_history.lpl".
[INFO] [Playlist]: Loading history file: "/home/grant/.config/retroarch/content_image_history.lpl".
[INFO] [Playlist]: Loading favourites file: "/home/grant/.config/retroarch/content_favorites.lpl".
[INFO] [Environ]: SET_GEOMETRY.
[libretro INFO] watchdog armed
[libretro INFO] [MAME 2003+] loading 1943.hi hiscore memory file...
[INFO] [Config]: Saved new configuration to "/home/grant/.config/retroarch/retroarch.cfg".
[INFO] [Core]: Content ran for a total of: 00 hours, 00 minutes, 05 seconds.
[INFO] [Core]: Unloading game..
[libretro INFO] [MAME 2003+] saving 1943.hi hiscore memory file...
[INFO] [PulseAudio]: Pausing.
[INFO] [Core]: Unloading core..
[INFO] [Core]: Unloading core symbols..
[INFO] [Core]: Saved core options file to "/home/grant/.config/retroarch/config/MAME 2003-Plus/MAME 2003-Plus.opt".

[grant2258]

when the state is there as mentioned above how to het I get this at the end. INFO] [State]: Loading state "/home/grant/.config/retroarch/states/MAME 2003-Plus/1943.state.auto", 68392 bytes. [INFO] [State]: Core does not support save states.

I have no idea why this is happening only on my end will test in the pi next week at some point its certainly seems there is an issue if its working on one platform and not another.

[mahoneyt944]

"Core does not support save states." Is suspect, That's a frontend message. Trace that message back to Ra and see what's triggering it or how it's trying to load a state without retro_unserialized()

[grant2258]

to what end do we trace that though itll be in tasks/task_save.c and the code ill trace will be from the 5th of june.

[mahoneyt944]

If the frontend is saying "Core does not support save states." That almost certainly has to be set by the info file, no? I have no idea why it would say that. Especially if it's not even calling retro_unserialize().

savestate = "true"
savestate_features = "basic"

[mahoneyt944]

Maybe try deleting the retroarch.cfg