So trying this out on the Everdrive, the hardware implementation was actually dead-easy, and in an evening I could get Black Box challenge saving my progress.
Haven't tried it for the Powerpak yet, but don't expect much problems there either.
The implementation just recognises the write-byte sequence as documented in
https://wiki.nesdev.com/w/index.php/UNROM_512 or in the official data sheet for the PRG-flash chip.
No handling of cleared pages has been attempted, nor trying to emulate the "everything written is a binary and with $FF after clearing".
That does mean the rule would be "make sure to write every byte you intend to read back after clearing". That means it's not really emulating. But honestly, I can't see why this would be a limitation for 99.9% of the software we'll see used on mapper30.
I'm happy to discuss improved schemes to get it slightly more compatible. But only for valid software intended to ship in the near future. And that does NOT include devil's-advocate-tech-demos intended to show flaws we already know exist with this implementation.
However, as is often the case, the simplicity of getting hardware working betrays the other-people's-code troubles when it comes to fixing the software to make the saves truly persistent...
For the Everdrive, there's not much I can do without Krikzz's assistance to update the Everdrive OS.
So I've tried tackling the Powerpak instead, seeing how the full source code is available at
http://nespowerpak.com/I've managed to write to the CF-card in a hacked .MAP module of my own, and that's fairly straightforward. But an unexpected nasty surprise has cropped up: It appears that to load directories, the Powerpak boot ROM regularly trashes the PRG-ROM space. All following the logic that this is a free RAM area the OS can use at will, because the data is never used after you've finished playing the game...
The routines needed to load the LASTNES.TXT file in the POWERPAK directory (which is what you need in order to know the cluster number to seek to to read/write the iNES file) are even hard-coded to set the bank number to the PRG area.
Duplicating those full routines into a .MAP module of my own is not feasible, because modules can only be 1kB in size. Hence my current attempts have been trying to copy the "pre-amble" of various OS functions into a .MAP module to set the bank to the WRAM instead, then jumping into a later phase in each function. This makes me feel quite uneasy, as I would be baking in assumptions about code not moving around inside the boot ROM. Though I suppose in practice the boot ROM is unlikely to change with the Powerpak software having been in a de-facto abandonware state for years now.
But after a few attempts at this, it occurred to me that there's still no way I can fix this without changing the boot ROM. Any module the boot ROM will load using the CardLoadModule function after reset will trash PRG-ROM when trying to read the POWERPAK directory, even when booting into the Q.MAP options screen that makes queries you for whether to save. By the time that has happened and my .MAP module is in control, the damage is already done. So the only way to fix it would be to change the boot ROM itself.
And apparently you need a CopyNES to flash the Powerpak boot rom? I still haven't got the one I bought years ago assembled. And even if I did, I can't expect people to get one just to get saving working in Mapper30 games. That's just a no-go for this implementation.
So my next "creative" idea for how to resolve this is yet-another hack: Have the mapper30 implementation on Powerpak enable writing to BOTH the WRAM and the PRG-ROM simultaneously for the first 8kB bank.
Assuming this is possible (and I guess it should be if you just enable the write sigal for both chips). By the time all the boot OS has done it's trashing of the PRG-ROM and loaded the LASTNES.TXT data for me, I can restore the PRG-ROM contents using the WRAM page that the Powerpak respects. While in theory a FAT directory could hold up to 65536 entries, as long as people don't put random crap in the POWERPAK directory of their CFs , the boot ROM shouldn't get a chance to trash enough of the PRG area.
This would obviously take advantage of Mapper30 being spec:ed as a mapper that has no WRAM, meaning no possibility for future WRAM upgrades to Mapper30 are possible to get working on this Powerpak implementation.
But I suppose that's a necessary evil, unless someone has a better idea... suddenly that "hack" of jumping to a WRAM trainer which directly writes the CF card doesn't seem as far-fetched.