So now that I have lots of tools, I'm thinking about, amazingly enough, actually writing code again. One thing I'm not sure about with the 65816 is how to organize the Direct Page (the equivalent of Zero Page on the 6502) so programs don't end up messing stuff up if there is more than one of them in memory.

The best strategy I can think of so far is to "incorporate" it into the code body to make it as easy as possible for the user to load and start. This assumes the easiest case, that we're staying on Bank 00.

Here, as an example, we assemble the program to reside at 00:2000, and put DP at the beginning of that range. To make it easy to use, we put a BRA instruction to the first actual code - the part that moves the DP - in the first two bytes, so the user just has to know "load this program to 00:2000 and then jump there and don't worry about the DP". In pseudoassembler: And the we continue with what we want to do. We give up two bytes of DP at the beginning for the BRA instruction (we don't want to start at something like "00:2002" because of the speed penalty if DP doesn't start on a page boundry) and we're overwriting part of the DP with acutal code. On the other hand, this means that every Bank 00 program "contains" its DP at the beginning, and so if we compile one program to 00:2000 and other to 00:3000, we never have to worry about the DPs clashing.

However, this can't be a new problem; how do you experienced 65816 codes do this? And is there a recommendation of what to do if the code is not in Bank 00?

My usual tack if the program is running in bank $00 (which is the case on POC V1, since there is no RAM above bank $00) is to set direct page to a BSS area after the program, since direct page effectively "grows up," unlike the stack, which grows down. The BSS has only to be as large as the maximum DP address you are going to use, which the assembler should be able to figure out for you. The DP located in BSS would be used by the mainline routine. Subroutines can be given ephemeral direct pages on the stack, which is a painless thing to do—some simple math and fiddling with the stack pointer.

If the code is outside of bank $00 you may have to have a supervisor that would keep track of where direct pages and stacks are located, and have each program request a direct page and stack range from the supervisor at startup. The supervisor can return the DP starting address in .C and the top-of-stack address in .X for convenience. You'd have to make sure that the running program doesn't violate the bounds of DP and/or the stack, or else you'd have a major mess on your hands.

Keep in mind that if the base address for DP is not on an even page boundary a one cycle penalty will apply to DP accesses. Hence DP should be set to $xx00 if performance is a concern (where xx is any page).

The fact that DP and stack references are always to bank $00 is something that I eventually hope to mitigate in programmable logic.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

That's something I am working on too. The Apple /// does this, it has the concept of the OS, called SOS, and the application, called the interpreter. When you switch from OS to interpreter the zero page and stack are switched to a different memory range. What I was thinking about was generalising this a bit to have a certain number of processes, and at context switch time their own ZP/DP and Stack are mapped into memory by the hardware. This would give each process their own DP and Stack without copying memory, so is actually very efficient. Of course the SP and other registers would need to be saved and restored at the same time, but if you consider DP as an extended 256 registers then this is a great way to save registers quickly.