The Ether is my term for software in every computer's RAM that routes messages about the chip. etherForth depends upon and exploits this vehicle to compile and distribute application code.
As with colorForth, tags are used to identify pre-parsed words in source code. This simplifies and speeds editing and compilation by moving effort from compile time to edit time.
In contrast to classic colorForth's Shannon-coded characters, etherForth uses 6-bit characters preceeded by a 6-bit tag. It also uses 6-bit tokens to indicate f18 instructions. This is designed to provide extremely compact source code that can reside in Flash memory and documenet an embedded application. Code also has to be easy to manage in the small f18 computers.
etherForth is a stand-alone operating system that boots from Flash. It expects external RAM memory, a RGB video monitor and a 4-key keypad. It will be available to anyone with those facilities.
etherForth presently employs the Evaluation Board. It boots on the Target chip and uses Serdes nodes (001 and 1701) to access the Host chip with ethercode. Host nodes are numbered 1000-1717. The editor is on Target with its video and the compiler on Host with its external memory. The keypad uses the 4 pins of Target node 705 (Flash on host). Plenty of nodes remain unused on both chips.
From a boot port, ethercode is loaded into a neighbor. Then that neighbor is given a packet with instructions to replicate itself along some path. And other paths until the chip is fully populated. So ethercode exists in 143 computers, with the exception of the boot port.
It is prudent when receiving instructions to switch from 4-port read to a focused 1-port read. Otherwise confusing input may come from other ports. But more importantly, when replying it avoids a broadcast that can confuse or hang neighbors who are likely hoping for instructions from you.
So the first instruction in an ethernet packet is a focus - a call instruction to the port from which the packet comes. With the program counter set to this port, instructions will be executed only from it and data fetches/stores using @p and !p will go thru it.
This call has another function. It pushes the previous program counter (port address) to the return stack. From there it can be moved to an address register (pop a!) to receive additional data. And send reply.
Path has 3 6-bit fields, each with the format nnnndd
Directions are coded
The last run can have 0 length. That means to turn in that direction but not move. But this turn cannot be to the right: '0 r' is indistinguishable from 0, which means end of path.
Path limitations constrain the possible routes and affect the assignment of nodes. In practice, this has not been a problem.
Payload has a maximum length of 128 words. This is adequate to fill the 64 words of destination RAM. But is limiting when moving data to/from external RAM. Someday 2 count words may be used.
There must be a payload of at least 1 word. That might just be a return to 4-port read.
A string of 6-bit tokens (0-57) represents f18 instructions, again terminated by a tag. This is compact and simplifies edit and compile. Tokens 0-37 are the actual f18 op-codes. Except for 2 and 3 (jump and call) which are not named. Others are
The first task of the editor is to display a block of source code. Video is set for 24 lines of 50 5x7 characters. Edit must display words and tokens, using a look-up for the latter. Each line occupies 30 scan-lines and requires 3 scans for each of the 10 slices of the characters. These slices come from the memory of 2 adjacent nodes.
The source is presently down-loaded from a PC, but will soon be retrieved from external SRAM. SRAM will have been loaded from Flash at power-up. Source is buffered in a couple nodes near the editor and will be rewritten to SRAM when changed. SRAM will be copied to Flash upon request. These data transfers are, of course, done by ethernodes.
A 4-key pad is used to change the source. It can increment/decrement a character or token, add/delete them and cycle colors. Hopefully this will address critism of the colorForth keyboard - but probably not.
The compiler has to read the 6-bit source coming from SRAM, build a (small) dictionary and compile tokens. It buffers compiled code in 2 adjacent nodes, needing more than 64 words for possible initialization code. And needing to buffer in order to update forward references (if, -if). When finished, the code is moved to its destination.