From what I could read somewhere, I am not sure if he is gonna add such feature right away, because it's gonna take like 10-15 minutes to sign and not a lot of people will probably want to wait this long for an app to sign. I think in later versions, it might be a good idea to implement, though, in case. Just make sure that the option needs to be selected everytime you choose to compile in APP format and that if you selected it, it forces you to confirm your choice, in case you accidentally selected it.

Btw, if you have too much data in your program and the total code+data is over 16 KB compiled, will it just put the data on a second page?

ah yeah I guess you have a point.

Well you don't have to sign an app to play it on your own calculator. The only time you do, from what I understand, is when you want to distribute it to other calculators. Which I think what Quigibo's logic is since you have to upload to a computer to distribute it you can just sign it in seconds on the computer instead of waiting ten minutes for the calculator.

Quote from: calc84maniac on June 19, 2010, 12:19:03 pm

Quote from: DJ Omnimaga on June 19, 2010, 12:08:38 pm

Btw, if you have too much data in your program and the total code+data is over 16 KB compiled, will it just put the data on a second page?

I don't think so, because multi-page apps cause headaches even for ASM programmers. We have to figure out how we're going to read data from the other pages, since they aren't mapped into memory at the same time. It would complicate things a lot.

Ouch, ok . I guess data will need to remain in appvar/program format then

Also in APP form, will the game requires as much RAM as an ASM 8xp file? Would we be able for example to run an Axe app containing 15 KB of code and have a game appvar unarchived taking like 22 KB of RAM?

I think that would be possible, yes. APPs don't take up any user RAM when executing.

To answer some questions:

An unsigned app runs fine on the calculator.  It does not need to be signed to use, only to transfer.

In order to compile the app, a copy of the executable is created in RAM first and then turned into an app at the end of compiling.  This is becasue the ROM can not be modified without erasing the whole thing (or most of it) becasue that's just how flash works.  So you're still limited by the roughly 24kb limit of free ram which is okay since the apps are only 16kb.  They will not be 2 page apps becasue 1) there is not enough ram on the calculator to compile such a large program and 2) I currently don't have any commands that handle page swapping.

A check is done on your battery level before writing to flash and there is a warning not to remove the power while it saves just like the game boys used to do.  Writing to flash is a little slow, it takes about an extra second per kilobyte I'd say on a 15MHz calc, but that's not so bad.

There are actually a lot of details about apps that change.  Fortunately I take care of most of them automatically so you won't even be aware of them:

• You can't display strings using the bcall since they need to be in ram (I changed the routine so it works)
• Apps have to be exited a special way (the entire program is actually one big subroutine so you can exit normally)
• You can not write over data in the program (nothing I can do about that)

Ok good. I was worried it was copied into RAM somewhere during execution, which would have made it very hard to run games with large amount of data (more appvars to archive/unarchive during loading sequences, depending of which you need)

@Quigibo, in future versions, do you plan any syntax changes that are specific to APP format? Or will the Axe source remain the exact same between both 8xp and 8xk files?