Now, I know that everyone's all like: blargh imma wanting some of that multipage app goodness, and Quigibo's like....not practical.

If I understand correctly, it's not that compiling a multipage app is difficult because it's large, but it's that creating the instructions to swap pages and that knowing when and where to swap pages in an arbitrary program makes it difficult.

Now, simplifying, the problem would be would that the parser doesn't have enough information (that only the programmer would know) to accurately create the multipage app.

So my idea was, to have integrate a compiler command to indicate the different pages :| There would probably two commands, one to call the 2nd page and one that is some kind of modification to the #include (prgmXXX) function, where that program would be parsed into the 2nd page. Then, in the app's code, when the program needs to swap pages, there would just be some command in the 'mother app' to switch pages. For example, if you wanted to mix a battle engine (in prgmBATTLE) with a tilemapper, the code might look like this:
blah blah blah tilemapper code
<when a battle occurs>
instruction to swap to 2nd page of app
more code blah
...

instruction to parse prgmBATTLE as the second page of the app

Basically, what this could do would be to enable "packaging" of a second app together with the first app, sort of like what Builderboy's virtual-page program does, but only with real app pages. While this method would in no way be close to producing the flexibility of a real asm-programmed multipage app, I figure that this, well, it's better than what we have right now . It would require the programmer to make sure that his pages can run completely independently of eachother (no subroutines or anything), but that's a small price to pay.

Thoughts? Is this even possible?

The only problem is that the routine to swap the pages cannot be located on the page you're trying to swap.

The best way to have multi-paged code is page calls.  On the main page, you write all your normal code.  But subroutines can be called off-page by special routines so perhaps they could be put on the other pages with the data.  The reason I can't do this though is that the parser simply doesn't have enough memory left to keep track of all the multi-page functionality.  The all data idea that calc84maniac is talking about seems like the only practical way at the moment.  And just for the record, the reason I haven't implemented this yet is actually because its difficult for the compiler.  Writing things to multiple pages of flash, additional parsing passes, creating new syntax, checking for errors, all while being compatible for all versions of calcs (which have different starting points for the app tables) is challenging and time consuming.  If there are any assembly programmers who want to help me with it, I can post the app writing code if you're up for it, but I can hardly understand it myself since about a third of it is written by TI.

This is why I think a computer version would be much more efficient.  But I think if I do end up doing that, it will look a lot more like C than Axe since the computer is fast enough and has enough memory to that I can automatically optimize the code so that you don't have to do all those weird syntax tricks like calling things with missing arguments or storing things after each other.

If there are any assembly programmers who want to help me with it, I can post the app writing code if you're up for it, but I can hardly understand it myself since about a third of it is written by TI.

Can I get that code?

Oh, thank you very much! What does P2ldir do?

Okay, then what is RAM defined as?