Recently, I polled my followers on Mastodon to find out what they expected to see from a Kestrel-2/EX after booting a hypothetical kit computer up for the first time. 33 people responded to the poll, which is by far the largest number of people I've ever had respond to a poll before. Note that the poll was set up so that people could select more than one item from the poll.
Of the people who selected "other" and who provided an additional suggestion, one person recommended either Lisp or Scheme, while another person recommended an independent implementation of Lua.
Based on these results, it is pretty clear I shall be working on a Forth environment first.
One of the first things the computer must do upon power-on is a power on self-test (POST). The POST process is responsible for, at a minimum, determining how much memory is available for the Forth environment to use.
Once memory capacity is determined, a banner is displayed as follows:
== Kestrel RV64IM Forth (MPLv2) == 1024 KiB memory system 262144 dictionary bytes free OK _
The memory capacity, as measured in POST, should be displayed; the size of the dictionary should be computed as a fraction of the RAM detected; 1/4 is a convenient ratio as it only requires a logical shift right.
Why? A dictionary size of 64KB on 8-bit and 16-bit Forth systems frequently proves to be ample to support the vast majority of applications written in Forth. Everything from classic video games to sophisticated business automation applications have been written under such constraints. Cell sizes for these systems tends to be 16-bits wide. Therefore, when sizing a dictionary, we estimate 65536 bytes / 2 bytes per cell = 32768 cells reflects an adequate amount of space for most applications.
If we wish to support a similar compliment of applications on a RISC processor that relies on subroutine threading, we expect scaling the dictionary size up is required in proportion to the typical cell size. The typical "cell" size will be 4 bytes with the occasional 8-byte element and requisite padding. Thus, 32768 cells x 4 bytes/cell = 131072 bytes minimum, and 32768 cells x 8 bytes/cell = 262144 bytes maximum.
If dictionary space is reserved in proportion to the amount of RAM detected, and the 1/4 ratio is used, we therefore need a minimum of 1 MiB of RAM installed to achieve the desired dictionary size. This would also suggest the minimum viable RAM installation is 512 KiB, giving a 128 KiB dictionary size.
Note: Despite scaling the dictionary size, it is possible that the dictionary still might not actually fit in the memory space available. Consider booting up a system with a faulty memory circuit, and only 128 KiB of memory is detected. A 640x480 monochrome bitmapped screen takes 38400 bytes, and assume the BIOS or kernel on which Kestrel Forth is based on takes another 65536 bytes (just hand waving here), for a total of 102KiB. That leaves only 26 KiB free for dictionary use, which is smaller than the 32 KiB anticipated for the dictionary. In such situations, the dictionary size must be the smaller of the computed size and the actual size left.
Note: The dictionary bytes free measurement is shown as 262144 bytes free above; however, in actual practice, this figure is expected to be less than this value, even on 512KB or larger systems. This makes sense, for a completely empty dictionary yields a Forth environment with no words that can be invoked.
Historically, Forth relies on two kinds of persistence. First is called block storage. It is the oldest method of storage, providing the Forth environment with raw, sector-level access to one or more devices. The second, and much more recent, is file storage. Kestrel Forth opts to go with file storage.
Why?
To this very day, I generally prefer block storage.
However, recent experience with
DurexForth on the Commodore 64
has left me genuinely impressed with the use of files,
provided there's good editor support for them.
Combined with MARKER words to manage dictionary space consumption,
the overall experience closely resembled block-based Forth usage.
Additionally, it is anticipated that the vast majority of people using Kestrel Forth will do so via the emulator, which will run hosted under an operating system such as Linux, Windows, or MacOS. All of these environments are inherently file-based.
Kestrel Forth will use Tripos naming conventions.
DEVICE:path/name/to/file
The DEVICE portion of a name can refer to a physical device,
such as SD0: for an SD card slot,
or DF2: for a floppy disk interface.
The DEVICE part may also refer to a logical device,
also known as an assignment.
These are fake pseudo-devices established via the Tripos ASSIGN command.
For example, SYS: always refers to the boot device,
regardless of its physical name.
Finally, depending on how the filesystem drivers are implemented,
the DEVICE part of a filename may also refer to the actual name
given to the volume when it was formatted.
For example, if a volume was formatted with the name Work Disk,
then you can access a file on it via the path
Work Disk:path/to/file.
(Depending on user interface, you may need to wrap names with spaces in quotes.)
Why? Kestrel Forth is expected to run natively at this point in time; however, future updates are anticipated to more fully implement the Tripos kernel and DOS library.
An emulator for the Kestrel-2/EX environment should let the user specify a number of paths rooted to virtual volume names. This can happen either at emulator startup or while the emulator is running.
The user is free to remove these bindings at any time.
As soon as a user removes a binding for EM0:, for instance,
all filenames referencing (directly or indirectly) EM0: becomes invalid.
For instance,
the Kestrel-2/EX emulator may provide a GUI interface which lets
the user specify the device ID (EM0: .. EM3:, for example)
and virtual volume label (which may be left blank if none needed),
along with a button that brings up a Gtk file picker.
If the user selects a file, that associates EM0:, the virtual volume ID,
and the provided path.
Then, any time software running in Kestrel Forth references either EM0:
or the virtual volume ID, that binding will be used to complete the
local equivalent filename. Later, the user may click Eject to
"eject" the virtual volume, cutting off all access to that resource.
This is deliberately left unspecified at this time, as physical hardware designs have not yet been started. This will also depend on details of how the underlying Tripos DOS library will be implemented then.
However, it is anticipated that SD cards will be accessed via the
SDn: device family, a RAM disk will be available via the RAM: device,
etc.
The Kestrel Forth environment will provide an RV64IM assembler. Since the Forth environment will be subroutine-threaded, assembly language can appear anywhere inside a colon or CODE definition. (In fact, a CODE definition is equivalent to a colon definition in this environment.)
This is an optional feature at this time.
The Kestrel Forth environment may provide support for assembly language disassembly. This may be built-in or it may be accessed via an external module.
The Forth environment will make every effort to comply with the latest Forth standards where possible. However, strict adherence to the standard is explicitly not a requirement at this time.
Completing the Forth environment takes priority over standards compliance.