Actually, a 65802. I guess I better check into that more when I go to more than bank 0. I was able to be kind of careless, I suppose.

I just finished this book. I found it easy to read and the examples were clear. The problems at the end of each chapter (with answers) were a great way to help explore the topics.

I would recommend this to anyone just starting out with Forth.

Now I intend to dissect FigFORTH with the hopes of understanding its inner-workings better.

Daryl

I remember my own journey into Forth, but I would be interested to hear someone else's thoughts (yours in this case) on various aspects of Forth while you're still pretty new to it, to find out how we can be more effective at helping others to successfully get into it.

I spent two+ years on college using an HP-41CV so the whole stack-based math was easy for me to grasp. The structure is also pretty easy - you just have to keep the "backward" order in mind. The IF ELSE THEN structure makes sense, but as someone commented elsewhere, the word THEN could be better named (too much time in BASIC and C).

One principle that has caused some internal struggle is the idea of keeping word definitions short and having a lot of them. I struggle with that as I see Forth could be spending as much time moving from word to word as it does performing the word's operation. Kind of equivalent to having too many JSR's in your assembly language code. That's one reason I gravitate towards assembly for most of my code (6502 and AVR).

Since the disk I/O in FigFORTH does not work as is, I implemented the RAM disk workaround for use in the Kowalski Simulator. But without an editor, it's pretty limited. I also find the Simulator really loads up my CPU, with the internal fans all running up to full speed while the Simulator is running. I switched to a Windows Forth for the bulk of the Getting Started book work.

I will play more the FigFORTH on my SBC-4P. At least on that, I can exit to the monitor and look "under the hood" at what's going on.

I plan to spent more time with console and disk I/O operation to get a better feel for how to best use those as well.

I'm not sure if I should plan on using the "screen/block/buffer" method or instead plan on implementing an "include text file" approach that more modern Forth's seem to use. Again, I have a lot more research to do.

Eventually, I may try some hardware I/O (SPI, RS-232, Ethernet, Video) along with some IRQ experiments.

I would encourage anyone who is curious to explore Forth for themselves. There are several free Forth environments available along with free documentation. The biggest investment will be your time.

Daryl

That helps. I started with HP4-1cx experience, and you've no doubt seen my related pictures. Forth of course takes the stack thing much further.


Yeah, it's
<Is condition true?>
<IF so, do this>
<ELSE, do that>
<THEN when you're done, pick up here>


I have a bit of an issue with some people's insistance on keeping them that short too, the major issue being that it does not really make things clear if you factor out things that you can't even give a descriptive name. And yes, it does cut performance a bit, and if you're compiling with headers, all those headers take up a lot more memory too. I wrote an article on Forth readability for Forth Dimensions when the magazine was in print. One man responded with a letter to the editor saying my definitions were entirely too long. Later however, he and I corresponded on another subject, and he sent me some code where one of his definitions was about 100 lines!


You can use it where you need the speed or control over something like the interrupt-disable processor flag, but you'll develop the application much faster and with very little if any speed penalty if you do most of it in Forth and use assembly only for a few small critical places. You can even put a little assembly inside a colon definition with Forth before and after it (if you don't want to factor it out and make it a primitive, which again I don't think is always justified).


I worked with screen files for a little while and it drove me nuts. Inserting lines and trying to move stuff around are the first things that come to mind. I'm all text source code files now. Screen files have a couple of advantages, but more serious disadvantages. I can see why they were used in the early years when technology was more limited, but there's not really any compelling reason to anymore.


My article on servicing interrupts in high-level Forth with zero overhead is at http://6502.org/tutorials/zero_overhead ... rupts.html .

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

I've already read that one and will use it as reference when I get to that point!

thanks!

Daryl

OMG, I should read old threads more accurate ... trapped into this while porting Garth's Forth to C64 SuperCPU with a real 65816 ...
The long absolute variant went not into my mind ...

I found three places: ?EXIT, ?LEAVE and the mentioned 0BRANCH.
The way I solved this is based on reordering the code. I just used the faster 0,X for the (small, IMHO) cost to duplicate INX_INX. The reuse of code has been reversed. Considering 0BRANCH, BRANCH's CFA points to the branch code of 0BRANCH and in that way it's not a real primitive anymore from structural point of view.

(originally in C32 format, I transcoded the source into a Tass64 format)





Johann