Ok, I'm glad it was all in one appvar because that makes it way easier.


;##########################################
;search for a user
;input: de = ptr to start of appvar data, (including size bytes)
; hl = ptr to username
;ouput: de = ptr to start of user section
; carry set if not found

searchForUser:
ld a, 8
ld bc, 5

jr realSearch




;##########################################
;search for a coordinate
;input: de = ptr to start of appvar data, (including size bytes)
; hl = ptr to coordinate
;output: de = ptr to start of user section
; carry set if not found

searchForCoordinate:
ld a, 12
ld bc, 13
jr realSearch


;##########################################
;search for an ID
;input: de = ptr to start of appvar data, (including size bytes)
; hl = ptr to coordinate
;ouput: de = ptr to start of user section
; carry set if not found

searchForAnId:
ld a, 5
ld bc, 0


; jr realSearch
; fall through

;#######
realSearch:
push bc
push hl
ex de, hl
ld e, (hl)
inc hl
ld d, (hl)
inc hl
add hl, bc
push hl
ex de, hl
push af
ld a, 25
bcall(_divHLbyA)
pop bc
ld c, l
pop hl
pop de


actualFindLoop:
push bc
push de
push hl
checkMatchLoop:
ld a, (de)
cp (hl)
jr nz, isntMatch

inc hl
inc de
djnz checkMatchLoop

pop hl
pop af
pop af
pop de
or a
sbc hl, de
ex de, hl
ret


isntMatch:
pop hl
ld de, 25
add hl, de
pop de
pop bc
dec c
jr nz, actualFindLoop
pop af
scf
ret

These routines are pretty simple. Just give it the DE that bcall(_chkFindSym) gives you and it will search the appvar for the data you give it. If it runs out of entries, it will return with carry set. Make sure that you don't have an appvar with more than 255 entries though, or else it won't look very far. I tried to make them as small as possible and a few times I was tempted to use the shadow registers, but I didn't.

I also have no idea what you wanted for your third routine. I just made one that searches for a specific ID, you can add whatever you want to the output it gives.

And if you need to search for other stuff, my realSearch: function should work quite nicely.

So are these all different appvars? If they are, why don't you throw them all into one big appvar?

Quote from: thepenguin77 on May 16, 2011, 06:35:42 pm

I think this might be similar to what modern digital cameras do.

Wrong. DSLRs simply leave the sensor active for the duration of the exposure. (Each photon deposits a small amount of charge into the photosite. As the exposure progresses, the charge builds up. At the end, an ADC reads out the charge level.) The main difference between a digital long exposure and film long exposure is film suffers from problems like reciprocity failure and color shifts, whereas digital sensors suffer from noise issues, even at low ISOs.

Quote from: thepenguin77 on May 16, 2011, 06:35:42 pm

If I had just summed rather than averaged, all the pictures would turn out white.

That's probably because your camera is trying very hard not to make each frame pure black, so it's pumping up the ISO. With manual control, you could fix that.

Ok, that makes sense. I forgot that the camera actually changes the picture before it gets to the computer.

This app is really awesome!
Quick question: would it be possible to get the [On] + [numpad] hook to launch apps as well?  Or is that impossible?

Lol, it does already.

EDIT: I just had an idea to die for! (Not really die, but I digress)
Can you please impliment an Omnicalc Quick-App style Quick-Program thing to make scrolling through the program list really fast.  All it is is a linked list (if my speculation is correct), so all you have to do is mess with the VAT.  This would have to be redone every time Mirage or DCS is re-sorted (I think), but I scroll through with the program menu and would use this a lot.  Thanks!
Also, was Quick-Apps in zStart ever implimented?  Personally, Omnicalc messes with too many things for me to use it, so I don't have Quick-Apps enabled because I don't have Omnicalc enabled and would like it running.
Thanks!

I could probably do that. It shouldn't be too hard. I'll just have to make sure I don't interfere with anything else.

So I mostly just cleaned everything up:

Updates:

• EditBuffer is reopened after [ON] + keys, (Mathprint isn't handled well, but it doesn't crash)
• Fixed a mistake where OFFSCRPT wasn't created the moment on ON program was set, (it was still set on ram clears and by running the app though)
• Without a shell, all ION calls except ionDetect and ionDecrompress work
• Without a shell, page $82 is swapped in, which means that if a program tries to use a Mirage call, it will have a clean crash
• APD is re enabled after running programs

And ACagliano, I fixed the running Apps on Turning On, but as for the DCS side, you'll have to bug Kerm about that. zStart will always have to overwrite DCS's OFFSCRPT in order to function. But to be nice, I only kill it if you are running a program on ON or are displaying a picture on startup. The problem is that DCS kills OFFSCRPT whether it needs it or not. So that's why DCS turns it off.

But I suppose if you have it enabled with both. zStart will do it the first time, and then DCS will handle it from then on.

Yes, I'll put a readme out eventually. It will be when I uploaded it to ticalc.org again.

The run on Ram clear option purely runs your program on ram clear. So simple enough, find the program, press [ON] + [ . ] twice, then on the next ram clear, that program will run right between displaying the calculator type and displaying "Ram Cleared."

The old ram clear is for OS's 2.53 and 2.55. It makes the ram clear screen look like the 2.43 screen.

And there's nothing really buggy about running on ram clear. It's no different than any of my other shortcut settings.

Yep, just run zStart, then press [ON] + [Y=] at the homescreen to make it work with headphones.

Well, actually there are two ways.

1. You can do it the TI way. Find the program, make sure it is in ram, load it's name into op1, then bcall(_executePrgm). This is the easy way, but it's limited by what TI can do.

2. Find the program, and you'll have to do different things based on whether it's in flash or ram.
    Flash: find the start of the program in flash, bcall(_insertMem) size - 2 at $9D95, ldir the program without the $BB, $6D to $9D95. When you are done, just bcall(_delMem) the $9D95 for the size you inserted.
    Ram: find the start of the program in ram, copy the program 768 bytes at a time by 1) ldir 768 bytes to saveSScreen, 2) bcall(_delMem) the bytes you just copied, 3) bcall(_insertMem) 768 bytes at $9D95, 4) ldir the bytes there, 5) repeat. When you are done, just do this but instead copy from $9D95 to the little stub of a program you left earlier. And don't forget, _insertMem and _delMem shift all memory, so you'll have to adjust your pointers while copying.