This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - chickendude
Pages: 1 ... 12 13 [14] 15 16 ... 55
197
« on: July 16, 2014, 10:14:44 pm »
The grayscale looks really nice on calc. Personally this is my favorite of the 2048 clones 
198
« on: July 06, 2014, 08:33:01 pm »
The bcalls are a bit more complicated than that. What you will find in ti83plus.inc is an address for the bcalls. Someone else can probably explain this much better, but i believe essentially there's a big table which holds the address + flash page of the bcalls. The bcalls are stored in the OS, the include file just provides you with an easy way to access them. Rather than remember the address in the table (for example, $450A for _PutS) you can just type the name. There isn't any code in the include file so it won't increase the size of your file any, there are only equates.
199
« on: July 05, 2014, 09:05:48 am »
I was talking about the underscore in the B_CALL macro 
200
« on: July 04, 2014, 05:05:45 am »
I think in the majority of cases jr z will be faster than jp z, i'm not sure but i would assume that you wouldn't come across an error very often. When jr doesn't take the jump, it's both faster and smaller than jp (i'm talking about after the bit 5,c). EDIT: Disregard what i said, i just looked at the code a bit more closely and realize that bit 5 would be set not reset if there was an error 
201
« on: July 03, 2014, 03:01:54 pm »
What doesn't work? Assembling it? Are you using the ti83plus.inc that i linked to? What exactly are you trying to assemble (can you post the code)? Does it not assemble or does the .8xp not work?
202
« on: July 01, 2014, 10:06:29 pm »
Great work, tifreak! (and Weregoose )
203
« on: July 01, 2014, 01:28:32 pm »
Because you'd have to change the jr to a jp, which uses an absolute address rather than a relative one.
And thanks calc84 and DrDnar for the explanations.
204
« on: June 30, 2014, 03:51:19 pm »
Assuming it's the same setup as the old GetKey values, i think all you really need to do is split the 10s and 1s. Subtract 4 from the 10s (A = 41, so 4-4 = 0), multiply by 5 (0*5 = 0) then add the 1s. If the number is greater than 3, you'll need to subtract 2. You'll also need to handle [Var] and [Clear].
A = 41 = (4-4)*5 + 1 = 1
B = 42 = (4-4)*5 + 2 = 2
D = 51 = (5-4)*5 + 1 - 2 = 4
Z = 93 = (9-4)*5 + 3 - 2 = 26
205
« on: June 29, 2014, 05:27:36 pm »
You'll need to add: #define b_call(xxxx) rst 28h \ .dw xxxx ..to the top. Also, i would recommend using this ti83plus.inc instead. Most people use bcall(_XXXX), you might find that that is already defined in your ti83plus.inc. EDIT: Just to clarify, that is bcall without the underscore. I believe TI added an instruction for B_CALL, so you might be able to use B_CALL _NewLine (no parentheses) just like any other instruction, too.
206
« on: June 29, 2014, 02:14:41 pm »
What do you mean by user protection? Anyone can run it using Asm(prgmRWAPPV. But there aren't very many error checks, i could add a couple simple things such as quitting when you don't provide any data in Ans (for example "1APPV1" instead "1APPV1Hello").
I think it's a little long for your average hex code and you might want to play around with it a bit first just to make sure that it works well, but you can do whatever you want with the code. Consider it in the Public Domain. And be careful, 'cuz if you pass it the wrong arguments when trying to write to an AppVar, there's a strong chance you'll get a RAM clear. I'd hate for your program to get erased...
207
« on: June 28, 2014, 10:20:41 pm »
I think the "trick" here is that bit 7 will always be the opposite of the byte you're trying to write (here in b), so if bit 7 of b is 1, bit 7 of (hl) will be 0 (so XORing the two will always give you 1). If it's finished, then you'll get the same bit that's in b, so XORing them will give you 0 (so z will be set). I don't really know how all of it works, that's just what i got from calc84's message.
EDIT: And (hl) doesn't really return the value of (hl) but rather a status byte, so i think you could read from anywhere in flash (like "ld a,($4000) \ xor b") and it would return the same thing until the thing finishes. Also, if you just cp (hl) there's a chance that the status byte has the same value as the byte you're trying to write.
208
« on: June 28, 2014, 05:24:56 pm »
The hex codes should be in the spoiler at the bottom of the post, so you should be able to use those. The program is pretty long, though, so it'd be much more convenient just to load the .8xp. If you've got any questions about the code feel free to ask, it appears that the information on some of those BCALLs at WikiTI isn't complete, _RclAns for example will also load the pointer to its data if Ans isn't a number, basically just like _ChkFindSym. From the 83 Plus System Routines Guide: RclVarSym will recall the contents of the variable to OP1 if it is real, to OP1 and OP2 if the variable is complex and otherwise leaves the name as is in OP1 and returns HL as the symbol table pointer and DE as the data pointer as in ChkFindSym. If there's anything else you'd like added (or if you find something that doesn't work), let me know and i'll see what i can do to add/fix it
209
« on: June 28, 2014, 03:17:57 pm »
I just wrote a program (151 bytes) that takes the following format: [1:NAME_OF_APPVAR:STRING_TO_STORE] to store a string to an AppVar or [2:NAME_OF_APPVAR] to store the contents of the AppVar into Ans. Here's the assembly: #include "includes/ti83plus.inc"
.db t2ByteTok,tasmCmp ;the AsmPrgm token
.org $9D95 ;progstart, all asm programs are loaded to this address in RAM
saferam1 =$86EC ;saveSScreen=768
name_str = saferam1
size = saferam1+7
code_start = saferam1+9
start:
bcall(_RclAns) ;de = start of data, first two bytes are size bytes
cp 4 ;if ans is a string, a = 4
ret nz
ex de,hl
ld e,(hl)
inc hl
ld d,(hl) ;de = size of Ans
inc hl
ld a,(hl) ;a = action # (1 or 2)
inc hl ;hl = start of string name
dec de ;the first byte is the action number
dec de
dec de
dec de
dec de
dec de ;-5 for the string name
ld (size),de
dec hl
ld (hl),AppVarObj
ld de,name_str ;copy name in Ans to name_str
ld bc,6
ldir
ld (code_start),hl
ex de,hl
ld (hl),0
ld hl,name_str
rst 20h ;_Mov9ToOP1, copy 9 bytes from (hl) to OP1 (copies our AppVar name)
sub '1' ;$31
jr z,write_appvar
dec a
ret nz
read_appvar:
bcall(_ChkFindSym)
ret c
ex de,hl
ld c,(hl) ;first two bytes are the size bytes
inc hl
ld b,(hl) ;bc = size of Ans
inc hl
ld (size),bc
ld de,code_start
ldir ;copy the whole string to code_start
bcall(_AnsName)
bcall(_ChkFindSym)
bcall(_DelVar)
bcall(_AnsName)
bcall(_ChkFindSym)
ld a,StrngObj
ld hl,(size)
bcall(_CreateVar)
ld bc,(size)
inc bc
inc bc ;rewrite the size bytes
ld hl,size
ldir
ret
write_appvar:
ld hl,(size)
bcall(_EnoughMem) ;check if we've got enough space to create the AppVar
ret c
ex de,hl
push hl
push hl
bcall(_ChkFindSym) ;OP1 = name of variable to find
jr c,$+5
bcall(_DelVarArc) ;delete AppVar if it already exists
pop hl
bcall(_CreateAppVar) ;OP1 = name, hl = size
pop bc
inc de
inc de ;skip size word
ld hl,(code_start)
ldir ;copy Ans into AppVar
retThe AppVar name must be 5 characters long, if you don't want to use 5 characters just fill them with spaces. There isn't very much error checking since that would increase the size of the program a bit. I'd recommend sending the .8xp to your calc, but here's the hex codes just in case. Be careful, if you give the wrong inputs (for example, not giving it any data making it try to create an AppVar of size 0) you risk clearing your RAM. Optimizations are welcome
210
« on: June 28, 2014, 10:43:37 am »
...or simply leaving out the bit 7,a. I'm also not sure what the following "bit 5, (hl)" is for. Have you tried seeing if it works without it? You're just waiting for the byte to update so i can't imagine what you'd need it for.
Pages: 1 ... 12 13 [14] 15 16 ... 55
|
Show Posts