Storing Memory Addresses to Ans Variable

[Turgrid]

Hello,

In ASM, how would you store the data contained in memory addresses 867Dh through 8685h to an OS variable string (i.e. str1 or ans) that you could access from a BASIC program. My knowledge of ASM is limited and when I attempted to implement the system call _stoAns, I couldn't seem to get it to work.

Thanks!

[Harrierfalcon]

I'm not that great at ASM either, but here's what the ROM call manual says about b_call(_stoans):

I'm not entirely sure what to do, I'm not familiar with floating-point registers.

Btw, welcome to United-TI!

[DarkerLine]

You might want to look at bcall _CreateStrng

[Turgrid]

Thanks for your response. I tried again, but I'm still not sure of what I'm doing, so I had no success. It seems like it should be a simple matter of reading the addresses starting at 867D and loading them into the OP1 floating point register and then calling the stoAns routine. The problem is, I'm not quite sure how to implement this exactly, or if I'm even on the right track.

[Liazon]

welcome to UTI!

exactly what are you trying to do w/ the basic program?

[brandonw]

What's at 867Dh that you want to save? That's a very interesting address to pick, which is ioData and can be fascinating for a lot of different reasons.

StoAns will store a number to Ans, which I don't think is what you want (not sure what other types it does). You should use the BCALL AnsName to put the name of Ans in OP1, then ChkFindSym it and delete it if it already exists with DelVar/DelVarArc. Then, put the name back in OP1 with AnsName and use _CreateStrng (you'll need to pass the size of the string to this routine in HL). Then, LDIR the string you want into it.

[WikiGuru]

No, StoAns stores whatever is in op1 into ans: this can be a real variable, complex variable, or random bytes that happen to reside where op1 is defined.

However, it is important to note that strings are longer than 9 bytes, so we would need to use _CreateStrng.

If you want, I took the time to create the code that converts hex numbers into string data and also has the part that copies that data into st1.

[Turgrid]

Thanks to all of you that responded!

Brandonw: I was modifying your calcid (brandonw.net) program (which writes to 867Dh), so my friend could use it in his basic program.

Ti-Ho: That was exactly what I wanted. I implemented it, and appreciate your time for assisting in its writing.

[brandonw]

I had a hunch you might be doing that. It's a pretty ugly method of getting the calculator ID, which I know doesn't work on older 83+ OSes (possibly all of them). And because of that, if you want to get the ID from an 84+/SE, the better thing to do would be to BCALL DispAboutScreen, which will put the ID in OP1.

[WikiGuru]

ummm... DispAboutScreen only works with 84+/SE models, which doesn't include any 83+/SE's. My routine also stores it into Str1, while DispAboutScreen stores it in hex form into OP1, so you will still have to convert it into a string using my routine (or a similar one). The only difference would be that IX would point to OP1, not the memory address of the calcid. Also, this method keeps the screen clean :biggrin:

[brandonw]

Umm...I clearly said "if you want to get the ID from an 84+/SE, the better thing to do would be to BCALL DispAboutScreen". I know it's 84+/SE only. The other method which he's using doesn't work on the 83+/SE OS versions, so neither method works on the 83+/SE.

[WikiGuru]

I don't think you see the problem... DispAboutScreen gets the ID in HEX form and stores that into OP1. You would still have to convert that number into string data and then create a string variable to store it into so you can use it in basic. Like I said, you could use DispAboutScreen, the only change to my code would be this:

original

[brandonw]

I don't think you see the problem either. It doesn't matter what form the calc ID is in, it's trivial to convert the hex to a string and vice versa. What I'm talking about is that the method/hack to retrieve it does NOT work on the 83+/SE. The last 4 digits of the calc ID are stored in the certificate, which can't be read from unless you unlock Flash. It's not stored in RAM.

DispAboutScreen was convenient because it unlocked Flash for you, wrote the calc ID to OP1, relocked Flash back, and forgot to erase OP1. The thing from my site digs into BCALL keyscnlnk and finds the code which unlocks Flash, gets the calc ID to ioData, and then relocks it. Such code doesn't exist on the older OSes, hence the exploit doesn't work.

[WikiGuru]

hmmm... I see. I don't normally find and document ROM calls in this fashion if at all so I'll take your word for it. So you would still need to use DispAboutScreen to unlock the flash? Then there's just that slight change to my code (as previously mentioned).

[brandonw]

As you said, DispAboutScreen is 84+/SE only. It unlocks it, gets the calc ID, and relocks it.

There is no way to get the full calculator ID on all calculators. There might be a scary way to force the About menu to be displayed and see if the ID gets stored to OP1 or somewhere similar, or worse, a really ugly "hard-coded for each OS version" way of directly jumping to the code from the About screen which gets it.

If this is just for BASIC, the first 5 bytes from GetCalcSerial should be more than enough for anyone's needs.

[Turgrid]

Thanks for the help, but I have one more problem. How do I implement the bcall GetCalcSerial with Ti-Ho's code to store the first five bytes of the calc id into str1?

[brandonw]

Change 867Dh to OP4.

GetCalcSerial puts the first five bytes of the calc ID at OP4.

[Turgrid]

Brandon: That was my first thought, but all I got was a memory cleared crash. Any thoughts on why it did not work (Note: it seemed to work on the emulator, but not on my Ti-84+ SE 2.21)?

[WikiGuru]

Okay, first of all my code was for an 8 string hex code. If you want to implement 5, you'll have to make a few changes, namely to anything doing with size.

[Turgrid]

Ti-Ho: Worked Great...Much appreciation. Thanks!

Now, however, it appears my client/friend would like one additional (he assures me this is the last!) routine. I hope I explain this clearly and don't get confused.

He would like to use BrandonW's calcid method originally discussed (the 7 bytes from 867Dh on). Instead of converting these hex numbers to a string, he would like them represented as a number variable (i.e. ans, A, X, theta, etc.). Now, he doesn't want the hex converted to decimal or anything, but rather those exact bytes as the number/integer.

For example, if I was to change the first list element ({5555} in this theoretical example case) in calcsys from 55 55 to 5A 55 (as is more realistic for an id, as ids have hex digits), when I recall that list, a "random" character would appear in place of the hundreds digit of the four digit number 5555. He doesn't mind that "random" character - thats what he is looking for. I don't know how else to better explain it - he wants the exact bytes stored to a number.

So, I guess, in essence, I want the seven bytes 867Dh through 8685h (generated from BrandonW's calcid method) stored exactly as they are into OP1 (?) and then that set of bytes stored into an operating system variable, such as would be done using _stox bcall (for example).

How do I implement this? It doesn't matter to me the exact route taken (i.e. what variable), but that is what we would like. He wants to be able to multiply the ID by various numbers as a sort of key generator of sorts. I would greatly be indebted to anyone who assisted in this. Thanks in advance. If you have any questions, please do ask, and I will try to clarify as best as possible.

Edit: BrandonW: BTW, is there a way using silent linking, that one could "simulate" that the user pressed SendID without actually going to the link menu. The key charm to this would be that SendID (even if it fails to xmit) would create the list L@ (which contains the calc ID) without the user ever intervening. Maybe I'm way off on what silent linking even is, but I thought I'd ask.