Updated in 2023-5-5 UTC+8
fx-9750GIII Storage Memory Crash
Posté le 26/10/2020 10:10
In August 2020, I encountered the problem on my fx-9750GIII where I couldn't use my storage memory. Later, I found that a file with impossible name "僂ASSE.g1m" appeared in my calculator stoarge and couldn't delete it in any available ways. After investigation it's confirmed that this file was originally "-CASSE.g1m" from Calcraft. The reason of having a Chinese character is that the hex code of "僂" is the combination of the hex codes of "-" and "C".
Possibly all USB Power Graphic 3 models
- fx-9750GIII: CalcLoverHK, PhantomOverrideAlpha
- fx-9860GIII: yukki410
- Graph 35+E II: yet to be seen
- Unable to modify the storage memory (even "Initialize All" won't work)
- LINK app shows error "Data conversion failed."
- Windows reports error 0X8007045D (I/O device error) when attempting to modify the storage content
- (Uncertain, happened once) A file with impossible name (e.g. 僂ASSE.g1m)
1. Install C.Basic for FX
(important as while it's possibly the main cause, it's also used to execute the workaround syscall below)
2. Create a new program file in SMEM mode
and save it without typing anything, then re-open the file OR
open an existing file in SMEM mode
3. Type something randomly and delete what you've exactly typed (even typing and then deleting a single letter works, just make sure the final modified file is exactly the same as the original one)
4. Save the file by pressing [EXIT]
5. The moment when you get a "Can't delete file" error pop-up with error code -6 is where this bug is triggered
At first it seems like nothing happened after the error, but as the time passes under normal use, C.Basic starts to pop up the same error more frequently and eventually even a modified program with a single letter added can't be saved.
Deducing from the error description ("Can't delete file"), it appears that C.Basic saves a file by deleting the original file first and creating another one with exactly the same content as the modified one. If there is no actual change in the latter one however, C.Basic may confuse between both files and thus being unable to delete the proper file, while forgetting to change the Bfile status from "file opened" state to "ready" state.
However, such problem also appears in other users' GIII calculators without C.Basic, and the reasons for them are unclear.
Warning! This method can only be used on the USB Power Graphic 3 models!
Execute Syscall(0x205) in C.Basic and restart the calculator.
If you have any method to solve this problem, feel free to post it here! Thanks for your help and also @Lephenixnoir @Yatis for helping me tackle the problem ever since the encounter of this bug
Citer : Posté le 26/10/2020 10:47 | #
The problematic file appeared as C.Basic failed to save a program to storage memory.
In a possibly similar situation, PhantomOverrideAlpha has met another storage memory lock apparently when trying to delete the INSIGHT add-in.
Citer : Posté le 15/09/2021 10:42 | #
Updates: There is a UCF member who also encountered the similar problem with mine.
Citer : Posté le 03/05/2023 09:02 | #
Updated the thread as my fx-9750GIII is now in the unusable state just like what happened in August 2020. This time the procedures for reproducing the bug are clear for my case.
Citer : Posté le 03/05/2023 09:54 | #
Thanks for the update. Having a protocol to reproduce is very good because then we can narrow down the issue and experiment with fixes. I'm a bit busy at the moment, but it seems like it would be a really good idea to go into the code (which I now realize we do have!) and look for the Bfile code that is triggered by your instructions.
Citer : Posté le 03/05/2023 10:46 | #
An interesting thread found on cnCalc: https://www.cncalc.org/forum.php?mod=redirect&goto=findpost&ptid=24682&pid=244556
(Translation) Found the reason (of this storage bug). The filesystem of fx-9750GIII has harsher restrictions on the files. When quitting from an add-in, if the file is not closed, attempting to reopen the add-in will lead to the crash as the file is occupied.
This might explain why Bfile can be stuck in "file opened" state. 🤔
Anyhow, one thing to mention, apparantly C.Basic does not support viewing nested subfolders as its own file manager derives from WSC & FVM by Wudy which is specifically developed for CASIOWIN filesystem instead of Fugue filesystem.
Citer : Posté le 03/05/2023 10:56 | #
Oh wait the Bfile part was already mentioned here and you replied too: https://community.casiocalc.org/topic/8033-how-do-you-reset-a-casio-fx-9750-giii/#entry64011
Btw, the syscall you suggested to me before to fix this bug is BFile_CloseFile() but I forgot the exact parameters Now it's time to validate it
Citer : Posté le 03/05/2023 17:25 | #
For reference, before we forget: this is what file descriptors look like: https://bible.planet-casio.com/yatis/software/fs/fugue.html#file-descriptor
My suggestion was thus something along the lines of
though I'm being told it just always returns -2 (ie. file descriptor does not correspond to an open file) so apparently the numbers for the lower field (C in the documentation) are more random than just from 1 to some limit N.