arrayForth Bugs

This page documents known problems with the arrayForth systems that are presently available via our website. In some cases we may maintain historical information as well.

3.5f (Production GA144)

The new word "reclaim" works correctly once to reclaim dictionary space. Unfortunately it reclaims part of itself, so garbage gets compiled over needed code causing something unexpected to happen when it's run for the second time. "remember" is used to define "reclaim". Change the definition of "remember" on block 88 by adding "15 +" and changing "call" to "jmp" as shown here:

remember
forths @ ,lit macros @ ,lit h @ 15 +
,lit
jmp !dict nop ;

Both 4.2e3 (GA4) and 3.4k2 (GA144)

We allowed a windows specific change to "sneak" into block 18 on these systems. The result is that on native machines the process of loading block 18 load aborts while trying to load the resident png generator utility. To correct this, the definitions of png and html must be changed in block 18. The safest way to do this on a native system is to take the following five steps:
  1. Boot and see the question mark on the feedback line.
  2. Edit block 18 to read as below.
  3. Type warm to restart kernel and reload block 18. Should see no question mark.
  4. Type save to write a new compressed floppy.
  5. Reboot to verify all is well.
png winver drop if 168 load then ;
html winver drop if 176 load then ;

3.4k2 (GA144)

The simulator for the +* opcode doesn't handle the sign bit properly. To fix take the following steps:
  1. Boot arrayForth.
  2. Edit the word +* on block 1288 to read as below:
  3. Type save to write a new compressed floppy.
  4. Reboot and test to verify that all is well.
+* t@ sx ar @n
1 ? if push s @n sx + pop
then 2/ over 1 and drop
if 20000 or then ar !n 2/ 3FFFF and t! ;

3.4k2 (GA144)

The port read/write handshake is simulated incorrectly, resulting in premature reading or writing of a port. For now please avoid multiport read, write, or execute. This bug will be fixed in the next release of arrayForth.