I independently rediscovered the U< when setting MEM to greater than $7FFF. The buggy U< cause CREATE to fail if there was more than 32K available for the dictionary because CREATE does a test for available space. Correcting the U< bug fixed the issue with larger available memory. Having critically examined the CREATE code, I believe I have identified an additional subtle bug in the original CREATE code. Below is the original code.
; CREAT .WORD DOCOL
; .WORD TIB
; .WORD HERE ;|
; .WORD CLIT ;| 6502 only, assures
; .BYTE $A0 ;| room exists in dict.
; .WORD PLUS ;|
; .WORD ULESS ;|
; .WORD TWO ;|
; .WORD QERR
;
The test ensures that HERE + $A0 is less than TIB which is used as an upper memory limit. This would be fine if the implementation followed the memory model in the Nov. 1980 Fig-Forth Installation manual, which show the User variables being located below the disk buffers. However, almost every version of 6502 Fig-Forth I have seen places the User variables at the top of memory and the disk buffers below i.e.:
;
; MEM .EQU $FF00 ; top of assigned memory+1 byte.
; UAREA .EQU MEM-128 ; 128 bytes of user area
; DAREA .EQU UAREA-BMAG ; disk buffer space.
;
This means it is possible for the dictionary to grow into the disk buffer area. If any of the disk functions were accessed, part of the dictionary could be over written. While this is unlikely since it would require a lot of Forth code to get that far up in memory. If the memory map puts the disk buffers below the User variables, then it would be more appropriate to test against FIRST as the upper memory limit. I have implemented this change with no apparent issues, though I have not yet done exhaustive testing.
I have several questions. Does anyone concur with my interpretation of the CREATE issue and the solution? Does anyone know why this test in CREATE is implemented for the 6502 only? Also is there anything special about ensuring at least 160 ($A0) bytes of available?

Welcome, CarlM! It's always nice to meet a 6502 enthusiast... and likewise your interest in Forth is one that's shared with quite a few others here (including me).

If you wish, please feel free to make a post in the Introduce Yourself thread. For example, maybe you'd like to share your background, and how these topics came to attract your attention.

Unfortunately I can't offer you any specific feedback at present, as I'm away on vacation (which means less access to my FIG docs and also there are other priorities competing for my time)! But you'll perhaps be interested in some of the threads turned up by the forum's Search function. For instance the following two examples seem to have relevance:

FIG Forth bugs and quirks (including U<) and
Why is PAD 68 bytes above the DP? (which touches on some issues regarding the FIG memory map for 6502).

Just a minor suggestion, but for future code snippets, you may wish to consider using the forum's Code formatting function for a clearer, mono-spaced presentation. Cheers,

Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

For the most part, the FigForth manual is just a general guideline, as different 6502 computers may require different Forth layouts.

I wouldn't get too hung up on right or wrong, or, should this idea be adopted as it seems to work. Some users may have used a certain way for years and a change like your suggestion would require them to change all their code. What is important is to get a layout that works for you.

We are more than happy to follow along on your journey to Forthdom.