I decided to take the plunge and explore Forth. I wanted to use a 6502-based Forth so I chose the FIG6502 source from the source code repository as my starting point.

In order to get it working quick, I decided to use the Kowalski IDE as my "platform". I built a quick wrapper for the FIG6502 source that handles the reset/IRQ/NMI vectors and provided the terminal interface code - XKEY (wait for key), XEMIT (output character), and XCR (output cr & lf).

I still need to do the XQTER (test for break key) code and provide support for the R/W command, but I was able to get the FIG6502 code running in short order.

Assembling the wrapper, running the debugger, and pressing the RST symbol brings up the terminal with the "fig-FORTH 1.0" banner.

Entering "2 4 + ." returns "6 OK" as expected.

Next is to fix the bugs Garth has mentioned.

I have a copy of the FigFORTH Installation Manual and plan to test each of the words in the glossary to get a good understanding of how each works.

From there, I'll find some simple code examples to experiment with.

If anyone is interested in getting these files to play with, PM be with your email address and I'll forward what I have.

Daryl

Here's an update:

I took the code that runs on the Kowalski platform and changed just the three IO vectors, and ran on my SBC-2 (WDC65C02).

I took the same code and modified it for the SBC-4P (WDC65816 in native mode) and it will not run. I get a long burst of garbage to the terminal then it hangs. The D reg is pointing to page 0 and all registers are set for 8 bit. There must be something in the indirect references or page wrapping that is causing this. I will try on my SBC-3 (65816 native mode) next.

In the mean time, it does not appear that my version of Fig6502 has the UM/MOD word. I can only find the U/ word that has the same code as Garth describes in his fix article. When I replaced that code, it failed. I think the byte order is different but have not dug into that yet.

I have played with a few more words, but have a long way to go yet.

Daryl

I've never used FIG-Forth so I had to look it up: it is indeed called U/ in FIG-Forth, whereas Forth-79, Forth-83, and ANS Forth call it UM/MOD.

Again, one of the best books for getting started in Forth is Leo Brodie's humorous book "Starting Forth" which you can read online, free, at http://www.forth.com/starting-forth/index.html . The differences between versions (like the U/ and UM/MOD above) are few, and this book does cover them.

I'm no expert on the '816, but wouldn't the first and most basic test be to attempt running in Emulation mode (utterly 8-bit, backward compatible)? Also you don't mention what modifications you made to the code. Aside from the switch to Native mode, is there anything else?

Perusing the '816 data sheet I notice that Native mode allows a full 16-bit Stack Pointer. Sorry if this is a dumb question, but did you initialize all 16 bits? I think the hi-byte ought to be set to $01, if I understand what it is you're doing, that is. Just trying to help...

I have fond memories of many, MANY fascinating hours spent with FIG Forth, btw!

-- Jeff

That might explain also why the data stack byte order might be different as well. I'll check out that book.

Yes, I thought about that too. All of my other code runs in native mode though and I was hoping to keep it that way. I do keep the registers set to 8 bit vs 16 bit and the stack is initialized to $01ff.

The only changes to the code are the IO vector assignments and the removal of the test functions.

I think that there must be some page wrap functions that do work on a 65c02, might work on a 65816 in emulation mode, but the 65816 in native mode advances to the next page. I had some issues with Lee's EhBASIC doing that too.

I hope to find time today to work on it more.

Thanks all

Daryl

Just tested emulation mode and it works so there has to be some page wrapping or stack wrapping going on - just need to find it.

Daryl

When the '816 is in native mode, the hardware vectors (IRQ and NMI) are in different locations, and BRK and IRQ are separately vectored. That could that be part of the problem.


The 65C816's emulation mode is not 100 percent 8 bit compatible. Unlike the 65C02, where some opcodes are technically illegal (and act as NOPs of various lengths), the '816 has no illegal opcodes and all of them work in either mode. Also, instructions such as XBA have no 8 bit equivalent. So the emulation mode is just that: emulation, which is not the same as exact equivalency.

I'm loading Fig6502 into RAM and the OS is left intact, so the vectors are all correct. When I first ran Lee's EhBASIC on the SBC-3, I found some stack manipulations were causing problems and another member here pointed out that there was some page wrapping being used. Meaning that an indexed address that results in an offset of over 256 would wrap around to the beginning of that same page on a 65c02, but on the 65816, in native mode, it would advance to the next page. That was the only issue to fixing EhBASIC and am hoping that's all there is with this too.

Daryl

Doesn't Fig6502 do some interrupt processing? I've never looked at the source code.

This one doesn't, yet. I think you have to add that and any other system tools. The good thing is that you could program those in Forth!

No. For servicing interrupts in high-level Forth, you need my article at http://6502.org/tutorials/zero_overhead ... rupts.html .

There are no limits on assembly-language interrupt service of course, and the Forth doesn't even have to be aware that you're doing it.


Yes, but when you get the assembler loaded too, you can write Forth primitives (or code definitions), runtimes, and subroutines, and also mix sections of assembly into a secondary (or colon definition) if you want.

Good to know -- thanks. (I told you I wasn't an expert!! )

I didn't say I was either.

Garth, thanks again for pointing out that book. I have worked through to chapter 3 and am finding it very helpful.

Also, your UM/MOD fix works just fine. I was trying to enter a double number by just typing it in. I found that it only loaded the upper 16 bits onto the data stack, not the entire 32 bits. After switching to HEX mode and entering two dividend words and one divisor, the code worked just as you described. (original's bugs and modified code's correct results)

Now, on to other bug fixes and Chapter 3. That deals with disk I/O so I need to fix up those routines too.

For now, I am running Fig6502 in emulation mode on SBC-4. I still plan to investigate the native mode issues.

Daryl

if it can help, i've also a well commented source by hand, i can scan and put online.

meanwhile here you can find a working original code
http://ptorric.tsc4.com/index.php/proje ... forth.html