IIRC, with Fig Forth what you do is include a decimal point as part of the number string. This'll result in a double value (32 bits) being placed on stack.

-- Jeff

I just tried it and it worked just like you said.

Thanks!!!

Daryl

Glad to hear it!
DPL (a User Variable) will retain the position of the decimal (radix?) point in case you actually need to interpret it somehow -- for fixed-point arithmetic, perhaps. But Forth makes no assumption -- you're on your own! (As usual ) Check out the Fig word NUMBER btw.

Re: tracing down the '816 wrinkle, I recall Fig has a JSR Trace that can optionally be included with NEXT. Using that, maybe you could determine approximately where things went off the rails, thus narrowing your search for the bug.

-- Jeff

I had removed the trace functions but might put them back.

There is only 1 TXS instruction in the source and I replaced that with the 65816 equivalent code and now I get the Fig Forth 1.0 splash. After that, it does not respond.

Using Trace might help now.

thanks for the suggestions!

Daryl

I found the page wrapping problem in two places. On a 65c02, an LDA $FE,X will wrap around back into page 0. The 65816 in emulation mode will too. However, in native mode, it will advance into page 1.

Example: X=$10, LDA $FE,X The address pointed to:
65C02 = $0E
65816 = $0E (emulation mode)
65816 = $10E (native mode)

Here's the offending code:


and here



Corrected code adds just one instruction:





The other fix I mentioned, a TXS replacement, is here:



This get fixed to:


FigForth now runs on a 65816 in native mode. I can now work on the disk interface.

Daryl

That's terrific, Daryl -- a fine bit of debugging, and a significant contribution that others can benefit from! I wonder what's the best way to make this information find-able for someone who needs it?

BTW, re Fig FORTH, you should (if you haven't already) get your hands on the fig-FORTH INSTALLATION MANUAL by William F. Ragsdale. The Glossary he includes is invaluable. Amazon lists this document; mebbe it's downloadable somewhere as well; dunno. (Copyright permitting, it'd be a worthwhile addition to the 6502.org library!)

-- Jeff

I found a plain text copy online. I have been using the glossary already to help figure words out. Thanks!

Daryl, I should have thought of that for you so you could save some time, but it has been years since I worked on my '816 Forth. What I did on that for 0branch (which won't work on the '02 though) is:

where HEADER is a macro that makes the header (which you omitted for brevity), PRIMITIVE is a macro which does the same thing as your ".WORD *+2", and INX2 is a macro that just puts a pair of INX's in since that's done in so many places in the kernel.

That code works too.

I compared bytes used and cycles used and both your way and mine are the same - 10 cycles and 6 bytes (just affected opcodes, not entire subroutine).

Thanks Garth. Down the road, I may try to optimize this Forth for the 816, unless you find time to publish your's first. In the mean time, I still have a lot to learn.

Daryl

I'll send you mine whenever you're ready. It's just that the explanations are not not all cleaned up as tidy as I would like it to be, especially for those who have no significant prior Forth experience. Wally Daniels (who's a member here but rarely checks in) has used it on the 65265 though. This '816 Forth is a complete re-write, not a slight modification from the '02 Forth. I was pleased to find that many of the words are not only faster as primitives (as expected), but even more memory-efficient as primitives (contrary to the situation with the '02) and sometimes even easier to write-- and certainly easier than writing the same primitives on the '02. This makes it worth having hundreds of primitives in the '816 Forth, whereas many more of the words kind of have to remain as secondaries on the '02 Forth to avoid taking up too much memory. It also results in the '816 Forth running 2-3x as fast as the '02 Forth at a given clock speed.

And again--for those who are afraid of the 816's mode bits-- You almost never take it out of 16-bit accumulator and 8-bit index registers. You leave it in those modes almost all the time. When you do change it, you use a macro so it's clear what you're doing, like "INDEX_16" instead of whatever the cryptic REP or SEP instruction is.

I'll take you up on that in a few weeks to few months ... once I've digested the Fig-Forth installation manual and that online book.

Thanks!

Daryl

_________________
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?

Perfect timing - I was just searching for the fix for that. I've made those changes as well.

Thanks Garth!

The FIG site:

http://www.forth.org

links to the Taygeta archive:

ftp://ftp.taygeta.com/pub/Forth

which has a ton of interesting stuff, but it can be hard to find things. IMO, it's worth spending some time looking through it, though.

The FIG-Forth Installation Manual is here:

ftp://ftp.taygeta.com/pub/Forth/Archive ... IGINST.ZIP

The FIG-Forth 6502 assembler is here:

ftp://ftp.taygeta.com/pub/Forth/Archive ... sm6502.txt

which can be used to write CODE words (i.e. primitives). It appears to be OCR'd since the letter O appears in several places where the number zero should be, and a lowercase L appears where the number one should be. I made some fixes to a copy of this file, but have not tested those fixes.

Also of interest is this FIG-Forth implementation for the 8086, not so much the 8086 assembly source code, but specifically the block file FORTH.SCR (.lzh is an old compression/archive format, like .zip):

ftp://ftp.taygeta.com/pub/Forth/Archive/ibm/fig86.lzh

Although it looks almost like a text file, it actually consists of 64 character * 16 line blocks (and hence its length is a multiple of 1024); there are no CRLF line terminators, so your favorite text editor may barf on it. In DOS/Windows EDIT /64 FORTH.SCR does the trick. I found it helpful to turn it into a real text file containing CRLFs (I probably used awk or perl or somesuch for this, I don't really remember).



To be clear, I should point out that any old STC implementation is not necessarily more space efficient than you'd think, but it's possible to create an implementation that is, without sacrificing too much of the speed advantages of STC.

By the way, you might want to make that $FFFFFE,X (i.e. long,X addressing) since abs,X will cross bank boundaries, so this will read from bank 1 (assuming the DBR is 0). I am guessing you're using this on a 64k 65C816 which ignores the bank byte.