Author Topic: Axe Q&A (Read 587233 times)

leafy · « **Reply #1590 on:** December 20, 2012, 08:50:04 pm »

Axe no longer uses the last 54 bytes as of Axe 1.2.0, so feel free to use L1 to 768 bytes. L2 is more or less stable for the first 800 bytes or so, but remember to run ClrDraw(L2) at the end of your program. Volatility doesn't refer to whether or not your data will get messed up during the program runtime, it refers to how screwed up bits of your OS will get after you quit out of the program (L2 has the chance of messing up tables and such).

133794m3r · « **Reply #1591 on:** December 20, 2012, 09:02:43 pm »

Quote from: leafy on December 20, 2012, 08:50:04 pm

Axe no longer uses the last 54 bytes as of Axe 1.2.0, so feel free to use L1 to 768 bytes. L2 is more or less stable for the first 800 bytes or so, but remember to run ClrDraw(L2) at the end of your program. Volatility doesn't refer to whether or not your data will get messed up during the program runtime, it refers to how screwed up bits of your OS will get after you quit out of the program (L2 has the chance of messing up tables and such).

Ah OK, that's really good to know then. And hmm that's itneresting about L2 as it says only 512bytes, but anyway thanks for the information. I'd upvote or thank, or whatever they call it on here but I can't seem to find it... Now onto finishing up the range encoder!(Worst case scenario, estimated as a reduction of ~16% on 768byte thing.)

squidgetx · « **Reply #1592 on:** December 20, 2012, 09:21:20 pm »

I think that Axe moved A-Z a few versions ago; L1 is 768 bytes. Also, L2 is perfectly safe, I think now just as safe as L1 in 1.2.1 (used to be interrupts used that area, but no more).

Edit: Actually, i just remembered that MirageOS uses L2 for its custom interrupts. Used to be you could put an FnOff at the beginning of your program to disable MOS interrupts, but I don't know if that still works (I'm 60% sure that it should)

For some reason the TI docs list L2 (statVars) as being only 531 bytes, but other areas of free ram start right after where L2 ends for at least a few hundred more bytes, so basically L2 is a lot bigger than 531 bytes.

Edit2: L2 points to 871 bytes of free ram, but you may have to zero (using Fill or something) the extra 340 bytes of RAM starting at 8C4D at the end of your program. Source: http://ourl.ca/16406

Sorunome · « **Reply #1593 on:** December 20, 2012, 09:23:33 pm »

According to the readme:
L₁: 768 bytes (saveSScreen) Volatility: LOW
L₂: 531 bytes (statVars) Volatility: LOW (Some shells, including MirageOS, use this for mostly non-vital storage)

Deep Toaster · « **Reply #1594 on:** December 20, 2012, 10:47:36 pm »

Quote from: 133794m3r on December 20, 2012, 09:02:43 pm

Quote from: leafy on December 20, 2012, 08:50:04 pm
Axe no longer uses the last 54 bytes as of Axe 1.2.0, so feel free to use L1 to 768 bytes. L2 is more or less stable for the first 800 bytes or so, but remember to run ClrDraw(L2) at the end of your program. Volatility doesn't refer to whether or not your data will get messed up during the program runtime, it refers to how screwed up bits of your OS will get after you quit out of the program (L2 has the chance of messing up tables and such).
Ah OK, that's really good to know then. And hmm that's itneresting about L2 as it says only 512bytes, but anyway thanks for the information. I'd upvote or thank, or whatever they call it on here but I can't seem to find it... Now onto finishing up the range encoder!(Worst case scenario, estimated as a reduction of ~16% on 768byte thing.)

It says only 531 bytes, but according to Runer the data after it isn't terribly important to the operating system, so you have about 800 bytes to mess around with.

Sorunome · « **Reply #1595 on:** February 28, 2013, 08:24:23 pm »

How do I convert a string with only one element into a char to get the ASCII number representing it?

Runer112 · « **Reply #1596 on:** February 28, 2013, 08:34:24 pm »

Just read the first and only character of the string: {ptr}.

Sorunome · « **Reply #1597 on:** February 28, 2013, 08:35:44 pm »

Oh, why didn't I think of that >.<
Thanks for helping anyways

EDIT: Is there a way to convert a number to a string?

Builderboy · « **Reply #1598 on:** February 28, 2013, 11:17:39 pm »

To convert a single digit to a single character is pretty simple, you simply do # + '0'. Converting a multi digit number into a string is simply a matter of going through the number digit by digit and converting each digit to a character.

Sorunome · « **Reply #1599 on:** February 28, 2013, 11:18:35 pm »

Thanks, jacobly already helped me via skype, I just thought that there's maybe a built-in function or a easier way

Caustic · « **Reply #1600 on:** April 07, 2013, 03:07:20 am »

Do forgive me if this has already been asked... couldn't search and it's becoming increasinfrrrftgly urgent. ^{posting on a phone is hard enough.}

What follows is a simple code sample that I don't understand why it refuses to run:

Nothing after setting up the interrupt is ran. The comments are results of some troubleshooting. Anything I change after ".Main" and the following "Return" is completely ignored during runtime. I commented out the pause in the Interrupt subroutine to see if it made any difference...

Code: [Select]

.AA
ClrDrawrr
Rect(0,0,32,32)r
fnInt(A,6)

.Main
Repeat getKey(0)
End
LnReg
Return

Lbl A
.Pause 75
DispGraphr

Runer112 · « **Reply #1601 on:** April 07, 2013, 03:10:26 am »

Perhaps the Repeat loop ends immediately because it's getting reached while you're still holding down the button that launched the program? Try changing the key value so it won't detect the ENTER/2nd key.

EDIT: Also, if you're using Axe 1.2.1, it's recommended that you use the safer LnReg^r rather than LnReg to turn off custom interrupts.

Caustic · « **Reply #1602 on:** April 07, 2013, 03:19:08 am »

I doubt it, because I have to remove the batteries every time I execute this. Thanks for the tip on LnRegr

Edit:It's probably an Axe bug because I tried a few code samples for "perfect" grayscale that all seem to work fine. But I want to understand why my own test didn't work in the interest of preventing this problem on a larger scale.

Runer112 · « **Reply #1603 on:** April 07, 2013, 03:32:40 am »

Oh silly me, I see the problem. The issue is that your interrupt takes longer to execute than the amount of time between interrupt timer requests, so as soon as one interrupt call finishes, another is made. To fix this, you probably want to add some code to your interrupt that results in the body of the interrupt, in this case the DispGraph^r, only being executed on some interrupt calls. One simple way to do this is with a counter that only executes the actual body of the interrupt every fixed number of interrupt calls. Here's a common way to do it:

Code: [Select]

..
1→I         .The counter
fnInt(A,0)  .I increased the interrupt speed for more counter precision
..
Lbl A
DS<(I,4)    .Only execute the body every 4 interrupt calls; play with this amount
DispGraphʳ
End
Return      .Axe automatically adds a final return if you don't, but it's still good practice to include it

Caustic · « **Reply #1604 on:** April 07, 2013, 03:45:22 am »

Alright. Just to clarify, if the interrupting routine lasts longer than the timer (I.e Pause 3000) will there be some sort of queue of interrupt calls? Trying to execute dispGraph at 60Hz sharp is quite a pain in Axe...

Author Topic: Axe Q&A (Read 587233 times)

leafy

Re: Axe Q&A

133794m3r

Re: Axe Q&A

squidgetx

Re: Axe Q&A

Sorunome

Re: Axe Q&A

Deep Toaster

Re: Axe Q&A

Sorunome

Re: Axe Q&A

Runer112

Re: Axe Q&A

Sorunome

Re: Axe Q&A

Builderboy

Re: Axe Q&A

Sorunome

Re: Axe Q&A

Caustic

Re: Axe Q&A

Runer112

Re: Axe Q&A

Caustic

Re: Axe Q&A

Runer112

Re: Axe Q&A

Caustic

Re: Axe Q&A