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.

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.

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).

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.

... wanna do some shit ? :troll:

Also, me gusta el avatar

Also, I planned on coding the whole battle engine as a sole function. But I'll need your opinion on which prototype can be the best. For now I have this :

BeginBattle(playersSequence, enemiesSequence, rewardSequence, canRunAway)

playersSequence : a pointer on a data giving info on who's in the battle, and structured as follows : number of players involved in the battle (1 to 4, one byte), then ID of each player (as many bytes as the first byte of the sequence). Basically, the ID would be used to assign the right stats and sprites to a character.

enemiesSequence : exactly the same as above, but for enemies (involving different stats, sprites etc).

rewardSequence : a pointer to a data giving info about what you obtain after winning the battle, and structured as follows : number of items gained (up to 255, one byte obviously, excluding money, which in my opinion should be given after every battle you win), the amount of money obtained (two bytes, I do think that we should use a 3- or 4-bytes number for the player's money), then each item's ID (as many bytes as the first byte of the sequence).

canRunAway : a simple flag set to allow the flee and reset to forbid it.

What do you think of it ?

You mean applying monsters' decisiveness to guys of your team ? That effectively can be a good idea for total newbies.

That's why I thank that a turn-based battle-engine without any movements would be clearly enough for a calc game. Moreover, we can still counterpart that with nice animations and stuffs. But writing enemies' AIs will surely be a PITA (which skill use when, on who etc).