I would like to create a Forth for the 6502. Right now I am thinking that I would like to make it as full as possible, without worrying about how much space it takes in ROM. Is there a list of Forth words I could try to include? Even if there is no one standard Forth, it would be nice to include just about everything a Forth programmer might ever use so that as little as possible has to be added.

Anton Ertl is maintaining several web pages related to the discussions of the newest standard at http://www.forth200x.org/

I am doing a similar project for my processor, but I am starting to wonder how much is too much. An earlier standard like Figforth has some idiosyncrasies and obsolete words, but is understood by most experienced programmers. The newer standards have new and deprecated words as well, including some extensions that may or may not be useful in a very small system, like floating-point.

You'll probably want to include this and this, and at least parts of this and this.

Forthers are an eccentric bunch (from the posts I've read on Usenet and elsewhere), and seem to take great delight in customizing their own versions and arguing about what customizations are worthwhile, so maybe you could pick a popular and well-respected version like Dr. Brad's CamelForth, and implement the same dictionary that he has. That last link is chock-full of useful links.

Mike

[Edit: Here is a nicely-commented .asm for the z-80 that you may be able to translate.]

Before the ANS standard, people were complaining that there's no effective standard (I thought the '83 standard plus a lot of things in common usage and documented in Starting Forth, Thinking Forth, Forth Dimensions, and other publications were enough of a standard), and then when the ANS standard came along, it seemed to give Forth more credibility outside the inner circles. I've added some things from ANS to my own '02 and '816 Forths, but I don't like being confined to some parts of ANS. Fortunately, in his book "Forth: The New Model," Jack Woehr said it's not the committee's intention to force anyone to comply. My Forths take about 24K of ROM, including assembler and loads of other things; but in the '816 Forth, I did it in modules, made of INCLude files, so you can easily leave out an entire set if you don't need it.

It would be impossible, impractical, and unnecessary to include everything though. One of the nice things about Forth is that the user can easily get under the hood extend the language himself; so if you want a new program structure or data structure that was not in the kernel, you can easily make it. Want time and date and alarm functions? You can make them (assuming the hardware is up to the job, meaning there's crystal control of timing and so on). (My Forths do have those, BTW.) Whatever you want, you can make it. It doesn't have to be part of the kernel to become part of the language.

I'm sure I'll be adding to this, but I'm in a hurry right now.

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

Ok, a little more time to write now. To give ideas for what you might (or might not) want to include, what I have in Forth in ROM is:

• many hundreds of primitives, particularly in the '816 Forth. I have seen countless topics on making NEXT (and nest and unnest) as fast as possible; but with more things defined as primitives, the number of times NEXT has to get run to get a job done is dramatically reduced, so you get much more effect on performance. In the case of the '816 which handles 16 bits at once, primitives not only ran much faster than the secondary (ie, colon definitions) counterparts (as expected), but possibly surprisingly were even shorter and easier to write. I show an example here.
  
  
• Eight prioritized interrupts are allowed for service in high-level Forth, and eight in assembly. ISRs can be installed and deleted on the fly (and installation includes sorting them by priority, so higher-priority sources get polled first). Any enabled potential interrupt sources that are to be serviced in assembly get polled before the ones that are to be serviced in high-level Forth. Aside from the polling, there is very little overhead for servicing interrupts in high-level Forth. On the '02 Forth there is no overhead; but it does not lend itself as well to the efficient dual-list prioritizing method as the '816 does, so it takes a little more programmer effort to install and delete ISR routings. I describe how to do it in my article on 65c02 interrupt service in high-level Forth, with zero overhead.
  
  
• triple- and quad-precision arithmetic, although I have not implemented the trig, log, and square-root functions in these
  
  
• For standard precision scaled-integer, there are trig, log, and square-root functions.
  
  
• time and date functions, including alarms, with alarm installation and deletion words. There can be many alarms in the queue at once, sorted by due time of course, and each one has associated with it the CFA of the word to execute when it comes due. Alarms is one of the methods of simple multitasking I describe in my article on simple methods to do multitasking without a multitasking OS.
  
  
• more program-structure words, for example RANGE_OF which can be used in a CASE statement so one of the cases could be for example 40-49, without having to have an OF for each number in the range when those will get handled the same anyway. There's an example at viewtopic.php?f=2&t=2311&p=24593#p24593 .
  
  
• words to handle all the hardware, including ports, LCD, keypad, A/D and D/A converters, etc.
  
  
• extra string-manipulation functions
  
  
• extra debugging functions (although it turns out that I don't really use them)
  
  
• assembler which uses the normal order of mnemonic then operand, although there's still no parsing; so for example you could have LDA# which lays down the op code, then you calculate your operand and compile it with C,. There's minor support of branching labels since it's really only for Forth primitives, runtimes, subroutines, and assembly-language ISRs, not whole applications. Since it runs under Forth, it automatically has macro capability.

I don't do floating-point. I have found, with practice, that virtually everything can be done with scaled-integer, as discussed in the introduction to my huge math look-up tables, here.

Round-robin cooperative multitasking is fairly easy to do on a 6502 in Forth as long as you don't need many tasks running at once. Six would probably be a maximum safe number to plan on. I haven't needed to do it, as I use the methods in my article.

There are still countless things I use frequently that are not part of the kernel, like I²C and SPI and running my PIC programmer; but OTOH there are things in the kernel that I have probably never used, like the random-number generator. So I'd say have a good set of options but have much of the stuff beyond the basics in separate files that could be loaded if desired.

_________________
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 am looking forward to the possibility that you'll be able to post your kernel sources in a public forum one of these days, Garth.

Mike

Actually the ANS Forth document (draft proposal 6 available here) is a pretty good starting list of Forth words. CamelForth implements only the Core word set. You'd certainly want to add Double-Number, Exception, Facility, File-Access, Programming-Tools, Search-Order, and String word sets. You might also want to add Floating-Point, Locals, and Memory-Allocation. For compatibility with older Forth applications you can add the Block word set.

And yes, do look at what the Forth200x group is doing. I blush to admit that I haven't been following their work, but I'm sure they have some nice additions.

Incidentally, if you want a "kitchen sink" Forth to use as a model, take a look at gForth. I believe it has implemented every bit of ANS Forth, and I expect they're also implementing all the proposals for Forth 200x.

_________________
Because there are never enough Forth implementations: http://www.camelforth.com

Note that if you're aiming for compliance with the ANS spec, that the File-Access word set requires implementing the Block word set, but that it doesn't require the Block word set to be defined usefully. If you declare that there are no valid block numbers then the implementation becomes trivial.

Having just gone through the same procedure for my own version of Forth (Tali Forth for the 65c02, you'll find the source code with a search in the forums), my experience was that you should first get the command loop going (ABORT, QUIT, ACCEPT, >IN, PARSE, PARSE-NAME, FIND; do yourself a favor and use PARSE-NAME instead of WORD) and them some tools for debugging (DUMP, .S). Once you have that going, you can sit down with a list of the ANS 200x standard and simply code word after word in the dictionary. Some are going to be trivial (DROP), others a pain (SM/MOD). I found it helpful to keep a list of what I have coded, what the name of the routine is in my assembler code, which zero page entries and registers it uses, and if it is native code, compiled or Forth.

Gforth, mentioned by Brad, is useful to figure out what the output of stuff should be, especially when you get to the bizarre parts of the language such as loops. What makes those parts harder is that the defintions changed from Fig to ANS Forth, so you can't use the old source code as a reference.

It's on my list of things to put on my website. It would be best if I could port it to a SBC someone (Daryl?) sells so the newbie could have something operational right out of the box, a turnkey solution. The 6502 stacks treatise is the next major thing to go up on the website. I've been talking about it for over a year but I have not gotten much time to work on it. I did get several pages HTML-ized in the last week which felt good because it had mostly been in one long file that was becoming very unwieldy. [Edit: It's up, at http://wilsonminesco.com/stacks/ .]

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

We could try porting it to POC V1.1, or perhaps POC V2.0. Although I don't have RAM beyond 64K in V1.1, there should be more than adequate space for a Forth kernel. There are also about 160 or so uncommitted direct page bytes that could be used as the data stack. It shouldn't be much of a task to get the kernel to coexist with the resident M/L monitor (in ROM).

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

That should work well, BDD. Is the M/L monitor in ROM? If so, it might be good to just make them separate ROMs and use them one at a time. The Forth kernel has all the same functionality plus a load more, except that if I add a file system for something like SD card, I would need help for that. That's an area I have not touched except for doing a FAT-less file chain in battery-backed RAM for a product in the late 1980's.

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

The monitor is in the same ROM that has the BIOS but is logically separate, meaning the monitor calls BIOS services for I/O and such, but the BIOS has no awareness of the monitor.

If control is given to a RAM-resident program (e.g., a Forth kernel), the monitor is out of the picture except for it being the default target of a BRK or COP, should one be encountered in the running program. The BIOS provides TIA-232 and SCSI I/O (all I/O being interrupt-driven), maintains an uptime counter, and provides a number of services that must be explicitly requested via JSRs. The front ends of all interrupt handlers are vectored through low RAM so they can be pointed elsewhere—the BRK and COP handlers are pointed to the monitor following reset.

So what I am saying is the Forth kernel can be run in RAM at any convenient address, subject to staying out of the way of the BIOS data structures, with about 51K of free RAM for code and data. If the goal is to ROMify Forth and eliminate the monitor (ROM is 8KB, so it's not possible to have Forth, monitor and BIOS all sharing the same ROM), then the ROM has to include enough of the BIOS to provide essential I/O services.

As V1.1 supports SCSI I/O, the Forth kernel could include extensions to provide mass storage to user programs. SCSI disks are readily available from many sources, so there's no reason to scrap that and replace it with some other type of storage. I'm not a Forth user, so I don't know enough about it to know if the core has words to read and write external storage.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!