ROMable Forth

[BillO]

Garth, in the General Discusions forum, wrote:

...In fact if you put a Forth kernel on your 6502 machine...

Is there a compact ROMable version of Forth?

[GARTHWILSON]

Hmmm... well, the public-domain FIG-Forth source is available at http://6502.org/source/forth65.zip . It's written out for a very basic assembler with no macro capabilities. I wondered what they were doing with variables since it might make a difference whether the kernel is in ROM or RAM. From a quick look, it looks like they're putting the system variables' data space in ZP RAM near address 0. Since that data space is separate from the code space, it would work with either RAM- or ROM-based systems, although you might still want to move it out of the precious page-0 space.

This issue of the variables' data space is the only difference between ROM and RAM versions that comes to mind offhand. The variables' headers (which FIND uses to find their addresses during compilation or interpretation of the input stream), as well as the small code that determines their runtime behavior, can go in either ROM or RAM, but the data itself must go in RAM, meaning it can't be mixed in with any headers and code in ROM.

What has kept me from publishing my own '02 Forth is that there are still a lot of fragments left that one particular company could claim a copyright on. A couple of months ago I started to look more seriously at taking care of those and neatening up the source code, and more-or-less decided that because of the size of the project, it would be better to spend my time on making my next computer with the '816 and further improving my very extensive '816 Forth instead. I have sent the '816 Forth out to several people, and one of them used it quite a bit.

I know, I know, if we're going to keep plugging Forth, we really ought to have something a little more turn-key for beginners. That, however, almost means either bundling it with working hardware that we supply, or publishing a version that is for specific hardware that's already available, whether Daryl's SBC-2 with a certain LCD, or something like that. As it stands now, the newbie would have quite an uphill battle to learn a system that he cannot see working yet, in order to make the necessary changes so it will work on his own hardware. There are plenty of Forths for PCs though, from very low-end to very high-end, if you want to tinker with it before trying to get it going on custom hardware. Samuel has some recommendations at viewtopic.php?t=1358&start=10 and viewtopic.php?t=1358&start=17 (both in the same topic). When you finally move to Forth on your own 6502 computer, you will normally have more freedom than you would on the PC.

As far as it being compact, Forth makes extremely efficient use of memory. I think I've heard of kernels themselves being as little as 2KB, but it's sure nice to also have a lot of the non-basics there ready to go, so you don't have to compile them every time you want them. After the kernel is in place, I've seen where someone won a competition by making a very full-featured screen editor in only 1KB of source code. The compiled code would take less than that. A screen editor is like a text editor for Forth source code, organized in 1KB blocks, 16 lines of 64 bytes each. I personally don't like screens. Although they have a couple of advantages, I think they're mostly very outdated and it works better to use a nice programmer's text editor and text files for your source code.

Keep hammering on us and someday we might get you a turn-key "starter kit".

[dclxvi]

One other possibility is to port eForth. According to one its authors this has already been done, but a quick web search turned up empty for me. Anyway, eForth is specifically design to be quickly ported, as it has only a couple dozen primitives (the rest is basically DW directives). The downside is that its not geared toward performance; the idea was that you rewrite high level words as primitives once you got it working. I took a shot at porting the primitives, and I could post/email/what-have-you if anyone's interested/adventurous. They are completely untested.

[kc5tja]

eForth is the closest thing to a radically updated (read, far more ANS-compliant) FIG-Forth; currently maintained by Dr. C. H. Ting. Right now, most folks in SVFIG tend to use SwiftForth from Forth Inc., eForth, or ColorForth.

[electronicresourceguy]

BillO wrote:

Is there a compact ROMable version of Forth?

I have been working on exactly that for the last 2.7 (3 in April) years.

GARTHWILSON wrote:

What has kept me from publishing my own '02 Forth is that there are still a lot of fragments left that one particular company could claim a copyright on.

That is also my concern. You may, however, be referring to code that you developed for your Automated Testing System. If not, can you clarify what the issues might be. I started with the FIG Forth code that I downloaded from this site. I then re-wrote it about 20 times, making several major changes to the architecture, especially in the data stack. This means that most primitives do not look even remotely close to the original, but higher level words bare a striking resemblance to the original.

GARTHWILSON wrote:

I know, I know, if we're going to keep plugging Forth, we really ought to have something a little more turn-key for beginners. That, however, almost means either bundling it with working hardware that we supply, or publishing a version that is for specific hardware that's already available, whether Daryl's SBC-2 with a certain LCD, or something like that. As it stands now, the newbie would have quite an uphill battle to learn a system that he cannot see working yet, in order to make the necessary changes so it will work on his own hardware.

One of my design goals was to eliminate this problem. As it stands now, The Forth kernel is completely ignorant of any hardware as I want to use the same kernel regardless of what hardware is attached.

Forth really only has two methods for interfacing to the world, get a character (KEY) and put a character (EMIT). I designed my system to use a vectored forth call for these routines. By default, KEY executes "0" and EMIT executes DROP. This is sort of an "I here nothing, I say nothing!" Just like Unix dev/null. These vectors are changed at first boot time with Forth code written in a boot rom area. You get to develop your preliminary I/O code in Forth, and can redevelop in ML if necessary.

This boot rom can be separate from the kernel rom. I have even been known to put a ram chip in a wire-wrap socket with a 5V regulator attached to a 9V battery clip and a pull-up resistor for the write line. Instant rom simulator. I would drop it into a zif socket attached to an Atari for programming, then move it to the zif socket in the breadboard computer. Pop the reset button, and away we go!

GARTHWILSON wrote:

As far as it being compact, Forth makes extremely efficient use of memory. I think I've heard of kernels themselves being as little as 2KB, but it's sure nice to also have a lot of the non-basics there ready to go, so you don't have to compile them every time you want them.

My goal was to fit inside of 8k. The kernel is 7k including a full assembler for 65C02. The remaining 1k is for the boot rom. This makes for rather simple address decoding, rom is 1/8th of memory and boot rom is 1/8th of rom.

dclxvi wrote:

The downside is that its not geared toward performance; the idea was that you rewrite high level words as primitives once you got it working.

In order to fit into this space, I did have to make some tradeoffs. But you can always define new primitives for performance as needed. If you have ram shadowing the rom area, you can copy rom to ram and then patch anything that you want. Atari XL and Xe computers had a rom2ram program to do just that. It was always fun to then load in alternative character sets. One of the main reasons for this program was to then be able to load the old 800(non-xl) rom code in so that older programs could run.

GARTHWILSON wrote:

Keep hammering on us and someday we might get you a turn-key "starter kit".

That will always be the dream. I too am concerned about the copyright issues. Garth, please help us work these out. I would like to share this work since I have put so much into it.

[ptorric]

maybe inspiration can be found in forth dimension, check vol 4 num 4
"ROMable Forth With Separate Headers Robert H. Hertel 4 4 9 ROM"
it can be found here http://www.forth.org/fd/FDcover.html

[kc5tja]

KEY can reliably return 0 as a valid character, particularly if you're using the console interface to receive a binary file. You really ought to be using KEY? to query whether or not a byte from standard input is available or not. This also significantly benefits the performance of multitasking implementations, as KEY is simply:

Code: Select all

: KEY   BEGIN PAUSE KEY? UNTIL (KEY) ;

Some systems also implement EMIT? to see if the output device is capable of receiving data. It's probably a good idea to implement this word too, for similar reasons.

[electronicresourceguy]

kc5tja wrote:

KEY can reliably return 0 as a valid character, particularly if you're using the console interface to receive a binary file. You really ought to be using KEY? to query whether or not a byte from standard input is available or not. This also significantly benefits the performance of multitasking implementations, as KEY is simply:

Code: Select all

: KEY   BEGIN PAUSE KEY? UNTIL (KEY) ;

Some systems also implement EMIT? to see if the output device is capable of receiving data. It's probably a good idea to implement this word too, for similar reasons.

Actually, I have implemented KEY like this:

; KEY [ -- sb,da:da ] Gets input character.
; sb: Key value.
; da: Key status - true if key availale, false if not.

The status is returned along with a byte if it is available. I did recognize that you could get a 0 from the input stream. I have not implemented round robin but I have implemented zero overhead interrupt support. According to Garth, this method has worked well in his embedded projects. I have enjoyed this feature as well under simulation, but am looking forward to seeing what can be done with actual hardware.

I have also considered the check to see if a write to output is necessary, but for now I believe that since you are writing the "driver" yourself, that retry functionality can be embedded in the driver.

[kc5tja]

electronicresourceguy wrote:

Actually, I have implemented KEY like this:

OK, as long as there is some means of identifying when (in)valid data exists.

Quote:

I have not implemented round robin but I have implemented zero overhead interrupt support. According to Garth, this method has worked well in his embedded projects. I have enjoyed this feature as well under simulation, but am looking forward to seeing what can be done with actual hardware.

It impacts Forth runtime performance, but has the advantage that it makes writing event-driven software in high-level Forth somewhat easier. I think you'll find its expressivity beneficial in real-world applications.

Personally, I wouldn't use zero-overhead interrupts because I prefer more control in my code, and I'm willing to pay the price in high-level expressivity. Plus, since I prefer subroutine-threaded Forth implementations over direct-threaded, the distinction between CODE and colon-definition interrupt handlers tends to fade away with only minimal impact on readability anyway.

Speaking of which, I really should complete my Kestrel Forth one of these days. Hehe. Having too much fun trying to solve my HDLC implementation for my optical transceiver project at the moment, though.

[electronicresourceguy]

kc5tja wrote:

It impacts Forth runtime performance, but has the advantage that it makes writing event-driven software in high-level Forth somewhat easier. I think you'll find its expressivity beneficial in real-world applications.

Here is the overhead in my NEXT for the zero overhead implementation:

Code: Select all

pNEXT                       LDY zINT		; Check for interrupt.
                            BNE pNEXT2		; Jump if interrupt has occured.

As Garth said in his article, you normally have an LDY #0. This is now a value loaded from ZP. +1 cycle. And the branch is not taken unless there is an interrupt to service, so I believe that is another +2 cycles.

Either way, I have had to make some design choices since my main goal was size over speed. I have also been working on a new NEXT method that will reduce cycles from 40 to about 23. If I can get that to work, I get a lot of performance back. Still should be faster than BasicStamp.

My overall goal was to have something that was very plug and play:
CPU, RAM, ROM, simple address decoding, and the ability to interface to anything and everything. I have some chips that I bought at RadioShack about 20 years ago that I would still like to use, and the basic stamp just didn't cut it. I just wish that I would have found Forth 15 years ago!

[GARTHWILSON]

Quote:

Quote:

What has kept me from publishing my own '02 Forth is that there are still a lot of fragments left that one particular company could claim a copyright on.

That is also my concern. You may, however, be referring to code that you developed for your Automated Testing System. If not, can you clarify what the issues might be.

I have no trouble giving away my ATE code. It was not copyrighted, and although the company I did it for used it for many years after I left, I'm not sure they're using it anymore. Where there's a slight chance of a problem is that we started with a 6502 Forth metacompiler that ran on the PC, and that came from a supplier who started with the FIG-Forth public-domain material but made their own modifications to make it Forth-83, changing, IIRC, the way it branches (which wasn't necessary, and they made it less efficient), does floored division, DOES>, and a few other things. It would not be very complicated to change those parts that aren't either public-domain or my own doing-- I just have to go through a lot of code and find them all.

What would take more time is writing it all out in a form that an assembler, instead of a metacompiler, could use. If I distribute it, it will have to be in a form that can be modified and re-assembled without the overpriced PC-based metacompiler which the company quit selling when I pointed out all the sinkholes (not mere pot holes!) in Forth Dimensions magazine. (I didn't give the name of the company in the article, but it wasn't hard to figure out.) The bugs became more and more severe as my overall code grew to 10,000 lines. (And this wasn't like the FIG source which only has one word per line, either.) Since the metacompiler itself was a black box, I could not get into it and fix it like you can in Forth. I figured out some work-arounds but they were running out of gas and I pretty much decided I'd have to re-write it for an assembler anyway even for my own use.

Quote:

I started with the FIG Forth code that I downloaded from this site. I then re-wrote it about 20 times, making several major changes to the architecture, especially in the data stack. This means that most primitives do not look even remotely close to the original

For many primitives, if you had a contest to write them the most efficient way, all the good entries would probably be identical, unless you made the stack grow up instead of down, or something like that. Those of course are not the ones where one has to be careful not to infringe on copyrights, since Bill Ragsdale did it first and made it public domain.

Quote:

In order to fit into this space, I did have to make some tradeoffs. But you can always define new primitives for performance as needed.

This was a nice thing I found about the '816 when I was writing my Forth kernel for that (which is entirely mine, unlike my '02 Forth kernel). In many cases, primitives on the '816 were not only faster than secondaries (as expected), but took less memory, and were even easier to write, than the secondaries. It was a nice surprise, considering most '02 fans who aren't familiar with the '816 yet tend to view it as more complicated and difficult. As a result, I have hundreds of primitives. Many of the words that were secondaries in '02 Forth were totally practical now to turn into primitives on the '816. This improves the performance not just in the obvious way, but also in that NEXT runs far fewer times to get a job done, as do nest and unnest.

Quote:

Quote:

but I have implemented zero overhead interrupt support.

It impacts Forth runtime performance, but has the advantage that it makes writing event-driven...

The impact on runtime performance is extremely small-- basically negligible.

Quote:

I wouldn't use zero-overhead interrupts because I prefer more control in my code, and I'm willing to pay the price in high-level expressivity.

I use both the zero-overhead Forth ISRs and assembly-language ISRs. The Forth ones can still have assembly mixed in. The interrupts that need the fastest response of course get assembly, and they get priority. But if there's a chance that they will need to be able to report an error condition and ask for the user's preference as to how to fix it, the assembly-language ISR can have a Forth ISR handle the displaying, the key input, and other things that are far easier to do in Forth.

Quote:

Quote:

I know, I know, if we're going to keep plugging Forth, we really ought to have something a little more turn-key for beginners. That, however, almost means either bundling it with working hardware that we supply, or publishing a version that is for specific hardware that's already available, whether Daryl's SBC-2 with a certain LCD, or something like that. As it stands now, the newbie would have quite an uphill battle to learn a system that he cannot see working yet, in order to make the necessary changes so it will work on his own hardware.

One of my design goals was to eliminate this problem. As it stands now, The Forth kernel is completely ignorant of any hardware as I want to use the same kernel regardless of what hardware is attached.

Forth really only has two methods for interfacing to the world, get a character (KEY) and put a character (EMIT).

KEY and EMIT are primarily for human I/O, which is only a minor part of my workbench computer's I/O; and even then, there still needs to be code to take care of the details of how to feed data to the LCD, scan the keypad, bring data in from a UART, etc.. If the newbie doesn't have those written and debugged already, he'll have quite an uphill battle to get it all going. It would be nice if he could start with something that works right out of the box-- plug it in, turn it on, see "Ok { 0 }", and, before he's out of page 1 of the tuturial, be typing in something and seeing results.

Quote:

Quote:

Keep hammering on us and someday we might get you a turn-key "starter kit".

That will always be the dream. I too am concerned about the copyright issues. Garth, please help us work these out. I would like to share this work since I have put so much into it.

I don't know about copyright issues other than to get the parts out of my '02 Forth that the metacompiler company might be able to claim any copyright to. If you're talking about supplying a turn-key setup to make it easier for others to jump into Forth, I don't know the perfect answer, but if there's more interest now, it does help motivate me. Should we start with Daryl's boards? I have jury duty this week, then a trade show to get ready for, then a business trip, so I probably can't do anything on it this month, but hopefully soon-- again, if there's interest.

Quote:

Still should be faster than BasicStamp.

The '02 ITC Forth averages about 12,500 primitives per secocond per MHz. My '816 does about 31,000 per second per MHz. If that's not enough, you can, at any time, jump into assembly at any time with the assembler that's part of Forth and can assemble a little piece of code in a fraction of a second instead of requiring a long cycle to re-compile the whole application. Another task that may be running at the time does not need to be interrupted.

[electronicresourceguy]

GARTHWILSON wrote:

KEY and EMIT are primarily for human I/O, which is only a minor part of my workbench computer's I/O; and even then, there still needs to be code to take care of the details of how to feed data to the LCD, scan the keypad, bring data in from a UART, etc.. If the newbie doesn't have those written and debugged already, he'll have quite an uphill battle to get it all going. It would be nice if he could start with something that works right out of the box-- plug it in, turn it on, see "Ok { 0 }", and, before he's out of page 1 of the tuturial, be typing in something and seeing results.

For me, writing the code to interface to an LCD or to drive a scan interface for a keyboard (that I have also had for 20 years) is what I am most looking forward to.

The system as it stands works with the Michal Kowalski simulator. This is working as if you already had a working UART connected to a dumb terminal.

To write code to support an actual UART should not be too difficult, I hope. Again, something that I am looking forward to. After that interface is up, you would have a functional interactive development environment to bring up any additional hardware that you connect. It would sort of be a Forth Stamp, allowing connection to just about anything.

[GARTHWILSON]

I really should do a YouTube video of my interactive embedded development. We have a digital camera that can do video, but I guess we'll have to find and learn some video-editing software. I had an article about this interactive embedded delvelopment in FD XVI-1 (May-June '94). Until they see it, people can't comprehend how simple it is to get instant turnaround between writing a piece of code on the PC and actually running it on the target 6502 computer connected by an RS-232 line.

I use the PC for the text editor for the program and to keep the source files on disc; but you could use any computer that has a text editor that allows marking a block in the text and sending it over the serial port to the target (6502) computer. No special software is needed for the PC-- no TSRs, no assembler or compiler (once the Forth is in the target's ROM), no OS or BIOS tricks etc.-- just the text editor. To write a new addition to the code, you just put it in the text editor in the PC, mark it as a block, and "print" the block. The text editor isn't even backgrounded, let alone suspended or exited, even it you were doing it on an old Kaypro computer. (Myself, I usually use DOS on a PC, but I can also use my HP handheld computers with the HPIL-to-RS232 interface adapter.) The target takes it in, and does its own interpretation, compilation, or assembly as appropriate, on the fly. As far as the PC is concerned, the target is just a serial printer. As far as the target is concerned, you just have an RS-232 keyboard and you're a lightning typist who never makes a mistake. As long as there's even a minimal display on the target (I have a 16-character LCD), there's no need for the RS-232 to be bi-directional. Sometimes I've had the target doing something else at the same time while I'm feeding it new instructions from the PC, instructions that change parameters on the other process while it's happening, so I can experiment and tweak things without pausing the operation every time I want to make a change. It's way more interactive than any BASIC I've seen.

[BigDumbDinosaur]

I'm not at all familiar with Forth, despite it having been around for eons. However, when I get my POC machine scaled up beyond the toy concept and have it to the point where it can chatter with a disk or similar mass storage, I may look at trying out Forth on it.

[GARTHWILSON]

Quote:

I'm not at all familiar with Forth, despite it having been around for eons. However, when I get my POC machine scaled up beyond the toy concept and have it to the point where it can chatter with a disk or similar mass storage, I may look at trying out Forth on it.

Browse the Forth forum here to get an idea of what it is. I made a long list of the main points here-- strengths that are beyond most programmers' dreams-- but it was looking too much like a spirited infomercial so I removed it. I can still move it back if you still want it.

The old standard book for starting Forth is called just that, "Starting Forth," by Leo Brodie who apparently was quite a comedian. It has been out of print for a long time, but there have been various efforts to put it online. One is at http://home.iae.nl/users/mhx/sf.html . Unfortunately the original cartoons have been replaced with ones that aren't as entertaining, and I see they still discuss some rather outdated methods; but you'll still learn plenty. [Edit: Forth, Inc. has it online now with the original cartoons, and with updates for ANS Forth.]

Samuel also posted a link to the follow-up book "Thinking Forth", http://thinking-forth.sourceforge.net/t ... -forth.pdf , but I just tried it and it's not working, at least not at the moment.