• The program counter wraps at bank boundaries
• rel and rl (branches) wrap at bank boundaries
• xyc (MVN and MVP) wraps at bank boundaries
• (abs,X) wraps at bank K
• (abs) and [abs] (JMP and JMP/JML) wrap at bank 0
• The direct page and stack wrap at bank 0

Pretty much everything else can cross bank boundaries. This means, for example, that the 12,S part of (12,S),Y wraps at bank 0, but the ,Y part can cross a bank boundary.

Since I developed my '816 Forth on an '802 which does not have access to anything beyond bank 0 (as it's an '816 made to go into a 6502 socket), I have not yet done the material for accessing 24-bit addresses. But I might at least sometimes just use a few DP variables to form those long addresses for the indirects instead of modifying the bank registers' contents. I'll have to see what works best; but I basically want it to look like a continuous 16MB space with no bank boundaries. I realize bank boundaries and bank registers have their advantages sometimes, but my use will be quite different from the typical use of the Apple IIgs for example. Of course memory moves using MVN and MVP do involve bank numbers. I plan to keep all actual Forth executable code in bank 0, which is a lot of space for Forth if the largest arrays & tables, and files, etc. can go outside bank 0. I've started getting parts to make my '816 computer.


And put the return stack where?

Well, I haven't seriously started coding. In fact I've never written anything for the '816. But I'd plan to keep the Return Stack Pointer in Direct Page and load it into X when required. The Forth IP would live in Y, and FIG style double-indirect NEXT would be as follows:


This is fast -- about 14 cycles! The cost of keeping the R-Stack Pointer off-chip seems worthwhile.

FWIW, the Forth I'd build is a 16/32-bit hybrid -- generally 32-bit but with exceptions regarding code. (Stack items occupy 32 bits, and @ and ! use Long addresses and access 32-bit data. But the Dictionary resides within 64K, and tokens are 16 bit.) In fact I still use my old 80286/386 Forth that's written this way. I wanted a data space bigger than 64K, and didn't want to be stumbling over FAR@ FAR! FARC@ FARC! etc etc (as I'd done with the KimKlone). In fact I was fed up with mixed precision in general, which I was doing a lot of due to the Far addresses being tossed around. It reached the point where 2SWAP 2DROP 2OVER and all the rest began to seem like tools for generating for errors and unreadable code.

I wanted something easier, and the solution was to simply make 32 bits the default. Yes, a 16-bit CPU has to work harder to make this happen, but the performance hit isn't as severe as you might suppose (given that you'll always have substantial overhead for NEXT BRANCH NEST UNNEST and so on -- which remains almost unchanged). If there's any interest we could start a new Topic about 32-bit Forth running on 16-bit hardware. In fact an '816 version could reuse a lot of the high-level coding (mainly compiler alterations) I did for my 80286/386 Forth.

Bruce's idea of using the 16-bit stack pointer as IP so NEXT is simply RTS practically took my breath away a couple of years ago when he proposed it, but without being able to use the hardware stack (the one that's in page 1 on the '02), you can't practically have interrupts. Subroutines using the hardware stack are almost a non-issue, since non-subroutine-threaded Forth has almost no subroutines and it wouldn't be hard to do a work-around for the seldom times you do have a subroutine.

We had a very extensive (9 pages!!) discussion on an all-32-bit 6502 at viewtopic.php?t=1419 . Basically a byte would be 32 bits, and there are no shorter loads and stores than that. Reading 32 bits happens in a single clock. With a 32-bit address bus, data bus, and registers, basically the whole 4GB space is in page 0 (eliminating the ABS and LONG addressing modes), and the stack pointer also spans the whole range. (Although I wrote "GB", remember that they're 32-bit bytes, so it would be as much memory as 16GB in the terms we're used to, although the usage won't be as efficient.)

Sounds like that discussion includes some of the same goals as mine; I'll check it out. Ummmm... It also sounds like you're designing a new CPU! For now I'll be content with my Virtual Machine that lets me run 32-bit Forth on an embedded 80186, a PC (and perhaps someday an Apple IIGS or '816 SBC)!
[Edit: clarify VM remark]