Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
This is an archived, read-only copy of the United-TI subforum , including posts and topic from May 2003 to April 2012. If you would like to discuss any of the topics in this forum, you can visit Cemetech's z80 & ez80 Assembly subforum. Some of these topics may also be directly-linked to active Cemetech topics. If you are a Cemetech member with a linked United-TI account, you can link United-TI topics here with your current Cemetech topics.

This forum is locked: you cannot post, reply to, or edit topics. Z80 & 68k Assembly => z80 & ez80 Assembly
Author Message
Turgrid


Newbie


Joined: 25 Jun 2007
Posts: 10

Posted: 25 Jun 2007 04:43:02 pm    Post subject:

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!
Back to top
Harrierfalcon
The Raptor of Calcs


Super Elite (Last Title)


Joined: 25 Oct 2006
Posts: 2535

Posted: 25 Jun 2007 04:57:08 pm    Post subject:

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! Smile
Back to top
DarkerLine
ceci n'est pas une |


Super Elite (Last Title)


Joined: 04 Nov 2003
Posts: 8328

Posted: 25 Jun 2007 05:03:53 pm    Post subject:

You might want to look at bcall _CreateStrng
Back to top
Turgrid


Newbie


Joined: 25 Jun 2007
Posts: 10

Posted: 25 Jun 2007 05:04:34 pm    Post subject:

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.
Back to top
Liazon
title goes here


Bandwidth Hog


Joined: 01 Nov 2005
Posts: 2007

Posted: 25 Jun 2007 07:41:22 pm    Post subject:

welcome to UTI!

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


Advanced Member


Joined: 12 Jan 2007
Posts: 455

Posted: 25 Jun 2007 07:59:52 pm    Post subject:

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.


Last edited by Guest on 25 Jun 2007 08:10:43 pm; edited 1 time in total
Back to top
WikiGuru
ADOS (Attention deficit... Oh! Shiny!)


Elite


Joined: 15 Sep 2005
Posts: 923

Posted: 25 Jun 2007 10:25:31 pm    Post subject:

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.


Code:
 ld ix,$867D      ;address of bytes to copy
 ld b,8         ;number of bytes to copy
 ld de,string

numloop:         ;turn hex data into string
 push de

 ld a,(ix)         ;get data
 ld c,a         ;save it
 and %11110000      ;MS nibble, aka hexadecimal digit
 srl a         ;get that nibble into first
 srl a
 srl a
 srl a
 
 ld d,0
 ld e,a         ;get correct character offset
 ld hl,chart      ;offset table
 add hl,de
 ld a,(hl)
 pop de
 ld (de),a
 inc de
 push de
 
 ld a,c
 and %00001111      ;LS nibble
 ld d,0
 ld e,a
 ld hl,chart      ;offset table
 add hl,de
 ld a,(hl)
 pop de
 ld (de),a
 inc de
 inc ix
 djnz numloop
 
 LD HL,Str1name      ;create str1
 RST rMov9ToOP1      ; OP1 = name
 LD HL,$10         ; size of string
 bcall(_CreateStrng)
 
 inc de         ;so we don't overwrite size bytes
 inc de
 ld bc,$10
 ld hl,string
 ldir

 ret

chart:
 .db "0123456789ABCDEF"
 
string:
 .db 0,0,0,0,0,0,0,0
 .db 0,0,0,0,0,0,0,0

Str1name:
 .DB StrngObj,tVarStrng,tStr1,0,0
Back to top
Turgrid


Newbie


Joined: 25 Jun 2007
Posts: 10

Posted: 26 Jun 2007 08:03:44 am    Post subject:

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.


Last edited by Guest on 26 Jun 2007 08:04:14 am; edited 1 time in total
Back to top
brandonw


Advanced Member


Joined: 12 Jan 2007
Posts: 455

Posted: 26 Jun 2007 09:31:03 am    Post subject:

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.
Back to top
WikiGuru
ADOS (Attention deficit... Oh! Shiny!)


Elite


Joined: 15 Sep 2005
Posts: 923

Posted: 26 Jun 2007 02:31:46 pm    Post subject:

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:
Back to top
brandonw


Advanced Member


Joined: 12 Jan 2007
Posts: 455

Posted: 27 Jun 2007 04:10:28 am    Post subject:

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.
Back to top
WikiGuru
ADOS (Attention deficit... Oh! Shiny!)


Elite


Joined: 15 Sep 2005
Posts: 923

Posted: 27 Jun 2007 10:31:00 am    Post subject:

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

Code:
ld ix,$867D

new

Code:
bcall(_DispAboutScreen)
ld ix,OP1


I care what you think, but the original is always smaller and faster.

edit: as for it not working on the 83+/SE, I did not know that, but that's alright... You just need to find out the RAM location of the Calc ID for the 83+/SE and just put a check (using hardware points) to see if it's an 84+/SE or an 83+/SE then set ix accordingly.


Last edited by Guest on 27 Jun 2007 10:32:24 am; edited 1 time in total
Back to top
brandonw


Advanced Member


Joined: 12 Jan 2007
Posts: 455

Posted: 27 Jun 2007 01:50:30 pm    Post subject:

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.
Back to top
WikiGuru
ADOS (Attention deficit... Oh! Shiny!)


Elite


Joined: 15 Sep 2005
Posts: 923

Posted: 27 Jun 2007 02:22:30 pm    Post subject:

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).
Back to top
brandonw


Advanced Member


Joined: 12 Jan 2007
Posts: 455

Posted: 27 Jun 2007 03:03:51 pm    Post subject:

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.
Back to top
Turgrid


Newbie


Joined: 25 Jun 2007
Posts: 10

Posted: 02 Jul 2007 10:16:49 pm    Post subject:

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?
Back to top
brandonw


Advanced Member


Joined: 12 Jan 2007
Posts: 455

Posted: 03 Jul 2007 07:33:16 am    Post subject:

Change 867Dh to OP4.

GetCalcSerial puts the first five bytes of the calc ID at OP4.
Back to top
Turgrid


Newbie


Joined: 25 Jun 2007
Posts: 10

Posted: 03 Jul 2007 07:53:03 am    Post subject:

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)?
Back to top
WikiGuru
ADOS (Attention deficit... Oh! Shiny!)


Elite


Joined: 15 Sep 2005
Posts: 923

Posted: 03 Jul 2007 10:07:26 am    Post subject:

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.

Code:
bcall(_GetCalcSerial)
ld ix,op4 ;address of bytes to copy
ld b,5 ;number of bytes to copy
ld de,string

numloop: ;turn hex data into string
push de

ld a,(ix) ;get data
ld c,a ;save it
srl a ;get that nibble into first four bytes
srl a
srl a
srl a

ld d,0
ld e,a ;get correct character offset
ld hl,chart ;offset table
add hl,de
ld a,(hl)
pop de
ld (de),a
inc de
push de

ld a,c
and %00001111 ;LS nibble
ld d,0
ld e,a
ld hl,chart ;offset table
add hl,de
ld a,(hl)
pop de
ld (de),a
inc de
inc ix
djnz numloop

LD HL,Str1name ;create str1
RST rMov9ToOP1 ; OP1 = name
LD HL,10 ; size of string
bcall(_CreateStrng)

inc de ;so we don't overwrite size bytes
inc de
ld bc,10
ld hl,string
ldir

ret

chart:
.db "0123456789ABCDEF"

string:
.db 0,0,0,0,0,0,0,0
.db 0,0

Str1name:
.DB StrngObj,tVarStrng,tStr1,0,0
Back to top
Turgrid


Newbie


Joined: 25 Jun 2007
Posts: 10

Posted: 03 Jul 2007 10:32:33 pm    Post subject:

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.


Last edited by Guest on 03 Jul 2007 10:56:48 pm; edited 1 time in total
Back to top
Display posts from previous:   
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
    » Goto page 1, 2  Next
» View previous topic :: View next topic  
Page 1 of 2 » All times are GMT - 5 Hours

 

Advertisement