Search

[cory1492]

Suggestion: instead of copying the files back and forth when changing save slots (which takes a long time) simply rename the files, which should be much faster. (DSOrganize takes less than 10 seconds to process a renamed file.)

It actually doesnt take very long to overwrite a 256K file, a matter of 3-5 seconds - its writing a completely new file that takes a tonne of time.

It shoulnt be all that hard to make a function/method to rename files though, all you'd really need to do is look at the new file creation function and see where its writing the long and short file names in the FAT tables and make a way to re-write that for an existing file. Probably just need to get the struct, change the variable and write it back again.

[m2pt5]

It actually doesnt take very long to overwrite a 256K file, a matter of 3-5 seconds - its writing a completely new file that takes a tonne of time.

The way QDSMS appears to do it now is to copy the current save to an entirely new file, delete the old one, then copy the slot you are changing to to the current save, and then delete the old one.

Another suggestion: Make it so you have to press A to lock in the save slot change. Having more than two slots can be very time consuming to switch between.

[cory1492]

The way QDSMS appears to do it now is to copy the current save to an entirely new file, delete the old one, then copy the slot you are changing to to the current save, and then delete the old one.

Then that is the true bottleneck that makes it slow, the DS should have more than enough memory to malloc 2x256K and simply do the swap from memory by overwriting already existing files (and create a new one, slowly, as needed only). From what I can see this app should be using less than about an eighth (512K) of the DS memory as it stands.

[Noda]

It actually doesnt take very long to overwrite a 256K file, a matter of 3-5 seconds - its writing a completely new file that takes a tonne of time.

The way QDSMS appears to do it now is to copy the current save to an entirely new file, delete the old one, then copy the slot you are changing to to the current save, and then delete the old one.

Another suggestion: Make it so you have to press A to lock in the save slot change. Having more than two slots can be very time consuming to switch between.

This actually inaccurate: first I copy the current save to a new one, then I overwrite the old one with the desired one, and delete this one after the copy.
But it takes the same time to copy the first one to a new save and to overwrite the first one, so it's not a matter of creating a new file or overwriting.
I'll try to see if I can make a rename function to make things easier and faster.

And I was planning to add the possibility to choose directly the number you want

[cory1492]

Why not just copy the current save to memory wrather than save.x? Renaming would be much more efficient though than constantly writing the lions share of the actual save data more than once.

[Noda]

After some tests, it seems that unfortunatly file creation / deletion is not safe on SCSD, a better fat driver is needed
Save files and/or games may be corrupted, so be careful.

I'm planning to do a new version of QDSMS with a new concept, according to Cory's idea on Gbatemp: preallocating space using a larger save file or something similar, maybe using a pc util do to that. So that save changing will be a lot faster, and everything would be more reliable.

I'm sure the way I'll implement this, I have some ideas but I think I'll drop the new save creation feature for the moment as it is unreliable.

[cory1492]

Yeah, I had alot of problems with file creation - there needs to be vblanks after some things and chishm did not use them. My problems were mostly with timestamps and making files of a rounded size (256K worked nicely though aside from timestamp issues that only chkdsk cared about).

Overwriting on the other hand shouldnt be an issue. Im not certain, does supercard use a template file to make the saves or does it create them on the fly? I know there is a template for GBA saves though I still dont quite get why the devs didnt include save sizes along with the patch data instead of just making every save the same size if its created on the fly.

[m2pt5]

The Supercard patcher uses a template file - a file containing 256k of "00".

I keep a copy of the blank save on my SD card to use when I give copies of my patched ROMs to friends.

[cory1492]

If you look in the program dir, there is a template file for:
save.sav (64K)
isave.sci (448K)
but no 256K one, Im assuming it makes it on its own without copying from the program dir like the GBA saves.

[m2pt5]

Ok, there's not a template file for it, but a freshly generated .sav file for a DS game from the SC patcher is just 256KiB of "FF". You can grab an unused one and rename it, and it'll work with any patched game.

[dai_uk]

Suggestion: instead of copying the files back and forth when changing save slots (which takes a long time) simply rename the files, which should be much faster. (DSOrganize takes less than 10 seconds to process a renamed file.)

yep I renamed a rom file and it screwed the entire fat table in 10 seconds, it was quick but put me off of DS Organise's file browser.

Real shame as it was really good until it happened  

[m2pt5]

yep I renamed a rom file and it screwed the entire fat table in 10 seconds, it was quick but put me off of DS Organise's file browser.

Real shame as it was really good until it happened  

I've only had the FAT get screwed up once, and that was with an early version of Draw3. If it happens, you can run a chkdsk to find the lost clusters and use a hex editor to figure out what they are.

[dai_uk]

I did run scandisk but to be honest on a 512mb card I didn't bother hex editing every file (they went into 2meg chunks!)

I now backup my .sav files regularly and don't rename on the DS itself anymore.

[MaHe]

Could  somebody re-upload the sources? Thanks!  :oops:

[MaHe]

Ah, I didn't saw the mirror. How dumb of me. Sorry for bumping.[/i]