A reminder, just because a device "sees" a given block range doesn't mean it has the capacity for said range. The single sided and single disk 1541 can only handle block numbers 0 - 165 ( 0 - $A5 ).
VICE, the C64 simulator allows simulating a Ram Expansion Unit with a maximum size of 16 megabytes ( 256 banks ) for a block range of 0 - 16383 ( 0 - $3FFF ). The actual Ram Expansion Unit I had back then had a capacity of 512k ( it was the one for the C128 but worked fine with the C64 ). It had a block range of 0 - 511 ( 0 - $1FF ). In actual use, I've only used a couple dozen or so blocks in the Ram Expansion Unit.

The Fleet Forth metacompiler has a new feature.
In another thread, Garth Wilson commented:

Since the DO LOOP primitives are only used by the DO LOOP compiling words, I was wondering if anyone thought about naming the primitives the same thing. DO would compile a primitive named DO , LOOP would compile a primitive named LOOP , etc. .
The Fleet Forth metacompiler does not allow redefinitions within the target vocabulary and for good reason. The metacompiler builds the target in virtual memory. For each word that is defined, a 'target word' is added to the target vocabulary on the host. the target words are CREATE DOES> words with three cells in their parameter fields. The first cell is the virtual address of the corresponding word in the target, the address it will have in the new kernel. The second address is the address of the word that was found with the same name ( usually found in the META vocabulary or the host FORTH vocabulary). The third cell is for statistical data ( how many times was this word compiled into a new definition? ). While interpreting, or if the target word is immediate, the target word ( the word in the target vocabulary on the host ) is executed. All target words have the same behavior, fetch the address in their second cell, abort with a message if it is zero, otherwise execute it. There are metacompiler versions of the compiler words in the META vocabulary. When compiling a word in the target that has a DO LOOP , the META versions of these words are found and executed. If the target versions of these words are already defined, the target word executes the META version when it is executed.
The problem arises if the primitive and compiling word for DO have the same name. If the compiling word has not been defined yet and a DO LOOP is used in the source of a word ( the primitives having already been defined ) , the primitive in the target will be found and compiled! No in line branching addresses will be compiled, just the primitive.
The metacompiler's new feature adds a name buffer which normally has a zero in the first byte. If there is a non zero value in the first byte, the name in the buffer is used for the name in virtual memory. If I want to name the DO primitive DO , I can do it like this:

The target word for the DO primitive will have the name (DO) , but the actual name for the primitive in the new kernel will be DO .
If I want to leave the name in the new kernel the same as in the source ( (DO) ) , I just leave out the T" <name>" .

T" has been replaced with VN ( virtual name ) which accepts a blank as a delimiter instead of a quote mark.
This:

now becomes this:

This change was made so I could also do this:

When a primitive has the same name as its compiling word, the disassembly looks a little odd.

Well, with the unsigned integer square root ( no rounding), the result requires half as many bits as the initial number.

The versions that do not round the result only return a zero result if taking the square root of zero. The rounding versions only return a zero result if taking the square root of zero or if there was an overflow. If your program never takes the square root of zero, then a zero result can only mean an overflow. I'm just going to go with returning a result as large as the input for the versions that round. The truncating versions don't need the extra size for the output.

Huh? It's my understanding that a fixed point number is an integer where a suitable scale factor is used. For example, if I'm using a scale of 1000 then 2.718 is represented as 2718 and 3.142 is represented as 3142. Wouldn't +1 simply be represented as 1000?

In twos-complement binary, there's always one more negative value than there are positive values. So, no matter how you scale things, the square of the most negative value is too large to fit as a positive value. I was thinking specifically of a setup where the numbers run from -1.0 to just shy of 1.0.

True.

As long as the absolute value is not less than one. For example: -0.5 to just shy of 0.5

Interesting. I never considered that case, till now, but then I am only a hobbyist, not a professional.

Here is the set of Auxiliary stack words I've settled on:

AP0 and APLIM are Fleet Forth user variables. AP0 is $256 and APLIM is $200. Location $256 also serves as storage for the Aux stack pointer. This address range is part of the BASIC input buffer on the Commodore 64. Fleet Forth uses the address range $2A7 - $2FF , an otherwise unused section, for its text input buffer.
In Fleet Forth, the control flow stack is the data stack and each control flow stack item ( CS ) is two cells, an address and a security number, so CS>A is an alias for 2>A and A>CS is an alias for 2A>.
The Aux stack words >A , DUP>A , 2>A , A> , A@ and 2A> are slower than their return stack counterparts, even though they are defined in code, but could be useful when testing a new word that needs to place temporary data to the return stack. Use these words to use the Aux stack instead of the return stack to test the new word or words since an Aux stack overflow or underflow will not, of itself, cause a system crash ( unlike the return stack). It is also easier to see what is happening if the only data on the extra stack is only what the word under test placed there ( or was placed there for it ). When the new word works successfully, the Aux stack words can be replaced with their return stack counterparts.
To see what is on the Aux stack, here is .AS

.S was rewritten so it never aborts:

and ABORT , which is called by the word compiled by ABORT" , is defined as:

ERR is a deferred word that is normally set to execute NOOP , a no-op.

I made a slight mistake with two of the Aux stack words. CS>A and A>CS should be immediate.

I tried this partly to establish a baseline for my next experiment: making the DO LOOP primitives headless. This didn't pose any insurmountable problems with the design of the decompiler. The kernel was a few dozen bytes smaller ( I also made the primitives for ." and ABORT" headless ). The complete system with tools was almost three dozen bytes larger partly so the decompiler could display something for the headless primitives.
Overall, I wasn't very satisfied with either approach and went back to primitives with heads and with their original names ( (DO) (?DO) (LOOP) (+LOOP) (.") and (ABORT") .

Sadly, that's not really an option on the Commodore 64. The C64 lacks a caps lock key, it has a shift lock key instead. The C64's default character set looks like upper case when not shifted and graphical characters when shifted.
I've read that some Forth's gave the primitives names like <DO> <?DO> etc. to avoid problems with parentheses delimited comments. I suppose the names could be <DO <?DO etc. to make them slightly shorter. Any thoughts on this?

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I had an idea for DEFERred words but I don't know if it is worth the overhead. In this post, vector refers to the word a DEFERred word is set to execute. In Fleet Forth, the DEFERred words defined in the kernel have a reset table. Forget goes through this table and resets any DEFERred word that had its vector forgotten. This only covers DEFERred words in the kernel. My idea was to add a new variable DEFER-LINK and add an extra cell to each DEFERred word as it is defined ( to link it into this DEFER-LINK chain). FORGET could traverse this link, after pruning the dictionary, and any DEFERred word that has its vector forgotten would be reset to -SET .All DEFERred words are initially set to this word. -SET displays the DEFERred word ( in reverse video) and the message "NOT SET" .
As I said, I'm not sure if this would be worth the overhead of an extra cell per DEFERred words plus the extra code in the kernel since the kernel DEFERred words are already covered.

I've removed the multitasker support ( such as it was and what there was of it) from the vectored I/O words CONSOLE , PRINTER , and LOGGER. Fleet Forth still supports multitasking, but there are better ways than maintaining an I/O state variable to do what I wanted.
I have also reworked the I/O redirection so that an abort does not cause an I/O reset. This made it easier to log certain tests that would cause an abort ( intentionally as part of the test or even as the result of a typo) . By 'log', I mean send output to the console and the printer. Most of the I/O words that call a Commodore I/O routine return an error number on the data stack. IOERR takes this number and reports the error and aborts if the number is not zero. ?IO was added. It checks the error number and exits if the number is zero otherwise it calls IORESET and IOERR ( which aborts.) The only words which have ?IO are the new vectors for EMIT , TYPE , QTYPE , and EXPECT .
Here are the updated I/O redirection words:

By the way, DEMIT and DTYPE are the versions of EMIT and TYPE normally used to send commands to a disk drive. They do exactly what EMIT and TYPE do except update the variables CHARS and LINES .

On the subject of DEFER. Is vector a good name for the word a DEFERred word is set to execute or is there a better one?

I was just rereading the thread on Extra stacks.
I named the words to transfer data between the data stack and the auxiliary stack with an 'A' rather than an 'H' because I didn't write the Auxiliary stack to be a high precision math stack, but rather a helping hand for manipulating high level and assembly control flow data. That and I wasn't thinking about that thread at the time I implemented the Aux stack.
As for implementing a split stack, that might save a few bytes in the stack transfer words, but it would cost more than that in the definition of .AS , the Aux stack counterpart to .S .

Fleet Forth has vectored (deferred) I/O words. Here is why.
Fleet Forth, like 64Forth and Blazin' Forth, uses the Commodore 64's I/O routines to save memory. On the Commodore 64, the same routine is used to send a byte to the screen, the printer, disk, or another device. There are Commodore 64 routines to redirect output to an open file, input from an open file, and to clear the I/O channels so output goes to the screen and input comes from the keyboard.

Fleet Forth's default I/O state is that the I/O channels are cleared and output goes to the screen while input comes from the keyboard. Both the cold start and warm start routines clear the I/O channels.

Words which perform disk I/O use one of the Commodore 64 KERNAL routines to redirect input or output to the specified open file. Data is read or written then the channel is cleared.

Redirecting output to a printer is handled similarly. There is a printer version of (TYPE) , the TYPE primitive. This printer-(type) , (PTYPE) , redirects output to the printer, types its data to the printer then clears the channel. PRINTER opens a channel to the printer and re-vectors TYPE, EMIT, and others to their printer versions. CONSOLE resets TYPE, EMIT, and others to their default vectors and closes the channel to the printer.

64Forth and Blazin' Forth do not re-vector EMIT and TYPE. They each have a word that opens a channel to the printer and redirects output to the printer. They also have a word that clears the channel and closes the file to the printer. 64Forth warns that when using PRINT to send a block listing to the printer, the block must already be in a buffer. Blazin' Forth does a little better. Blazin' Forth has a variable, PRINTING? , that gets set by PRINTER and cleared by NOPRINTER. Blazin' Forth's (LINE) , which is used by a word which is used by Blazin' Forth's LIST , has some extra code to check if PRINTING? is true and clear the I/O channel if it is. It also has some extra code after calling BLOCK to see if PRINTING? is true and redirect output to the printer if it is. The same goes for Blazin' Forth's word .INDEX ( which is used by INDEX ). This works for listing blocks to a printer or even sending the index of blocks to the printer, but it doesn't work when loading blocks and a block causes a message to be displayed. Since PRINTER? is defined in Blazin' Forth's system loader, it wasn't available when the block read write routine was written.

This is why Fleet Forth's EMIT, TYPE and some other words are deferred and the printer version of these words, like any word in Fleet Forth that communicates with devices other than the screen and keyboard, redirect the Commodore 64's I/O, send the data, and clear the I/O channel. In my opinion, it is much easier to start with a known state and return to that state ( I/O directed at keyboard and screen) than it is to try keeping up with the state of the I/O and trying to set it to what it was prior to the latest time it was redirected.

Note: The information in this post is specific to the Commodore 64 and interacting with the Commodore 64's KERNAL routines.