6502.org

On GitHub: The structure of the source has been changing dramatically to add the '265sxb port alongside the previous port.
I'm trying a scheme where there is a set of core files & a port file that has port-specific stuff & settings & includes some core files.
So far it's good, but there are some loose ends (e.g. what if a port wants a different stack size?).

Unfortunately, 65816 code seems to be either bloated with mode save & set code or must be called in a particular mode. Mess this up & it looks OK & compiles fine, but runs weird! I've been using these to get simple code with a minimum of mode management.
---Compile time: the assembler follows REP & SEP instructions in source file order. The source is ordered so code will run in the expected mode. Assembler mode change pseudo-ops are used when source ordering won't suffice.
---Run time: The default mode is native with M & X flags=16-bit & decimal flag=off. Routines expect to be called in default mode. A routine can change M & X & decimal flags internally, but must not call any standard routines this way & must go back to default mode before returning.
In many cases it's easier to just do a 16-bit operation instead of mode switching for 1 or 2 8-bit operation.

On EMIT & KEY: Maybe implement these now as simple calls to put_chr & get_chr, then make them fancier later when you're ready. I have them use per-task vectors - connect several terminals & start a task for each of them running INTERPRET to make a multi-user system.

On the Mensch monitor: WDC has the "W65C265 Monitor ROM Reference Manual" & "W65C265 Monitor ROM Code Listing".
I'm still inclined to eventually switch off the '265 internal ROM & use code from the flash ROM. I also get most of another 8KBytes of 0 bank ROM to fill up that way too!

Why would someone writing greenfield '816 code be "jumping back and forth", why not just pick one (ideally '816 "mode") and run with it.

I'm pretty sure that's what BDD does -- config the CPU and start and leave it alone.

Because, yea, the idea that a setting in a subroutine can affect how code is execute after it's returned -- man, that's just makes me itch thinking about that.

The reset handler in POC switches the MPU to native mode and leaves it there—the firmware and machine language monitor are 100 percent native mode code.
The only reason one might temporarily put the '816 back into emulation mode would be to deal with an operating environment that was written for the 65C02. An operating system built natively for the '816 would not need to engage in any such shenanigans.

Incidentally, one does not "compile" assembly language, any more than one "assembles" C or FORTRAN.

Funny how the words 'compile' and 'assemble' - and very nearly 'link' - have such similar meanings in everyday language. A C program is typically an assembly of files, and a Fortran deck is an assembly of cards... now wait there while I link these libraries which are conveniently coded on paper tape...

Oh man! Please don't remind me of those !#*%^~%$&^@ punch cards! Paper tape was less trouble.

People who think line numbers are not so useful have never dropped a deck of cards...

...or had a couple of card mangled by the card reader.

Character manipulation would seem to be easier with A in 8-bit, and faster, too, and at the moment, I'm doing all the ACCEPT, PARSE-NAME and FIND-NAME words, so it's all about characters. Otherwise, it is 16-bit all the way.

What I'm doing now is rewriting my Tinkerer's Assembler to show me what it thinks A and XY are in each line of 65816 code. That should help with these sort of bugs.

This program is now operational on a stock WDC w65c265sxb board. So far it seems good except for flow control on data to the board.

Even though you stay in '816 (ie, native) mode, you can still select 8- or 16-bit mode for A, and separately, for X and Y. My '816 Forth leaves A in 16-bit mode nearly full time, and X and Y in 8-bit mode nearly full time. The emulation bit gets cleared at the beginning and never touched again though.

I was playing with the example code mentioned in Tali Forth here .
The Mandelbrot example runs in 26 sec on a stock WDC W65C265SXB board.

Playing with the BASIC floating-point Mandelbrot at viewtopic.php?f=1&t=5649

This runs in about 172 secs on a 1.05MHz 65816.

That seems like a very impressive translation - by hand? - from Basic into Forth. Somehow you've managed a couple of GOTOs without tripping up. It looks very clean indeed - well done!

The BASIC to FORTH translation was by hand. It feels like drogon built the original with structured flow control, then converted it to GOTO & IF..GOTO for simple BASICs. I just needed to change these back into the structured equivalents. I wish it was this easy for spaghetti code BASIC programs!

The FORTH to 65816 translation was by the FORTH compiler running on the 65816.

The disassembly was by FORTH's SEE running on the 65816. I typed in the original FORTH source to the right for reference.

Looking at viewtopic.php?f=8&t=5678#p69489

65816F uses just over 36 clock cycles per double-cell loop.