When you put it on your calculator, open Axe and compile prgmEDITORSC (it takes a little bit; it's a lot of code!)

A little bit? You should see my 'main' project. The executable is over 100k and takes almost a half hour to do a full recompile.

So are you building it first before you optimize it?

A lot of the issues are with the menus I think. Every time I open a menu(except for the prgm menu) it freezes, opens the menu, then refreezes with random letters but not random numbers, then I have to pull the batteries.

Oh, yea. I forgot about that. I messed something up with the loop that selects the tokens. It doesn't *actually* freeze, just displays so many tokens on the screen at once that it is like 5 secs between frames.

As for optimizing it, the core of it is as optimized as it is going to get. The cursor movement and scrolling was a huge pain to get right and I'm not spending 10 hours optimizing it and fixing all the bugs I made for a boost in speed which won't matter once I limit the framerate. Not that it is terribly inefficient or anything though. Almost all the cpu's time is spent on text and displaying the screen. Im using a custom text routine that I made that is 2x faster than the OS's and Ill eventually make a custom lcd update that is 6+ times faster than the default one Axe is using. (partial update instead of the whole screen) Speed isn't an issue. And since the finished editor will be an app anyway space doesn't really matter. I think that pressing 2nd + right to scroll to the end of a really, really long line of code takes a long time but Ill deal with it later. Trying to scroll past the bottom line might be an issue.

Ill work intermittently on this as I find time / motivation. Don't expect speedy updates though. The whole reason I put this up was to help Zeda since she? is making one for Grammer 3. From what I have heard of what is done though, I don't know why mine is needed. That might get more constant updates but I really don't know.

As long as the user doesn't disable the RAM execution limit, you could `jp $C000` and that automatically crashes the calc.

I have no problems resetting ram. Im trying to set up memory so that IF the os regains control, the calc will crash but if the programs gets control I can recover and easily undo whatever I did. Like setting the floating point stack to somewhere random. That wouldn't result in an instant crash for a program (and is easy to set back to the right value) but if the OS got control with the pointer to the floating point stack set to some garbage location it would crash. (Im not entirely sure that is how the floating point stack works since I have never really messed with it)

I want to be a part of this and help wherever I can. Whether it's testing for or giving ideas.

Ok, I kinda just threw it out there as a base for anyone to expand on but if you are interested, I can pick development back up. First, a couple questions for you so I know how experienced you are. Are you really comfortable with Axe? How familiar are you with assembly? Do you know what an edit buffer is? Do you know how to dynamically resize variables either using Memkit or using Bcalls? Do you know how memory mapping works? (ports 5, 6 and 7)
Its fine if you don't know any of these, I just need to know so I can figure out what parts you can help with.

Also you mentioned ideas. What do you have in mind? If I were to finish it I would add copy / paste, search, search + replace, jump to label, jump to line number, editing from archive, the ability to look at other programs without closing the current one, and others that I can't think of off hand.

A long time ago I made a small font program editor. At @Xeda112358's request I recently revived it and am working on beating it into a working shape. Im posting it here so I don't have to constantly upload to a 3rd party site every time I update it and on the off chance someone else might want to use it.

You can't. Also why are you using ti-basic for a security program? It can be defeated by just pressing the on key.

I have had similar problems with my SE and I have found some workarounds that I think could fix your problems. When compiling an archived program on the SE (not on the basic ti-84+) Axe occasionally will truncate the name of the produced program or straight up refuse to compile saying that the output name is incorrect (even though it is fine). I looked into this a bit and it seems to have to do with where the variable is located in flash. In most of the cases I bothered to investigate, the variable was usually located close to the start of the page. The longer you go between garbage collects the more likely it seems to occur. Assuming your problem is the same as mine, it is relatively easy to fix. Just garbagecollect more often than usual. I would do it once every 20 hours of programming unless you are writing huge (16k+) programs to flash every couple minutes.

Archive error might be a problem but I rather doubt it. I used my old ti-84+ very heavily for 3 years and I never had any problems with the archive wearing out but it isn't nearly that old. I don't actually know what happens when the archive starts to go bad but I would assume that certain bits would stick into either the set or reset state and refuse to change. I would suspect that that would just cause your program to contain garbage when you save it to archive (or the header if you are really unlucky). I can't imagine that a bad flash would cause programs to suddenly vanish even if you are so colossally unlucky as to have the size entry of the program corrupted. On a ram clear, the OS goes from program to program in flash to build the VAT. It sees deleted and non deleted programs. Archive undelete works because when you delete a program in flash the OS doesn't remove it, it just sets a flag on the program saying 'this is deleted, ignore it'. All the data is still there and all you have to do to recover it is copy the data to a program in ram. All garbagecollect does is delete all the entries with the deleted flag set. (due to how flash works that is actually a complicated process) So even if you have a bad size entry, that should only break programs you archive after the corrupted one. It shouldn't have any effect on programs that have been archived before.

If you are only working with ti-basic, why are you bothering to archive your programs? Unless you are using some unstable libs there is no way your calc can crash. Just edit them in ram.

Another way to recover your data is to have a program that copies all of ram to a program. Assuming that the calc didn't crash on the error your program still exists in ram. It just doesn't have a VAT entry. Copying it all to a program could let you recover a good chunk of what you were just editing if you are willing to sift through a bunch of garbage data.


I would really recommend zStart over Doors for programming. Its tools like jumping to labels, copying and pasting, and being able close a program editor without saving the changes are really really useful.

What's the risk with using real hardware? Sure you are running code with flash unlocked but you are hardly likely to corrupt things. Maybe if you set it so that none of flash is executable and it gets stuck in a reset loop but unless the port lets you deny execution on page 0 the OS should fix it... right? I know the OS does some strange things but I'd be really surprised if it doesn't set the executable limits for flash on boot. It does with the RAM execution.