I think this has been mentioned before, but I wasn't sure how much it has been talked about, but what about reading/writing to/from AppVar's?

I think this has been mentioned before, but I wasn't sure how much it has been talked about, but what about reading/writing to/from AppVar's?

That will be done using GetCalc().  You can also get Variables, Lists, Strings, Ans, and other RAM variables and locations with this command and it will return a pointer to said object or zero if it doesn't exist.  Therefore, you can also store to these objects.  I'm nowhere near ready to support that command however so don't expect it soon.

I second the on-calc APP compiling feature.
It is full of win.

Well, I'll wait on that then.

Anyway, I need to propose some safety features and I'd like some feedback.  Here is the idea.  If you select a "safety mode" in the options, the following will occur: All data in ram is archived and an application variable is created to keep track of what it archived (The appvar is also archived).  A dummy variable is also created and is kept in RAM.  Next, after the program is compiled, it is executed within axe parser itself rather than coming back to the home screen.  Once the program finishes, the ram is automatically cleared on the calculator so any corrupted data gets restored to the default.  Next, the appvar gets unarchived and unarchives the variables on its list.  So when the program quits, everything is back to normal.

Now, if the program crashed, and you need to pull the batteries, then the dummy variable gets deleted.  That means that the next time you run axe, it will notify you that you have recovered from a crash and automatically unarchive the programs from the save list to return the calculator back to normal.

This seems like the perfect system to prevent crashes, but its a little too perfect.  What I mean, is that if you start getting used to this, then if it corrupts the memory when safe mode is off, it will be very hard to find where the error is since the error would never be detectable in safety mode.

You might ask "Isn't it possible for axe to automatically detect when memory is corrupted?"  but the problem is that I would need a copy of the entire original RAM to compare it before and after the program is run and that really isn't going to be possible.  And even if it were possible, many assembly programmers often intentionally change non-safe areas of RAM to set flags, alter external variables, run self modifying code, etc.

I'm still going to add this mode anyway, but does anyone else have any other ideas about how to improve safety?

I like the safety mode idea.

OMG.
I can has DEBUG mode!?

It would be nice if you could edit programs inside of Axe Parser instead of jumping back to Home and reprogramming and recompiling...

well debugging would be possible on older 15MHz models with all that extra RAM...but of course that's cutting out all the other people...

Actually, I'd think debugging would be pretty darn hard to pull off. Unless, of course, you might be able to build executables that allow debugging, but have larger code size?

How about a sandbox mode where your RAM will be backed up, but won't be cleared after you run the prog, so that if it corrupts the memory, the user will notice it?