Just tried it. It didn’t load the srm that I cooked. Bummer. When the core gets fixed, we shall find a way!
1 Like
Content of yesterday’s and today’s commits :
- removed the srm stuff, it was handled by retroarch by directly accessing the bupram pointer through retro_get_memory_data/retro_get_memory_size libretro api (this code was a remnant of old yabause port), however while it works for saving, it doesn’t work for loading. The size was also hardcoded to
0x10000(64kb) in the libretro code for whatever reason, while it was0x8000(32kb) in the codebase. - hooked the real bup stuff from the codebase instead, it’s now saving into its own savefiles subfolder named kronos, i further splited stv/saturn into 2 subsubfolders.
- hooked a new core option allowing to either have shared bup or per-game bup (shared file will be named shared_bup.ram, per-game’s will be named after the game)
- real bup stuff from the codebase saves 32kb files, however the hexadecimal
FFstuff is still there. Try cutting the file where you inserted theFF(ÿ) in half so it’s back to 32kb perhaps ? Afaik the second half of a mednafen savefile seems to be a padding of00, actual data seems to be stored only in the first 16kb. My thoughts are that those FF are actually present in real hardware (which is 32kb indeed), however mednafen remove them (i guess they are useless indeed) and stay with a 32kb savefile while 16kb would be enough after removing those FF.
2 Likes
So fast, and lots of good news! You are great, man. I will try now with the new version.
Yeah, we can only thank you, seeing support for a Saturn emulator is really rare. @BarbuDreadMon, please let me know if you manage to convert import saves from Mednafen Saturn, thanks!
1 Like
I’ll wait for @Squalo’s report. If mednafen’s saves work by inserting the FF everywhere and cutting in half, i’ll try to implement something to detect and automaticaly convert mednafen’s save files.
2 Likes
Thanks to the great work of BarbuDreadMon and hitomi2500 (the person that made the save manager), the method I was trying yesterday works, as expected. We can now transfer saves between all Saturn major emulators with the save parser. Potentially different file I/O modes and cluster sizes don’t seem to be an issue in the end.
aorin, you have to do the following:
-Set Kronos to save per game.
-Download SS backup ram parser from https://github.com/hitomi2500/ss-save-parser/releases/tag/0.9.5
-Click ‘load’, find your .bcr (external cart) or .bkr (internal memory) file, leave the mode/cluster size alone and ‘ok’ that window. Extract the save wherever you like. Note that it is important to know whether the game was saved internally or externally. When Beetle’s cart config is set to auto it will produce both a bcr and a bkr; only one of them should contain useful data.
-Load a Kronos .ram file. You can create one by simply playing a game on Kronos.
-Insert the save you extracted before and overwrite the one Kronos created, if there’s one. Save this new file using the same name that Kronos gave you and voilà.
If I come up with a faster/simpler method I will post it here. The ‘FF-everywhere + cutting in half’ way would be even worse haha
Awesome
Edited to correct a few things.
1 Like
Ok, the third party tool seems convenient enough, and as far as i understand we are still not sure the ‘FF-everywhere + cutting in half’ way is working, so i guess i won’t try anything else for now.
Thanks for the report !
1 Like
No we are not sure, and I hope we will not have to go that way. Thank you, man!
An update: some saves work great, others not at all. And I think I know why, the problem is neither the method nor the emulator. Thing is (I believe) that many of my saves were stored originally in a simulated external data cartridge, so some games expect to read there. That wasn’t a problem on Beetle but Kronos doesn’t support those carts, for reasons already stated by Barbu (can I call you that? Your name is too long :P), and with which I agree (in fact, I’m configuring Beetle in the same way: force the 4mb RAM cart and always save in internal memory).
I will try to transfer them to the internal memory using the Saturn bios on another emulator, re-save the game via emulated Saturn and continue from there.
I’ve managed to transfer the Mednafen Saturn to Kronos, which was originally imported from a SSF save from years ago, for Shining Force 3. Kronos shows a lot its Yabause roots, Shining Force 3 has a lot of glitches in any Yabause ports, broken character cursor, missing magic aura, missing magic effects or broken in general. Sound is off half the time, the sound effects aren’t reproduced correctly.
What I like in this core is the upscale options, which is interesting, but I still like the original resolution with a nice scanline shader.
Kronos outperforms Mednafen Saturn, I can run this game much faster with frameskip ON, which is really good for a turn based strategy game. Since Mednafen is totally emulated via software, it is still a CPU eater.
Save States are broken, trying to save/load breaks the emulator, it also totally broke the video output when pressing F for Windowed mode, turning it full screen again won’t do anything and clicking this window will terminate the process.
I know it’s really early and I think this core has a lot to offer in the near future. I’ll keep my eye on it and I’m glad a developer for a Saturn emulator is here to help us with simple stuff, like importing saves from other emulator. Which is really great!
Another update: actually it’s not that the games were looking for the save in an external cart. Some games still refuse to load their saves, BarbuDreadMon. Even if they were produced by Kronos itself. This was driving me crazy, it didn’t make sense. So it’s either the emulator or the core. I haven’t tried Kronos standalone, but Yabasanshiro saves/load ok. Two games that have this problem (there are probable many more) are The Legend of Oasis and Panzer Dragoon Zwei, both USA.
Seems to happen in standalone too, i reported the issue. Interesting fact : the save is shown when in game and you are trying to save again.
1 Like
Savestates fixed.
The issue with toggling fullscreen is known, however it’s not easy to fix, afaik even reicast is still suffering from the same issue when using the oit renderer (and we are nowhere near the amount of time flyinghead spent working on reicast), i think it’s related to the use of compute shaders. Right now there are more urgent things to deal with.
1 Like
I did some changes to kronos, now you can select cart from core options, with an “auto” setting that will try to select the best cart on a per-game basis, and default to external backup cartridge 512k if no particular setting is needed by the game. The main reason for this change is that some games won’t boot with the 4M extended ram cartridge, they work exclusively with the 1M version (mainly SNK titles it seems).
As a side effect, i noticed Legend of Oasis’s saves work with the external cartridge, however the size of the generated file for external cartridge is twice the size it should be (again), it might mean that internal memory is somehow not working because it’s not twice the size, and old yabause was somehow forcing the size to 64k because it was aware of this, i’ll do some tests later.
2 Likes
I’m going to try stick to the plan of saving per game and internally because that makes it easier to keep track of all the saves, specially considering that at the moment I’m using 4 different Saturn emulators. Not being sure which games were in the cart and which ones internal was a bit of a pain. But what you did sounds great, it’s the most compatible solution. Beetle does it the same way. Good to know Oasis is working. Probably many games that ‘require’ the external cart will be save-able now too. I will try Panzer Zwei.
Update: Panzer Zwei and Oasis still can’t ‘see’ the saves I inserted, neither in shared_bup nor in ext512k. And by the way, shouldn’t shared_bup.ram be 512kb instead of 32?
It’s the internal when not using the per-game setting, so no. External are always per-game btw.
Most likely an issue when you insert it to a “double sized” external cart, Kronos is able to save/load its own external cart in those games though. I’ll look if the size is somehow fixable.
I see, got it. I am inserting the saves in ram files created by Kronos though, so the ‘container’ should be compatible right? One might think that the problem is in the way the save manager writes files, changing something that makes them unsuitable for Kronos, but many other games worked 
I have been reading a lot of your posts lately and I know you would not be doing this if it wasn’t more or less important/interesting for the core, RA and yourself, but I still really appreciate it : )
The guy that developed the game parser is obviously familiar with the way Saturn saves work… we could maybe try to contact him.
I also found this
http://ppcenter.webou.net/pskai/
It’s being developed for real consoles, but I think it might be useful for emulators as well. I shall investigate.
I’m not sure i understand, are you still trying to insert your mednafen “Legend of Oasis” save to an internal Kronos save ? As i said that doesn’t work and that’s a different issue. But if you manage to insert it properly to the “ext512k” one it should work, because this game is clearly able to read/write from this external cart.
About the ss-save-parser, feel free to report to them that their project doesn’t work with Kronos (and probably YabaSanshiro & Yabause too since they appear to use the same save format to me).
1 Like
No, no… you missed a few things. The save parser works like a charm with many games (i.e. I have managed to transfer those saves to Kronos), that’s why I said it’s weird it doesn’t with Oasis and Zwei. And yes, of course I’m inserting the saves in an ext512k.ram file created by Kronos. That’s why I said that the container should be compatible.