So if I have an app, could I read in the page I'm running on, then swap it into bank 2 and jump to bank 2, where I then swap in the RAM?  Probably tough to pull off in Axe, but I have a few ideas.

No, like this, in asm:
di
in (6), a
out (7), a
jp $+4000h
ld a, 83h
out (6), a
; Business as usual

So if I have an app, could I read in the page I'm running on, then swap it into bank 2 and jump to bank 2, where I then swap in the RAM?  Probably tough to pull off in Axe, but I have a few ideas.

That would work in assembly language - as you say, it might be tricky in Axe - but you'd want to be sure interrupts are disabled.  Like I said before, the OS doesn't like it if you change port 7, and that includes the system interrupt service routine.  And remember that stuff like the screen buffers and A-Z variables are all stored in that area as well.

Another option, with the same caveats, would be to simply leave your app mapped in the 4000-7FFF slot, and temporarily map whichever RAM page you're interested in in the 8000-BFFF slot.

So, I've never made a multi page APP before... Would it be that I could make a code like this:

This heads both pages

Code: [Select]

<<Header>>
1803          This skips the next 3 bytes
DB06          This changes the flash page to whatever was in a
C9            This is executed on the next page, pops the value into PC and picks up the code from there
Continuing code to some part on the next page:

Code: [Select]

DB06          This gets the current flash page in a
3C            This increase a
21****        This is the address to jump to on the next page
E5            This pushes HL
C38240         This jumps to 2 bytes after the header


Yes, that will work, I think.  In other words, you use the routine at 4082 (which is present at the same address on both pages) to switch from one page to the other.  The 84+ boot code uses a similar technique.

Another option is to use application B_CALLs and B_JUMPs.  You can make a table of addresses and page numbers on the first (or "base") page of your app, and then use a B_CALL instruction to call those routines from anywhere in your app.  For instance, if you have a routine at address 4567 on the second page, and you write the bytes 674501 at address 4083 on the first page, then (from either page) you can call that routine using a B_CALL 0083h (EF8300), or jump to it using a B_JUMP 0083h (CD50008300).  This is much slower than the method you're suggesting, but also takes less space.

Well, first off, for normal system B_CALLs, between 4000 and 7FFF, the B_CALL handler first looks on page 1B (or 3B or 7B, depending on the model), where there's a table of all the system routine addresses and page numbers.  So for instance, if you do a B_CALL GetKey (4972h), it looks at the 3 bytes stored at address 4972 on page 1B - in OS 1.19, that's 8B 49 06, i.e., address 498B on page 6.  The OS then pushes your original page number on the stack, as well as the address of a handler routine (on page zero).  It then loads page 6 in the 4000h bank and jumps to 498B.  When the GetKey routine returns, it returns to the handler, which pops the original page number off the stack, restores that value to port 6, and returns to your program.

Boot B_CALLs are provided by the boot code, not the OS.  They work exactly the same way, except that you use an "address" between 8000 and BFFF; the B_CALL handler subtracts 4000h from that value, then looks up the address to call on page 1F (instead of 1B.)

And finally we have application B_CALLs, like I mentioned above.  In this case, you use an "address" between 0000 and 3FFF; the B_CALL handler adds 4000h to that value, and looks up the address to call on the first ("base") page of whatever application is currently loaded in port 6.  In this case, the page number listed in the table is relative to that base page (so if your app is stored on pages 15 and 14, a value of 00 in the table corresponds to page 15, and 01 corresponds to page 14.)

(B_JUMP does the same thing as B_CALL, except that it doesn't save the original page number or push the extra handler on the stack.  You almost never want to B_JUMP to a system routine, but you may sometimes want to B_JUMP to routines within your app.)

I'm not sure.  It looks like it would subtract 4000h from that value, so it would look for a jump address in RAM between 8000 and BFFF.  That might not work on all OS versions, though.

Okee, I think I'll give it a try. Meanwhile, I just had a brilliant idea with an interrupt, if only I could manage it in my head. It will be my first interrupt \(^_^)/

Sounds scary.   I'm still amazed at how you can program the way you do.  Good luck!