Blocks
The traditional Forth mass storage system is centred around the concept of BLOCKs. A BLOCK is traditionally a 1kilobyte chunk of storage.
The design philosophy of CamelForth BootROM’s disk access is, like Forth itself, intentionally low-level. It views the entire disk as an array of blocks. Blocks are just data, they can be anything: source, data, random blobs of quantum information… They are what you make of them.
The CompactFlash uses 512byte sectors, so two consectutive sectors would equal 1 BLOCK. Each sector is addressed using LBA. Therefore, a 64MB CompactFlash card can be viewed as sixty-four thousand blocks, numbered 0 to 65535. Probably enough for anyone! (where have I heard that before?)
However, you may want to organise them into something more intelligible.
Disk partitioning
Most modern Forth implementations use the host computers operating system to seperate files and data into items of information. As I mentioned before, like the old days, the CamelForth BootROM access to the disk is low-level.
So, how did they do it back in the day?
According to Lee Brodie’s Thinking Forth, most Forth development teams partitioned the disk in multiples of three.
Why three?
Source files are written into these blocks, as a SCREEN. A screen is the block divided into 16 lines of 64 characters. Three screens fit quite nicely onto a printed page. If chunks of code were divided, and laid onto blocks, into multples of three, then it was easier to print out source only a section of three screens, and stick it into a binder. They called this a TRIAD.
As he says:
In many Forth shops it’s considered desirable to begin sections of code on screen numbers that are evenly divisible by three.
Major divisions on a disk should be made on boundaries evenly divisible by thirty.
Example of a disk-partitioning scheme within one department:
Screen 0 is the title screen, showing the name of the application, the current release number, and primary author.
Screen 1 is the application-load block.
Screen 2 is reserved for possible continuation from Screen 1
Screen 4 and 5 contain system messages.
Screens 9 thru 29 incorporate general utilities needed in, but not restricted to, this application.
Screen 30 begins the application screens.
So, keeping this hierachical system, there is no need for any funky filesystem.
So, imagine we have the system disk:
Screen 1 would look like this:
\ CamelForth BootRAM system disk 30 CONSTANT FORTH2012
Then, by doing “FORTH2012 LOAD” would cause screen 30 to load and execute:
\ Forth 2012 extensions
33 LOAD \ core-ext
36 LOAD \ facility-ext
39 LOAD \ double numbers
42 LOAD \ string
45 LOAD \ tools-ext
54 LOAD \ memory
Screen 33 would look like this:
\ Forth 2012 Core extensions for CamelForth BootROM
.( Loading core-ext definitions… ) CR
FORTH DEFINITIONS
1 2 +THRU
The +THRU word loads screens 1 to 2 from the relative position of the current screen.
Files
CamelForth BootROM has an simple inbuilt screen editor to write code. But how to transfer source code?
However, transfering screens from a PC text editor, and the RC2014 can be quite torturing lining up the code into 16 lines of 64 characters. Looking at the Forth2012 test suite, there is no way I intend on refactoring that lot!
So, we need to define a concept of a text file. For this, we’ll borrow from CP/M. A line of text ends in control code 13 (carriage return)……and the files end in control code 26. The start of the file is the first byte of a block, and spans consecutive blocks.
The load from these files, we’ll read a line into a buffer, use the Forth interpreter on it, and repeat until we reach a control-code 26.
So, we need a script to convert these text files into blocks. I could write this in python (and, I already have, to be honest), but it would be more appropriate to write it forth.
Filesystem
The most simple “filesystem” would then be a bunch of indexes to the first block of each “file”. These could be CONSTANTs to load…..or it could be a list of strings representing filenames.
But more on this, later.