[FEATURE REQUEST] Add a way to override cart dump size

[mariomadproductions]

Some dev carts report their dump size incorrectly (above or below the capacity of the cart), which means that allowing GM9 to try and dump the cart based on that value will result in a too-small dump, or an error if it tries to dump past the boundary. I think providing an option to dump the cart with a specific size would be useful. I think this could be implemented without a significant interface change by adding some more "virtual ROM files" to the GAMECART drive. E.g. XXXX-64MiB.nds/.enc/.3ds, XXXX-512MiB.nds/.enc/.3ds etc - with all the possible cart sizes listed. Maybe to keep the directory listing clear, they could be in a subfolder (although maybe that is harder to implement).

[d0k3]

@mariomadproductions - won't happen, as this will help a handful of users at the expense of confusing a large number of users. Is this really still an issue? I thought we fixed this already.

What happens in case of an overdump? And, is there a safe way to distinguish such dev carts from retail carts? Maybe @GerbilSoft can chime in?

[mariomadproductions]

I mean as long as the files are in a subfolder or labelled correctly (like "XXX-Size forced to X MiB.nds"), I don't think it will be confusing.

I've asked the dumper to confirm if this issue still occours in GM9 v2.0.0.

Not sure what you are asking about an overdump. Either an error would occour, or it would just read out invalid data. But that doesn't really matter - if the user is forcing the dump size, they should expect that. Not sure what you mean about distinguishing dev carts from retail carts.

[d0k3]

What happens in GodMode9 if it tries to read more than what's there? Is there an error message, does it simply crash, ...? If GodMode9 can detect an error here, and if GodMode9 can also recognize dev carts, then it could detect the actual size by just trying (ie. doing what a human would do anyways in that subfolder).

[d0k3]

I've got another idea. What about providing a script command for dumping carts with a specified size? Would that help?

[mariomadproductions]

What happens in GodMode9 if it tries to read more than what's there? Is there an error message, does it simply crash, ...? If GodMode9 can detect an error here, and if GodMode9 can also recognize dev carts, then it could detect the actual size by just trying (ie. doing what a human would do anyways in that subfolder).

I'll ask.

I've got another idea. What about providing a script command for dumping carts with a specified size? Would that help?

Yeah that could work.

[d0k3]

Alright, here's a testbuild with a new scripting command: cartdump GodMode9-v2.0.0-39-g0f7eb65b-20211023143854.zip

Usage: cartdump [output_file] [size_in_hex] <-e>

The -e is optional. Use it for an encrypted secure area on NTR carts. Card2 saves on CTR carts are not blanked - this is as raw of a dump as it gets.

I didn't have a cart with me to test this, so you need to try, with various carts, with and without the -e flag.

[mariomadproductions]

I'll ask the guy with the dev cart to test their "problematic" carts.

[mariomadproductions]

I've just tried it myself with the following script and New Super Mario Bros. (Europe) [A2DP], which has a size 0x2000000 ROM.

set SIZE 800000
input "Cart size (in hex)" SIZE
cartdump cartromout $[SIZE] -e

I'm not sure how to make it output to the default cart dump filename of "0:/gm9/out/[based on ROM header]", if that's possible.

I just used the default size (0x800000) when prompted. It seemed to be stuck at 0% and 59m59s remaining time, so I held B to cancel. When I checked the SD card root, the output file was present, and it was just 1MB. I've attached it as its only a partial ROM header and some zeroes.

[d0k3]

Well, looks like I didn't pay attention. Try this one: -- snip --

As for the filename based on the ROM header, I wonder what you'd need it for. As I understood, this is special functionality, for some special dev carts, most not even having the usual format (NCSD/NDS). Do you really need the standard output path for that and what for?

[d0k3]

I figured we may as well do it proper. This test build has cart dumping via script and a cart dump option in the context menu [R+A] of the cart drive: GodMode9-v2.0.0-39-g0f7eb65b-20211108185829.zip

If you give it a try and it works for you, could you please provide me with screenshots of the input dialogues? As I said, I can't test it myself, but I still want it to look proper.

[mariomadproductions]

I'll try it out now.

As for the filename based on the ROM header, I wonder what you'd need it for. As I understood, this is special functionality, for some special dev carts, most not even having the usual format (NCSD/NDS). Do you really need the standard output path for that and what for?

Just so the user can dump multiple ROMs in one go without worrying about the previous dumps being "clobbered", and for easy identification by the user which ROM dump goes with which cart.

[mariomadproductions]

Okay, tried it - didn't have time yesterday. It seems to be working properly now. Although there seems to be a visual issue with the R+B dump - the progress bar isn't cleared from the screen when its finished (you can force it to clear by navigating to any menu/folder, however).

[d0k3]

Alright, uncleared progress bar fixed. GodMode9-v2.0.0-41-g209a72c0-20211109190232.zip

Does it dump as much data as you specify, and does the secure crypto yes/no option give the desired result, too? If you can, could you do screenshots of the two prompts, so I can have a look?

[mariomadproductions]

Yeah it does, and choosing to leave the secure area encrypted works. I'll test "no" to leaving it encrypted now. I'll take screenshots (or photos).

[mariomadproductions]

Okay, initial test results: it says "Failed dumping cart" if I select "no" to leaving it encrypted. Screen clears properly. Couldn't take screenshots (some of my 3DS buttons are not very responsive so it may be that), but here are some photos of my dirty 3DS screen

[d0k3]

All fixed and merged to master. Feature will be in the next release.