[Coco] A brief history of f83

[bkheath at gmail.com]

Hello all,

This is the first of two messages intended to introduce the f83 port
I've been working on to the CoCo community.

Someone once asked "What is this f83 you keep talking about?" but
since I was email challenged at the time he was obliged to go
elswhere for an answer. Nonetheless it was a valid question and
answering it gives me an excuse to give some context that will
(hopefully) clarify the issues raised in the status update to follow.

NB: Much of the history is from memory/hearsay so don't quote me
unless you can find independent corroborating evidence:)

FORTH is a programming language developed by Charles Moore out of his
preferred practices when working (during the late '60s and early
'70s) in a wide variety of computing environments. Largely writing
telescope control programs for various Observatories.

This history is relevant here for two reasons:
    1.  Many of these Observatories used the DEC PDP-11 for telescope
        control, a machine which AIUI has a certain architectural
        affinity with our beloved 6809.

    2.  It's not too much of a leap to conclude that the need to be
        quickly productive in a wide variety of mutually incompatible
        computing environments heavily influenced FORTH's design.
        Specifically a small and powerful but easy to implement "inner
        interpreter" (or virtual machine) that presented a repeatible and
        comfortable "outer interpreter" (or working environment) to the
        programmer. But more on this later.

In addition to FORTH INC. -- founded by Charles Moore and Elizabeth
Rather -- during the 70's other companies released proprietary versions
of FORTH for various platforms. Also, FIG (The Forth Interest Group)
produced a Reference Model and public domain implementations for a
number of Microprocessors (8080, 6502, etc.).

1979 saw the first pass at harmonizing the wide variety of
implementations with the release of the FORTH-79 standard. It was
largely (though not completely) backwards compatible with FIG-FORTH.

FORTH-83 was the next standard released. Though it was essentially
intended to be evolutionary the language had grown quite a bit and
there were enough fundamental changes from FORTH-79 to make FORTH-83
programs completely incompatible with older implementations.

Also in 1983 Henry Laxen and Michael Perry wrote and released f83. A
FORTH-83 compliant implementation for CP/M-80, CP/M-86, CP/M-68k and
MSDOS-1.0. In addition to a very generous license (Unrestricted as
long as you credit the authors for their work), it differed from
previous free releases in two important respects.

    1. Undoubtedly because of it's origins as an environment which had
       to run on platforms that might not even have disks available,
       much less a file system, FORTH traditionally saw storage as a
       sequence of 1k blocks and typically dealt directly with the raw
       disk (or tape) rather than any higher-level construct. F83 added
       a file I/O interface to the host OS.

    2. Although there were lot's of free utilities and development
       tools available for FIG-FORTH you had to go out and find them
       for yourself if you wanted to build up a reasonable working
       environment. F83 came out of the box as a full integrated
       development system with complete source for everything. Let me
       emphasize this point. In addition to a number of utilities that
       are merely useful, handy, or comfortable -- F83 out of the box
       included everything necessary to modify and recompile any part
       of the system, including the core language and development tools
       themselves, without reference to any external software other
       than the host OS. Not bad for CP/M .com file of only 24k!


I'll defer the explicit list of f83 components to the following
message where the status of each can be itemized.


Let me close by pointing out a not quite obvious implication of the
above for f83-coco (I haven't finalized the name yet). As long as
there's 64k of memory available f83 could quite happily recompile
itself on a tape only system. The limitations of the CoCo cassete
interface make editing tape source files problematic but there are
feasible (if tedious) workarounds. Smaller target applications could
use a stripped down version with a subset of the utilities and thus
correspondingly less memory. This means that those wishing to use
such platforms for sensing, control, or other experimental purposes
could have resident development, debugging, and protoyping
capabilities without the need to connect to an external system.


Think about that for a moment:)



Brett K. Heath