Quote from: ASHBAD_ALVIN on October 27, 2010, 07:42:35 pm

Quote from: BlackRabbit on October 27, 2010, 06:05:19 pm

I've recently completed Warrior 2, another big RPG, in Ti-Basic with xLib. The only problem is that I have an 83+ so I cannot send it to the computer and upload it. I've also done several other projects but not any that I am still prowd of.

this is a bit off topic to respond and I'm sorry, but you CAN transfer it if you buy a certaqin type of cable, or type it up in source coder.

okay. I'll do that.

Alternatively, if someone else  owns a TI-84 Plus or a TI-Nspire with 84+ keypad and you got a link cable, and that person lets you borrow  his calc, just send your program to his calc, take a mini-USB to USB cable (a camera one will do) then use it to transfer it to the computer from the 84+ calculator. That's what I did with my 83 Plus since I did not have the appropriate cable for a while.

Quote from: Runer112 on October 27, 2010, 07:37:02 pm

Have you made use of the whopping 1094 bytes of effectively safe RAM starting at $8000?

"Safe" I'd have to dispute... sure, all of RAM can be considered "safe" if you disable interrupts and never call any system routines.  And if you're going as far as keyExtend, you're already trashing the keypad-scanning variables, so why stop there?

For his purpose of parsing, during which key inputs aren't checked, it won't matter if he overwrites that. Although if he didn't want to overwrite it, I'm sure 1,093 bytes would be just as good. I've filled these 1,094 bytes of RAM with random data a few times before to see if it affects anything, and the calulator runs fine. I've actually been using the calculator to do other stuff since then, with this area of RAM having been filled with garbage, and no side affects have cropped up.

EDIT: Or, just to be safe, I remembered that Iambian mentioned something about this on IRC a while ago (here) when I was considering using this area as temporary storage:

[22:19:28] <Runer112> yeah, appdata is 8000h
[22:19:29] <Iambian> You're free to use that area regardless.
[22:19:44] <Runer112> appdata is completely safe for my purposes? whether or not i'm running an app?
[22:19:52] <Iambian> Thought you were talking about something that looks more important, like baseAppBrTab or something.
[22:20:21] <Iambian> Either way, this magic romcall that (I think) BrandonW found recovers most of it before you want to exit. bcall($5011) it is.
[22:20:52] <Iambian> It was noted in my source as "restores first 1087 bytes in RAM"

None of my axe progs show up in Crunchy

On an semi-unrelated note, would Axe programs be compilable for CrunchyOS?

Doesn't Crunchy support all Ion and MOS programs, though?

For his purpose of parsing, during which key inputs aren't checked, it won't matter if he overwrites that. Although if he didn't want to overwrite it, I'm sure 1,093 bytes would be just as good. I've filled these 1,094 bytes of RAM with random data a few times before to see if it affects anything, and the calulator runs fine. I've actually been using the calculator to do other stuff since then, with this area of RAM having been filled with garbage, and no side affects have cropped up.

EDIT: Or, just to be safe, I remembered that Iambian mentioned something about this on IRC a while ago (here) when I was considering using this area as temporary storage:

Quote

[22:19:28] <Runer112> yeah, appdata is 8000h
[22:19:29] <Iambian> You're free to use that area regardless.
[22:19:44] <Runer112> appdata is completely safe for my purposes? whether or not i'm running an app?
[22:19:52] <Iambian> Thought you were talking about something that looks more important, like baseAppBrTab or something.
[22:20:21] <Iambian> Either way, this magic romcall that (I think) BrandonW found recovers most of it before you want to exit. bcall($5011) it is.
[22:20:52] <Iambian> It was noted in my source as "restores first 1087 bytes in RAM"

If you don't have a solid understanding of what a RAM area is used for, when it's used, and what the consequences might be of modifying it, how can you say whether it's "safe" for your application?

(Experimenting and finding things that seem not to crash is really not a substitute for this level of understanding.  To wit: I can infer from your comment above that either you have an 84+, or you never use Flash apps.)

"Restores first 1087 bytes in RAM" is cute, but wrong, and frankly, kind of a dangerous thing to go around telling people.

The term "safe" is meaningless without context: what is safe depends both on what type of program you're writing - i.e., the context in which it will be executed - and on what your program is going to do.  By safe, we generally mean that
 (1) a RAM area is not going to be modified by any system or library calls we intend to perform, or by the system interrupt routine, and
 (2) the RAM are is not already in use at the time our program runs (so altering the data there will not have any effect on the system), or more specifically, it won't be expected to contain valid data at the time our program exits.

In some cases we may also want to consider areas where the RAM is already in use, but
 (a) it can be easily reset to its default settings,
 (b) we can reliably ensure the reset routine does get called, regardless of when or how our program terminates, and
 (c) the user won't mind us trashing his or her data.

In brief: the RAM areas between 8000h and 843Dh (I'm going to go ahead and assume you didn't mean to include kbdScanCode and friends) are used by a lot of different system routines under a lot of different circumstances.  As far as I know, all of this memory except for baseAppBrTab is scratch memory (it satisfies condition 2 for most execution environments), but whether it satisfies condition 1 is dependent on what system routines you're using, what hooks those routines might call, whether APD is possible, and whether silent linking is possible.

As for baseAppBrTab, it does not satisfy condition 2 at all, and it is absolutely essential that the table be correctly populated when your program exits.  Realize that the primary purpose of the table is for performing application B_CALLs - so really, it ought to be correctly populated at any time when a hook might be called, or in a shell program, at any time when a shell library might be called.  In practice, using that area is so dicey that I would not feel comfortable doing so at any time when any code outside my control might be executed.

Has anyone tried running Axe Parser in TI NSpire w/ 84+ keypad?

I can't, when I open the application Axe what shows up immediately is the Compile list and I can't compile them due to Unknown Error (and they are written in Axe, for sure).

Any ideas?

random question: is it worth it to put this code in a subroutine?

<exp>*22+GDB0+<constant>..... so it looks like sub(0^r,<exp>,<const>).....lbl 0 : r1*22+GDB0+r2

I would almost always need the ^r when calling this routine, and I suspect that the size of calling sub(lbl^r) with two arguments to be loaded might be bigger than just typing it out every time. Can anyone confirm? Also, I will be using this snippet of code only around 15 times throughout

If you use a line with that format only once or twice, it would be optimal to just to type it all out in those instances. If you use it more than twice, the most optimized way would be as follows:
<exp>sub(22)+GDB0+<constant>
Lbl 22
Return *22

---

EDIT: So as not to double post, I'll add this as an edit. It is, however, completely unrelated.

Quote from: Runer112 on October 28, 2010, 05:53:52 am

For his purpose of parsing, during which key inputs aren't checked, it won't matter if he overwrites that. Although if he didn't want to overwrite it, I'm sure 1,093 bytes would be just as good. I've filled these 1,094 bytes of RAM with random data a few times before to see if it affects anything, and the calulator runs fine. I've actually been using the calculator to do other stuff since then, with this area of RAM having been filled with garbage, and no side affects have cropped up.

EDIT: Or, just to be safe, I remembered that Iambian mentioned something about this on IRC a while ago (here) when I was considering using this area as temporary storage:

Quote

[22:19:28] <Runer112> yeah, appdata is 8000h
[22:19:29] <Iambian> You're free to use that area regardless.
[22:19:44] <Runer112> appdata is completely safe for my purposes? whether or not i'm running an app?
[22:19:52] <Iambian> Thought you were talking about something that looks more important, like baseAppBrTab or something.
[22:20:21] <Iambian> Either way, this magic romcall that (I think) BrandonW found recovers most of it before you want to exit. bcall($5011) it is.
[22:20:52] <Iambian> It was noted in my source as "restores first 1087 bytes in RAM"

If you don't have a solid understanding of what a RAM area is used for, when it's used, and what the consequences might be of modifying it, how can you say whether it's "safe" for your application?

(Experimenting and finding things that seem not to crash is really not a substitute for this level of understanding.  To wit: I can infer from your comment above that either you have an 84+, or you never use Flash apps.)

"Restores first 1087 bytes in RAM" is cute, but wrong, and frankly, kind of a dangerous thing to go around telling people.

The term "safe" is meaningless without context: what is safe depends both on what type of program you're writing - i.e., the context in which it will be executed - and on what your program is going to do.  By safe, we generally mean that
 (1) a RAM area is not going to be modified by any system or library calls we intend to perform, or by the system interrupt routine, and
 (2) the RAM are is not already in use at the time our program runs (so altering the data there will not have any effect on the system), or more specifically, it won't be expected to contain valid data at the time our program exits.

In some cases we may also want to consider areas where the RAM is already in use, but
 (a) it can be easily reset to its default settings,
 (b) we can reliably ensure the reset routine does get called, regardless of when or how our program terminates, and
 (c) the user won't mind us trashing his or her data.

In brief: the RAM areas between 8000h and 843Dh (I'm going to go ahead and assume you didn't mean to include kbdScanCode and friends) are used by a lot of different system routines under a lot of different circumstances.  As far as I know, all of this memory except for baseAppBrTab is scratch memory (it satisfies condition 2 for most execution environments), but whether it satisfies condition 1 is dependent on what system routines you're using, what hooks those routines might call, whether APD is possible, and whether silent linking is possible.

As for baseAppBrTab, it does not satisfy condition 2 at all, and it is absolutely essential that the table be correctly populated when your program exits.  Realize that the primary purpose of the table is for performing application B_CALLs - so really, it ought to be correctly populated at any time when a hook might be called, or in a shell program, at any time when a shell library might be called.  In practice, using that area is so dicey that I would not feel comfortable doing so at any time when any code outside my control might be executed.

You were right, I did accidentally look over the fact that baseAppBrTab is present in this area of RAM. That's why I later searched for Iambian's reference to bcall($5011). I know it does not "Restores first 1087 bytes in RAM," and I'm sure Iambian does too. But it restores the data in baseAppBrTab. As long as this bcall was called after use of this RAM area and hooks/interrupts didn't try to use it while you were (which I believe should be relatively easy to ensure), it should be okay to use it.

I also did know that a lot of the other data areas in there were used by system routines, but for the purpose of parsing, during which I would assume very few bcalls are used (key input bcalls are included in those not used), it would be okay to fill these areas with your own data.

However, I did completely forget one very important thing: Axe is an application. So it probably shouldn't be using baseAppBrTab at all. Or ramCode for that matter, located at $8100. So you're right, now that I think about this again, this area of RAM isn't entirely safe to use. Although appData (256 bytes starting at $8000) and tempSwapArea (323 bytes starting at $82A5) are large blocks that should be safe to use.