Posté le 03/12/2024 22:32
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2025 | Il y a 97 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
Citer : Posté le 23/03/2025 22:41 | #
Is there anything I can do as an alternative? I don't mind saving some state to ROM manually before gint_poweroff. Is there a way for my add-in to reload itself after the calculator comes back on? It can then load what it saved to ROM if necessary.
Citer : Posté le 23/03/2025 23:00 | #
You could save application-specific session save state to a file before you call gint_osmenu() or gint_poweroff(). Leave a canary in RAM or a checksum in a register so you can determine, when you come back, whether RAM has been wiped. This detection is a bit subtle (because it cannot rely on any data being present in memory) and could be a feature of gint_poweroff(). And then somehow if RAM is zero'd out, recover. The most reasonable way I can imagine would involve exiting the add-in and restarting it so it can pick up session data from the file and restore it.
I don't think you can reasonably recover automatically with no application-specific support. Many problems would arise from having your RAM wiped, and that's putting it, er, lightly. Just consider all of the variables and heap allocations being gone for every function in your code and every library along with it. Recovering from there without restarting completely would require either a coordinated effort from every software component (no way that's happening) or the ability to just snapshot and restore all memory, for which you'd need to save all relevant memory. You could reasonably find all of it, but that'd make for a pretty sizeable file, which could fail to save and either way would take entire megabytes to store and minutes to generate.
Citer : Posté le 23/03/2025 23:26 | #
It's interesting you say the RAM is "wiped." Does the OS zero it out when the loading wheel is spinning? If not, I'd expect the RAM and any canary to read a random value rather than 0 which means the canary has a 1/256 chance of being wrong.
I understand what you mean about saving all state and restoring it from ROM which does seem unreasonable. My thought was to design things knowing the off key could be pressed at any time and the program needs to be completely reloaded. I do think the amount of state you would need for this could be quite small if you prioritize it. I'm also fine with restarting the add-in after every power off even if RAM wasn't wiped. How can I make the add-in restart?
Citer : Posté le 23/03/2025 23:49 | # |
Fichier joint
Yeah "wiped" is maybe the wrong word. The RAM chip just stops retaining the data; I don't know what you read out of that. I don't think the OS zeroes it out while spinning, I suspect it's just reloading what it needs.
You'd use the App_Start() syscall. First you need to find the add-in table (for which there is no standard syscall I believe), then find which integral id your add-in has in the table, and then run it that way. I can think of two pieces of code that do that (Add-In Push and Kbd2's filesystem optimization code). I have source code for the latter; I'm attaching the assembly file. Note that the function itself runs in a world switch, as you'd expect. You can ignore SMEM_Optimisation. The rest is the search logic for FX.
Citer : Posté le 24/03/2025 16:42 | #
Thanks! This is great. Out of curiosity, what do you usually see other programs do? I could imagine not allowing the OFF key while the add-in is running and exiting the program completely when the menu key is pressed.
Citer : Posté le 24/03/2025 17:13 | #
I think this is the first time someone has reported this issue. But yeah when issues of this nature come up the solution is usually to leave before doing wacky stuff. The OS interface is always a complicated matter. It's a lot easier if you don't interleave complex hardware interactions in the middle of an add-in.