We can currently extract these, but we can't take a cart save and convert it and/or add it to a mempack file.

Might be easier to convert it to its own mempack file rather than having the ability to add it. How would be differentiate which are regular saves and which are cart saves? Need to think here.

We'd need to truncate any empty pages from the end of the cart save

This would let people use their gameshark to write saves downloaded from the internet to their carts

Refactor tests/unit/save-formats/FlashCarts to be closer to the directory structure of the source files

Also add tests for the passthrough conversions like NES/SNES etc

Does the repairing code I copied from mpkedit need to be used? Maybe parse the file into its internal notes, then use those to make a new save file and see if that loads better?

This one for Ready 2 Rumble wasn't able to be repaired by the game. Can it load it if we try and repair it?

Ready 2 Rumble Boxing (U) [!].mpk.zip

Currently, .wasm files are loaded in a very hacky way, particularly in development and production modes on a remote server. We look inside the Webpack stuff stored in window to pull out the hashed filename, which clearly is not the intended method.

It's probably worth upgrading to Webpack 5 to solve this, as it apparently has built-in support for wasm files. We may even want to upgrade to Vue 3 at the same time.

The 4 environments in which loading .wasm files needs to work are:

• In tests running locally (e.g. yarn test:unit)
• When running a development server locally (i.e. yarn serve)
• When running a development build on a remote server (i.e. yarn build --mode=development && yarn deploy --mode=development)
• When running a production build on a remote server (i.e. yarn build --mode=production && yarn deploy --mode=production)

The site appears to no longer exist. Double check that it's still gone before removing the link.

https://github.com/ner01/gb-save-dumper-n64/

Note that it can only read save files and not write them

This is an infrequent but consistent request that would require nontrivial effort to make work beyond the simple methods outlined in the readme.

Maybe something like this? https://laniewski.me/blog/2019-01-05-creating-offline-first-vue-apps/

A list can be found at hcs64/neon64v2#20 (comment)

In particular Startropics 1 & 2!

We should add tests here for the Wii VC and possibly the NES Everdrive, PocketNES emulator, and Mega Everdrive Pro.

Note also the mention of the specific field in the iNES 2.0 header that allows this: hcs64/neon64v2#20 (comment)

It would be easier to make work offline, and would allow batch processing of files.

How to make it work with node easily? Would need node installed, and what else? Might not be super user friendly if there's a bunch of deps to manage. Especially as they need upgraded as time goes on.

Again, because so few people would want this (and it goes against the site goal of being easy-to-use for everyone), maybe consider making this a paid service. Although then the dependency issue would really need to be solved in a clean way for the user.

It can be confusing to have a file not load up after conversion, which can sometimes happen if the region for the save file isn't the same as for the game.

For N64 controller pak saves, we have info on the region so let's display it to the user.

Region codes: https://github.com/bryc/mempak/blob/master/js/codedb.js#L44

Also possible to do for PS1 and Wii VC?

https://github.com/dangiu/PicoMemcard

https://emulation.gametechwiki.com/index.php/Save_Converters

Right now deployment to prod requires several manual steps. We should automate deployment so it happens whenever something is pushed to the main branch.

Ideas:

• Conversion direction
• Convert a whole file (PS1/N64) or just extract a file?
• Which platform for Wii VC conversion
• Differences seen between problematic and known good files in Troubleshooting tool
• Game title/ID for save file

They're already in 8 bit bytes, so don't need to be converted. Test for this by noticing that when getting a uint16 it's > 255, and then returning an error we can display saying the file does not need conversion

We're getting our DES algorithm from that package, so may as well get everything? Looks like it's modular so can just include what we need. Should verify with the bundle analyzer though.

https://github.com/brix/crypto-js

https://bennvenn.myshopify.com/

When building for prod, we see a warning that the size of chunk-vendors is > 1 MB when it should be < 244kB. Even compressed, it's > 350kB.

Right now we populate that field with:

• Made with savefileconverter.com: SMSAdvance
• SAVE: PocketNES (consistent with how it appears when running in standalone mode on an EZ Flash ODE)
• The internal name from the game ROM: Goomba

We could consider unifying this to contain the filename of the raw file it was converted from (assuming that Goomba doesn't use the internal ROM name to verify the save is for the correct ROM. It also has the checksum for that. More code reading needed here).

I don't believe that these names appear anywhere in the emulator UI, but if we did #134 then it would be nice to have something better to display in our UI.

From Wonder Boy in Monster World, just to make sure that it gets correctly padded out too, in addition to the regular Genesis saves

I think we can take out the async aspect of it by putting a try catch block around the require in config.js rather than first doing an async test for the file existing. This would let us get rid of some boilerplate in the PSP ISO test file and fix the indentation in that file.

https://stackoverflow.com/questions/13197795/handle-errors-thrown-by-require-module-in-node-js

Example save from Zelda Minish cap from EZ Flash V has 16 byte header added on.

Issue 1: Current Troubleshooting tool barfs on this file, finding a negative padding size.

Issue 2: Consider adding a rule to the tool to get the diff in size between the known good a troublesome files, and if known good < troublesome then try cutting that from the start (and end?) of the troublesome file. See if there are any matching characters at the beginning of the files then (in case of GBA then there appears to be some plaintext info about the game)

It may be better to handle the plethora of EZ Flash cart type using this tool (or making a similar tool and just calling it EZ Flash so it's easier to find) since I'll bet they all have simple headers like this.

Saturn Kai: https://www.retrorgb.com/pseudo-saturn-kai-update-released.html
Rhea: https://videogameperfection.com/2015/03/18/sega-saturn-review/ (is this still manufactured?)

From a user:

on the drop down box for the file size you want the created save file to be, i couldn't see 32kb as an option. and the save file I was replacing was that size, so that was what I ideally wanted to go with. but I went with 64kb instead and it worked fine, so no big deal.

it was Drill Dozer. my own .sav file for it is 32kb and so that's why I was trying to make the game save I found online be that same size when I converted it to .sav with your site

From a user on discord:
ecw-hardcore-revolution.1000.n64.zip

https://www.retrogamesaves.com/

Apparently if the file is the wrong size the everdrive will just ignore and overwrite it.

These emulators can run on the GBA in "bundled" mode, where you select a list of game ROMs on your PC and then a program creates a single executable that runs on the GBA and allows you to select between these games.

The save file for that executable contains save info for all of the games.

Right now, we only support extracting one game's save data from the file, but we could make a dropdown menu to display all of them with their associated game title, similar to how N64/PS1 memory cards are done.

My goal for this site is to just support built in emulators on flash carts, and not get sucked into supporting every emulator ever, so it's not a priority to include this. When run from the flash cart OS directly, an individual save file for each game is created.

But it would be easy to add this ability. If there's enough demand we should consider adding it.

Here's a list https://forum.digitpress.com/forum/showthread.php?134961-NES-SNES-Genny-Games-with-Battery-Back-up-Save-feature&p=1614576&viewfull=1#post1614576

They just shouldn't have their bytes expanded from 8 -> 16 bits. Is there something in the internal Wii file that indicates save type, or do we just need a hardcoded list?

Note also that there's some FRAM games -- which treatment do they need?

https://docs.aws.amazon.com/codebuild/latest/userguide/sample-build-notifications.html

BrianBTB/SED-PC#5 (comment)

I don't have any example files for this type of save on 32X for these flash carts. A good example game would be NBA Jam TE (without any SRAM hacks applied)

https://github.com/sanni/N64SAVERW

There seems to be a bunch of different flash carts here: https://www.ic2005.com/shop/home.php?cat=1

The dropdown is getting cluttered, and it may be confusing to find and select what someone is looking for (do I want NES or NES on Genesis?)

Consider breaking it into 2 dropdowns where we first select the flash cart type, then the type of save. Or is it possible to have a hierarchical list within a single dropdown?

It would still be a single component, which would return the same string.

Currently the system can only resize the files, which at least makes them transferable between different platforms. Ideally though we'd like to be able to split apart the individual saves within the files, like we can with N64/PS1 memory card images.

All parsing of these files is apparently done by the Sega CD BIOS, and there's no documentation about how the files are laid out.

There's a tool by Krikzz that can parse these files, savesplitter.exe, but there's no source: https://krikzz.com/pub/support/mega-everdrive/pro-series/

I tried looking at the executable in a disassembler but the results didn't make a lot of sense to me. I think the next step here would be to step through it in a debugger.

It's really slow to run the unit tests on the various ISO files for PSP. So I added a switch in code to skip them for desktop devving (and another switch to skip testing retail ISOs because obviously those can't be committed to the repo).

But it's annoying to have changes to that file that can't be committed. And it's an error waiting to happen to accidentally commit a change with that flag set to false.

So it should be in some sort of a local config file instead.

The MiSTer pads out saves to be pretty large, and when converting them back they may not fit on an original cart. I'm a little nervous about just truncating the file blindly, but having a dropdown that defaults to the file's current size seems like a good solution.

e.g. Phantasy Star IV Genesis MiSTer save is 64kB (reduces to 32kB after un-padding the bytes), but the cart can only hold 16kB and some cart dumpers (e.g. the Retrode) won't write that big a file to it.

In order to avoid confusion about why the Convert button doesn't become enabled, we should add a default filename to these conversions:

• PS1: individual saves -> emulator/ps3/dexdrive
• N64: individual saves -> emulator/dexdrive

For example:

• Resizing a save by adding/removing padding (allow user to select 0x00 or 0xFF padding)
• Endian swapping (allow the user to select 16, 32, 64 byte endian swapping)
• Byte expanding/contracting Genesis files (allow user to select byte expansion byte: 0x00, 0xFF, or double byte e.g. 0xA -> 0xAA)
• Remove a header/footer (allow user to specify number of bytes, or attempt to autodetect based on making the file a size that's a power of 2)
• Add a header/footer by copying it from another save file
• Allow people to select a certain range of offsets to slice out, for example to allow: https://www.reddit.com/r/AnaloguePocket/comments/10ampwi/solution_for_extracting_pokemon_emerald_cartridge/
• Maybe decompressing the data using a common compression scheme like .zip or .lzo

See here for ideas: https://forums.launchbox-app.com/topic/66417-n64-save-converter-tools/

https://aws.amazon.com/blogs/infrastructure-and-automation/how-to-trigger-aws-codebuild-jobs-for-selective-file-changes-in-aws-codecommit/

Needs a lamba function

https://github.com/superg/srmtools - Source code for an existing converter in c++

Source code from there. Would be nice for us in the community to link people to your site when they ask about this. :)

https://krikzz.com/our-products/accessories/flashkitmd.html

It looks like SRAM and flash ram files should be endian swapped but not EEPROM saves (4kb and 16kb)

So clicks on an instance running on a local machine, or from the dev bucket, both show up along side production stats in the google tag manager interface.

We're currently on version 0.13, and it's up to 1.0. Also have lots of outdated syntax that needs fixing.

Use tfenv to manage different versions of terraform installed on the local machine

Similar to JanErikGunnar/vcromclaim@60da63f

Maybe return the full extra memory if the portion to truncate isn't empty?

Doesn't seem to be a problem in practice because there's just a finite number of retail games to consider, so no homebrew or hacks that might use extra memory.

There's tons of cases where different extensions mean the same thing, and we should be less strict about which extensions are accepted in various places.

e.g.

.srm and .sav
.mcr and .mcd