Hardware EzFlash Jr Saves Slow

[Bratbatdeath]

Hi, i recenly update my Ezflash Jr to a new Sandisk 32gb card and y have a issue with saving, i whatch some videos and the saving progress take 1 to 2 minutes, but mine take like 4 minutes to save the initial save, is this ok or is something wrong with my card?

 

[ciaomao]

Hi, i recenly update my Ezflash Jr to a new Sandisk 32gb card and y have a issue with saving, i whatch some videos and the saving progress take 1 to 2 minutes, but mine take like 4 minutes to save the initial save, is this ok or is something wrong with my card?s check the cluster size

maybe check the cluster size? false size slows down everything is my experience with ez. i only use it with my gb pocket and classic gb games, but a save takes approximately 2s.

 

[Bratbatdeath]

maybe check the cluster size? false size slows down everything is my experience with ez. i only use it with my pocket and classic gb games, but a save takes approximately 2s.

y have the SD formatted in 32kb on cluster size, what size you recomended me?

 

[ciaomao]

y have the SD formatted in 32kb on cluster size, what size you recomended me?

its a while ago…i would need to check, but if it wasnt 32kb i would assume 64kb. with my gb pocket it also increased browsing speed, as I reduced the files in a folder, to an acceptable level.

 

[Bratbatdeath]

its a while ago…i would need to check, but if it wasnt 32kb i would assume 64kb

y put the cluster size in default and still 4 minutes of saving, maybe is for have some directories?, y have the Everdrive pack load in to my SD card

 

[ciaomao]

y put the cluster size in default and still 4 minutes of saving, maybe is for have some directories?, y have the Everdrive pack load in to my SD card

just checked my fat32 card with fw4:
32 KB/cluster,
64 sectors/cluster,
512 Bytes/sector

 

[Bratbatdeath]

just checked my fat32 card:
32 KB/cluster,
64 sectors/cluster,
512 Bytes/sector

y reordenate my folder structure and compact in less folders and now is saving much faster 40-45 seconds!

 

[ciaomao]

y reordenate my folder structure and compact in less folders and now is saving much faster 40-45 seconds!

it is really a mystery to me why the number of files per folder has anything to do with the time to save. browsing is understandable, but saving?!? the main thing is that it helps. here is a clip from my pocket. it shows the save process in real time

 

[Bratbatdeath]

it is really a mystery to me why the number of files per folder has anything to do with the time to save. browsing is understandable, but saving?!? the main thing is that it helps. here is a clip from my pocket. it shows the save process in real time

The first time you save a game and the everdrive creates the sav file, takes more time, y think if you have so many directories, when the Everdrive backups the save, load the entire SD card to refresh the info and the rute of the sav file

 

[ciaomao]

The first time you save a game and the everdrive creates the sav file, takes more time, y think if you have so many directories, when the Everdrive backups the save, load the entire SD card to refresh the info and the rute of the sav file

i recommend 3 folders:
us
eu
jp

create a-z folders in each.
thats how i handle it. the 1st initial save takes ~4s.
Btw. I hope we still discuss ez, just asking as you mentioned everdrive.

 

[davidmorom]

Hi everyone! I don't know if there is someone still interested in this issue (hope there is), but anyway, I want to share my recent discoveries regarding this problem.

I recently started to use my EZ Junior again, and soon I remembered this annoying issue it used to have: sometimes save files are created instantly, but, sometimes, it takes some minutes for apparently no reason.

After thinking about it, an idea came to my mind. It is obvious that, everytime you want to create a new file in a file system, you first need to find free space to allocate the file onto. If the Junior finds this free space by scanning clusters sequentially from the beginning, this would explain why sometimes it takes less than a second but another times it could take several minutes. If there is free space at the beginning of the partition, it will be instantly, but, if there is not, it would have to traverse trough all used clusters until it finds the first free one.

To check my theory, I formatted a fresh 8GB card in FAT32 with 32k clusters, copied the "ezgb.dat" file, created and empty "SAVER" folder (so the Junior doesn't have to do it) and copied the whole GB and GBC romset (2.3GB).

After that, I started to run games. The save file of the first two games took less than a second to be created. For the third one, it took almost 2 minutes. I repeated the same process with 64k clusters and the result was the same but with one difference, the third game took only almost 1 minute to create the save file.

Then, I connected the SD card to the PC and analyzed the "SAVER" folder with an hexadecimal editor. As you can see in the attached image, the first two save files marked in green are at the beginning of the partition (sectors 8704 and 8832, or about 4MB from the beginning) and took less than a second to be created. The third one, marked in red, is at sector 4914432 (2,34GB from the beginning), just after all the ROM files, and took 1 or 2 minutes to be created, depending on the cluster size (64k/32k).



So all of the above confirm my initial assumptions: the Junior takes a lot of time traversing used clusters to find the first empty one, so it is recommended to leave empty space at the beginning of the partition. Also it is recommended to use the biggest clusters size possible so, in case the Junior needs to traverse trough a lot of files to find empty space, the number of used clusters is the smallest possible.

But, how to leave empty space at the beginning of the partition? Operating system doesn't allow the user to specify where files will be allocated (not easily at least), so a little trick can be used. Just after formatting the partition, copy an empty file of, for example 2GB, to the card, then copy the whole GB/GBC romset and finally delete the dummy file. By doing this, there will be 2GB of free space at the beginning of the partition, plenty enough for thousands of save files.

To sum up, my recommended way of formatting and preparing the SD card is the following:

• With Windows "diskpart" or Linux "fdisk" clean the card and create a small partition, 4GB is enough for the complete GB and GBC ROM set, but bigger also works fine
• Format the partition in FAT32 with 64k cluster size
• Copy the file "ezgb.dat" and create a "SAVER" folder in the root of the card
• With any hexadecimal editor, create an empty 2GB file and copy it to the root of the card
• Copy the entire GB and GBC ROM set to the card, at once, so every file will be correctly sorted
• Delete the empty 2GB file

With the above procedure I was able to create a lot of save files without any single problem.

If anyone is interested in this info and try this procedure, any feedback will be welcome.

 

[ciaomao]

is there really such thing as „empty space at the beginning of the partition“ when every cluster is only virtual, as the controller uses wear leveling?

 

[davidmorom]

is there really such thing as „empty space at the beginning of the partition“ when every cluster is only virtual, as the controller uses wear leveling?

Of course there is, I'm always talking about logical level (what the operating system sees). A partition is just a bunch of sectors from 0 (first sector) to N (last sector).

At physical level of course the controller can rellocate sectors to different places for many reasons.

The problem seems to be the number of clusters the Junior have to check, and their logical position on the partition, not the physical position on the card.

 

[The Real Jdbye]

is there really such thing as „empty space at the beginning of the partition“ when every cluster is only virtual, as the controller uses wear leveling?

SD cards don't have a controller chip, it's a bare flash chip, no wear leveling.

 

[ciaomao]

SD cards don't have a controller chip, it's a bare flash chip, no wear leveling.

i did a quick search and it seems all sandisk SDs do WL, but the algorithm is their IP.
see also: https://www.delkin.com/blog/how-do-wear-leveling-sd-cards-work/

 

[moon_rabbit]

SD cards don't have a controller chip, it's a bare flash chip, no wear leveling.

https://news.samsung.com/us/samsung...d-cards-improved-performance-higher-capacity/

Micro sd cards have a controller inside.
Are there any that only have nand flash?

 

[The Real Jdbye]

https://news.samsung.com/us/samsung...d-cards-improved-performance-higher-capacity/

Micro sd cards have a controller inside.
Are there any that only have nand flash?

Maybe I was mistaken. I'm pretty sure I've seen them with just flash but it seems they're not all like that (maybe cheaper/lower end/slower cards don't have them?)

 

[ghjfdtg]

If only the Jr. would take advantage of the FsInfo structure that is supposed to tell where the next free clusters are.

 

[moon_rabbit]

So that's why the first save is always slow.
On gba they used FatFs, but on gameboy they used simple filesystem code due to hardware limitations.
But everdrive saves fast, so it's not just hardware limitation.

 

[ciaomao]

So that's why the first save is always slow.
On gba they used FatFs, but on gameboy they used simple filesystem code due to hardware limitations.
But everdrive saves fast, so it's not just hardware limitation.

Did you check the mov. That´s not slow, or?
https://gbatemp.net/threads/ezflash-jr-saves-slow.626742/post-10083447