Dreamcast-Talk.com

ateam wrote: ↑Mon Jan 13, 2025 6:04 pm

pmp174 wrote: ↑Mon Jan 13, 2025 5:10 pm I don't think it would be too hard to implement. KallistiOS supports the serial port adapter. I just think the second idea with backups/pushing save could eventually ruin the VMU if you are writing and wiping the VMU too much.

You have to intercept calls to/from MAPLE bus to implement something like that. Not trivial, despite KOS support for serial SD adapter.

That said, DreamShell did it for the IDE mod (https://www.youtube.com/watch?v=1kVy4lc ... c2hlbGw%3D). It's not uncharted territory.

Doesn't KOS support game save management? https://kos-docs.dreamcast.wiki/group__vfs__vmu.html

I don't think it would involve reengineering anything. Also a similar feature to the one I mentioned has been implemented in dreamshell.

pmp174 wrote: ↑Mon Jan 13, 2025 3:24 pm Megabolt85 or mrneo240
Feature Request: Serial port sd card save management
Right now you have support for VM2. What I would like is to add support for game saves via the serial port sd card adapter. There are two possible ways this can be implemented.

I won't suffer bullshit like Mnemo in his pathetic USB-GDROM.
There is VM2 and usb4maple, which completely solve this problem, without forcing the user to wait an additional 10-15 seconds before starting the game and without wasting the VMU resource, which by the way, is limited.

pmp174 wrote: ↑Mon Jan 13, 2025 7:58 pm Doesn't KOS support game save management? https://kos-docs.dreamcast.wiki/group__vfs__vmu.html

I don't think it would involve reengineering anything. Also a similar feature to the one I mentioned has been implemented in dreamshell.

Yes, of course KOS can read/write to VMU. However, let's think about what you're asking for here...

If you want openMenu to treat an individual virtual VMU stored on a serial SD card as if it were a native VMU, it would need to hook into the BIOS in such a way that all calls to the VMU from any game software are intercepted and "re-routed" to serial SD. This is what I described as "not trivial" (though it would appear that DreamShell has this feature as per the video I linked in my previous post).

Perhaps you're thinking of it a different way, though...

1) Virtual VMU file is stored on the serial SD card using a filename that corresponds to a game disc folder (or game disc ID/name).
2) When that game is launched from the menu, its corresponding virtual VMU file is read from the serial SD card and then written to your VMU.

Now I have a question for you: as you play the game and your save file is updated with new progress, how do you envision the contents of the real VMU being written back to the serial SD card's virtual VMU? Without that BIOS hook-in method, this would require the user to return to openMenu and then initiate a process where the contents of the VMU are dumped back to the serial SD card.

Now, I'm not saying this is an absolutely horrible user experience. However, it would require users to undergo an extra step to prevent data loss.

ateam wrote: ↑Tue Jan 14, 2025 6:50 am

pmp174 wrote: ↑Mon Jan 13, 2025 7:58 pm Doesn't KOS support game save management? https://kos-docs.dreamcast.wiki/group__vfs__vmu.html

I don't think it would involve reengineering anything. Also a similar feature to the one I mentioned has been implemented in dreamshell.

Yes, of course KOS can read/write to VMU. However, let's think about what you're asking for here...

If you want openMenu to treat an individual virtual VMU stored on a serial SD card as if it were a native VMU, it would need to hook into the BIOS in such a way that all calls to the VMU from any game software are intercepted and "re-routed" to serial SD. This is what I described as "not trivial".

Perhaps you're thinking of it a different way, though...

1) Virtual VMU file is stored on the serial SD card using a filename that corresponds to a game disc folder (or game disc ID/name).
2) When that game is launched from the menu, its corresponding virtual VMU file is read from the serial SD card and then written to your VMU.

Now I have a question for you: as you play the game and your save file is updated with new progress, how do you envision the contents of the real VMU being written back to the serial SD card's virtual VMU? Without that BIOS hook-in method, this would require the user to return to openMenu and then initiate a process where the contents of the VMU are dumped back to the serial SD card.

Now, I'm not saying this is an absolutely horrible user experience. However, it would require users to undergo an extra step to prevent data loss.

Upon each boot open menu would backup the contents of the VMU back to the serial port in the background.

pmp174 wrote: ↑Tue Jan 14, 2025 6:53 am Upon each boot open menu would backup the contents of the VMU back to the serial port in the background.

Gotcha. There are several flash carts that behave this way as well.

In essence, each time you boot a game with openMenu, a "flag" would have to be set (i.e., something written to the serial SD card) that would tell openMenu on its next boot "hey, there is probably updated save data on the real VMU, please dump it back to virtual VMU".

I don't disagree it would be a useful feature for some users, but without you or someone else writing it and submitting a pull request, I wouldn't expect it to be added by megavolt85 (as per his comment).

I agree with Derek (ateam).

Plus, even if megavolt was willing to go through all this mess, still the approach of "next boot" + "flag" is flawed. There are multiple case scenarios, with at least one leading into wrong VMU data writing..

ateam wrote: ↑Fri Jan 10, 2025 6:27 pm

legolas119 wrote: ↑Fri Jan 10, 2025 5:08 pm thanks.
Well, they already have the same ID:
https://i.postimg.cc/N0G9sNXQ/Cattura3.jpg
But as i show into my post above, they have 2 different artwork... Is it correct that the 2 discs are in 2 different folders?

Yes, they belong in different folders. Are you sure you have the multidisc setting on "hide"?

yes sure: https://i.postimg.cc/HxmgjVSw/Whats-App ... -12-30.jpg

Do you think i have to named both the disc into the same way? Currently they have 2 different names:
https://i.postimg.cc/02jq6gCB/Cattura1.jpg

thank you

legolas119 wrote: ↑Tue Jan 14, 2025 11:19 am yes sure: https://i.postimg.cc/HxmgjVSw/Whats-App ... -12-30.jpg

Do you think i have to named both the disc into the same way? Currently they have 2 different names:
https://i.postimg.cc/02jq6gCB/Cattura1.jpg

thank you

Ah, perhaps the game name matters too. I'm not sure. Worth a try!

ateam wrote: ↑Tue Jan 14, 2025 11:26 am

legolas119 wrote: ↑Tue Jan 14, 2025 11:19 am yes sure: https://i.postimg.cc/HxmgjVSw/Whats-App ... -12-30.jpg

Do you think i have to named both the disc into the same way? Currently they have 2 different names:
https://i.postimg.cc/02jq6gCB/Cattura1.jpg

thank you

Ah, perhaps the game name matters too. I'm not sure. Worth a try!

I tried to set the same name...but the 2 discs are still separated... Did Anyone else had this strange behaviour?
thanks

Can you open a track 03 in a Hex editor and take a screenshot?