Australian engineer [John Catsoulis] developed a small module called the Scamp2 dedicated to running Forth. The focus of his Udamonic project was not only to highlight Forth, but to make a module which was easy to use and doesn’t require any IDE on your computer. According to the website, these modules have found their niche in education as well as rapid prototyping for product development. His site has some good resources, including several Scamp/Forth example applications such as a model train controller or adding a real-time clock module.
The core of the module is a Microchip PIC24F64GB202 MCU with 64K Flash and 8K RAM. Of this, Forth takes up only 20K of Flash and 2K of RAM. [John] is using FlashForth, a version of Forth which came from [Mikael Nordman] at the University of Queensland almost ten years ago. FlashForth has been implemented on a wide variety of PIC and AVR ATmega processors and has apparently developed quite a following in Australia and elsewhere.
We estimate from the photo that the Scamp is about 80 mm long, just slightly longer than a standard piece of MIL-A-A-20175A Type II chewing gum ( 73 mm ). You can use it as-is, or with the header pins installed, the Scamp can be plugged into a breadboard for easy hacking. Regarding the interfacing of Scamp to other equipment, [John] says “Writing software to use other hardware is very easy, and fun.” We like his attitude.
Here is some more information from his Hackaday.io project page, and he also has a Tindie site. If you want a good overview of using Forth in embedded systems, check out Forth: The Hacker’s Language by our own Forth-guru [Elliot Williams]. Thanks to [Stephen Walters] for sending in the tip.
I don’t know how I feel about the fact that I feel more informed regarding the fact that there’s mil-spec chewing gum, than a forth compatible microcontroller dev board.
That’s nothing, the U.S. Army has a 26 page specification for a friggin’ brownie!
https://nsarchive.files.wordpress.com/2010/05/mil-c-44072c.pdf
Could be worse
Left the link out
https://www.youtube.com/watch?v=Yz_-k9qoYns
To be fair, that document covers not only chocolate covered brownies but also chocolate covered cookies and all the requirements to prep their ingredients, allowable substitutes in the ingredients, baking procedures, alternatives for baking procedures, storage and packaging in order to meet field ready food standards for troops. It’s 26 pages because it’s whole lot more than how to cook a brownie. That doc is meant for a manufacturer so they can deliver proper field ready product that will be accepted. The people doing the baking probably get a sanitized version 2-3 pages long covering just the baking.
+1
The US government document describing that specification of which is conspicuously labeled “INCH-POUND”, and contains measurements of length in inches, “weight” (not mass) in grams, pressure in mm mercury, and temperature in degrees C. Hunh?
We support in diversity.
I’m surprised it’s not done on a Raspberry Pi, and called “a modern day Jupiter Ace”.
If it were done on a Raspberry Pi, it could be done with a ‘555–as is the case with most things done on a Raspberry Pi.
Maybe it would take two…
Two? Do you mean two 555’s or two clusters of Pi’s?
People thought of the Jupiter Ace as a ZX-81 with FORTH instead of BASIC. I think the only ones who bought it had an interest in FORTH.
But since the Raspberry Pi was introduced as a modern equivalent of computers like the Commodore 64, then running FORTH would make it a modern day Jupiter Ace.
https://github.com/organix/pijFORTHos
One thing I’ve noticed about Forth is that people spend more time writing interpreters than actual Forth programs.
I think that is because the further you get from the kernel words, the harder it is to keep what is going on straight. An appropriate quip is that FORTH is a write-only language.
Documentation is practically a necessity.
I thought so too. Then I was pointed to this.”Working software over comprehensive documentation.”
If a Brownie was modern software that milspec would be completely written on a leaf of Tally Ho. The Brownie would be edible but there would be a sense that something was missing which could wait for the next release.
http://agilemanifesto.org/
I’ve seen an awful lot of unreadable Forth, which gives it the write-only reputation; but I blame that on the programmer, not the language. Same with some other languages.
“the further you get from the kernel words, the harder it is to keep what is going on straight.”
That’s the exact opposite of the way I see it. Forth itself is terse and horrible, but it makes it pretty easy to build your own middle-level language / domain-specific language that’s totally readable. The further you get away from Forth, the faster, the better. :)
I think of it as a bootstrapping language, and I use Forth all the time.
I was going to say that’s somehow in contrast to any other programming language, but it’s not. When you want to get some work done, you pull down somebody’s library to do whatever, and then you have to spend your time learning that library. But how the library is designed has very little to do with C/Java/Python/whatever itself.
Documentation in Forth, as people say, is absolutely a necessity. The old tradition of writing out the stack side-effects is absolutely essential, and it makes you wonder why you just don’t implement formal arguments and type checking… turn the tradition into a requirement. :)
Once you get into how Forth works, it is easy to see improvements or “better ways” to do things. Or to see that a specialized implementation will fit your problem better. Then the project takes the fatal turn from engineering to language definition. It bogs down into language implementation choices or arguments, schedules are not met, and the project folds or you give up and move on. The 1980’s and 90’s were the heyday of failed Forth based projects in Silicon Valley – and some successes like Openboot and Openfirmware at SUN and the Canon Cat.
There are some fine examples of this working out well. A one man project called Mops is a brilliant OOP model built on the ANSI Forth spec. The docs are very well written and worth reading just to see one way OOP can be done that makes a lot of sense. I think it is way better than C++ and similar efforts. It was first done for PPC PowerMacs IIRC. https://sourceforge.net/projects/powermops/files/Documentation/PDF-Manual/
What ever happened to Gumstix? Seemed like good potential.
Same thing that happened to the Dallas Tini I guess.
Better marketing allowing for lower cost and I guess aligned to newer hardware perhaps along with development tools that are easier to use.
Are you quite sure that you aren’t confusing “…writing interpreters…” for the much more common activity of porting FORTH to a particular processor? There is a not-inconsiderable amount of difference in the two–and work involved…to say nothing about negotiating involvement with Forth, Inc.
Change the firmware to something that runs BASIC and you might have something usable by the general public there.
Just good old line number BASIC, i suspect it would be more than enough for 95% of everything being done with Micros. With the added benefit that even my mom could understand whats going on by reading the source.
Parallax Propeller is pretty close to what you’re looking for.
FORTH has an inherent advantage which most people are not aware of, at least not until having thought about the subject in some depth: security of the developed program, and the security of one’s creation (based on a computing device) which uses that program.
Regarding the ability to ‘dis-assemble’, or ‘reverse-engineer’ a FORTH program–
because of the way in which FORTH works (is written; is programmed), any program one writes is inherently extremely more secure than any other language which might be used. It is almost impossible (some would say that it is impossible) to dis-assemble any FORTH program, of any reasonable size, which has been written to perform a particular non-trivial task.
This attribute derives from the fact that FORTH is an extensible language, and its language used to solve a particular problem (yours) is created by you when you create new FORTH words as part of the programming process. Because of this fact, the program to control any but the most trivial of tasks will contain many more custom instructions (FORTH ‘words’) than the basic repertoire of FORTH ‘words’.
I know of only one major manufacturer which (who?) made a conscious decision to take advantage of this outstanding characteristic of FORTH (there are possibly many more): the Rockwell Semiconductor Division of Rockwell International.
Rockwell was, and possibly still is, THE major supplier of fax-modem ICs for the facsimile industry, and to protect their chip designs, all their fax-modem chips were designed around 65xx-microprocessors which were all programmed in FORTH. Rockwell’s commitment to FORTH extended even to having their own variant, called RSC-FORTH.
I have referred to “non-trivial” tasks, To test this characteristic of FORTH (and to get you started, if you have an interest), try writing a FORTH program to simply flash two LEDs, in sequence (which some popular single-board computers canNOT do without your first having loaded a complete operating system…and then hiding the Assembly Language program from you).
Now try dis-assembling that program.
FIF–FORTH is fun.
Once you’ve developed the application, you can re-compile it without headers. To the snoops, the result will appear like it came from a random-number generator, LOL. (That’s for ITC and DTC Forth. STC might be easier to figure out.)