Right, sorry.  In that case, I'm not sure what exactly you're asking.  Could you post an example of code you've tried that doesn't work the way you expect?

Well, as "easily" as writing to other areas in Flash.   (And yes, that's kind of dangerous; if you screw up the certificate, it's possible to crash the boot code and make it impossible to install an OS.)

Well, first off, how much RAM do you really need?  Could you stick to using the main RAM, and keep compatibility with the 83+ BE?

Hardware-wise, the Z80 address space is divided into 4 "banks", which each hold one 16k memory page.  The first bank is always used for Flash page zero; the second two ("A" and "B") can be mapped to any page you like, and the fourth ("C") is always used for RAM page zero on the 83+ BE, but can be mapped to any RAM page on the 83+ SE and 84+.

Now, all of that said, you should realize that you can't usually change the pages mapped in banks B and C, unless you're very careful about it; bank C contains your program's stack, and bank B contains your program's code and variables.  Bank B - RAM page 1 - also contains lots of variables that are used by system routines, including the system interrupt service routine.

So that leaves bank A.  In a RAM assembly program, you can change bank A whenever you like (unless it's a shell program and you're using shell library routines), but you also have to be sure to restore the original page to bank A when your program finishes.  This might be a plausible strategy for Axe programs (correct me if I'm wrong, but I don't think Axe programs use any shell library routines), but it wouldn't work for Flash applications.  And of course it does break compatibility with the 83+ BE.

As far as what pages you can use: newer 84+es have only 1 extra page of RAM, whereas older 84+es, 83+ SEs, and (I believe) Nspire-84+es have 6 extra pages.  Of RAM page 3 (or, on newer calculators, the single extra page), a small amount of memory is used by the OS for storing application base pages (so if you overwrite that area, you have to call FillBasePageTable to restore it), and a further area (about a kilobyte, as I recall) is used as scratch space for USB operations.

Perhaps it would be useful for Axe to provide an "allocate temporary buffer" function, which could be implemented in various ways depending on the calculator model and the type of program (RAM versus application) you're compiling.

Z-address is what it's called in the official documentation from Toshiba.  They also call the vertical direction "X" and the horizontal direction "Y", so take that with a grain of salt.

EDIT: Screenshot! (Note: I had to use PindurTI instead of WabbitEmu because PTI is the only emu that emulates Z-Adress properly)

TilEm II does that as well, but I guess I'm not allowed to brag about that until I get my act together and finish it.

Looks like restarting the browser did the trick.  I still have no idea what was wrong, but thanks.

Iceweasel is the Debian rebranded version of Firefox; it's essentially identical, but (for weird and complicated reasons) they can't, or won't, use the Firefox name.

The file is 143 kB, so I doubt it's a size limitation.  I'm using Iceweasel (i.e., Firefox) 3.5.15.  It's very strange; I believe I've uploaded zip files here in the past.

I'm trying to post a zip file as an attachment (see http://ourl.ca/74475 ) and the forum won't let me.  When I try to upload it with a .zip suffix, it gets rejected, despite the fact that zip is listed as an "allowed file type", both on the edit-my-post page and on the error page.  Any idea what might be going wrong here?

(I also tried renaming it to .txt, but then all the CRs got helpfully turned into CR-LFs.)

There are a few good reasons to make your program a Flash app:
- it installs persistent hooks (in which case, a Flash app is the only reliable way to do it)
- it provides libraries for other programs (whether using hooks or by other means; this can be done without making the program an app, but it's much less convenient)
- it allows the user to edit large data files (in which case, you want to leave as much RAM as possible free for the user's data)
- or the program itself requires a huge amount of code and/or data (but in this case, you should also probably consider splitting the program up.)

Normal (RAM) assembly programs are really a lot more convenient for the user (you can hide them, rename them, launch them using any shell you like, organize them into folders if your shell does that, compress them if need be, store them in RAM or archive or on a USB stick...)