0 Members and 1 Guest are viewing this topic.
"appvTMPFILE"→Str0GetCalc(Str0,1)→X[sub]E[/sub]C9→{X}(X)()
Knowing the TI-84+ only has 24KiB RAM, it puzzled me to learn my program was using memory pointers all the way up to DFFF.
Everywhere I have tried to execute has an address somewhere between 8000-BFFF.
If I were to try this with the program data itself or a safe zone (like L1) it works just fine.
:GetCalc("prgmWHATEVER", Y1) .Get pointer to the program:Copy(Y1, E9D95, 1000) .Copy it to the ram area. Since programs are normally executed from E9D95, you can use absolute jumps and calls without problem:(E9D95)() .Run the program. Once it is finished you should use Delete( to restore the 1000 bytes of memory you took. Or you can copy a different program there and run it first
Thank you for the suggestion; I'm basically trying to create a launcher that can run assembly programs apart from TI-OS.
The allowed program size built in my program should be variable, but I guess I should watch out for the 8K program size limitation as well. Also, is there any article about the actual structure of memory/Flash/addresses that I can read? I originally thought it was 24K RAM + 1M Flash and that's it, but it appears there's a lot more I need to learn before I go digging deep in memory.
.This is my execution subroutineLbl X.Get the program, use X and Y0Return!If XIf LA0=E9D95 .We are running in a program Return!If {Y0-2}r>EC000-GDB3ND .Too large, can't execute Copy(Y0,GDB3ND,{Y0-2}r) .assuming this is a special format Goto (GDB3ND) .The program will automatically exit this subroutineElseIf LA0/4096=4 .This is an app, let's just use 9D95! Return!If {Y0-2}r>8811 .This is the real limit from 9D95h to BFFFh Copy(Y0,E9D95,{Y0-2}r) Goto (E9D95)End .Still haven't bothered working with shells at this point
That looks good, but I can't do that given my Axe version doesn't have New( and Delete( (and also only supports two-character labels).However, I think I have this figured out now. What I did was put Lbl A0 at the beginning of my code and Buff(1)→GDB3ND at the very end, and use this little subroutine (I left out a lot of code to make it short:Code: [Select].This is my execution subroutineLbl X.Get the program, use X and Y0Return!If XIf LA0=E9D95 .We are running in a program Return!If {Y0-2}r>EC000-GDB3ND .Too large, can't execute Copy(Y0,GDB3ND,{Y0-2}r) .assuming this is a special format Goto (GDB3ND) .The program will automatically exit this subroutineElseIf LA0/4096=4 .This is an app, let's just use 9D95! Return!If {Y0-2}r>8811 .This is the real limit from 9D95h to BFFFh Copy(Y0,E9D95,{Y0-2}r) Goto (E9D95)End .Still haven't bothered working with shells at this pointOf course, this assumes the executable data begins right with the file.
:...If LA0=E9D95 .I'm using a conditional comment. Since this will only ever be an app or a program and never swap, why compile the code for the other?:.Stuff for program version here:...Else .No need for an ElseIf here. If we aren't a program, we have to be an app.:.Stuff for app here:...
Well, I tried both. When I try it from a program compilation method, it goes absolutely nuts.
First, it looks like it does nothing. Then, when you exit the shell, it returns back to the program selection screen (in my shell). Then, when you try to exit the shell again, it does one of two things. 1) it stays on with a blank screen and executes a seemingly infinite loop. 2) It goes through what I can only describe it as: the calculator is on drugs. The user input is about 1/4-normal; you can point out various misplaced parts of some recognizable menus; and finally, if you hit On and other keys enough, it "burns out" with that weird blue line across the screen (I've seen this before: see the footnote) and resets after about 2 minutes.
I've double-checked that the program I'm working with is within the size range (nothing hanging past BFFFh).
Footnote: That weird blue line on the screen is very frightening and I've seen it before; that is the MAJOR indicator that you have done something horribly wrong. I believe that may be a side effect of executing bad code, that sends absolute nonsense to your LCD, causing it to shut off and display a blue line across your screen. I only call it "burning out" because it's generally what it does after an absolute overload of bad data, and the line fades away in tatters before eventually returning your calculator to a fresh RAM wipe. I have found nothing about this on YouTube.