gForth Block File Question

[Van Kichline]

I am new to Forth and just beginning to get serious. I an using gForth on Ubuntu for now. I want to use block files, and have found a nice little block editor: editb, which is working well but has no block file management functions. I've added Index, but really need to reorganize my block file.
Brodie says moving blocks is easy (at least for fig Forth) but I haven't found the way to load a block and write it to a different block number. Can anyone provide a hint?
Or, if there's somewhere I can look at the source of a more complete block editing environment, I may be able to figure it out for myself.
Any help appreciated, thanks!

[Van Kichline]

I've found an answer, but I think it can be greatly simplified:
: copy-block ( from to -- )
block swap block
1024 0 do
2dup i + swap i + swap
dup C@ rot C! drop
loop 2drop ;

[dxforth]

buffer swap block swap 1024 move update ;

(assumes more than one block buffer)

[dxforth]

On 11/03/2023 1:56 pm, dxforth wrote:
>
> : copy-block ( from to -- )
>    buffer swap block swap 1024 move update ;

Incorrect. Should be:

: copy-block ( from to -- )

swap block swap buffer 1024 move update ;

[Van Kichline]

On Friday, March 10, 2023 at 7:01:32 PM UTC-8, dxforth wrote:
…
Thanks! That’s considerably simpler! I have a lot to learn.

[Brian Fox]

On Friday, March 10, 2023 at 10:24:34 PM UTC-5, Van Kichline wrote:
> On Friday, March 10, 2023 at 7:01:32 PM UTC-8, dxforth wrote:
> …
> Thanks! That’s considerably simpler! I have a lot to learn.

Not sure if this works on GForth but some older systems kept a cell
just before the buffer address that contained the block number
and the update flag. This was how HsForth did it.

In those systems copy was:

: COPY ( from to -- ) FLUSH SWAP BLOCK CELL- ! UPDATE ;

Quite clever and even simpler.

[dxforth]

Looking at COPY from a screen editor I notice UPDATE was followed by
SAVE-BUFFERS. That ensures the data gets written to disk instead of
trusting it will.

This was the code for COPIES. Today it seems clumsy. Perhaps someone
can do better.

\ Copy u3 screens from screen u1 to u2
: COPIES ( u1 u2 u3 -- )
?dup if
swap 2 pick - >r over +
r@ 0< if swap 1 else 1- -1 then
r> 2swap do i 2dup + copy over +loop
then 2drop ;

[Ruvim]

It's a system specific solution (both variants are correct to the same
extent).


The address of a block buffer returned by BLOCK or BUFFER is transient,
with very weak guarantees by the standard to a program. This address
becomes invalid after any next performing of BLOCK, BUFFER, LIST, or
LOAD, parsing, displaying characters, etc, — see 7.3.2 Block buffer
regions [1].

The standard allows a system to implement even only one buffer for blocks.

So, a standard compliant solution is to use a separate temporary buffer:

1024 buffer: tmp

: copy-block ( u.block-from u.block-to -- )
swap block tmp 1024 move
tmp swap buffer 1024 move
update
save-buffers \ it's optional
;


"save-buffers" is optional since the system shall save to the HDD an
updated buffer before reuse it anyway.


[1] https://forth-standard.org/standard/block#block:buffers

--
Ruvim

[minf...@arcor.de]

Once upon a time blocks had been invented to map whole disk sectors to memory
and process them there. Efficient during its time, but rather awkward today IMO.

Most OS-based Forths like gforth have moved on to sequential text files. So unless
you have specific reasons, consider converting your blockfile to a text file and use
your favourite text editor for restructuring and editing.

[dxforth]

On 11/03/2023 7:23 pm, Ruvim wrote:
> On 2023-03-11 03:01, dxforth wrote:
>> On 11/03/2023 1:56 pm, dxforth wrote:
>>>
>>> : copy-block ( from to -- )
>>>     buffer swap block swap 1024 move update ;
>>
>> Incorrect.  Should be:
>>
>> : copy-block ( from to -- )
>>      swap block swap buffer 1024 move update ;
>>
>
> It's a system specific solution (both variants are correct to the same extent).
>
>
> The address of a block buffer returned by BLOCK or BUFFER is transient, with very weak guarantees by the standard to a program. This address becomes invalid after any next performing of BLOCK, BUFFER

That's depressing. Any idea what might cause the address/contents of BLOCK to
become invalid when BUFFER is executed?

[Anton Ertl]

Note:

|A call to BLOCK or BUFFER may render a previously-obtained
|block-buffer address invalid, as may a call to any word that:
[lots of other cases elided]

So a standard COPY-BLOCK should copy from the BLOCK to an intermediate
buffer, and only then call BUFFER and copy the data to the resulting
address.

Is this just a theoretical concern? No:

1) The first implementation of blocks in Gforth used just one block
buffer, so COPY-BLOCK would never work.

2) This implementation was replaced with one that currently uses 32
bufferes, so COPY-BLOCK works as intended in many cases, but
insidiously not in all cases: It chooses only one of the buffers for a
given block. In particular, if the block number of the two involved blocks modulo 32 is the same, you get the same buffer:

4 block hex. $5601034AB198 ok
68 block hex. $5601034AB198 ok

If you want to copy between two blocks that use the same
buffer, COPY-BLOCK will not work as intended.

Yes, one can consider this behaviour to signify a low quality of
implementation of the blocks wordset, or maybe that the standard is
not tight enough. But it seems to me that blocks these days cater to
a small minority, they know the quality of the blocks implementations
they use, and know how to work around their quirks. That's probably
why nobody has even discussed tightening the standard in this respect,
and IIRC nobody has asked for a higher-quality implementation in
Gforth. It's also not clear how such a tightening of the standard
would look like given multi-tasking Forth systems.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2022: https://euro.theforth.net

[Anton Ertl]

dxforth <dxf...@gmail.com> writes:
>> The address of a block buffer returned by BLOCK or BUFFER is transient, with very weak guarantees by the standard to a program. This address becomes invalid after any next performing of BLOCK, BUFFER
>
>That's depressing. Any idea what might cause the address/contents of BLOCK to
>become invalid when BUFFER is executed?

1) If BUFFER needs a buffer and chooses the same one (e.g., in Gforth
even without multi-tasking).

2) (In a classical Forth system:) If BUFFER chooses a buffer that
contains a (different) UPDATEd block, performs I/O to save the
contents of that buffer to disk before giving it back as buffer for
the passed block number. Now, while the classical Forth system waits
for I/O to do it's work, it switches to a different task, which may
perform, e.g., one or more BUFFER operations, one of which might
choose the buffer that contains the block the original task loaded
with BLOCK.

[none albert]

BUFFER was renamed into (BUFFER) in ciforth from FIGForth.
It is worthy of the round brackets, because it is an internal word.
--------------------

() Return the address addr of a buffer assigned to identification n ,
probably a block number. Block numbers are positive, so a negative
value can be used for a buffer that is used for some other purpose.
The buffer layout is as follows: a cell with n, a cell with the
status, and the content of length B/BUF . The status is negative for
locked. The l.s.b. gives zero for free and one for valid data. The
block is not read from the disc. The buffer is either one that was
already assigned, or else a free buffer. If there is none free, some
non-locked buffer is freed. The contents of that buffer is written to
the disc, if it was marked as updated. In ciforth this will never
happen, because updated blocks are written immediately. In ciforth
blocks can be locked, and locked buffers are never freed by (BUFFER) .
An update flag would somehow be multiplexed with the lock count, but
it is not needed in this ciforth. If all buffers were locked, (BUFFER)
throws exception 48.
-------------
The description suggest that you don't need the word unless you want
to mess with the internals of FORTH.

\ Copy block one to block two.
: C-S SWAP BLOCK SWAP BLOCK B/BUF CMOVE UPDATE ;
This requires that you have at least two block buffers.
Any content made before to other blocks, is at risk of
being lost, unless you do UPDATE diligently.
You must understand that BLOCK is a cache for a disk or a
file. So after any change to a block in memory you should
say UPDATE to notify that it is to be written to disk in
at a convenient time.

You have a wrong understanding of BLOCK if you ask that the address or
content has changed. You have only control over blocks via the UPDATE.
You can only change a block immediately after obtaining the address of
the block. In other words you have no business worrying about address
or content of blocks!

Using blocks is inherently more difficult than files, and any
newbies are strongly advised against using blocks, if files are
available.

I use blocks in lina (and am chastized for it!) but actually I
use it as a read only library, never changing blocks, never using
blocks for application source code, inserting blocks using external
tools, and never using block numbers, not even if symbolically
defined.


Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

[dxforth]

On 11/03/2023 8:56 pm, Anton Ertl wrote:
> dxforth <dxf...@gmail.com> writes:
>>> The address of a block buffer returned by BLOCK or BUFFER is transient, with very weak guarantees by the standard to a program. This address becomes invalid after any next performing of BLOCK, BUFFER
>>
>> That's depressing. Any idea what might cause the address/contents of BLOCK to
>> become invalid when BUFFER is executed?
>
> 1) If BUFFER needs a buffer and chooses the same one (e.g., in Gforth
> even without multi-tasking).

BUFFER doesn't read. How would the contents change?

> 2) (In a classical Forth system:) If BUFFER chooses a buffer that
> contains a (different) UPDATEd block, performs I/O to save the
> contents of that buffer to disk before giving it back as buffer for
> the passed block number. Now, while the classical Forth system waits
> for I/O to do it's work, it switches to a different task, which may
> perform, e.g., one or more BUFFER operations, one of which might
> choose the buffer that contains the block the original task loaded
> with BLOCK.

That's likely it. Reading the polyForth manual it only guarantees contents
between BLOCK ... UPDATE and BUFFER ... UPDATE provided no word that does
I/O is executed. Apparently PF comes with a function BLOCKS that copies a
range of blocks. Presumably it's multi-tasking friendly.

[Anton Ertl]

dxforth <dxf...@gmail.com> writes:
>On 11/03/2023 8:56 pm, Anton Ertl wrote:
>> dxforth <dxf...@gmail.com> writes:
>>>> The address of a block buffer returned by BLOCK or BUFFER is transient, with very weak guarantees by the standard to a program. This address becomes invalid after any next performing of BLOCK, BUFFER
>>>
>>> That's depressing. Any idea what might cause the address/contents of BLOCK to
>>> become invalid when BUFFER is executed?
>>
>> 1) If BUFFER needs a buffer and chooses the same one (e.g., in Gforth
>> even without multi-tasking).
>
>BUFFER doesn't read. How would the contents change?

In Gforth BUFFER just calls BLOCK, and that reads.

[dxforth]

On 11/03/2023 9:38 pm, albert wrote:
>
> Using blocks is inherently more difficult than files, and any
> newbies are strongly advised against using blocks, if files are
> available.

The Standard makes the writing of programs difficult by postulating
a hypothetical least common denominator. It's much easier writing
for a real system.

[minf...@arcor.de]

Anton Ertl schrieb am Samstag, 11. März 2023 um 12:23:03 UTC+1:
> dxforth <dxf...@gmail.com> writes:
> >On 11/03/2023 8:56 pm, Anton Ertl wrote:
> >> dxforth <dxf...@gmail.com> writes:
> >>>> The address of a block buffer returned by BLOCK or BUFFER is transient, with very weak guarantees by the standard to a program. This address becomes invalid after any next performing of BLOCK, BUFFER
> >>>
> >>> That's depressing. Any idea what might cause the address/contents of BLOCK to
> >>> become invalid when BUFFER is executed?
> >>
> >> 1) If BUFFER needs a buffer and chooses the same one (e.g., in Gforth
> >> even without multi-tasking).
> >
> >BUFFER doesn't read. How would the contents change?
> In Gforth BUFFER just calls BLOCK, and that reads.

Shouldn't it be the other way round? Somewhat in the line of

: BLOCK \ ( ub -- adr ) 7.6.1.0800 provide block in assigned buffer
dup buffer dup (update-flag-set?)
IF nip ELSE tuck swap (read-block-from-file) (reset-update-flag) THEN ;

[Van Kichline]

On Friday, March 10, 2023 at 9:46:37 PM UTC-8, Brian Fox wrote:
> Not sure if this works on GForth but some older systems kept a cell
> just before the buffer address that contained the block number
> and the update flag. This was how HsForth did it.
>
> In those systems copy was:
>
> : COPY ( from to -- ) FLUSH SWAP BLOCK CELL- ! UPDATE ;
>
> Quite clever and even simpler.

That's what I (almost) recalled, from looking at a FIG Forth editor some time back which I can no longer locate. I scoured the gForth docs for any mention of such organization, but found none. In general the docs didn't touch on implementation, so it may be so, but it doesn't seem safe to assume. Thanks for clarifying that, though.

[S Jack]

On Saturday, March 11, 2023 at 2:02:34 PM UTC-6, Van Kichline wrote:

I like block files and wouldn't care for a Forth that doesn't support
them. The way they worked originally, as in FigForth, I find neat. I
also like the simple coding of the Fig editor. I use Vim editor for my
everyday editing needs. Of course the Fig editor is not going to
compete with that but I make point to use blocks and the simple editor
where I can.

It seems blocks are of little interest to the standard community. You
may be better served by looking at original block code to see how
they worked. You can get copy of a DOS FigForth in below link.
The Fig editor is also contained in the zip.

https://archives.scovetta.com/pub/power_programming/FORTH/FIG_4TH.ZIP
--
me

[Van Kichline]

Thanks! I did not have this, will dig into it.

[Van Kichline]

On Saturday, March 11, 2023 at 12:23:43 AM UTC-8, Ruvim wrote:
...

> : copy-block ( u.block-from u.block-to -- )
> swap block tmp 1024 move
> tmp swap buffer 1024 move
> update
> save-buffers \ it's optional
> ;

...
> Ruvim

Thanks! While I have plenty of buffers on hand now, I am aiming for embedded systems in the future and this may help me prevent issues a year or two down the road.
After relying on search engines for doing Forth research for a month, posting here and getting excellent feedback has been a delight!

[Brian Fox]

On Saturday, March 11, 2023 at 3:11:16 PM UTC-5, S Jack wrote:
> On Saturday, March 11, 2023 at 2:02:34 PM UTC-6, Van Kichline wrote:
>
> I like block files and wouldn't care for a Forth that doesn't support
> them. The way they worked originally, as in FigForth, I find neat. I
> also like the simple coding of the Fig editor. I use Vim editor for my
> everyday editing needs. Of course the Fig editor is not going to
> compete with that but I make point to use blocks and the simple editor
> where I can.

Not sure if this is of any interest to you but I took a run at adding more
VI features to Sam Falvo's VIBE editor for blocks.

The code is here:
https://github.com/bfox9900/VIBE99/blob/main/src/VIBE9980.FTH

The preamble at the top conditionally loads a bunch of stuff because
my iteration of Camel Forth is just 8K, mostly CORE.
(NEEDS FROM is my way to make a tiny conditional compilation tool)

It might not be too tough to port it to another system however.

The biggest not portable part is the copy buffer called TEMP.
TEMP uses video RAM. If you changed TEMP to a BUFFER:
and replace VREAD and VWRITE with MOVE it would be
closer to ready for a conventional Forth system. (no promises)
And replace VTYPE with TYPE.

If nothing else it's beginning to create what you like in VI for blocks.
I can't go much farther with 24K of RAM for code. :-)))

[dxforth]

On 11/03/2023 10:17 pm, Anton Ertl wrote:
> dxforth <dxf...@gmail.com> writes:
>> On 11/03/2023 8:56 pm, Anton Ertl wrote:
>>> dxforth <dxf...@gmail.com> writes:
>>>>> The address of a block buffer returned by BLOCK or BUFFER is transient, with very weak guarantees by the standard to a program. This address becomes invalid after any next performing of BLOCK, BUFFER
>>>>
>>>> That's depressing. Any idea what might cause the address/contents of BLOCK to
>>>> become invalid when BUFFER is executed?
>>>
>>> 1) If BUFFER needs a buffer and chooses the same one (e.g., in Gforth
>>> even without multi-tasking).
>>
>> BUFFER doesn't read. How would the contents change?
>
> In Gforth BUFFER just calls BLOCK, and that reads.

So that leaves multi-tasking as the only reason for ANS' requirement an
interim buffer be used to copy a block. The simplified code posted would
work on Gforth and majority of systems in use today?

[dxforth]

When editing screens some way to insert/delete blocks comes in handy.
Not sure how many systems support that.

[dxforth]

Gforth it's defined : BUFFER BLOCK ;

Since BLOCK contains the functionality of BUFFER it begs the question why
not factor it out as tradition and everyone else has done.

[Andy Valencia]

S Jack <sdwj...@gmail.com> writes:
> I like block files and wouldn't care for a Forth that doesn't support
> them. The way they worked originally, as in FigForth, I find neat. I
> also like the simple coding of the Fig editor.

I should mention my block editor with vim-ish key bindings:

https://vsta.org/cgi-bin/fview.py?path=/src/vi.txt

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

[Van Kichline]

On Saturday, March 11, 2023 at 7:50:06 PM UTC-8, Andy Valencia wrote:
> I should mention my block editor with vim-ish key bindings:
>
> https://vsta.org/cgi-bin/fview.py?path=/src/vi.txt
>
> Andy Valencia
> Home page: https://www.vsta.org/andy/
> To contact me: https://www.vsta.org/contact/andy.html

I will give this a try, thanks!

[Anton Ertl]

"minf...@arcor.de" <minf...@arcor.de> writes:

>Anton Ertl schrieb am Samstag, 11. M=C3=A4rz 2023 um 12:23:03 UTC+1:
>> In Gforth BUFFER just calls BLOCK, and that reads.
>
>Shouldn't it be the other way round? Somewhat in the line of
>
>: BLOCK \ ( ub -- adr ) 7.6.1.0800 provide block in assigned buffer
> dup buffer dup (update-flag-set?)
> IF nip ELSE tuck swap (read-block-from-file) (reset-update-flag) THEN ;

Yes, now I think that the idea is that block calls buffer. The
current implementation of BUFFER in Gforth is actually the same as the
very first implementation of buffer I wrote in 1994:

(Bernd Paysan 1998-12-13) : buffer ( u -- a-addr ) \ block
(Neal Crook 1999-04-16)[documentation, not shown here]
(Anton Ertl 1994-08-10) \ reading in the block is unnecessary, but simpler
(Anton Ertl 1994-08-10) block ;

I can only guess at why I did it this way at the time: Apparently
despite having used blocks from 1983 to the late 1980s, I did not
understand them well enough at the time to know exactly what the point
of BUFFER is, and that despite the reading taking a noticable amount
of time (I used blocks on a C64 with floppy disks); I guess it was not
that often that I wanted to just write a block from scratch.

And Bernd Paysan kept this BUFFER implementation in his multi-buffer
revision, intended for better performance. He had worked extensively
with blocks, too, and blocked.fb in Gforth is from him.

Makes me wonder if the non-reading BUFFER is just a too-complex
interface, or if I just used the wrong source material to learn it
(Ronald Zech's book was my primary source for learning Forth).

[Anton Ertl]

dxforth <dxf...@gmail.com> writes:
>> In Gforth BUFFER just calls BLOCK, and that reads.
>
>So that leaves multi-tasking as the only reason for ANS' requirement an
>interim buffer be used to copy a block. The simplified code posted would
>work on Gforth and majority of systems in use today?

If you mean

|: copy-block ( from to -- )
| swap block swap buffer 1024 move update ;

from <tuhh4p$2dn7r$1...@dont-email.me>, that would fail with Gforth for
certain values of from and to.

[dxforth]

On 12/03/2023 7:55 pm, Anton Ertl wrote:
> dxforth <dxf...@gmail.com> writes:
>>> In Gforth BUFFER just calls BLOCK, and that reads.
>>
>> So that leaves multi-tasking as the only reason for ANS' requirement an
>> interim buffer be used to copy a block. The simplified code posted would
>> work on Gforth and majority of systems in use today?
>
> If you mean
>
> |: copy-block ( from to -- )
> | swap block swap buffer 1024 move update ;
>
> from <tuhh4p$2dn7r$1...@dont-email.me>, that would fail with Gforth for
> certain values of from and to.

Why - what's special about that code whereby certain values would fail?

[none albert]

In article <167859284307.22763....@media.vsta.org>,

Andy Valencia <van...@vsta.org> wrote:
>S Jack <sdwj...@gmail.com> writes:
>> I like block files and wouldn't care for a Forth that doesn't support
>> them. The way they worked originally, as in FigForth, I find neat. I
>> also like the simple coding of the Fig editor.
>
>I should mention my block editor with vim-ish key bindings:
>
>https://vsta.org/cgi-bin/fview.py?path=/src/vi.txt

My editor with wordstar key bindings may be interesting.
mina version of ciforth works in DOSBOX and have full screen
editing mode, see the chapter of editing commands.
It accesses the video memory directly. It is a decendant
of my Osborne (CP/M) editor. (63 K + 1k video memory ).
I've seen no other editors that can copy a multi line definition
easily from one screen to the next. (It piles up lines
at the bottom of the screen, the pulls it in editing the
target screen.)

>
>Andy Valencia
>Home page: https://www.vsta.org/andy/
>To contact me: https://www.vsta.org/contact/andy.html

[none albert]

In article <2023Mar1...@mips.complang.tuwien.ac.at>,
Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
<SNIP>

>
>Makes me wonder if the non-reading BUFFER is just a too-complex
>interface, or if I just used the wrong source material to learn it
>(Ronald Zech's book was my primary source for learning Forth).

It comes from the old times hardware capabilities.
This was the time only IBM had 8" floppies, not available and
certainly not affordable.
Allocating a buffer for block 1000 with no previous content saves the
time spooling the tape to nearly the end. Arie Kattenberg had a block
system working on the digital Philips micro cassette recorder, that
was accessable by block number, relatively fast, but what matters
more, you had not position a tape recorder by hand.
This strategy saves you a ton of waiting time.
Imagine you working on a project with 8 blocks. You can
work mostly in cache. Then you take a coffee break and
type FLUSH. I still posses that hardware.

In ciforth I have not bothered to change the original fig-forth
source, w.r.t allocation, that works fine.
For the WANT system I needed locking the block in memory,
and later I discovered that the buffers came in handy for
implementing a classical INCLUDE that works line-by-line.
In general I lock blocks, files and in this case buffers in
memory for interpreting the content.

I changed UPDATE to write with no delay. Delaying write does
not make sense for blocks allocated in files.
Editing blocks is rare. Maybe a user wants changing a
line in a preference block, or an address that is
different in Raspberry pi from 1 to 2.
That is much simpler in vi in overtype mode, just
take care not to change the line length.

>- anton

[Anton Ertl]

Remember:

4 block hex. $5601034AB198 ok
68 block hex. $5601034AB198 ok

So if you use 4 68 COPY-BLOCK, $5601034AB198 will contain block 68 and
MOVE will see the same from and to addresses, so it will not do
anything. And the end result will be that block 68 will be unchanged.

[Van Kichline]

On Sunday, March 12, 2023 at 9:28:10 AM UTC-7, Anton Ertl wrote:
...

> >Why - what's special about that code whereby certain values would fail?
> Remember:
> 4 block hex. $5601034AB198 ok
> 68 block hex. $5601034AB198 ok

...

True, in gForth I find any two blocks or buffers with a separation divisible by 32 yield the same address. (32 being the number of buffers allocated.)
That makes utility copying quite risky without the interim buffer.
I did not anticipate that. Thanks!

[dxforth]

On 13/03/2023 3:24 am, Anton Ertl wrote:
> dxforth <dxf...@gmail.com> writes:
>> On 12/03/2023 7:55 pm, Anton Ertl wrote:
>>> dxforth <dxf...@gmail.com> writes:
>>>>> In Gforth BUFFER just calls BLOCK, and that reads.
>>>>
>>>> So that leaves multi-tasking as the only reason for ANS' requirement an
>>>> interim buffer be used to copy a block. The simplified code posted would
>>>> work on Gforth and majority of systems in use today?
>>>
>>> If you mean
>>>
>>> |: copy-block ( from to -- )
>>> | swap block swap buffer 1024 move update ;
>>>
>>> from <tuhh4p$2dn7r$1...@dont-email.me>, that would fail with Gforth for
>>> certain values of from and to.
>>
>> Why - what's special about that code whereby certain values would fail?
>
> Remember:
>
> 4 block hex. $5601034AB198 ok
> 68 block hex. $5601034AB198 ok
>
> So if you use 4 68 COPY-BLOCK, $5601034AB198 will contain block 68 and
> MOVE will see the same from and to addresses, so it will not do
> anything. And the end result will be that block 68 will be unchanged.

The problem surely is that you implemented BUFFER with BLOCK (arguably
contrary to ANS) and the latter reads. Even this wouldn't have been a
problem had you implemented a working LRU buffer selection scheme. It's
these two departures from convention in combination that causes Gforth
to fail - not copy-block.