This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Terrav
Pages: [1]
1
« on: January 29, 2021, 03:35:42 pm »
Thanks! It would also be great if I could use your text axiom as well; I've been trying to make my own but it is turning out to be horribly inefficient.
2
« on: January 26, 2021, 06:40:45 pm »
I recently finished making a Minesweeper program for MirageOS and I was wondering how I could keep track of time. I know there must be some sort of hardware clock; how do I use it? Or at least is there an assembly routine that will allow me to read it?
3
« on: January 07, 2021, 01:26:09 pm »
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). This seems absolutely nuts, so as soon as I can I will get the MEMKIT Axiom library and use that.
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.
4
« on: January 06, 2021, 01:44:58 pm »
OK, I see. I made a mistake in the code. You're right, it is ReturnIf. However, I tried this and it works! as long as the program is just one byte. I tried it with a program that just returns, and it works fine. But when I compiled a Minesweeper game to run with this, it resets either when the program starts, or shortly after (after user input). There's absolutely no difference each time. To make things weirder, when the calculator resets, it deletes a certain appvar I use. What's weird is the appvar is only ever in the RAM immediately after the program finishes, then goes right back into the archive. (I use this var to keep track of which programs were last run) I thought maybe there's a C9h inserted in the wrong spot (my shell is supposed to add a C9 to the end of a program when it executes it for safety) and the calculator resets when it returns to the app without unsetting Fix 7 (my program uses this).
5
« on: January 05, 2021, 06:08:29 pm »
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:
.This is my execution subroutine
Lbl X
.Get the program, use X and Y0
Return!If X
If 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 subroutine
ElseIf 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
Of course, this assumes the executable data begins right with the file.
6
« on: January 04, 2021, 04:18:57 pm »
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.
7
« on: January 02, 2021, 04:18:17 pm »
I was designing a modular program executor when I encountered this problem: The code I was trying to execute was not being executed and instead the calculator reset. I've tried and checked everything; I think the problem is the address. 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. A brief summary of my test code is printed below.
"appvTMPFILE"→Str0
GetCalc(Str0,1)→X
[sub]E[/sub]C9→{X}
(X)()
Note: I know 0xC9 is the assembly equivalent of Return.
If I were to try this with the program data itself or a safe zone (like L1) it works just fine.
Displaying the memory pointer just before calling it shows something like C3F2 or D19A.
My questions are, how is this caused, and how do I work around it?
Pages: [1]
|
Show Posts
