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?