• 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.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

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.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

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]

In another thread I mentioned 'C02 undefined instructions, and was speculating on whether the Rockwell and WDC chips treat these "illegal" opcodes the same way. After installing a WDC CPU in the KimKlone I'm convinced they do.

I admit it was a thrill to see this comparatively ancient computer boot up with an updated CPU, and I did a little photo session that day -- a portrait, as it were, of the machine that occupied so much of my time, both in its creation and in the following years as a tool used day-to-day (in the same manner as Garth's Workbench Computer). Today for some Friday-afternoon frivolity I decided to share a few of those shots. (Older pix can be seen here.)

The KK included quite a lot of stuff that was rarely or never used, and the keypad and LED display (above) are definitely in that category. But, on the plus side, I notice the LED display photographs quite nicely! In this shot, the machine monitor is running and the address and contents of a zero-page location are displayed. (KK uses six-digit addresses).

Pin 1 of the WDC cpu (VPB) is bent outward so as not to engage the socket. The removable daughterboard at the top left is an RC oscillator, adjustable via trimpot for test purposes. Its output (presently 80 MHz) gets divided down to supply video and CPU clocks.

Here's the video display, showing mostly just power-up garbage in RAM. The video format is extremely flexible, but defaults to 16 kilohertz scanning suitable for re-purposed NTSC televisions. That limits us to 32 characters per line -- which I found to be adequate or even preferable when the material viewed is Forth source code!


This last shot is just silliness, hamming it up for the camera. After the Fig-Forth greeting and OK prompt, you can see I've entered a text string in English -- not Forth.

Playing coy, perhaps, KK responds with message code zero, indicating it hasn't recognized the first word, "say." (Then I hit CR a bunch of times to bring the dialog to center screen.)

cheers,
Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

A whole lot of chips and no vile-smelling smoke. Now you should be able to really crank up the clock.

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