I've tried to learn Forth in the past. But I gave up in frustration. Mainly because of the Reverse Polish Notation. Which is odd for me because I worked on a calculator program years ago and I was studying implementing RPN in it at the time.

For the life of me, I just could not get



That just doesn't sound right! I always felt like I was missing something. I knew the concept in my head, but it never materialized.

That is until the other day when I discovered the "Starting Forth" book.

https://1scyem2bunjw1ghzsf1cjwwn-wpengi ... -FORTH.pdf

I guess I'm more of a visual learner than I thought. The cartoons really helped and the writing style is also easy to understand. It's starting to sink in!

I still have a few issues with solving problems like


Mainly knowing when to use SWAP, etc.

But I have to admit, I'm really enjoying it. Being able to rapidly create chained objects (words) out of smaller words, etc. is very productive. It's almost like you get debugging built in for free. Once you know that a custom word like "STARS" works, you can feel confident in using it in things like "40 STARS", etc.

Right now I'm using an online Forth environment but I really want to implement Forth in my SBC (after I finish my mini-monitor).

1) What 6502 Forth do you guys recommend?

2) How much is Forth in your SBC? Meaning, do you use it more for things like DOS routines or do you use it all the way down to the driver (audio, serial, I2C, etc.) level?

I envision my SBC having a crude, interactive OS driving menus, launching BASIC or Forth environments and playing audio tunes. I'm wondering how far to try and take Forth vs. assembly.

Thanks!

_________________
Cat; the other white meat.

All depends on your goals, and depends on your hardware.

For Garth's workbench computer, his Forth is essentially the system OS/Monitor. It IS a Forth system. And that's great for a system such as his which is basically a system designed to play with other systems, not so much as a stand alone "personal computer". It's more a generic piece of test equipment with a lot of general purpose I/O to talk to "anything".

Then he uses Forth as a shell to interact with that equipment, combined with the ability to create "scripts" to automate things. But, in the end, these are snippets of code that are "cut and pasted" from his host system in to the workbench computer. None of this is "permanent", at least from the workbench computers POV. I don't believe that the machine has any persistent storage, for example. He uses his host machine for that.

With the Forth system, you don't have to "choose" between Forth and assembly as you can have both. Having a Forth hosted on your machine makes it easy to do what Garth is doing, interact with the machine. You can do what Garth does and "cut and paste" code over to your machine for real fast turn around, even in assembly using a built in assembler. This in contrast to assembling, linking, downloading, restarting, etc. As long as your assembly snippets don't crater the computer, you can cut and paste all day long. If you have storage on your computer, then just edit it in place, and reload the code. If you don't have hard timing issues, i.e. if "Forth is fast enough", then you can just do things in high level Forth.

When you're happy with your changes, you can then uplift the code to your "normal" monitor/driver/whatever.

A nice thing to have is something that Garth has which is the ability to hook a high level Forth word as an interrupt handler. That way you can use high level Forth to prototype a UART driver, for example, or something else.

On my simulator, I have the disk I/O in high level Forth. It's just simple memory copies and such, and it's "fast enough".

The nice part is the interactive development and fast turn around, and the "more close than not" to the metal that Forth is vs BASIC. The built in assembler helps a lot as well.

Of course the perpetual Forth hobby is to write your own Forth. But you can always just use the 6502 Fig Forth. It's functional and easy to port. We have Taliforth here, you can try to port that one. Porting is typically simply a matter of getting the memory right and tying in the character I/O. If you have block I/O, you need to wire that up as well.

You'll have lots of support here, we have lots of threads on getting Forths to work here.

Wow, Mr. Hartung has really been paying attention! Thanks for that good description. The only mass storage I've done on my workbench computer was really to record digitized audio in flash for example, not actual program material. I use a separate DOS PC with a MultiEdit professional programmer's text editor and a high-res monitor and dozens of files loaded at once (which most people don't realize you could do in DOS). I would like to eventually break the dependency on the PC though. Ideally you could still use the PC as a host when you want it for the full keyboard, hi-res monitor, and other benefits, but you would not be required to.


Don't think of "+" as "plus," but rather as "add," a command. So you have, "two, three, add."

Yes, "Starting Forth" is an excellent book, in spite of how old it is. I got my start in that nearly 30 years ago, in the paper one.

I have a long list of things I hope to do in 65xx work in the coming years, and one of them is to port my Forth (either '02 or '816) to a working board so newcomers can have something that works like the above right out of the box. The unfortunate history of Forth on the 6502 has mostly been that people have to do a lot of learning of its insides before they can get anything at all working. I have 75 65c02's and twice that many 65c22's (in DIP; not including some in PLCC), and my employer has more than that (again in DIP) plus RAM and EPROM that I hope they get tired of storing and just give them to me, and then I would like to provide a low-cost board with Forth pre-installed in ROM for education and hobbyists.

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

That would be an awesome idea. And wow. That's a lot of chips!

As I'm going through the book, I find I can do some of the quizzes but one that has me stumped is the guessing game.



LOL. Got a lot to learn.

_________________
Cat; the other white meat.

Spend some time looking at Thinking Forth.
It is a great way to think about programming regardless of what language you are using.
Dwight

You've got ( mystery guess-number ) GUESS

So you want to compare the two (which will consume them), but to keep the bottom one ... so you use OVER and have ( mystery guess-number mystery )

: GUESS ( u1 u2 -- u1 "{response"} ) OVER ... ;

... now, if there are equal, you are done, ...

: GUESS ( u1 u2 -- u1 "{response"} )
CR OVER 2DUP = IF
." CORRECT!" 2DROP DROP
ELSE
...
THEN CR
;

But you don't need to retain the u1 if they are equal, so it's better to postpone the OVER until you find out they are not equal. And if they are not equal, do an unsigned compare, and that will say whether the guess is too low or too high ...
... Now, ( guess-number U< mystery ) if it's true, you are too low, if it's false, you are too high ...

: GUESS ( u1 u2 -- u1 "{response"} )
CR 2DUP = IF
." CORRECT!" 2DROP
ELSE
OVER U< IF ." TOO LOW!" ELSE ." TOO HIGH!" THEN
THEN CR
;

Untested, so if the TOO HIGH and TOO LOW answers are the wrong way around, convert that to U>