Hacking EZ-FLASH Junior folder and filename regulation

[EZ-Flash2]

This regulation is corresponding with kernel 1.03. may be changed with further kernel update.

1. The total items in root no more than 99. including SAVER folder and ezgb.dat, it means you can create another 97 items(folders or files) in the root folder.
2. Filename length no more than 80 characters(file extension not included).
3. The total letters of folder name + file name are no more than 255 letters. if you are using sub-folder, it means the all folders name length must be calculated into the 255 letters. for example, root:/homebrew/A/Aball.gb. the total length is homebrew + A + Aball= 14.
4. Remove all non-letter symbols and unnecessary info in the filename if possible.
5. The total files in a folder no more than 90.

meanwhile, the regulation in the readme.txt of kernel package is deprecated.

 

[Nikokaro]

This regulation is corresponding with kernel 1.03. may be changed with further kernel update.

1. The total items in root no more than 99. including SAVER folder and ezgb.dat, it means you can create another 97 items(folders or files) in the root folder.
2. Filename length no more than 80 characters(file extension not included).
3. The total letters of folder name + file name are no more than 255 letters. if you are using sub-folder, it means the all folders name length must be calculated into the 255 letters. for example, root:/homebrew/A/Aball.gb. the total length is homebrew + A + Aball= 14.
4. Remove all non-letter symbols and unnecessary info in the filename if possible.
5. The total files in a folder no more than 90.

meanwhile, the regulation in the readme.txt of kernel package is deprecated.

Does the restriction concern .sav files in Saver folder too?. I think that over 255 letters the cartridge can not write saves on the SD. Am i wrong?

 

[ghjfdtg]

Sorry to be a party pooper but these restrictions are nonsense. You can't expect any customer to know and respect them. They will run into issues and blame the product. So either try and find ways around the limited RAM or use some sort of cache stored on the microSD. The market and demand is small for GB(C) flashcarts so you better try and grab as much of the cake as possible.

 

[EZ-Flash2]

Sorry to be a party pooper but these restrictions are nonsense. You can't expect any customer to know and respect them. They will run into issues and blame the product. So either try and find ways around the limited RAM or use some sort of cache stored on the microSD. The market and demand is small for GB(C) flashcarts so you better try and grab as much of the cake as possible.

Sorry. those restrictions are brought by file sorting function. if everyone does not need the file sorting function, we can remove it from next version kernel.

for the cache idea, we already think about it before. it still need user launching a thread to generate the file index. the efficiency is not acceptable with a microSD which full of roms. and it needs generate again if you add/delete/modify files.

so. remove the sorting function is the fastest and easiest way to solve those restrictions. after all, the competitor does not have file sorting ether. and no body complain it.

 

[ghjfdtg]

You could also use the FPGA to speed things up but it probably doesn't have much internal RAM.

 

[EZ-Flash2]

You could also use the FPGA to speed things up but it probably doesn't have much internal RAM.

Believe me, the current way is the best effect we can achieve on GB hardware. it is too slow and small ram. the same file sorting algorithm is fast in a blink of the eye on EZ-FLASH OMEGA.

 

[ghjfdtg]

Another option is sorting on PC by creating the files in order so they are already sorted in the FAT. This will break if users add files later obviously but better than nothing. Or as you said removing sorting/making it optional with a warning about the limitations.

 

[Nikokaro]

Sorry. those restrictions are brought by file sorting function. if everyone does not need the file sorting function, we can remove it from next version kernel.

for the cache idea, we already think about it before. it still need user launching a thread to generate the file index. the efficiency is not acceptable with a microSD which full of roms. and it needs generate again if you add/delete/modify files.

so. remove the sorting function is the fastest and easiest way to solve those restrictions. after all, the competitor does not have file sorting ether. and no body complain it.

For those, like me, that have bought this cartridge to carry around the full GB romset in a single microSD those restrictions are so severe that i hope this sorting sistem will be removed in next (i hope close) update, as losses are greater than gains.

 

[Localhorst86]

I'd prefer a non-sorted approach if it allows you to speed up the menu navigation and it removes restrictions currently in place.
I do understand that automatic alphabetical sorting is a feature often requested on many flashcards, but as it turns out, they usually lack that feature for a good reason.

 

[fillicudi]

I manage to resolve error 2 on entering folders, i simply copied all the folder to my desktop, delete the one in the sd(6 at a time) and recopied back in from desktop(6 at a time still) i hope this also works for you.
P.s. i'm a mac user so i eject the sd with clean eject to prevent junk files
p.p.s also i forgot to mention that i update the kernel to version 4