[TI-APP, BCALLS] chkfindsym and others return improper data

[driesguldolf]

Currently, to allocate space for my smc routines I create an appvar with the same size as the smc routines, and I copy the previous contents of $9D95 to there and overwrite it with the routines.
But for some strange reason the emulator kept crashing (the game runs fine but crashes on exit), thus I follow it line by line and I found something strange, whenever I B_CALL(_chkfindsym)'ed he should return the pointer to RAM where the actual data is stored not? In my case he keeps returning $9DB7 or $0600 in DE, I everyone should see that this is impossible :S.
Any ideas?

EDIT: when I do the chkfindsym, he also sets the carry flag (it couldn't find the var), wich he shouldn't do, because I just created the variable with B_CALL(_createappvar)... I store name of the variable in op1, that is correct not? (and hl the size of the var)?

[benryves]

I'd need to see your code to be sure.

(OP1) should contain the variable type, and (OP1+1) is the first character of the variable's name.

As far as I'm aware, the first two bytes of data are the size of the variable, so you have to increment that pointer by two bytes to get to the actual data area.

[King Harold]

Did you load OP1 with the name again when you chkfindsym it?

[driesguldolf]

@benryves: nope I tought tios already incremented the pointer, they say nothing about that in 83psysroutines.pdf, thanks

@King Harold: If simply skipping those bytes doesn't work, I'll try reload op1 with the appvar name

The code:

Code: Select all

; -- Allocate space for SMC routines --
; Simply create an appvar and store the stuff that will be overwritten there
; If the appvar already exists it is deleted and recreated
	ld hl, tempvar
	rst rmov9toop1
	B_CALL(_chkfindsym) ; Return garabage and cflag set, perfectly normal
	jr c, {+}
	B_CALL(_delvararc)
+  ld hl, libs_endsmc - libs_startsmc
	B_CALL(_createappvar) ; Returns $9DB7 or $0600 in de, not correct
	B_CALL(_chkfindsym) ; desperate attempt to get proper data, returns garbage and cflag set (???)
	ld hl, $9D95
	ld bc, libs_endsmc - libs_startsmc
	ldir ; and obviously this fails... plus I forgot to increment de

EDIT: ok I skipped the length word and reloaded the varname, the app exits properly but when I type something, the screen is filled with tokens...
EDIT2: And when I try to access the memory manager, it gives my a "ERR:MEMORY" error

Here's another question: (seems a bit stupid to make a new topic about it)
How do you properly reset the ram of your calc? I tought a simple jp 0 would do the trick, but it doesn't

[King Harold]

Well, you should know that not all those routines preserve OP1..
But the ones you use shouldn't destroy op1 (never trust TI's documentation though)
Why would you want to reset the RAM though?
You should really shouldn't call chkfindsym after you create the var.. no matter how desperate you are
Do you have enough free RAM? (call memcheck)

[driesguldolf]

Well, you should know that not all those routines preserve OP1..

At least they could've said that in there 83psysroutines.pdf :S, normally I use wikiti, but I have no choice when I'm offline...

Why would you want to reset the RAM though?

Out of curiosity, and if the exits fails every time, I can temporarily reset the ram while debugging, then I at least know that it exited, and isolate the exit bug later.

You should really shouldn't call chkfindsym after you create the var.. no matter how desperate you are

That's my reflex when dealing with tios, do redundant things because you never know with ti...

Do you have enough free RAM? (call memcheck)

The create appvar checks of theres enough ram, and quits the app if there isn't, I don't think this is related to the random tokens and the mem error

[King Harold]

Well in PTI there is F9 to reset it
You have a pretty weird error btw..

do you use the right AppvarObj as (OP1)?

[driesguldolf]

Ah found a typo

Code: Select all

	ld hl, libs_endsmc - libs_startsmc
	ld hl, tempvar
	rst rmov9toop1
	B_CALL(_createappvar)

EDIT: WTH??? fixed it and calc crashes...

initailizing code:

Code: Select all

startapp:
.using tios

; -- Allocate space for SMC routines --
; Simply create an appvar and store the stuff that will be overwritten there
; If the appvar already exists it is deleted and recreated
	ld hl, tempvar
	rst rmov9toop1
	B_CALL(_chkfindsym)
	jr c, {+}
	B_CALL(_delvararc)
+	ld hl, tempvar
	rst rmov9toop1
	ld hl, libs_endsmc - libs_startsmc
	B_CALL(_createappvar)
	ld hl, $9D95
	inc de		; Skip length word
	inc de
	ld bc, libs_endsmc - libs_startsmc
	ldir

; -- Copy routines that use SMC to RAM --
; Now I've made a backup of the previous contents of $9D95 and is safe to overwrite
	ld hl, libs_end   ; The start of the smc libs, the smc libs are relocated with .relocate $9D95
	ld de, $9D95
	ld bc, libs_endsmc - libs_startsmc
	ldir

; -- Install my costum interrupt --
; Interrupts are wonderful, they can add TONS of neat little features to your program
	call install

; -- Initalize some system variables --
	ld a, 25		; Used to repeat the arrow keys
	ld (longkeydelay), a	;
	ld a, 15		;
	ld (shortkeydelay), a	;
	xor a
	ld (nextrow + 1), a	; This is used by... TODO: look this up, something with drawing
	ld (lastkey), a		; Used by the scankeys routine
	ld hl, tismallenhanced	; My own costum small font!
	ld (charset), hl	;
	ld a, $CD		; If I ever need to call a 'flexible' address
	ld (calladdr), a	;

; -- Sync with the hardware --
; Who knows what button you are pressing when the app starts
	call scankeys

; -- lcd routines and fast mode --
; If it's not running on a ti8splus I would like to speed things up a little bit
; but I can't use fastcopy in that case
	ld a, $C3		; Set the jump instruction
	ld (updatelcd), a	;
	ld (copyerase), a	;
	ld hl, fastcopy
	ld de, fastcopyerase
	call getcalcmodel	; Get the model we're running on
	jr z, {+}		; Don't set to high speed if running on a ti83plus
	ld a, 1			; This calc is capable of a higher speed
	out ($20), a		;
	ld hl, safecopy		; This means we have to use safecopy
	ld de, safecopyerase	;
+	ld (updatelcd_addr), hl
	ld (copyerase_addr), de

; -- Erase graph buffer and lcd screen --
; Why I'm doing this? Dunno...
	ld hl, gbuf
	ld de, gbuf + 1
	ld bc, 12 * 64 - 1
	ld (hl), 0
	ldir
	call updatelcd

exiting code:

Code: Select all

exitapp:

; -- Invalidate some stuff --
; Invalidate graph is handy in class when you just pressed the teacher key and you have to show the teacher your graph
	set graphdraw, (iy + graphflags)
	res statsvalid, (iy + statflags)

; -- Sync the system with hardware --
; The halt is needed because tios checks the keys during an interrupt
	im 1
	ei
	halt
	B_CALL(_getcsc)

; -- Restore the memory used by SMC routines --
; If I don't do this your calc will blow up
	ld hl, tempvar
	rst rmov9toop1
	B_CALL(_chkfindsym)
	ASSERT(c)		; You seriously messed things up if it couldn't find the appvar...
	push de
	push hl
	ex de, hl
	inc hl
	inc hl
	ld de, $9D95
	ld bc, libs_endsmc - libs_startsmc
	ldir
	pop hl
	pop de
	B_CALL(_delvarnoarc)

; -- And quit to the home screen --
; About time too!
	B_JUMP(_jforcecmdnochar)

tempvar:
	.db appvarobj, "TMP5041", 0

I only use saferam areas (except smc routines) (plotsscreen, appbackupscreen, savesscreen and textshadow)
Anyone who sees what I do wrong?

[King Harold]

Do you have to use SMC? You would avoid all this trouble by not-using it..
Also, consider having "jp 0" somewhere in the SMC code if you want "flexible calls", just load the address after it and call the jp. You could put jp (hl) which is faster and smaller but obviously it won't remember the address you called last time. The initialization would be quite a bit faster than loading an opcode through A.
Then I have 1 more tip: use a saferam area for the SMC and put data that doesn't fit anymore in the appvar, that way you could leave $9D95 alone and you won't have to copy everything 3 times, but only once. Don't forget to save it's address somewhere though.

[driesguldolf]

AAAAGRH, _createappvar STILL doesn't return proper addresses, but it DOES create it...

aaaaaaaaah, FINALY!!! I HATE TIOS!!!!
ok it finally works (just have to run a couple of more test), I skipped the length bytes, reloaded var name, and it turns out _createappvar DOESN'T return pointers :S

@KH: Too bad the smc routines are (a little bit) over 768 bytes...
I first intended to use that flexible call, but it is kinda redundant now. Nice spotted.

[tr1p1ea]

One thing to point out is that emulators might sometimes defragment when you create variables. Afaik it doesnt happen on an actual calc nearly as often.

[King Harold]

_createappvar should return pointers though.. maybe TI made a little mistake there, but surely HL points to the VAT entry? If so, you could step through it a bit and find its location..
You could use _CreateVar http://wikiti.denglend.net/index.php?ti ... CALLs:4E70

[driesguldolf]

hmmmm, suddenly it does return proper values... strange... Probabely something with flashdebugger (I know, I should use PTI...)

@tr1p1ea: Shouldn't be a concern, I don't use tios anywhere (except at the begin and the end), and even emus shouldn't suddenly start to defragment.

[driesguldolf]

ah bugger, it has started returning improper values again... I'm sick of this problem... I'll simply make the smc libs smaller so they fit in 768 bytes and continue... I could use some motivation... (hint hint )

[Goplat]

Currently, to allocate space for my smc routines I create an appvar with the same size as the smc routines, and I copy the previous contents of $9D95 to there and overwrite it with the routines.

Bad idea - the OS could easily place your AppVar itself in a place where it overlaps with where you want to put your SMC. Why not just use InsertMem?