Hacking Regarding EZ Flash Omega's saving method...

[rs1n]

After reading up on EZF Omega, I cannot help but wonder why they did not just implement saving like the regular EZ Flash IV (upon reboot, it saves from SRAM onto SD, with the option of holding L to skip). If it is because they removed the SRAM chip, then why not at least create a visual effect to let the users know that the save is being written onto the card? For example, why not just draw an overlay (e.g. a red border on the screen) that signifies the card is being written to? This would be non-intrusive, and give users a visual clue about the status of the save file.

 

[FAST6191]

While I have no problem with the patch and write on next boot method per se (it has worked well for many years) by emulating the save chip you skip having to patch, and also needing a battery to store the save (I know they turned around and kept one to power the clock).

Implementing an overlay on the screen would be rather difficult, and possibly also dodge the "no patches" thing some seem to consider a selling point -- flash carts are not emulators, and the GBA does not have any kind of hypervisor or firmware always running you can poke. If I were the EZTeam I would have sooner stuck an LED on the back of the cart somehow and had the light escape, or maybe a mode that burns a lot of power to see if you can get the needs charge indicator to flash if that is an option. As it stands waiting a few seconds is not so bad though.

 

[rs1n]

While I have no problem with the patch and write on next boot method per se (it has worked well for many years) by emulating the save chip you skip having to patch, and also needing a battery to store the save (I know they turned around and kept one to power the clock).

Implementing an overlay on the screen would be rather difficult, and possibly also dodge the "no patches" thing some seem to consider a selling point -- flash carts are not emulators, and the GBA does not have any kind of hypervisor or firmware always running you can poke. If I were the EZTeam I would have sooner stuck an LED on the back of the cart somehow and had the light escape, or maybe a mode that burns a lot of power to see if you can get the needs charge indicator to flash if that is an option. As it stands waiting a few seconds is not so bad though.

Yeah, the RTC battery was what made me think of having it save after next boot. I suppose not having an SRAM chip also cuts down on costs (not to mention PCB space needed).

As for the "border" thing... I may be oversimplifying the process but I imagine that whatever code is being used to write to the SD card could just have a jump to a short routine that draws the border (after all, it draws the UI, right?), or even just a small 2x2 pixel square in the top right corner (or _any_ visual cue, really). I suppose I could look at the source to see how it draws the UI and writes to the SD card to see if it is feasible.

The LED idea is also a good one too. Placing it at the "top" of the card would be fine.

 

[FAST6191]

You words seem to imply you keep thinking they just chucked out the SRAM chip and replaced it with something else. It is not that at all (if they had then they would probably have gone for FeRAM like the commercial carts and kept up with the next boot write back) and the Omega represents a somewhat new approach to GBA flash carts (a fairly obvious one, indeed you can probably find threads from when the GBA was still current talking about emulating save types, but still a new one as far as practical stuff went).

The code used to write to the SD card is held within the "processor" of the flash cart itself -- the GBA game writes a save much like it would natively, the cart detects this with its own processor and snatches the data off to stuff it on the SD card (as opposed to classic flash cart which patches every game to behave like specific types of SRAM save, and then either leaves it in SRAM or copies it upon next boot when it runs its firmware again). The GBA, much less a game written possibly 2 decades ago at this point, has no knowledge of its goings on and patching in code to do something with it is a non trivial exercise. Between like sorts of things that gave us BOMA, the EZTeam's own entry points, the stuff that gives us GBAATM and some other automated stuff you could get pretty far but it is a lot of effort to solve a rather small problem. The GBA and DS are the last real examples of mainstream class leading gaming devices that don't have any kind of firmware/OS running in the background and thus all the GBA games are running every aspect of the system by themselves at all points, and thus have to be treated as individual cases -- no options to have the firmware/OS look for a cue, have their own timer and then stick something up on screen. The DS has a few more options here but in the end it is still each and every game that gets a look at to do it, or do it well without crashing.

 

[kuwanger]

(if they had then they would probably have gone for FeRAM like the commercial carts and kept up with the next boot write back)

Given the nature of the GBA, I really do believe that would have been the better approach. There was only four real problems* with the EZ IV: the need to patch for saves, the requirement for a battery, the relative slow time to save if you had many games, and the general issue of corruption of the memory card when saving. The last one was (AFAIK) almost if not entirely addressed by the latest kernel. The first was something that could be addressed at the hardware level. The second one, like you said, just requires switching to FeRAM. The third one could be addressed by using some sort of bucket sort. The fact that EZ Omega was clearly intended to be open source and was means especially the last two could have been addressed by people like me. Turning the saving into a black box really made the situation in some ways worse. :/

* One could add a fifth one, relatively slow loading of games which was worse with later kernels, but that's closer to an annoyance or argue that near instant loading is a feature. It's not a deal breaker for a game to take 10-20 seconds to load. It is when saves are corrupted regularly.

 

[rs1n]

You words seem to imply you keep thinking they just chucked out the SRAM chip and replaced it with something else.

Not exactly. (Full disclosure -- I still have not look carefully at the source code.) I saw getting rid of the old save method and the SRAM chip more as a convenient consequence of the write-to-SD-on-the-fly feature.

The code used to write to the SD card is held within the "processor" of the flash cart itself -- the GBA game writes a save much like it would natively, the cart detects this with its own processor and snatches the data off to stuff it on the SD card (as opposed to classic flash cart which patches every game to behave like specific types of SRAM save, and then either leaves it in SRAM or copies it upon next boot when it runs its firmware again).

This is where I think my confusion is:

Once the kernel loads the game, whatever process that saves data (whether the data be in-game data or ANYTHING to the SD card) presumably has access to writing to the screen to, no? (EDIT: To be clear, I mean the code the EZ Team created that writes to the SD card, not the in-game code that handles saving game data.) If not, then I that answers my question plainly; end of discussion. However, I was assuming that wherever that saving process resides (doesn't matter how it's implemented) it had write access to the screen (be it to some section of memory, i.e. a frame buffer or directly to the screen itself). For example, the firmware update and kernel both have the ability to write text to the screen. So even a simple "*" displayed at the top left corner of the screen would suffice (and maybe even a user option to display or not).

In other words, what is preventing the saving process from additionally writing something to the screen while the game continues running? No room for extra code? No access to the screen/framebuffer from where the saving process resides?

The GBA, much less a game written possibly 2 decades ago at this point, has no knowledge of its goings on and patching in code to do something with it is a non trivial exercise.

Again, if I gave off that impression, then it was a mistake on my part. But no, I am not assuming patching of any sort to catch save-file write calls, or ROM patching.

--------------------- MERGED ---------------------------

Given the nature of the GBA, I really do believe that would have been the better approach. There was only four real problems* with the EZ IV: the need to patch for saves, the requirement for a battery, the relative slow time to save if you had many games, and the general issue of corruption of the memory card when saving. The last one was (AFAIK) almost if not entirely addressed by the latest kernel.

If this is indeed the case, then my questions are somewhat insignificant. Nevertheless, I am still curious as to why it would not be practical and/or feasible.

 

[FAST6191]

In other words, what is preventing the saving process from additionally writing something to the screen while the game continues running? No room for extra code? No access to the screen/framebuffer from where the saving process resides?

The modern style general flash cart approach is present the kernel as its own ROM to the GBA. Handle saves and whatever. Have user select the ROM. Set the entire ROM section to the user selection + any extras like cheats and soft reset (if possible/desired). Either hard reset (you see the GBA logo again) or get the undocumented soft reset (no logo) going on and boot into the game, which usually involves a memory wipe. At this point there is no visibility for any code the flash cart has that it did not just inject into the game. It might be able to stuff some code in a blank section at the end of the ROM* (or do some kind of exotic bankswitching) but the GBA game would have no idea about jumping to it other than if you patched it (or for the bankswitching had foreknowledge of where the code would next run on the cart) -- I am not aware of any cart level interrupts that it can send and say jump here in this CPU mode, and if there were we would have a lot better cheats, savestates, in game text readers, soft reboots, probably new ROM selection, possibly cheat search, some kind of screenshot, memory readers, possibly auto button pressers, selectable slowdown...

If you are coming more from playing with NES, SNES, GB/GBC, possibly N64 and the like then the GBA cart is basically very fast bulk ROM storage and a save bus, anything fancy like tilt, solar, rumble and whatnot being game specific http://problemkaputt.de/gbatek.htm#gbacartioportgpio and not that much use here. There are no particular instances of the cart getting involved with/boosting the game console's operations itself (thus making a suitable candidate for twisting for use here), much less a general case, like some of the NES mappers, SNES special chips, GB/GBC MBCs and whatever the N64 had beyond the CIC.
There is also no OS/firmware layer always running you could fiddle with like we saw with the PSP, Wii IOS modules, 3ds and such.

*other than the GBA video stuff all but about 3 games people actually use anything like the whole space, and of those then Mother 3 is the only one to use essentially every byte. Everything else has 32 megs of space visible at all times and it is rare for more than half of that to be used. At the risk of confusion as well I might as well include the main exception other than flash carts themselves and also include the stuff done for the Shrek videos https://mgba.io/2015/10/20/dumping-the-undumped/ which would still not help much here.

Given the nature of the GBA, I really do believe that would have been the better approach. There was only four real problems* with the EZ IV: the need to patch for saves, the requirement for a battery, the relative slow time to save if you had many games, and the general issue of corruption of the memory card when saving. The last one was (AFAIK) almost if not entirely addressed by the latest kernel. The first was something that could be addressed at the hardware level. The second one, like you said, just requires switching to FeRAM. The third one could be addressed by using some sort of bucket sort. The fact that EZ Omega was clearly intended to be open source and was means especially the last two could have been addressed by people like me. Turning the saving into a black box really made the situation in some ways worse. :/

* One could add a fifth one, relatively slow loading of games which was worse with later kernels, but that's closer to an annoyance or argue that near instant loading is a feature. It's not a deal breaker for a game to take 10-20 seconds to load. It is when saves are corrupted regularly.

I would probably agree with most of that, though I will say I never had corruption issues with my EZ4s outside of micro-mini adapters and other contact issues, my EZ4 lite battery (almost a watch battery) dying on me, me messing around with multi save, and me hitting the power switch too early in game or when it was writing back.

 

[kuwanger]

Once the kernel loads the game, whatever process that saves data (whether the data be in-game data or ANYTHING to the SD card) presumably has access to writing to the screen to, no?

The simple answer is no. The FPGA that copies the SRAM (and there still is SRAM on the EZ Omega, it's just not battery backed) runs concurrently and separately from the GBA CPU. To draw to the screen would require interrupting the CPU and attempting to interject code*. It would be possible to patch every ROM before loading it, but not all games are stable/compatible with this, and it'd preclude using at least some ROM hacks, homebrew, etc. So, the optimal solution would basically devolve back to the EZ IV way of patching on the fly as a basic requirement of saves to work which would reduce compatibility.

Having said all that, EZFlash2 did talk about possible including a visual or auditory patch thing for "with Add ons" but neither they nor I have attempted to pursue it. It'd honestly be a lot of work, and again I can't imagine there'd ever be 100% compatibility.

Nevertheless, I am still curious as to why it would not be practical and/or feasible.

SRAM is mapped into memory. Ie, the GBA CPU can write to it directly at any time and the presumption is that the instance after the last bit of data is written, the save is good. The EZ Omega (or other flash cart) has to constantly check the SRAM for changes, wait a short while until all changes are made, and then start writing out data. SD cards themselves have different times it takes to make writes, even if it should in theory only be a few seconds. If the GBA used some sort of communication to the flash cart like the DS does, it would tell it what data to write in blocks then wait for a confirmation before the game displays save success.

though I will say I never had corruption issues with my EZ4s outside of micro-mini adapters and other contact issues

Older EZ4 kernels routinely would have mismatching FAT tables. I'm not sure if they fixed that in later kernels. Other than that, most of my corruption issues in the past were my own fault (not having a properly named save file) or probably contact issues with micro-mini adapters as you suggest.

* There's also the point that games will often use one or more different screen modes. At that point writing something to the screen should be possible, but restoring the screen is hard. Admittedly, the EZ Omega has enough RAM to store a RTS, so the safest approach would be to basically do at least a partial save/restore RTS; RTS is far from 100% reliable, though, on real hardware. Sound is worse (or it's always been for me whenever I've done it at the hardware level) because often DMA is involved with timers, so any interjection of sound messes up the DMA or the timing.

PS - Sorry if I'm mostly repeating what FAST6191 is saying.

 

[FAST6191]

I had plenty of junk in the save folder but as far as it translating to saves not working I never got there outside of those things mentioned. I usually keep a fairly modest selection of games on mine though so tended not to end up on the ragged edge of its code.

 

[kuwanger]

I had plenty of junk in the save folder but as far as it translating to saves not working I never got there outside of those things mentioned. I usually keep a fairly modest selection of games on mine though so tended not to end up on the ragged edge of its code.

My saver folder had a lot of files. That included all sorts of things, though, from nes, gb, video, midi files, etc packaged as gba files. I don't recall if I had much if any actual save corruption as a result. I know for a while I pretty aggressively backed up my saves (at least once a month) because the risk seemed great enough--in fact I've got 45 archives compressed down to 9.3MB which is about the same size merged into one archive . I don't clearly losing any saves, but I definitely have the feeling I did once or twice and always as a result of me failing to create a .sav file. :/ As far as I know the inconsistent FATs is a pretty common and relatively benign error.

 

[hitsgamer]

While I have no problem with the patch and write on next boot method per se (it has worked well for many years) by emulating the save chip you skip having to patch, and also needing a battery to store the save (I know they turned around and kept one to power the clock).

Implementing an overlay on the screen would be rather difficult, and possibly also dodge the "no patches" thing some seem to consider a selling point -- flash carts are not emulators, and the GBA does not have any kind of hypervisor or firmware always running you can poke. If I were the EZTeam I would have sooner stuck an LED on the back of the cart somehow and had the light escape, or maybe a mode that burns a lot of power to see if you can get the needs charge indicator to flash if that is an option. As it stands waiting a few seconds is not so bad though.

replace sram with fram would be easier to remove battery.

 

[FAST6191]

replace sram with fram would be easier to remove battery.

If you have a pin and footprint compatible replacement (or a source of adapter boards) then we are all ears.

 

[hitsgamer]

Converting a GBA game over to battery-less saving (SRAM to FRAM)

I'm not familiar with chips. I have found someone replacing SRAM on FlashingCards with FeRAM to get rid of battery.

maybe it's not suitable for ezo.

I'm new about GBA programming , only read and rewrite of part of ez o kernel, still learning about how ezo patching game rom to write save files and show in game menu.