Saroo is an open-source product that we did not profit from, and its purpose is simpler: to provide players with the cheapest and simplest usage solutions.
That's fine but it's irrelevant to what we're talking about here.
For you, as mentioned earlier, labeling your homebrew with an ID means running it on an unpatched system, just like the two games （Utenyaa and SLIDEHOP）mentioned here.They are not patched. Because they have their own GAMEID.
The problem is the Product ID you are using for one of your patches is for a generic IP.BIN that was included with the SDK and therefore used in various other homebrew apps, demos, and probably other unreleased prototypes. It was a placeholder value for development purposes. Relying on it alone to do your patching is a flawed and unreliable approach.
Is patching reasonable?Let's conduct two experiments based on Satiator（or CDdriver and other ODE） and real saturn hardware:
First experiment:
1. Download IN THE HUNT (USA);
2. Set the clock of Sega Saturn to June 8th, 2024;
3. Run this game 2-3 times
Any bug with this that is not caused by your device isn't your responsibility to deal with. If your device is causing the issue then you should be fixing the issue on the device. If the game itself has a bug that prevents it from working after a certain date then release it as a patch for anyone to enjoy regardless of their ODE.
Second experiment:
1. Download Die Hard Trilogy;
2. Insert the EXRAM4M card into the host and ensure good contact;
3. Run this game
Die Hard Trilogy clearly isn't compatible with the 4MB RAM cart, so the proper solution here would be to remove the RAM cart. For Saroo you guys should be disabling it on the Saroo itself, not patching the game's code.
What did you see in the above experiment?
For the design errors of the software itself, we solve them by patching to prevent ordinary players from being disturbed. Why not?
You should be fixing them in passive ways that don't require you to actively mess with the game's code in memory. After the first boot file has been loaded and executed all memory in the system becomes off limits to you guys. It's the games and it has full control over it. You shouldn't be messing with it.
(Here is just an example. In reality, the virtual external memory card and EXRAM card of SAROO coexist：When using the CDdrive, you can manually unplug and insert the card to decide whether to insert a backup memory card or an EXRAM card. In older emulators, you need to choose which card to use in the settings bar, and SAROO will obtain the working status based on the GAMEID, which is the importance of ID.
The problem is the Product ID is unreliable. You can't just rely on that to decide whether or not to patch.
For determining what type of cart to use Saroo should work in a passive way like Action Replay and Pseudo Saturn Carts. They are able to work as both Backup RAM and 1MB/4MB carts without relying on checking the individual games. They just work by following the spec of the carts and behaving correctly when the games interact with them. If a specific type of cart is incompatible with a specific game, then that should be a setting the user sets in the menu to disable that feature on the cart itself. It shouldn't be something that the cart actively patches in the games running code to hide the issue.
What if your homebrew needs to be stored on an external backpu memory card, but the ID uses an ID that requires an EXRAM game?）
Then I'll interact with the cart the way Sega's spec says to interact with it. If your cart is passively behaving correctly and following spec it should work regardless.
Even if I use a unique game ID how will Saroo know what my game is to configure itself if you haven't programmed that new ID I just came up with into it? Do you see the flaw there? Your cart should instead just be behaving correctly and following the correct specs. If it requires a specific configuration that should be something the user configures instead in the menu before they boot a game.
Better yet, maybe instead of using the Product ID number in IP.BIN to determine what peripheral features need to be enabled in Saroo, maybe you should instead look at the Supported Peripheral Codes? You know if there's a W in there it means the game uses the 1MB or 4MB RAM cart. If there's an R in there it means it uses a ROM cart, X Means the Modem. If that section doesn't have any of those then you can probably just configure it as a Backup RAM cart instead.
Let's take a look at the mednafen emulator. Does it patch some games based on GAME ID？
To my knowledge no it doesn't patch anything in the game's code. For the Auto feature for Cartridges it probably uses the Supported Peripheral codes in IP.BIN.
You need a pure virtual CDblock System.
then
give Homebrew a unique GAMEID.
give Homebrew a unique GAMEID.
give Homebrew a unique GAMEID.
Or you guys could actually take some time to read the official documentation and come up with more robust ways to do this checking than relying on the Product ID number? Especially when one of the games you're patching is a prototype with no real Product ID number and therefore is using a generic placeholder one used for development purposes.
