6502.org

While reading up on the technical guts of Forth (mainly to understand what the hell FIG Forth is doing), I came across this series of articles by Bradford J. Rodriguez: http://www.bradrodriguez.com/papers/moving1.htm: Moving Forth. It discusses the various design decisions (ITC, DTC, STC, etc) and their trade-offs, and why things are done the way they are. Includes some refences to FIG Forth, including what people do different these days. The top-level link is http://www.bradrodriguez.com/papers/index.html

Thank you for the link! I hope it was useful.

- Brad Rodriguez

I certainly have enjoyed reading the first two. They have cleared up a couple of concepts for me. I look forward to reading the whole series. I used to subscribe to TCJ, and would keep all issues. However, a few moves ago, I just had to part with a whole slew of those old magazine. I certainly regret that decision periodically, and am glad to read your articles on line.

Welcome to the forum, hope you'll engage. I am certainly interested in getting forth running on a 6502, but my interest is more from the perspective of a dabbler. My interests lie more to old computer architectures and microprogramming. So I am interested in getting HLLs running on my M65C02 processor core.

Well, I'm essentially a newbie where the 6502 is concerned, but I'll be happy to answer any questions about Forth (the language or its implementation).

I confess to being surprised that so many people are still using fig-Forth. I don't have the time right now to port CamelForth to the 6502, but if someone else wants to give it a go, I'll try to help with suggestions. It only has about 70 assembly-language primitives, so it's fairly easy to port.

Hi Brad,

Thanks for the articles, they really help understand what is going on under the hood. Yes, FIG is still around, though I've been using gforth to learn the basics (runs on my MacBook, runs on Linux, runs on Android ...) and the differences in syntax are pretty brutal. On the other hand, stuff in the ANS Forth standard like ENVIRONMENT? seem to be overkill if you are trying to fit Forth in 8 kb on a 6502 machine. Sigh.

Today's minimalist tip:

: ENVIRONMENT? 2DROP 0 ;

is technically ANS-compliant. (It returns a "false" result for all environment queries.)

If it can run on an 8051, it can run on a 6502!

I've been writing ANS Forths for the 65C02 (ITC) and 65816 (STC) cribbing bits and pieces from your code and few others. Still in development but not far off. Now I have my W65C134 system working its become the initial test platform.

Splendid! That's what it was written for.

Incidentally, I have a standing offer to anyone who ports CamelForth to a new CPU -- I will either host the download at camelforth.com ("contributed" downloads), or if you wish to host it somewhere else, I'll link to it ("offsite" downloads). And I'll be happy to post a news item to announce any new Forth implementation that's made available.

I didn't realize you were here. Your whitepapers were incredibly helpful to me with implementing Forth for the PET. http://pettil.tumblr.com . Only 15 clocks for NEXT! Thank you!

Charlie

15 clocks for NEXT? Impressive!

Until I read your web page I thought I was the only person who used a Pearson hash (in my case, for error checking on a flash memory device). And I'd never heard of a Bloom filter before; I'm reading that Wikipedia page now.

If you'd like, I'll post a link to your page on the CamelForth "news" page.

PETTIL is really not ready for prime time like that. I don't have working CREATE : FORGET yet, What's working are the inner and outer interpreter, and a whole mess of prematurely optimized words. I did a lilttle benchmarking once vs. Blazin' Forth on the C=64 (both in the Vice emulator) and the results were promising. Screen shot photos at http://www.flickr.com/photos/chitselb/s ... 696682160/

I've been blocked by BLOCK these past couple years so there's no virtual memory yet. Somehow I got wrapped around the idea that for it to be a Forth, it had to be Forth-83 compliant, or even ans-compliant. And that meant having BLOCK work just like in Leo Brodie's "Starting Forth" book, even if the only hardware available were cassette tape.

I recently (about an hour ago) had an epiphany that the Forth way is to get the job done on the available equipement, and for early micros, that includes firmware. New mass storage design would involve storing source code as native sequential files on the tape, so they can be created/edited on foreign platforms (e.g. Linux), and leveraging the PET screen editor to perhaps append to an already-open SEQ file. Code will still be done in screens, but with a formfeed character in the sequential file between the screens , etc... BLOCK will be implemented, but it will return -1 or some such to indicate that there is no such virtual address. And of course it will work for a PET with a disk drive.

Sure, just let me know when you're ready for an announcement.

Are you aware that BLOCK is an optional word in ANS Forth? Blocks vs. files is one of the oldest debates in Forthdom; the ANS committee compromised by specifying the behavior of both, but requiring neither to be present.

I would enjoy more traffic and participation on PETTIL. It's open-source. The primary design goal of PETTIL is optimal use of miniscule hardware resources to improve user experience. And having a course on which to play some code golf. Being complient with a standard (any standard reallly) seemed like a good idea so others could use it. Not that I'm expecting hordes of users.

The primary design objective of camel seem to be portability and ANSI standard compliance?

Correct. That, and use on embedded systems, which is why I gave no attention at all to block or file storage.

Originally CamelForth was an educational project for The Computer Journal, to illustrate how to write Forth kernels. It has since taken on a life of its own, as a lightweight "traditional" Forth implementation.