SRAM and eeprom are different devices and are accessed in different ways. You talk to eeprom the way you talk to controllers, through PIF commands. By comparison, communicating with SRAM and FLASH is normal hardware access, like carts, using DMAs and word writes after setting proper EPI settings.
There was only one vendor for SRAM chips from what I know, but there were multiple vendors for FLASH chips. You have to query the chip type; set the EPI settings for the corresponding pulse width, page size, latency, etc.; and possibly alter the protocol a little bit for communication. I haven't exactly gone through all the code for each one. Emulators cheat and always report MX_PROTO_A.
SRAM is effectively a blob of memory at a given address, usually mapped to A8000000. They burst the whole thing in one go, which would mean it has a fairly hard limit of 0x20000 bytes unless you write your own interface for it. If you aren't using stock chips then you'd pretty much have to do that anyway.
A couple games use their own hand-rolled save hardware.
The important point here though is that all of these have different sizes. Cart eeprom comes in a 4k and 16k, SRAM as previously mentioned, and FLASH is larger still. Downconverting from FLASH to SRAM will limit the number of usable save files or lead to data loss; upconverting from any type to any other requires changing code and is relatively pointless since you're wasting all that unused data.
I'd suggest reversing the code used in several titles to see how it's done for specific types. Looking at homebrew source code isn't terribly helpful for understanding hardware behaviour and often masks complexity.