When ever I play ScummVM om my M3 Lite and save a game I get a file system with minor errors. Using fsck in linux, it reports that the two FATs differ and also a wrong "free cluster summary". The second FAT seems to be more inconsistent with the actual file system and specifically with files connected to the last save from ScummVM.
I have not checked this with the latest released version of ScummVM, but I have a fairly recent beta build requiring me to press L to enable M3 support. If required, I can try to verify this with the latest release if the M3 code changed?
Who should I bug to resolve this issue? Is this a consequence of a buggy fat library? In that case which? I am in no way criticizing the work done for ScummVM on DS (on the contrary, I find it absolutely fabulous!), I just want to make it better, and if possible fix some bugs.
M3 Lite bug?
Moderator: ScummVM Team
It seems the M3 has various incompatibility problems with different brands of SD cards. You will probably be able to get it to work using a different card. Alternatively, you can use SRAM saves, as described on the ScummVM DS website, which will work.
If you want to have a go at fixing the M3 driver, you can check out the code from SVN. io_m3sd.c is a good place to start. New code has been released by the M3 people since I released ScummVM DS 0.9.1, and I haven't looked at this yet, but it seems it will need a wrapper written/modified to use it with gba_nds_fat.
If you want to have a go at fixing the M3 driver, you can check out the code from SVN. io_m3sd.c is a good place to start. New code has been released by the M3 people since I released ScummVM DS 0.9.1, and I haven't looked at this yet, but it seems it will need a wrapper written/modified to use it with gba_nds_fat.
I believe this "issue" is not related to my SD card (Sandisk Ultra II) or M3 Lite, but instead to the FAT library used.
I took a peek at the source code for scummvm and found out you are using gba_nds_fat (or some derivative of it). It seems as if this library only writes to one of the FATs. (I am not sure why, maybe card life-time related or for recovery reasons should the FAT library be buggy.) I haven't yet checked as to why the "free cluster summary" was wrong, but my guess is that the library does not update this either after a write. I do not remember, when reading the FAT documentation, if not updating this value is allowed. I don't see any problem with the current use if this value is just for caching purposes (e.g. think 'dir' under DOS produces a 'free bytes' summary at the end).
To summarize, using ScummVM on my M3 does produce some inconsistencies in the FAT(according to fsck under linux), but these seem to be by design. So, you will get errors when checking the file system, but these errors are not(?) important.
Now I can sleep thight knowing I can play ScummVM on my DS.
I took a peek at the source code for scummvm and found out you are using gba_nds_fat (or some derivative of it). It seems as if this library only writes to one of the FATs. (I am not sure why, maybe card life-time related or for recovery reasons should the FAT library be buggy.) I haven't yet checked as to why the "free cluster summary" was wrong, but my guess is that the library does not update this either after a write. I do not remember, when reading the FAT documentation, if not updating this value is allowed. I don't see any problem with the current use if this value is just for caching purposes (e.g. think 'dir' under DOS produces a 'free bytes' summary at the end).
To summarize, using ScummVM on my M3 does produce some inconsistencies in the FAT(according to fsck under linux), but these seem to be by design. So, you will get errors when checking the file system, but these errors are not(?) important.
Now I can sleep thight knowing I can play ScummVM on my DS.