Author Topic: Bug Reports (Read 455917 times)

TheMachine02 · « **Reply #1815 on:** January 25, 2013, 01:25:18 pm »

thank you. it work perfectly now !

jo-thijs · « **Reply #1816 on:** February 03, 2013, 02:27:33 pm »

I've got 3 issues:
- at some random momments axe will throw up an invalid token error when trying to compile an app from which the source is in archive. I've done some tests, and I think that it keeps throwing that error if you don't change anything, but if you unarchive it, it works perfectly, but even unarchiving and rearchiving sometimes seems to solve the problem.
- for some reason my multiplayer game (with 2 calculators) can't make connections between 2 calculaters. I check whatever the other calculator is waiting, if so, start the game, else, start a loop where you keep checking whatever the other calculator has already started this game. Now, the loops just start at both calculators, which shouldn't appear. I didn't use the port variable, since I don't really understand what it does. I've tried to make connection between a TI84+ silver edition with the latest os (2.55) and a normal ti84+ with the same os, and I use the ports to the right.
- it seems that at the latest os, the input function has a slight difference when in MATHPRINT or in CLASSIC modus: in MATHPRINT, it doesn't clear the screen before execution, while it does in the other modus. this isn't an important issue though.

Matrefeytontias · « **Reply #1817 on:** February 03, 2013, 02:56:15 pm »

MP OSes are known for compatibilities issues with ASM programs. You have better to avoid them.

Runer112 · « **Reply #1818 on:** February 03, 2013, 03:06:59 pm »

Quote from: jo-thijs on February 03, 2013, 02:27:33 pm

I've got 3 issues:
- at some random momments axe will throw up an invalid token error when trying to compile an app from which the source is in archive. I've done some tests, and I think that it keeps throwing that error if you don't change anything, but if you unarchive it, it works perfectly, but even unarchiving and rearchiving sometimes seems to solve the problem.
- for some reason my multiplayer game (with 2 calculators) can't make connections between 2 calculaters. I check whatever the other calculator is waiting, if so, start the game, else, start a loop where you keep checking whatever the other calculator has already started this game. Now, the loops just start at both calculators, which shouldn't appear. I didn't use the port variable, since I don't really understand what it does. I've tried to make connection between a TI84+ silver edition with the latest os (2.55) and a normal ti84+ with the same os, and I use the ports to the right.
- it seems that at the latest os, the input function has a slight difference when in MATHPRINT or in CLASSIC modus: in MATHPRINT, it doesn't clear the screen before execution, while it does in the other modus. this isn't an important issue though.

Invalid token errors: Wait a little bit.
Linking issues: I would suggest making a separate topic about this in the Axe Programming Help Board and posting the code you're using for linking. Linking is always a tricky topic, so I can't be sure if the issue is in your code or in Axe's code. But posting the code you're using should hopefully result in either situation being solved promptly.
input quirks: input has always been a very strange command. Because it's more or less entirely handled by the OS, it's tricky to make sure it works how we want it to instead of how the OS wants it to. Due to this and other reasons (like the fact that it returns a string of tokens rather than characters), it's never really fit quite right into the Axe language and has just sort of had the feeling of being slapped on (which it was). So honestly I'm not too interested in fixing quirks like this. The command works for quick and dirty input, but for text input in programs that you want to distribute, I would advise writing your own input routine. You can usually make it look and function much better for your needs, anyways.

ben_g · « **Reply #1819 on:** February 03, 2013, 03:09:52 pm »

Quote from: jo-thijs on February 03, 2013, 02:27:33 pm

...and I use the ports to the right.

I don't know which port is on which side, but axe can only handle connections trough the I/O port (the round one). If you try to connect them trough the USB port (the rectangular one), axe will act like they aren't connected.

jo-thijs · « **Reply #1820 on:** February 03, 2013, 03:45:43 pm »

then that'll be the problem, I didn't use an I/O port, but the USB.
I'll try out the effect when I use the other port (at least if I find a cable for that).
Thanks!

Matrefeytontias · « **Reply #1821 on:** February 21, 2013, 09:30:33 am »

Found something really, really weird ...

Since Super Crate Box is now more than 8192 bytes and keeps crashing MirageOS (speaking of this, Runer if you have time if you could check the source of Super Crate Box here to help me finding the thing that makes MirageOS crash, it would be nice), I wanted to compile it as an app. Everything is working fine, except one little GDB that have a really strange behavior ... This code :

:1?{GDB1CRAT+3 :Text(44,0,{GDB1CRAT+3}?Dec

Displays 0 at the indicated position. And it's only for this GDB and not any of the more-than-10 others.

Just in case, GDB1CRAT+3 is $5F84.

Runer112 · « **Reply #1822 on:** February 21, 2013, 11:31:40 am »

You can't perform writeback to applications. You'll probably need to move whatever that data is to static RAM somewhere to be able to modify it during execution if you're going to proceed with your project as an application.

As for crashing MirageOS, does Axe give you a warning about the program being too large? If so, that's definitely the issue, and you should either convert it to an application or use Fullrene. If not, does the program crash when MirageOS launches it, randomly during execution, or when your program exits? If it's the first one, then that's definitely some weird MirageOS bug that I'm not sure would be avoidable. If it's either of the latter two, it might be due to you using L2, which MirageOS uses. If you do use L2 and it crashes during program execution, try adding LnReg to the initialization code. If you use L2 and it crashes when your program exits, try adding ClrDraw(L2) to the cleanup code.

Matrefeytontias · « **Reply #1823 on:** February 21, 2013, 11:41:05 am »

Quote from: Runer112 on February 21, 2013, 11:31:40 am

You can't perform writeback to applications. You'll probably need to move whatever that data is to static RAM somewhere to be able to modify it during execution if you're going to proceed with your project as an application.

~~Okay then, but that's not the only GDB I modify in this program and it's the only one not working.~~ Never mind, it's not the only one not working. This is the problem, so thanks for helping me.

Quote from: Runer112 on February 21, 2013, 11:31:40 am

As for crashing MirageOS, does Axe give you a warning about the program being too large? If so, that's definitely the issue, and you should either convert it to an application or use Fullrene. If not, does the program crash when MirageOS launches it, randomly during execution, or when your program exits? If it's the first one, then that's definitely some weird MirageOS bug that I'm not sure would be avoidable. If it's either of the latter two, it might be due to you using L2, which MirageOS uses. If you do use L2 and it crashes during program execution, try adding LnReg to the initialization code. If you use L2 and it crashes when your program exits, try adding ClrDraw(L2) to the cleanup code.

It crashes when the program exits, and it already did when the program was under 7000 bytes, but I'm not using a single byte of L₂ (I took a great care in verifying that).

Matrefeytontias · « **Reply #1824 on:** February 21, 2013, 12:42:29 pm »

And now Axe doesn't want to compile as an app anymore ... -________- I tried MirageOS, but the game keeps crashing at the exit.

Here's what I get by pressing stats :

00B4FA00BBB03511 BBB0BBB05BAB8AA7 1F00000040018478 004068CB

What's it in fact, all of this hex ? How do you use it ?

Hayleia · « **Reply #1825 on:** February 21, 2013, 01:00:13 pm »

If you want to compile a program that is larger than 8192 bytes, you can Also use CrabCake instead of compiling as an app. There is also Fullrene that should do the same as CrabCake but for some reason I couldn't figure out how to make it work so I sticked to CrabCake.

Runer112 · « **Reply #1826 on:** February 21, 2013, 01:48:07 pm »

Matrefeytontias, what model is your calculator? That might help me debug your app compiling issue. Now that I think of it, I probably should've put that information in the dump...

As for crashing on exit in MirageOS, the only other thing that comes to mind is that you could have problems if you're using a custom interrupt and not disabling it properly before quitting. If you are using a custom interrupt, make sure you properly disable it using LnReg^r. If this doesn't fix it, let me know and I'll go ahead getting my hands dirty trying to debug it myself.

Matrefeytontias · « **Reply #1827 on:** February 21, 2013, 02:59:21 pm »

I use a TI-83+.fr with OS 1.19, and I don't use anything related to MirageOS (I don't use any interrupt).

Maybe I forgot to say that this error not only happen with MirageOS : with this latter, the program crashes at the exit, but in Noshell there's a ERROR:SYNTAX, ERROR:INVALID or ERROR:VERSION one time out of three at the exit too, and compiled as an app (I'll explain later in the post) it leaves strange characters on the homescreen without changing currow nor curcol.

So, about the app thing, I think I found something : when there was the UNKNOWN ERROR right before the writing to flash, the parser in fact already wrote something, something that took up a whole page without even showing in any menu. So I had to delete an app in order to force the OS to defragment the flash and to get back the corrupted page. I deleted Axe and sent it again, and now everything's back to normal.

Why it kept displaying the error afterwards is that I didn't have enough Flash to build another app I guess.

Freyaday · « **Reply #1828 on:** February 23, 2013, 07:48:03 pm »

~~I think there might be an issue with HLines() drawn off the screen.~~
Nevermind. It was my fault.
However, Axe does now let programs have "invalid" names--it no longer cuts off at the first invalid char.

Runer112 · « **Reply #1829 on:** February 23, 2013, 07:52:09 pm »

Quote from: Freyaday on February 23, 2013, 07:48:03 pm

I think there might be an issue with HLines() drawn off the screen.

What version of the command are you using? Because the 3-argument version is known to be broken in Axe 1.2.1.

Author Topic: Bug Reports (Read 455917 times)

TheMachine02

Re: Bug Reports

jo-thijs

Re: Bug Reports

Matrefeytontias

Re: Bug Reports

Runer112

Re: Bug Reports

ben_g

Re: Bug Reports

jo-thijs

Re: Bug Reports

Matrefeytontias

Re: Bug Reports

Runer112

Re: Bug Reports

Matrefeytontias

Re: Bug Reports

Matrefeytontias

Re: Bug Reports

Hayleia

Re: Bug Reports

Runer112

Re: Bug Reports

Matrefeytontias

Re: Bug Reports

Freyaday

Re: Bug Reports

Runer112

Re: Bug Reports