Correct me if I am wrong. So basically, if I do Realloc(L5), then °A=L5, °B=L5+2,... etc and If then I do Realloc(), °A comes back to L1+741, etc ?
That's absolutely correct.
Erm, nope, I just reread my post and I made a typo, it is L1+714 not L1+741 -.-° But yeah, I was asking about the idea, not the figures, thanks for answering
Hey, I need to change a sprite from one hex to another during promotion. I DelVar the sprite, then create a new one with the same name, and assign a new hex to said sprite... but when compiling, I get an invalid token error... any ideas?
Wait, did you try to do for example this ? [<Hex>]→Str1 .code Delvar Str1 .code [<Hex>]→Str1 That is not possible in Axe. I quote shmibs here because he explains very well:
the difference here is that, in basic, STR1 is the name of an external object that is created in ram when the program is running, and can be modified however you choose. in axe, however, STR1 is a pre-processor directive. there is no actual object named STR1 that is created, and it is not used at all by your running program. STR1 is a label used by the compiler to point to a specific spot in your compiled program itself, so you can't tell it to point to two different places at once, which is what saying "store X" -> STR1 and then "store Y" -> STR1 is doing. the first time the compiler sees that, it appends the data "store X" to your program and then labels that point as STR1 for everything else to use. the second line would, then, be trying to append data at a different spot in the program and tell the compiler that that place is also called "STR1", which is causing an issue.
now, all that being said, it's easy enough to modify data stored at an STR#, GDB#, or PIC# label later on, provided that you are compiling a program, that will run in standard RAM space, rather than an application. you have to use the label as a part of a pointer, though, and store all the number values manually. it's much easier to work with free ram areas outside of your own program, like hayleia showed above.
And since shmibs' post tells about one of my post, I quote it too:
It says Duplicate Symbol because you are using twice the pointer Str1. Note that Str1 is a pointer, not a string, and Axe is not Basic What you can do is that: "STRING1"→GDB1 "1GNIRTS"→GDB2 Then, when you need the first string, do that: Fill(L1,8,0) Copy(GDB1,L1,7) Now, at the pointer L1, you have a null-terminated string with "STRING1"[00] in it And to get the second string in L1, do that: Fill(L1,8,0) Copy(GDB2,L1,7)
I just tried it on my 84+SE, it is great Is there a way to make it work on the 83+ too ?
He mentioned the patch works on OS 1.19, so I assume that means TI-83+ is supported.
That is what I thought too but I didn't want to be the one that crashed a calc for more precision And the title only mentions the 84+ so I really had doubts.
I just wanted to point out that if we are working with character data like Axe strings, uppercase and lowercase both take a single byte.
Well then, I think I'll start putting my text data outside of my programs (yeah, I was being stupid, the thing that takes 2 bytes is the lowercase token, not the lowercase character)
That sucks. I wish text data was as easy to deal with in Axe/ASM as it was in TI-BASIC (where you simply needed to get the string lenght with one command)
Well there is a command for that... as long as the text data is in RAM -.-° But if you try to put your data outside (for example in an archived appvar), you have to deal with those difficulties It is not hard, it is just too much brain work
now, all that being said, it's easy enough to modify data stored at an STR#, GDB#, or PIC# label later on, provided that you are compiling a program, that will run in standard RAM space, rather than an application. you have to use the label as a part of a pointer, though, and store all the number values manually. it's much easier to work with free ram areas outside of your own program, like hayleia showed above.
Yeah, I could have used Str1 (like the original program) but I used L1 to avoid triggering writeback for something that doesn't need it
in the meantime you can simply keep all your data external and try to work around a 16 KB limit for code
This is very hard to do with text data. You must calculate how much bytes you have in your text (knowing that uppercases take 1 byte and lowercases take 2 bytes) and you can't easily access the nth string without copying all the data to RAM But for every other kind of data, it is very possible
Show Posts
.gif)
(where you simply needed to get the string lenght with one command)
