Show Posts

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 - Runer112

Pages: 1 2 3 [4] 5 6 ... 153
46
The Axe Parser Project / Re: Axe Library, Axiom, and Tool Collection
« on: June 25, 2016, 10:11:25 am »
I would like create an axiom for TI 84+ SE but when I build my code, and I transfer the program on my calculator, I execute the progra and the calculator says me "Error: Version" :(
I don't understand :(

Can you elaborate? Because I'm not sure I'm understanding the situation correctly. It sounds like you're executing the axiom as a program, but that doesn't really make sense.

47
ASM / Re: Random Questions
« on: June 23, 2016, 03:28:54 pm »
I use the on key frequently, but that seems to break the equation evaluator since it counts as basic. Is there any way to clear the ON break error? (I already used runprgm's error handler to no avail.)

Perhaps res onInterrupt,(iy+onFlags)? Otherwise, I don't really know myself.


What are the arguments for the Axe compile B_CALL? Is it the program name in op1?

Developers\API.txt in the Axe download says:
Quote
####################
#  api_CompileOP1  #
####################
Inputs: OP1 = Name of program to compile
          a = Compile Mode
            bit 0-2:
              0 = No shell
              1 = Ion
              2 = MirageOS
              3 = DoorsCS
              4 = Application
            bit 3
              0 = Regular compile
              1 = Zoom compile
Outputs: none

Compiles the program and then returns



Is there anyway to tell for sure if you have memory corruption? The program behaves normally except when it is asked to create a new program. (It behaves weirdly like saying the prgm took up x bytes but displaying many more in the editor.)

If the memory management menu shows weird values, then your memory is probably corrupted and the calculator will likely crash soon. Should be fixed by a RAM clear (or crash), though.


In order to find custom tokens in axioms the program reads the compiled axiom. Is there a better way to do that?

No, unfortunately you do have to scan through the whole Axiom. Sticking them at the end was the most reasonable way Quigibo/I could think to add them while retaining backwards compatibility.

48
The Axe Parser Project / Re: Bug Reports
« on: June 15, 2016, 04:17:09 pm »
Ohhhhh! Ok! Could add a way to search backward (such as inData(byte,data)r)?
It seems odd that you can search forward but not back (when you change it).
Will fixing the "bug" break compatibility with programs that use the backwards searching?

It was only added in 1.2.2, so I doubt it's even seen much use. And the search order was never documented, so if anyone relied on it searching in reverse, then they were relying on undocumented behavior and it's their problem if the behavior changes. :P But it shouldn't be that hard to add reverse variants with the superscript r suffix, so I'll probably do that (for both arity variants).

49
The Axe Parser Project / Re: Bug Reports
« on: June 15, 2016, 01:13:23 pm »
I (think) I found another bug!
I am still using 1.2.2. The command, inData(byte,data,size) won't always work.
inData(byte,data) works fine though.
Here is some code...

GetCalc("prgmNAME",100) sto A
For(X,0,99
X to {X+A}:End
inData(3,A,1000) sto B
Disp B >Dec
Pause 1500

Outputs 891 as the answer.
Changing the 1000 to 100 makes the program work correctly.
It seems that the command won't take a two byte number as an argument.

This is technically not a bug, but instead a result of weak documentation that enabled me to perhaps over-optimize.

The documentation doesn't state what order the data will be searched in, which I took advantage of by searching the data in reverse to save one byte. In retrospect, searching forwards is probaly more sensible/expected/useful and it's almost certainly worth not saving the single byte.

I'll make this change, then, and specify the forwards search order in the documentation while I'm at it.

50
Axe / Re: Axe Q&A
« on: May 21, 2016, 04:28:30 pm »
Perhaps this just got lost in the manual copying process, but is ax1end defined properly?

If so, nothing seems obviously wrong to me. If you posted the assembeld axiom, I could probably figure out what's wrong, though.

51
The Axe Parser Project / Re: Bug Reports
« on: May 21, 2016, 04:17:25 pm »
Nope I am still using 1.2.2
Is 1.3 stable enough to use now?
(Last time I looked it still had several nasty bugs that made 1.2.2 the only viable option)

Oh... not really, it still has those particualrly bad bugs... I think? I keep losing track of my progress because I don't revisit it very often, so I never get particulary far. I should really finish it off.

52
The Axe Parser Project / Re: Bug Reports
« on: May 21, 2016, 04:12:16 pm »
There is still the app too large error with huge data files.
I got one when I tried to include a 18000b file in a program.

I remember fixing this, and looking at the current source code, it definitely appears fixed. Are you using the latest published dev version of 1.3.0, which can be found here? I thought that included the fix, although perhaps it's never made it into any published version...

53
The Axe Parser Project / Re: Bug Reports
« on: May 17, 2016, 06:31:31 pm »
I found a bug!
PRGM:NAME
.CAKE
Disp t sub( >Dec
Disp {GetCalc("prgmTOK")}r >Dec

PRGM:TOK
sub(

The t before sub( is the token character.
The two values are not the same.
The t doesn't get two byte tokens correctly. (I think this is a bug... maybe I'm missing something)

You're absolutely right. It looks like two-byte token constants currently produce the bytes backwards. I'll try to fix that, but in the meantime, you should probably just enter two-byte token constants manually. There's no great reference with every token listed on one page, but TIBD at least has this page that has links to all the 2-byte token pages.

54
Axe / Re: Axe Q&A
« on: May 10, 2016, 08:55:49 pm »
B_CALL(_ExecuteApp). It won't return to your program, though; if you wanted behavior like that, you'd have to rig something up with hooks.

55
Axe / Re: [Tutorial] Key hooks in Axe
« on: March 25, 2016, 01:46:35 pm »
It works! How do I disable it from displaying done?
(it runs a basic program)

Asm(FDCB00AE) might do it. If not, I'm not sure how.

56
Axe / Re: [Tutorial] Key hooks in Axe
« on: March 25, 2016, 11:17:19 am »
Maybe I came over as knowing more than I do.
What would the hex code be? Can I put it anywhere or just at the end?

Put this right before you return from your hook to return nz: Asm(AF3D).

57
Axe / Re: [Tutorial] Key hooks in Axe
« on: March 22, 2016, 08:43:39 am »
Are you running this on an 83+SE or 84+? If so, it's possible that your hook (and anything it does as a result) is only running at 6MHz, while BASIC normally runs at 15MHz. In this case, try setting full CPU speed.

58
Axe / Re: [Tutorial] Key hooks in Axe
« on: March 21, 2016, 06:53:25 pm »
You need a zero byte at the end of the name. You can either add it manually, or you could write the name in string form and the compiler would automatically add it for you.

As for error handler issues, I can't say I understand what you're experiencing.

59
Axe / Re: [Tutorial] Key hooks in Axe
« on: March 20, 2016, 05:15:34 pm »
I'm sure you could manage it with a key hook, but perhaps the homescreen hook is better.

60
Axe / Re: [Tutorial] Key hooks in Axe
« on: March 20, 2016, 01:20:07 pm »
Yes, deleting a small app is about as "bad" as deleting a big app. But unless you're doing it 100+ times a day, I don't think you'll ever actually wear the flash out.

Pages: 1 2 3 [4] 5 6 ... 153