I saw this post and decided to write a keyhook that puts the current LCD contents into a pic variable.
You install it by running prgmASAVEPIC and take a screenshot by holding [ON] and pressing a key from 0 to 9.
Currently it has basic functionality and is useful, but be aware of the following limitations (some of which I can fix and will probably get around to fixing):
Although you can start it, there is currently no specific way to get rid of the hook. If you have CalcSys, you can manually reset bit 0 of (iy+$34), but other than that the only way to get rid of it is a RAM reset. (Though it works fine and there's no reason to remove it )
It doesn't chain the current keyhook. It can probably be successfully chained, though, so for apps that have keyhooks and do chain them, you just have to install my hook first.
It overwrites picvars in RAM, and will not take a screenshot if the picvar is in flash. These are both intended.
It will create picture variables as necessary, but will not if there is no free RAM. This is only a problem when free RAM could be gotten, i.e. when the edit buffer is open (e.g. on the home screen). I'll look into making it work when the edit buffer is open.
It saves 768 bytes. If the picvar chosen already exists, but is only 767 bytes (as viewed from the memory menu), it will overwrite 12 bytes of RAM. Make sure they are 779 bytes.
It only works within bcall(_GetKey). This is a result of using the GetCSC hook. You probably won't be able to use it in most of your favorite ASM programs.
In the ASM programs in which it does work, it carries the potential to break them if they expect OP1 to remain intact across a bcall(_GetKey)

Other than that, have fun! (The .8xp is a binary, .8xv is Mimas-format source (yay!), and .z80 is said .8xv converted)
(Note that you can use it on the homescreen or in the program editor, you just need to have a 779-byte picvar in RAM first.)

This topic has been moved to Spam.

http://ourl.ca/12618

Why, so we confuse you with dman2073?

Oh my... That was a bit much on SirCmpwn's part
The permban is definitely deserved, I think.
As for the channel, I think it's fine if it remains on EFNet for the most part. We haven't had any real impersonation issues or anything, so it doesn't seem necessary.
Edit: annoyingorange, most likely.

Of course it is, but I was hoping one could search for something like 01??? and get all the 8bit LDs and a couple of other things

You can just look at rows 4, 5, 6, and 7 to get the same effect, couldn't you?
Deep Thought, can the space be put into the table cells themselves?

Runer112 offers another solution for running archived code, in contrast to my earlier idea:
Say that the largest subprogram is 256 bytes. At the very beginning of the program, put Asm(0000...0000), where there are 256 00s.
Then, your subprograms can be run like this:
GetCalc("prgmSUBPRGM",Y₁)
Copy(Y₁+2,_E9D95,256)
(_E9D95)()
There are some limitations to this method, though.
Axe's more complicated built-in routines only get included in the compiled program once when they are used. This way, they'd be included once in every subprogram.
You'll have to treat each subprogram as a blob. That is, you can only run it from the beginning, not use any routines in it. Same for trying to run routines in the main program from a subprogram. No can do. The first problem is actually a specific instance of this one.
If you want more capability/flexibility, you'll have to use assembly. That, or manually calculate addresses.

Archived code...
Well, you have two options for that, if you really need to do it.
The first option is to make your program an app. That gives you almost 16KiB total space for in-program code and data.
You can store code in appvars if you really want to. You wouldn't be able to run it directly from flash; you'd have to copy it to RAM first. Since Axe doesn't have the ability to compile to a base address other than $9D95 (programs) or $4080 (apps), any code would have to be in assembly. That said, such an appvar could be run like so:
Return!If GetCalc("appvCODE",Y₁)
Copy(Y₁,L₃,{Y₁-2}^r)
(L₃)()
I highly recommend that you use an app, though.

It just waits the number of T-states that are 1/4 the port's value.
So, to answer your questions, no, it will not continue executing, and no, it will not wait for the byte to be successfully sent. It will just wait a certain amount of time.