Omnimaga

Calculator Community => TI Calculators => Axe => Topic started by: Michael.3545 on June 24, 2010, 12:41:31 pm

Title: The case of the decreasing RAM
Post by: Michael.3545 on June 24, 2010, 12:41:31 pm
Axe is amazing.  In fact, it is so amazing, that it made me sign up for a forum, an act which I am rarely caught doing.  But to get down to the meat of the problem I am having, a password program I am working on has developed the uncanny ability to eat RAM.  In fact, each time i get the password wrong, then right, it eats 572 bytes of RAM.  I believe that this may have something to do with the assembly code I am using to give the program the ability to turn off the calculator.

This code is EF0850C9

which via the use of calcsys' hex editor and decompiler, I have discovered translates to:
bcall 5008
ret

After testing the code to see if it was the culprit, I learned that every time this code is ran, it eats 6 bytes of ram.
If you factor 572, you get 2, 2, 11 and 13.  So no matter how many times you loop that code, you can't lose 572 bytes.  

Oh, and I looked through all of the symbols and the VAT section of calcsys, and couldn't find anything that matched the size of my missing bytes.  The have been eaten, I tell you!

Does anyone have any idea what could be causing this?

If you want, I could post the source, but it is 516 bytes large and I have no idea exactly what portions are related to the problem.
Title: Re: The Case of the Missing RAM
Post by: _player1537 on June 24, 2010, 12:46:37 pm
can you please post the source
Title: Re: The Case of the Missing RAM
Post by: Michael.3545 on June 24, 2010, 01:03:09 pm
Click here (https://docs.google.com/leaf?id=0B1AfyYYD6YT9ZTFkYjBiOGItYzkxMS00ZDVjLWIyNmItNmRhODIyZjg3M2U1&hl=en) for the .8xp file.  If there is a better way of posting code, could you tell me?
Title: Re: The Case of the Missing RAM
Post by: _player1537 on June 24, 2010, 01:08:47 pm
http://sc.cemetech.net
that will work for .8xp (non-asm) pictures, and... something else...
just choose the file and press parse, and then post the output over here :)

also, I thought this was an .8xp?  like the source?
Title: Re: The Case of the Missing RAM
Post by: Ikkerens on June 24, 2010, 01:11:41 pm
Code: [Select]
[quote author=Michael.3545 link=topic=3608.msg44428#msg44428 date=1277398989]
Click [url=https://docs.google.com/leaf?id=0B1AfyYYD6YT9ZTFkYjBiOGItYzkxMS00ZDVjLWIyNmItNmRhODIyZjg3M2U1&hl=en]here[/url] for the .8xk file.  If there is a better way of posting code, could you tell me?
[/quote]

There are 2 ways [ code ] tags and uploading (which becomes available after 5 posts.
Title: Re: The Case of the Missing RAM
Post by: Michael.3545 on June 24, 2010, 01:17:23 pm
Ah, I see. 5 posts.  And I lied, it is an 8xp file, but I edited it so it is right now.  And there isn't any output from the compiler, it compiles fine.  Running the program itself eats the RAM somehow.
Title: Re: The Case of the Missing RAM
Post by: DJ Omnimaga on June 24, 2010, 01:22:41 pm
Hi and welcome here.

By the source, by the way, he meant to post the code of your Axe program before compiling/parsing. Either the 8xp file or the code will do. Sadly, due to spam protection, the former is impossible until 5 posts, though, so you would need to go for the later for now.
Title: Re: The Case of the Missing RAM
Post by: Michael.3545 on June 24, 2010, 01:25:25 pm
I did post the source.  That 8xp file is the source code.  It has not been axed yet.


And why would I put ...SRC in an assembled program?
Title: Re: The Case of the Missing RAM
Post by: LordConiupiter on June 24, 2010, 01:26:36 pm
so this is the code:
Code: [Select]
:.PWD
:ClrHome
:DiagnosticOff
:
:
:
:.SET UP APPVAR
:"vPwdTries"→Str1
:GetCalc(Str1)→A
:!If A
:GetCalc(Str1,1)→A
:Return!If A
:3→{A}
:End
:
:
:
:.LOCKDOWN MODE
:If {A}=0
:Disp "    LOCKDOWN"
:Pause 3000
:If getKey(54)
:If getKey(55)
:If getKey(56)
:3→{A}
:End:End:End
:Goto SD
:End
:
:
:
:.SET PASSWORD
:DeltaList(34,26,18,35,27,19,36,28)→GDB1
:
:
:
:.GET INPUT
:Output(1,3,"INPUT PASSWORD")
:Output(4,4)
:For(I,0,7)
:While getKey(0)
:End
:0→K
:Repeat K
:getKey→K
:End
:K→{{L1}+I}
:Disp 63►Frac
:End
:
:
:
:.CHECK INPUT
:1→K
:For(I,0,7)
:If {I+{L1}}≠{I+GDB1}
:0→K
:End:End
:ClrHome
:If K
:Goto AG
:Else
:Goto AD
:End
:
:
:
:.CORRECT
:Lbl AG
:3→{A}
:Disp " ACCESS GRANTED",{i}
:Return
:
:
:
:.INCORRECT
:Lbl AD
:{A}-1→{A}
:Disp " ACCESS  DENIED"
:Pause 3000
:
:.SHUT DOWN
:Lbl SD
:ClrHome
:Asm(EF0850C9)

Generated by SourceCoder (http://sc.cemetech.net)
© 2005-2010 Cemetech (http://www.cemetech.net)

I don't really get what's all the code doing, and why all the code is the way it is, so perhaps u could explain it a little more?
like the .LOCKDOWN MODE part ???
Title: Re: The Case of the Missing RAM
Post by: DJ Omnimaga on June 24, 2010, 01:30:03 pm
Ok thanks, I did not notice the link a few posts earlier, as I opened the page before the edit.

Quote
And why would I put ...SRC in an assembled program?
It was rude and unnecessary. It's not like the 8xp link was that visible anyway (it was even a 8xk file before I posted). Most people are used to full URLs being shown (or attachment names). Otherwise in the end people will no longer help you if you are not respectful to them.
Title: Re: The Case of the Missing RAM
Post by: Michael.3545 on June 24, 2010, 01:37:22 pm
@_player1537
Ah, so THAT is what that link was for.

@LordConiupiter
Here is a description of what the program does.

It is safe to run, it doesn't clear your ram.  It just eats it.   :)

It is meant to be ran using the startup app.

.SET UP APPVAR
checks to see if the appvar already exists, if not, it creates a new one.  The apvar stores how many tries you have left before the program locks down.


.LOCKDOWN MODE
if you get the password (which is 1 2 3 4 5 6 7 8 currently) wrong three times, the next time the program is ran you must press [2ND] [MODE] and [DEL] simultaneously within 3 seconds to reset your remaining tries to 3.

.SET PASSWORD
 is where I store the correct password into GDB1

.GET INPUT
Gets input and stores it to L1

.CHECK INPUT
compares L1 to GDB1

.CORRECT
exits the program normally, giving you acess to the home screen

.INCORRECT
Turns the program off, causing it to be started again next time you turn the calculator.  (remember the startup app)
Title: Re: The Case of the Missing RAM
Post by: Michael.3545 on June 24, 2010, 01:40:31 pm
Sorry, I guess I assumed you had clicked on my link and somehow come to the conclusion that it wasn't the source.

Next time I will just use http://sc.cemetech.net to avoid all this confusion and get all of the information in one place.
Title: Re: The Case of the Missing RAM
Post by: souvik1997 on June 24, 2010, 01:59:22 pm
How did you get it to assemble with a string inside the Output() and Disp?
Disp and Output only accept pointers, not strings.
You have to store the strings to pointers.

Title: Re: The Case of the Missing RAM
Post by: ACagliano on June 24, 2010, 02:12:14 pm
Check the size of the program itself. Here's what I see...

Whenever you run the "CalcOff" hex (Asm(EF0850C9)), the calc turns off, but the program doesn't quit. Then, as it turns on, the calculator's Startup App relaunches the program again. Thus, each time the program is used, you add another running instance of the program to memory, and that causes your "missing RAM".

Title: Re: The Case of the Missing RAM
Post by: Michael.3545 on June 24, 2010, 02:18:59 pm
@souvik1997
It doesn't seem to mind, and it works as it should.

@ACagliano
prgmPWD is 584 bytes, so subtract out whatever header stuff and your probably do get 572.  Now it all makes sense.  Is there any way to work around this problem?  If only I could exit the program and then do the bcall.

EDIT:  Now that I think of it, there MUST be some way of doing this, as other password protection Apps and Programs don't have this problem.  Oh, and where in memory do the copied programs go? I can't seem to find them with calcsys.
Title: Re: The Case of the Missing RAM
Post by: ACagliano on June 24, 2010, 02:25:38 pm
Take the program off Startup and add a routine that once you turn the calc back on, the program returns to the beginning of itself. Thus, you stay within the same instance. Remember, when the calc is turned off using asm within a program, when the calc is turned back on, it resumes from the line it left off. Hope this help.
Title: Re: The Case of the Missing RAM
Post by: Runer112 on June 24, 2010, 02:32:59 pm
Try this hex instead maybe: 3E01D303FB76FDCB09A6C9
Title: Re: The Case of the Missing RAM
Post by: Michael.3545 on June 24, 2010, 02:37:20 pm
@ACagliano

...when the calc is turned off using asm within a program, when the calc is turned back on, it resumes from the line it left off...

My code doesn't do this.
I tried:
Code: [Select]
Disp "HI"
Asm(EF0850C9)
Pause 1000
Disp "HI2"

And I received the output of HI on the home screen after turning the calculator back on.



@Runner112


EF0850   =   bcall 5008
C9   =   ret


Why is the longer one so much longer?
Title: Re: The Case of the Missing RAM
Post by: ACagliano on June 24, 2010, 02:41:14 pm
Because, the "calc off" command doesn't really turn off the calc. It just turns off the LCD, but the processor moves forward onto the next instruction. So when you press ON, the Pause 1000 is already done, so now "HI" is on the screen.

At least I think thats how it works. correct me if I'm wrong.
Title: Re: The Case of the Missing RAM
Post by: Runer112 on June 24, 2010, 02:43:21 pm
Because, the "calc off" command doesn't really turn off the calc. It just turns off the LCD, but the processor moves forward onto the next instruction. So when you press ON, the Pause 1000 is already done, so now "HI" is on the screen.

At least I think thats how it works. correct me if I'm wrong.

This hex only turns off the LCD: 3E02D310C9

The hex he's using turns off the entire calculator and halts processing.
Title: Re: The Case of the Missing RAM
Post by: Michael.3545 on June 24, 2010, 02:46:30 pm
Ah, so is there one that pauses processing and turns off the LCD screen?  Like a standby mode in windows?
Title: Re: The Case of the Missing RAM
Post by: Runer112 on June 24, 2010, 02:50:36 pm
I'm looking at the bottom of this page http://tibasicdev.wikidot.com/hexcodes (http://tibasicdev.wikidot.com/hexcodes) for information about hex codes involving turning off the calculator. They say the hex code you're using should do what you want, but there's another hex code that it sounds like your code is producing the behavior of. I'm thinking perhaps the two got mixed up and the one you really want is 3E01D303FB76FDCB09A6C9.
Title: Re: The Case of the Missing RAM
Post by: Michael.3545 on June 24, 2010, 03:06:08 pm
That new code (the long one) doesn't resume where I left off, but it also seems to not eat RAM, so I will test it out.

EDIT:  The new code now works just like the old one (returns to home screen on power-on) , only without the RAM-eating side effect.  Thanks everyone, it seems that this case is closed.
Title: Re: The Case of the Missing RAM
Post by: Michael.3545 on June 24, 2010, 06:00:09 pm
Well, when you turn back on again from the new asm code, the startup application doesn't launch.  Any suggestions?  Perhaps there is a way to make the program start itself without the app?


(self-starting programs *shudder* what's next, a calculator virus?  skynet8x?)
Title: Re: The Case of the Missing RAM
Post by: ztrumpet on June 24, 2010, 10:39:38 pm
EDIT:  Now that I think of it, there MUST be some way of doing this, as other password protection Apps and Programs don't have this problem.  Oh, and where in memory do the copied programs go? I can't seem to find them with calcsys.
When programs are run they start execution at $9D95. :)

I'm glad you figured this out.  It sounds like a neat program. ;D
Title: Re: The case of the decreasing RAM
Post by: DJ Omnimaga on June 24, 2010, 10:45:22 pm
Btw I renamed the first post of this topic so OmnomIRC grabs it under it, because it might make people think this topic is about the extra 84+ RAM pages issue that hits TI-Boy SE, Msd8x, Omnicalc RestoreMem and the like.
Title: Re: The case of the decreasing RAM
Post by: calc84maniac on June 25, 2010, 02:09:15 am
I think the C9 should be removed from ASM routines you use, because that causes it to return, which you don't want with inline assembly like this.
Title: Re: The case of the decreasing RAM
Post by: DJ Omnimaga on June 25, 2010, 02:18:08 am
Will it act like Stop does in BASIC in some ways, exiting from every single program you were in back to the TI-OS? I remember Doors CS had troubles dealing with this.
Title: Re: The case of the decreasing RAM
Post by: calc84maniac on June 25, 2010, 02:21:01 am
Well, it works just like a "Return" instruction in Axe (and you probably won't want your program/subroutine to exit after your Asm() statement)
Title: Re: The case of the decreasing RAM
Post by: DJ Omnimaga on June 25, 2010, 02:23:38 am
Aaaah ok, I see, thanks for the info
Title: Re: The case of the decreasing RAM
Post by: mapar007 on June 25, 2010, 02:58:30 am
ret (C9) in asm is pretty similar to Return in BASIC, (and Axe, it seems).
Title: Re: The case of the decreasing RAM
Post by: Quigibo on June 25, 2010, 04:40:15 am
Return IS ret in Axe.  They are one and the same :P

A self launching program is going to be too difficult without help from the OS or the start-up app.  What I would do instead is have the calculator turn off the LCD and then halt the execution until the next [ON] interrupt.  You might have to get an ASM programmer to write this for you if you're new to assembly since its pretty tricky.
Title: Re: The case of the decreasing RAM
Post by: calcdude84se on June 25, 2010, 11:42:24 am
The code for that is:
Code: [Select]
;Wait until [ON] is pressed, and in low power mode
ld a,1
out (03h),a ;Set the calc to go into low power mode on a halt, and only respond to the [ON] key
ei ;Just to make sure they are on
halt ;Wait until [ON] is pressed
ld a,$0B ;normal mask
out (03h),a ;Set things back to normal
Let me assemble that for you.
* calcdude goes and assembles this.
Edit: The hex is 3E01D303FB763E0BD303
This should be inserted as a normal line in code, seeing as there is no return at the end
Title: Re: The case of the decreasing RAM
Post by: Michael.3545 on June 25, 2010, 05:18:29 pm
As all of you stated above, the C9 on the end was the issue.  I figured this out myself last night before I went to bed.  Actually, it was keeping me up.  I thought to myself, "What if ret is the same as Return?"  I took off the C9, and bazinga!  After turning back on, the code resumed where it had left off.  After a slight modification of my program, (eliminated the appvar and added a big ol' loop) it worked beautifully.  So all of the people who were talking about the C9 above were right.  In conclusion, C9's are bad to have at the end of your Asm( tags in Axe.  Quigibo, perhaps this would be a worthy addition to the Asm( portion of the commands list?  And if anyone wants the working source code, I will post that here as soon as I unlock uploads at 20 posts.  The 8 digit password can be easily changed in the source code if you use the keycodes.png file included with axe.
Title: Re: The case of the decreasing RAM
Post by: ztrumpet on June 25, 2010, 05:21:15 pm
I took off the C9, and bazinga!
Nice bazinga. ;D

Great!  I'm glad you got it to work properly. :D
Title: Re: The case of the decreasing RAM
Post by: DJ Omnimaga on June 25, 2010, 07:13:29 pm
Nice to hear you got it working properly :)
Title: Re: The case of the decreasing RAM
Post by: Michael.3545 on June 25, 2010, 10:33:33 pm
Here's the source file, for anyone who's interested.  To change the 8 character password, put the key codes into GDB1.  Currently, it is set a 1,2,3,4,5,6,7,8.
If it locks after two tries, holding [2ND] + [MODE] + [DEL] will reset tries and go back to password screen.  You can change the initial tries by changing the value stored to T.  All the things that you might want to change are on the first screen.
Title: Re: The case of the decreasing RAM
Post by: DJ Omnimaga on June 25, 2010, 11:15:01 pm
Mhmm I might try this later, altough I might not need it much personally (since no one else touches my calc, so no risk of getting mem resets)
Title: Re: The case of the decreasing RAM
Post by: Michael.3545 on June 26, 2010, 12:33:39 pm
It seems that the off mode the program goes into is somehow fundamentally different than a normal shutdown, and Press-To-Test cannot be enabled.  Of course, the password may just PO a teacher and cause them to rip out a battery, clearing your RAM.  But that could be fun to watch.  (If you had a back-up)
Title: Re: The case of the decreasing RAM
Post by: DJ Omnimaga on June 26, 2010, 01:00:31 pm
Mhmm... interesting. TOo bad I couldn't test the later because I have been out of hi scool for years ;D
Title: Re: The case of the decreasing RAM
Post by: Builderboy on June 26, 2010, 02:01:32 pm
And I just got out of high school :O haha what would be funny is if you hacked your calculators to have secret extra bateries :P watch them pull the bateries and *nothing happens*!  (and then get your calc confiscated x.x)
Title: Re: The case of the decreasing RAM
Post by: DJ Omnimaga on June 26, 2010, 02:05:45 pm
Yeah I think if they noticed your calc was modded/hacked so no reset can be possible, they would take it away for the entire test
Title: Re: The case of the decreasing RAM
Post by: Michael.3545 on June 26, 2010, 02:23:06 pm
Hence the two patches to respectively disable PTT, and make it appear to be non-disabled.
Title: Re: The case of the decreasing RAM
Post by: Builderboy on June 26, 2010, 02:30:28 pm
Ahh tricky tricky ^-^ teachers around the world are losing their grasp of control :D
Title: Re: The case of the decreasing RAM
Post by: DJ Omnimaga on June 26, 2010, 02:48:00 pm
Hence the two patches to respectively disable PTT, and make it appear to be non-disabled.
True, usually they won't notice that one :P
Title: Re: The case of the decreasing RAM
Post by: willrandship on June 27, 2010, 10:28:58 pm
I feel so lucky now. My math teacher cleared the ram once on a test we did, since it was a regulated test, but never does it otherwise. Once, I let him reset my ram with my 84+ pad in, then switched to my nspire pad with all my progs :P

It rocks and sucks at the same time to live in the country.
Title: Re: The case of the decreasing RAM
Post by: mapar007 on June 28, 2010, 05:04:00 am
Just to remind everyone: pulling a battery during a normal OS _GetKey loop (like the homescreen, and maybe the PTT screen, I don't know for sure) will NOT cause your RAM to clear.

The RAM clear isn't caused by pulling the battery, the OS merely does it because the RAM checksum doesn't match the actual memory content.
So if you want good pw protection, use _GetKey, and not _GetCSC or direct input, and make sure the OS interrupt runs. (Krolypto does this, btw)


EDIT: I'm posting this because I inferred certain fallacies from previous posts, so don't blast me :)
Title: Re: The case of the decreasing RAM
Post by: Michael.3545 on June 28, 2010, 11:26:57 am
Removing all batteries and holding ON for three seconds should always work though, right?
Title: Re: The case of the decreasing RAM
Post by: DJ Omnimaga on June 28, 2010, 11:30:16 am
Just to remind everyone: pulling a battery during a normal OS _GetKey loop (like the homescreen, and maybe the PTT screen, I don't know for sure) will NOT cause your RAM to clear.

The RAM clear isn't caused by pulling the battery, the OS merely does it because the RAM checksum doesn't match the actual memory content.
So if you want good pw protection, use _GetKey, and not _GetCSC or direct input, and make sure the OS interrupt runs. (Krolypto does this, btw)


EDIT: I'm posting this because I inferred certain fallacies from previous posts, so don't blast me :)
Mhmm, I noticed it doesn't work when under the TI-OS BASIC pause mode, btw (tested under OS 1.12 through 1.18 on the 83+ and 1.13 through 1.18 on 83+SE, btw). If I am in pause mode in a BASIC program (even auto-power-down/APD) and I remove a battery, my RAM will be cleared when I turn the calc back ON.

Removing all batteries and holding ON for three seconds should always work though, right?
Mhmm I never heard of that trick before. Could you explain in more details?
Title: Re: The case of the decreasing RAM
Post by: Michael.3545 on June 28, 2010, 11:43:48 am
http://education.ti.com/guidebooks/graphing/84p/TI84PlusGuidebook_Part2_EN.pdf (http://education.ti.com/guidebooks/graphing/84p/TI84PlusGuidebook_Part2_EN.pdf)

Quote from: TI 84 Plus Guidebook on page 668
If the TI-84 Plus does not function even though you are sure that the batteries are
fresh, you can try manually resetting it.
• Remove all of the AAA batteries from the graphing calculator.
• Press and hold the [ON] key for ten seconds.
• Replace the batteries.
• Turn on the unit.

Oops, I guess it is 10.  Well, three has always worked for me.  This was good for when my password program messed up in development, and the turn off code ended up in a loop.
Title: Re: The case of the decreasing RAM
Post by: DJ Omnimaga on June 28, 2010, 11:52:19 am
Does that force the calculator to go back on the TI-OS homescreen? Darn, I had a TI calc for almost 9 years now and I still don't know about this x.x
Title: Re: The case of the decreasing RAM
Post by: Michael.3545 on June 28, 2010, 11:59:53 am
It clears the RAM.

EDIT: As far as I know, there is no way around it.

(except fake batteries, lol builderboy.)
Title: Re: The case of the decreasing RAM
Post by: DJ Omnimaga on June 28, 2010, 12:58:16 pm
Oh ok, lol. It would have been kinda funny if that was a way to get around RAM clears temporary and barely any on-calc programmer knew XD. We would bypass crashes, go in the MEM menu, hopefully succeed in archiving our program then either manually RAM clear or let the crash do its course normally, eventually clearing the RAM by itself. It would prevent some data loss (altough in many cases, when the calc crashes, the RAM is corrupted so it may not be that reliable since your code might be filled with random garbage