Another 65816 STC Forth

[leepivonka]

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!

[whartung]

leepivonka wrote:

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.

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.

[BigDumbDinosaur]

whartung wrote:

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.

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.

leepivonka wrote:

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.

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.

[BigEd]

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

[BigDumbDinosaur]

BigEd wrote:

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.

[BigEd]

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

[BigDumbDinosaur]

BigEd wrote:

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.

[scotws]

whartung wrote:

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

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.

[leepivonka]

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.

[GARTHWILSON]

whartung wrote:

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

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.

[leepivonka]

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.

[leepivonka]

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.

[BigEd]

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!

[leepivonka]

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.

[leepivonka]

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

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

Code: Select all

65816F 2019May30
: x 1000000. 0. ddo dloop ;  ok
: z cc@ x cc@ d- d. ;  ok
z -36000702  ok
see x
04F4 A00F00     LDY #000F {' SInCnt1+0001}
04F7 A94042     LDA #4240
04FA 20CF85     JSR 85CF {PsuYA}
04FD A00000     LDY #0000 {' SInIndx0}
0500 A90000     LDA #0000 {' SInIndx0}
0503 2021AE     JSR AE21 {DDo+0016}
0506 2066AE     JSR AE66 {DLoop+0006}
0509 D0FB       BNE 0506 {x+0012}
050B 60         RTS
 ok
see z
0510 02F5       COP #F5 {S0+0009}
0512 20CF85     JSR 85CF {PsuYA}
0515 20F404     JSR 04F4 {x}
0518 02F5       COP #F5 {S0+0009}
051A 203589     JSR 8935 {D-+0003}
051D 20D7A4     JSR A4D7 {D.}
0520 60         RTS
 ok