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.)

Adding features requires expanding the hook outside the boundaries of smallEditRAM, which I don't feel like implementing right now
As for also having it install an interrupt, I'll add that to my to-do list. Note that many programs still will di, so it's not perfect.
Most likely you'll have to wait until tomorrow for more features, as I'm not sure how much more opportunity I'll have to work on this tonight.

I'll look into making it work when the edit buffer is open

If (cxCurApp) == $40 (homescreen)
ld hl, (editCursor)
ld de, (editTop)
or a
sbc hl, de
ld (op6Ext), hl

bcall(_closeEditEqu)


;do stuff

;#########################################
fixEditBuffer:
bcall(_closeEditEqu)

bit 5, (iy + $44)
jr z, notMathPrintEnabled

ld hl, saveSScreen
ld bc, 767
bcall(_memClear)

xor a
ld (menuCurrent), a
bcall(_clrLCDFull)
ld hl, cmdShadow
ld de, cmdShadow+1
ld bc, 127
ld (hl), $20
ldir
bcall(_clrTxtShd)
bcall(_homeUp)

ld hl, $40
bcall(_pullDownChk)
bcall($5125)
set curAble, (iy + curFlags)
res curLock, (iy + curFlags)
ret

notMathPrintEnabled:

bcall(_setupEditCmd)
tryIt:
ld bc, (op6Ext)
ld a, b
or c
jr z, bufferIsZero

ld hl, (editTail)
ld de, (editCursor)
ldir
ld (editTail), hl
ld (editCursor), de
bufferIsZero:

ret



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)

;#########################################
pushOP1:
push af
push bc
push de
push hl

ld hl, -12
add hl, sp
ld sp, hl
ex de, hl

ld hl, 12
add hl, sp

ld bc, 10
ldir

ld hl, op1
ld bc, 12
ldir

pop hl
pop de
pop bc
pop af
ret

;##########################################
popOP1:
push af
push bc
push de
push hl

ld hl, 10
add hl, sp
ld de, op1
ld bc, 12
ldir

ld hl, 10+12-1
add hl, sp
ex de, hl

ld hl, 10-1
add hl, sp

ld bc, 10
lddr

inc de
ex de, hl
ld sp, hl

pop hl
pop de
pop bc
pop af
ret

That's how I do it. <.< >.>

Edit:
   Forgot about a prerequisite of the first routine, it's good now though.

Cool stuff. Dthought's program had me thinking about if something like this was doable. I thought I had seen something similar before, but I couldn't remember. Maybe I'll try to make one too.

Thepenguin77, thanks for the code. I've handled the OP1 issue differently, however. Also, before I integrate your code for the homescreen, would it be possible that it work in all contexts where the OS uses an edit buffer, not just the homescreen?

I'm sure it's possible, it just starts to get really messy, you'll have to do a lot of disassembling and wabbitemu memory exploring to make it happen.

HOWEVER, the code has expanded beyond smallEditRAM, and the mechanism I have used to extend it beyond that requires that you have execution protection disabled for RAM page 0. If it isn't disabled, it might crash your calc. (Personally, I've patched my boot code so I never have to worry about it again, but most people won't do that.) If you can disable the protection yourself, then you'll be fine.

One way you could avoid this would be to stream your data to saveSScreen from wherever the original program is. I've done that in the past and it works quite well.

(PS, zStart can unlock page 0 <.<)