Context Equates to Call Edit Screens?

[youssarian]

While scrolling through ti83plus.inc, I noticed a group called "Context Equates". Commented next to these were various sorts of screens, like stats editor, matrix editor, program editor, and so on. I put in this code into a fake program:

call cxMatEd
ret

(with proper heading, closing and tabbing, of course.)

When I ran it through the converter, it worked fine. So, would the context equates (like cxMatEd or perhaps kMatrixEd) be useful for calling up these screens?

[DarkerLine]

If the assembler works, it just means you don't have any syntax errors in the code. It doesn't know the difference between the equate for the address of a routine (like _GrBufCpy), the address of some other location in memory (like UserMem), or any other constant (like your cxMatEd).

When you run your code, you'll end up calling $0042, which I think is part of the OS interrupt code, but in any case it's not something you want to be calling. It definitely won't call up the matrix editor.

[youssarian]

Oh.

Is it possible to call these screens in assembly?

[DarkerLine]

Probably, but I don't know how, and I doubt you'll get control back afterwards.

[TheStorm]

Well using hooks you could get control back but other than that I doubt there is a way You'd have to ask BrandonW or someone with equivalent ti hacking knowledge. maybe poke around the Detached Solutions forum they may be dead(or just sleeping) but there is a lot of good info there.

[DarkerLine]

Also, I'm guessing there's an easier way to do whatever it is you want to do.

[fourchanb]

If you want to make a menu that looks like that, you'll want to try one of the menu makers out there. TI has one but that is incompatible with every assembler out there that people actually use.

The equates you talked about are numbers that are put in some sort of variable that tells keyhooks and the like in what menu they are.

[FloppusMaximus]

No, those aren't addresses for you to call. They're values used internally by the OS to identify the built-in apps. For example, (cxCurApp) is set to the value corresponding to the currently-running app. They're also used in various B_CALLs and hooks.

In general you can't "call" an app -- either a TIOS builtin app or a Flash app. The OS considers itself to be running only one app at a time; when you switch to another app, the FPS, OPS, and hardware stack are (usually) reset.

What you can do if you *really* need to is to "jump" to a built-in app while setting one or more hooks that will restart your program when the user exits the app. This is rather difficult for FlashApps to do safely, and virtually impossible for other programs.

There is one exception that I know of, a B_CALL which does something similar to the BASIC "Input" or "Prompt" command; I don't remember the name or address, but it essentially saves the current state and loads up the cxPrgmInput app temporarily. This should only be used by FlashApps or AsmPrgms, not by shell programs.

[brandonw]