There's been a lot of trouble lately with people trying to open the program editor (mostly Quigibo and I) so I'm here to show you how it's done. The complete code for opening the edit buffer looks like this:

ld a, kExtApps ;1
ld (cxCurApp), a

ld a, kPrgmEd
bcall(_pullDownChk) ;2
bcall(_clrTR)

ld hl, programName
ld de, progToEdit-1 ;3
bcall(_mov9B)

bcall(_newContext0) ;4

ld sp, (onSP) ;5
bcall(_resetStacks)

bcall(_mon) ;6


programName:
.db progObj, "NAME", 0

I'll now explain why this code works by parts:
1. There are two main reasons to set the current app to kExtApps: 1) the OS won't try to clean up an app that isn't already open, 2) if for some reason the previous app was kPrgmEd, the editor is not going to initialize. By setting this, we are essentially resetting the app system

2. This little section takes care of any menus that are currently up. For instance, without this block, if you open the editor from the standard PRGM->Edit menu, the editor will appear to open correctly. But as soon as you try to move, you'll find out that you are actually still inside of the PRGM->Edit menu and all hell will break loose.

3. Simply put, progToEdit is the name of the program you are going to edit. You don't have to copy the progObj token if you don't want to, I just do it for good measure.

4. The _clrTr will actually return kPrgmEd in A, you then feed this value into _newContext0 so that the OS can initialize the program editor app. After the _newContext0, the program editor has actually loaded: the screen looks good and the edit buffer is open. What this means is that at this point, you can mod the edit buffer in whatever way you choose. (In zStart, this is where instant goto happens)

5. These two lines are semi-optional. You don't technically have to have them, but they are a good idea. You should reset the stacks at this point because if you don't do it now, they aren't going to be reset. This means that after a few iterations of opening the editor, SP is going to make its way into the VAT and you'll start corrupting stuff.

6. This hands control back over to the OS so it can do its job.


There's my technical writing of what I've been working on for quite some time. If you don't understand any of it, that's ok I guess, the code still works even if you don't understand why

Edit:
   I changed this post to reflect my resetting of the stack.

Bet you didn't think you'd see a topic from me.

In any case, we just discussed it on IRC, and there's a pretty simple way to call one axe program from another.

Copy("prgmNAME",33912,9
asm(EF7C4E)

This will work as long as prgmNAME is in ram, so if it's not, you'll have to unarchive it first. Hopefully someone has fun with this.

Edit:
   And here's how you do Basic programs.

Bug: when you copy/paste/restore tokens that axe replaces (Copy, Rect, Data, etc) they get changed to a Y# token.

Noted

Feature request: have zStart work with Dr D'nar's Omnicalc
(More information about this version here.

That's not as straightforward as it would seem. I directly call like 5 places in omnicalc, so I'd have to add checks to all of those places as well as try to determine which version of omnicalc is installed, all of which would be quite a hassle.

So, my thought would be to try to modify 2.23 to work with zStart, it would actually be really simple to do it on a finished product. All you would have to do is go to the specific places I call and add a jump to the new location. I'll try to work on this, but it might be difficult.


Also, things I'm working on right now.

• Instant Goto (this is for the next few)
• Lbl's can be midline
• Basic/Axe test run (You figure out what that means, but it relies on the instant goto, and you'll like it)

I found a very specific glitch with editing archived programs. If you go to Memory Management/Delete ([2nd]+[Mem]+2) or the About screen([2nd]+[Mem]+1), and at either of those screens go directly to your program list, and try to edit an archived program, it will give you "ERR:ARCHIVED". I also had a friend confirm that the bug is on his calculator, too.

Believe it or not, that's actually not entirely a glitch. The zStart hooks only work at the homescreen, and those menus are actually different "contexts." You'll also notice that you can't edit stuff from the Y= menu or the graph screen. I'm really glad you pointed out the cause of this glitch, because I've run into it, but I'm not sure I have a clean fix for it.

Another friend has a glitch(I don't know how to replicate) and when ZStart is installed, If he edits a program(archived or unarchived) it displays random tokens extremely fast, and crashes. When ZStart is uninstalled, it works just fine, but as soon as it's re-installed the glitch comes back. He is still having this glitch.

Hmmm... That one is awkward, but to fix it, I'll have to be able to repeat it. I use 2.53 all day and I actually haven't seen this happen. I'm not exactly sure what's causing it, so you'll have to try to get me something repeatable. (Or, you can send (email/pm) me a wabbitemu savestate of the calculator in a situation where the glitch will occur. In any case, I need to get it to happen in my wabbitemu.)

I just realized.....


can having a modded os cause crashes?
because i crash often, but zstart is so helpful, i put up with them.

I'd go out on a limb and say that no OS mods will cause crashes. Most OS mods are tiny little changes and not the kind of thing that would cause a crash. The zStart mod is only like 30 bytes in fact, and it's written to never crash. (Plus it only runs on ram clears.)

That's actually not a bad idea. I made them the way they are because they used to interfere with basic programs, but now they shouldn't.

If I don't remember (or get super busy) v1.3.005 is currently pending on ticalc.org. So within the next few days, people will finally stop emailing me.

I remember the reason I held off on this was because the omnicalc ram recovery was acting up again, but, I've been so busy lately, that the fix is not coming anytime soon. So, v1.3.005 it is.

Someone give me a post here when it's updated. Unless of course I beat you to it

There probably is an easy way, however, we do not know how to do it. So you are free to look (I've talked to brandonW about this)

But, on another note, brandonW's Pterodactyl will break an OS file into pages and assign all of the common memory locations with their proper names. (As well as take a solid whack at the page 00 calls)

So, I recommend pterodactylling your OS, and then going in page by page. After that, you'll have to convert the two bytes after every rst 28h (bcall) to data to avoid weirdness. (If you happen to be disassembling 2.53 or 2.55 and you are on a x64 machine, I can give you my current progress (I'm pretty sure this is actually legal too ))

Heh...It'd be cool to be able to have your screen burning with grayscale fire while using the calc normally.

Those kind of mods are rather difficult as many OS processes only update the screen and nothing else. That means it would be difficult to keep a memory of what was actually on the screen.

The only solution I see would be to read the entire LCD back before every single grayscale interrupt and compare it to a known copy of what the screen looked like. This however would require two full screen updates and therefore 100% of cpu time at 60hz. It should run at 30hz though.

So, if I get bored... (Or if xeda gets bored (make a getCSC hook that enables your interrupt ))