microFORTH

[JUERGEN]

microFORTH documentation is available on the FORTH, INC. website. Not a new product - but many here will probably remember it. And might have a look after many years ...

+++++++++++++++++++++++++++++++++++++++++++++++++
Forth has been around a long time. It would be a mistake to look at any of these early systems and think they represent today’s standards-based, commercial-grade Forth products. However, there is much to learn from the work of others and Forth’s history is studded with some stunning examples of both systems and applications.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


https://www.forth.com/resources/archive-forth-systems-software/

[HAA]

Thanks for that.

I never knew Fig-Forth was *that* close to microFORTH. I had assumed
0 VARIABLE <BUILDS END etc were a Fig-Forth invention.

[Elizabeth D. Rather]

According to Don Colburn, writing in the History of Programming Languages
paper http://www.forth.com/resources/forth-programming-language/ the first
figForth was written by Maj. Robert Selzer, who had used microFORTH for an
AMI 6800 development system on an Army project and was privately developing
a standalone editor/assembler/linker package for the 6502. Selzer wrote a
6502 Forth assembler, and used the Army’s microFORTH metacompiler to target
compile the first 6502 stand-alone Forth for the Jolt single board computer.
He completed the project with Bill Ragsdale, who used it in his business
and then published it for FIG.

Cheers,
Elizabeth

--
Elizabeth D. Rather
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA 90045
USA

[lehs]

Interesting indeed! I had heard that Bill Ragsdale somehow had come
in contact with Forth, but not how.

The ideas behind Forth bubbled up at that time: stacks, RPN, interactive
And structured programming, micro processors etc. The puzzle had begun
added, but Charles Moore seems to be the predestinated inventor.
And thanks for that! His concept is outstanding.

As the ancient compiler concept, translating from traditional formulas to
machine code, is the seed to the dominating computer science, the
canonical simplicity is the good soil for an eventual future.

[David Schultz]

On 04/25/2017 03:15 AM, JUERGEN wrote:
> microFORTH documentation is available on the FORTH, INC. website. Not
> a new product - but many here will probably remember it. And might
> have a look after many years ...
>

I don't know how useful it is, unless you want examples of bugs.

It starts off with the definition of LOAD:

: LOAD BLK C@ <R IN @ <R 0 IN ! 8* OFFSET @ + F9F DROP
BLK ! INTERPRET R> IN ! R> BLK C! ;

The value in BLK is saved and restored using C@ and C! yet it has to
have a larger range than that and the new value is set using !.

Plus most of the code is missing.


--
David W. Schultz
http://home.earthlink.net/~david.schultz
"Life without stock is barely worth living..." - Anthony Bourdain

[rickman]

On 4/30/2017 4:02 PM, David Schultz wrote:
> On 04/25/2017 03:15 AM, JUERGEN wrote:
>> microFORTH documentation is available on the FORTH, INC. website. Not
>> a new product - but many here will probably remember it. And might
>> have a look after many years ...
>>
>
> I don't know how useful it is, unless you want examples of bugs.
>
> It starts off with the definition of LOAD:
>
> : LOAD BLK C@ <R IN @ <R 0 IN ! 8* OFFSET @ + F9F DROP
> BLK ! INTERPRET R> IN ! R> BLK C! ;
>
> The value in BLK is saved and restored using C@ and C! yet it has to
> have a larger range than that and the new value is set using !.
>
> Plus most of the code is missing.

What is <R ? I can't find that word in win32forth.

--

Rick C

[HAA]

A closer look at microFORTH reveals it was also quite different from Forth
we know today. There was no AGAIN or REPEAT. UNTIL was called END.
Backslash '\' was COMPILE. WHILE worked like REPEAT but resolved a
preceding IF/ELSE. FILL had no resemblance to today's word.

In comparison Fig-Forth, which came out not long after, looks relatively
modern. So while Fig-Forth's origin may have been microFORTH, its
influences appear to have extended well beyond.

[David Schultz]

On 04/30/2017 08:13 PM, rickman wrote:
> What is <R ? I can't find that word in win32forth.
>

>R

[HAA]

David Schultz wrote:
> On 04/25/2017 03:15 AM, JUERGEN wrote:
> > microFORTH documentation is available on the FORTH, INC. website. Not
> > a new product - but many here will probably remember it. And might
> > have a look after many years ...
> >
>
> I don't know how useful it is, unless you want examples of bugs.
>
> It starts off with the definition of LOAD:
>
> : LOAD BLK C@ <R IN @ <R 0 IN ! 8* OFFSET @ + F9F DROP
> BLK ! INTERPRET R> IN ! R> BLK C! ;
>
> The value in BLK is saved and restored using C@ and C! yet it has to
> have a larger range than that and the new value is set using !.
>
> Plus most of the code is missing.

It seems a little too obvious to be a bug - besides which it would only
limit the range of screens on which the word LOAD could appear.
I would reserve judgement until I saw the entire code. I assume the
distribution disk contained a boot image representing the forth kernel
which then loads screen 3.

[rickman]

On 4/30/2017 9:24 PM, David Schultz wrote:
> On 04/30/2017 08:13 PM, rickman wrote:
>> What is <R ? I can't find that word in win32forth.
>>
>
> R

see R
^
Error(-13): R is undefined

--

Rick C

[Elizabeth D. Rather]

On 5/1/17 2:36 PM, HAA wrote:
> David Schultz wrote:
>> On 04/25/2017 03:15 AM, JUERGEN wrote:
>>> microFORTH documentation is available on the FORTH, INC. website. Not
>>> a new product - but many here will probably remember it. And might
>>> have a look after many years ...
>>>
>>
>> I don't know how useful it is, unless you want examples of bugs.
>>
>> It starts off with the definition of LOAD:
>>
>> : LOAD BLK C@ <R IN @ <R 0 IN ! 8* OFFSET @ + F9F DROP
>> BLK ! INTERPRET R> IN ! R> BLK C! ;
>>
>> The value in BLK is saved and restored using C@ and C! yet it has to
>> have a larger range than that and the new value is set using !.

Actually, this is for the 1802, which had a development system using
250K floppies! This is 1978, folks. And BLK is a user variable, so it
had to be 16 bits. That ! is pretty tacky, but it wouldn't cause a
failure. Obviously the "endianness" worked ok.

>> Plus most of the code is missing.

Um, no, actually, this is all of it, including the assembler, compiler,
text editor, source printing utility, metacompiler, and code for the
kernel. We wrote a bunch of completed applications with it.

> It seems a little too obvious to be a bug - besides which it would only
> limit the range of screens on which the word LOAD could appear.
> I would reserve judgement until I saw the entire code. I assume the
> distribution disk contained a boot image representing the forth kernel
> which then loads screen 3.

Yes, that's correct. The bootstrap was in 0 and the precompiled kernel
is in 1 and 2.

[HAA]

Elizabeth D. Rather wrote:
> On 5/1/17 2:36 PM, HAA wrote:
> > David Schultz wrote:
> >> On 04/25/2017 03:15 AM, JUERGEN wrote:
> >>> microFORTH documentation is available on the FORTH, INC. website. Not
> >>> a new product - but many here will probably remember it. And might
> >>> have a look after many years ...
> >>>
> >>
> >> I don't know how useful it is, unless you want examples of bugs.
> >>
> >> It starts off with the definition of LOAD:
> >>
> >> : LOAD BLK C@ <R IN @ <R 0 IN ! 8* OFFSET @ + F9F DROP
> >> BLK ! INTERPRET R> IN ! R> BLK C! ;
> >>
> >> The value in BLK is saved and restored using C@ and C! yet it has to
> >> have a larger range than that and the new value is set using !.
>
> Actually, this is for the 1802, which had a development system using
> 250K floppies! This is 1978, folks. And BLK is a user variable, so it
> had to be 16 bits. That ! is pretty tacky, but it wouldn't cause a
> failure. Obviously the "endianness" worked ok.

'blocks' were 128 bytes. While any screen on the disk could be LOADed
thanks to ! , the C@ C! would limit use of the word "LOAD" to screens 1-31
by my calculation. Not a big deal for floppy size storage.

>
> >> Plus most of the code is missing.
>
> Um, no, actually, this is all of it, including the assembler, compiler,
> text editor, source printing utility, metacompiler, and code for the
> kernel. We wrote a bunch of completed applications with it.

There does appear to be some source that's missing - INTERPRET,
WORD, BLOCK etc and parts of the run-time e.g. WHILE.

>
> > It seems a little too obvious to be a bug - besides which it would only
> > limit the range of screens on which the word LOAD could appear.
> > I would reserve judgement until I saw the entire code. I assume the
> > distribution disk contained a boot image representing the forth kernel
> > which then loads screen 3.
>
> Yes, that's correct. The bootstrap was in 0 and the precompiled kernel
> is in 1 and 2.
>
> Cheers,
> Elizabeth

Perhaps someone who still has disks can dump the image. I notice there's
been a revival of interest in 1802 Forths e.g. CamelForth and others.
http://www.retrotechnology.com/memship/figforth_1802.html

[hughag...@gmail.com]

On Monday, May 1, 2017 at 8:02:00 PM UTC-7, HAA wrote:
> Elizabeth D. Rather wrote:
> > On 5/1/17 2:36 PM, HAA wrote:
> > > David Schultz wrote:
> > >> On 04/25/2017 03:15 AM, JUERGEN wrote:
> > >>> microFORTH documentation is available on the FORTH, INC. website. Not
> > >>> a new product - but many here will probably remember it. And might
> > >>> have a look after many years ...
> > >>>
> > >>
> > >> I don't know how useful it is, unless you want examples of bugs.
> > >>
> > >> It starts off with the definition of LOAD:
> > >>
> > >> : LOAD BLK C@ <R IN @ <R 0 IN ! 8* OFFSET @ + F9F DROP
> > >> BLK ! INTERPRET R> IN ! R> BLK C! ;
> > >>
> > >> The value in BLK is saved and restored using C@ and C! yet it has to
> > >> have a larger range than that and the new value is set using !.
> >
> > Actually, this is for the 1802, which had a development system using
> > 250K floppies! This is 1978, folks. And BLK is a user variable, so it
> > had to be 16 bits. That ! is pretty tacky, but it wouldn't cause a
> > failure. Obviously the "endianness" worked ok.
>
> 'blocks' were 128 bytes. While any screen on the disk could be LOADed
> thanks to ! , the C@ C! would limit use of the word "LOAD" to screens 1-31
> by my calculation. Not a big deal for floppy size storage.

It was a bug --- using C@ C! sometimes and @ ! other times --- that is definitely a bug!

It is irrelevant if this happened to work because the range was small and the machine was little-endian -- it is never a good idea to try to explain away a bug as a feature --- it is best to just admit that it is a bug.

[hughag...@gmail.com]

Note that I'm not criticizing Charles Moore for having a bug in his MicroForth --- bugs happen, and I'm sure he would have fixed it right away if he had noticed it --- he presumably did fix it in PolyForth, which was the next Forth system that he wrote.

I'm saying that claiming that a bug isn't a bug is a bad idea --- this is why all Forth Inc. software after 1982 was bug-ridden --- nobody wanted to fix bugs, but instead they claimed that they didn't have bugs, and Elizabeth Rather was okay with that.

[HAA]

HAA wrote:
> Elizabeth D. Rather wrote:
> > On 5/1/17 2:36 PM, HAA wrote:
> > > David Schultz wrote:
> > >> On 04/25/2017 03:15 AM, JUERGEN wrote:
> > >>> microFORTH documentation is available on the FORTH, INC. website. Not
> > >>> a new product - but many here will probably remember it. And might
> > >>> have a look after many years ...
> > >>>
> > >>
> > >> I don't know how useful it is, unless you want examples of bugs.
> > >>
> > >> It starts off with the definition of LOAD:
> > >>
> > >> : LOAD BLK C@ <R IN @ <R 0 IN ! 8* OFFSET @ + F9F DROP
> > >> BLK ! INTERPRET R> IN ! R> BLK C! ;
> > >>
> > >> The value in BLK is saved and restored using C@ and C! yet it has to
> > >> have a larger range than that and the new value is set using !.
> >
> > Actually, this is for the 1802, which had a development system using
> > 250K floppies! This is 1978, folks. And BLK is a user variable, so it
> > had to be 16 bits. That ! is pretty tacky, but it wouldn't cause a
> > failure. Obviously the "endianness" worked ok.
>
> 'blocks' were 128 bytes. While any screen on the disk could be LOADed
> thanks to ! , the C@ C! would limit use of the word "LOAD" to screens 1-31
> by my calculation. Not a big deal for floppy size storage.

Correction. According to the tech manual BLK is allocated one byte but
is permitted to overlap IN which is two bytes. Hence the confusing mix
of byte/word operators in dealing with BLK. How WORD handles the IN
overlap would be interesting to know.

BTW BASE is also one byte (to save space).

[HAA]

hughag...@gmail.com wrote:
> ...

> Note that I'm not criticizing Charles Moore for having a bug in his MicroForth --- bugs
> happen, and I'm sure he would have fixed it right away if he had noticed it --- he
> presumably did fix it in PolyForth, which was the next Forth system that he wrote.

It turns out it was 'a feature not a bug'. A confusing one all the same and perhaps
more trouble than worth. I recall PolyForth using the same (user?) variable for two
mutually exclusive purposes. That at least was clean and simple.

[JUERGEN]

There is the EMMA2 simulator, but we took it a step further. Steve Teal did me a big favour to design an 1802 IP, running on a low cost ICE40 8k board - the ony one ww that has an open source tool chain.
FIG-Forth Manual is now part of the Forth Bookshelf at https://www.amazon.co.uk/Juergen-Pintaske/e/B00N8HVEZM and more details at https://wiki.forth-ev.de/doku.php/projects:fig-forth-1802-fpga:start.
You find an image to flash the FPGA there. And the github link to the 1802 IP.
We are still looking for a complete source for microFORTH, but FORTH,INC was kind enough already to release the information on their website. And we hope to get it running on the same board at some time. Why? Retro, fun and good memories.

[Elizabeth D. Rather]

microForth was mostly written by Dean Sanderson. polyFORTH was a team
effort, including Chuck, Dean, Greg Bailey, and a few others.

[Andrew Haley]

David Schultz <ab...@127.0.0.1> wrote:
> On 04/25/2017 03:15 AM, JUERGEN wrote:
>> microFORTH documentation is available on the FORTH, INC. website. Not
>> a new product - but many here will probably remember it. And might
>> have a look after many years ...
>>
>
> I don't know how useful it is, unless you want examples of bugs.
>
> It starts off with the definition of LOAD:
>
> : LOAD BLK C@ <R IN @ <R 0 IN ! 8* OFFSET @ + F9F DROP
> BLK ! INTERPRET R> IN ! R> BLK C! ;
>
> The value in BLK is saved and restored using C@ and C! yet it has to
> have a larger range than that and the new value is set using !.

From what I remember COSMAC disk drives were about 80k bytes.

> Plus most of the code is missing.

MicroFORTH shipped with a precompiled nucleus of less than a kbyte and
the rest of system built on top of that. I think Maj. Seltzer had
more than just MicroFORTH.

Andrew.

[Andrew Haley]

Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
> David Schultz <ab...@127.0.0.1> wrote:
>> On 04/25/2017 03:15 AM, JUERGEN wrote:
>>> microFORTH documentation is available on the FORTH, INC. website. Not
>>> a new product - but many here will probably remember it. And might
>>> have a look after many years ...
>>>
>>
>> I don't know how useful it is, unless you want examples of bugs.
>>
>> It starts off with the definition of LOAD:
>>
>> : LOAD BLK C@ <R IN @ <R 0 IN ! 8* OFFSET @ + F9F DROP
>> BLK ! INTERPRET R> IN ! R> BLK C! ;
>>
>> The value in BLK is saved and restored using C@ and C! yet it has to
>> have a larger range than that and the new value is set using !.
>
> From what I remember COSMAC disk drives were about 80k bytes.

Never mind that answer: the correct one followed later.

Andrew.

[Rod Pemberton]

If you were joking, I didn't find that funny at all.
If you were serious, it's time to get a real newsreader.


Rod Pemberton
--
"Well, many people are really f---ing stupid too. Should we just adopt
all their standards?" - George Carlin

[Howerd]

Hi Andrew,

IIRC the COSMAC had two 160K 8 inch floppies.

OMG this was 39 years ago...
If I am correct this is longer retention than some FLASH chips and all CDs...
Of course I may have dropped a bit or two ;-)

Cheers,
Howerd

[Coos Haak]

Op Mon, 1 May 2017 21:02:44 -0400 schreef rickman:

<R is a very old version of >R
R is an old version of R@

groet Coos

[rickman]

Thanks. Seems David typed >R at the beginning of a line which my
newsreader saw as a quoted line. There are many issues when trying to
communicate with Forth code in the message. It can really mess up
punctuation and vice versa.

--

Rick C

[hughag...@gmail.com]

On Monday, May 1, 2017 at 8:02:00 PM UTC-7, HAA wrote:

> Elizabeth D. Rather wrote:
> > On 5/1/17 2:36 PM, HAA wrote:
> > > David Schultz wrote:
> > >> On 04/25/2017 03:15 AM, JUERGEN wrote:
> > >>> microFORTH documentation is available on the FORTH, INC. website. Not
> > >>> a new product - but many here will probably remember it. And might
> > >>> have a look after many years ...
> > >>>
> > >>
> > >> I don't know how useful it is, unless you want examples of bugs.
> > >>
> > >> It starts off with the definition of LOAD:
> > >>
> > >> : LOAD BLK C@ <R IN @ <R 0 IN ! 8* OFFSET @ + F9F DROP
> > >> BLK ! INTERPRET R> IN ! R> BLK C! ;
> > >>
> > >> The value in BLK is saved and restored using C@ and C! yet it has to
> > >> have a larger range than that and the new value is set using !.
> >
> > Actually, this is for the 1802, which had a development system using
> > 250K floppies! This is 1978, folks. And BLK is a user variable, so it
> > had to be 16 bits. That ! is pretty tacky, but it wouldn't cause a
> > failure. Obviously the "endianness" worked ok.
>
> 'blocks' were 128 bytes. While any screen on the disk could be LOADed
> thanks to ! , the C@ C! would limit use of the word "LOAD" to screens 1-31
> by my calculation. Not a big deal for floppy size storage.

C@ doesn't sign extend --- not nowadays anyway --- so the range would have been [0,255].

If the floppies were 250KB, and the processor was little-endien, the code would have worked despite the bug.

[Elizabeth D. Rather]

Ah, the good old days. My memory of enormous 250K floppies is clearly
from a later, happier era.

[HAA]

There's no bug. When referencing a disk block, BLK is 16 bits.
However as BLK and IN represent 3 contiguous bytes, a mix of
C@ C! ! @ were needed to save/restore/zero both BLK and IN.

[hughag...@gmail.com]

You need BLK to be 16-bit because there may be more than 255 blocks.

You need >IN to be 16-bit because the block has 1024 bytes, which is more than 256.

This seems like a weird attempt to explain away a blatant bug.

As I said before, this is why all Forth Inc. software after 1982 is bug-ridden. The Forth Inc. employees have the attitude that they are perfect, like angels, and they never make any mistakes --- they never have any bugs, gosh no! --- bugs get explained away, and they stay in the code forever without getting fixed.

They may have gotten away with this bug on early systems because the disk had less than 256 blocks, and the processor was little-endian --- it is still a bug though --- it will definitely bite you when you upgrade your system to use a disk with more than 256 blocks (which should have been easy to predict, even in the 1970s when 256KB seemed like a lot).

[Andrew Haley]

HAA <som...@microsoft.com> wrote:

> There's no bug. When referencing a disk block, BLK is 16 bits.
> However as BLK and IN represent 3 contiguous bytes, a mix of
> C@ C! ! @ were needed to save/restore/zero both BLK and IN.

Oh yes, and blocks were only 128 bytes so there was no need for >IN to
be more than one byte. How very Dean. :-)

Andrew.

[David Schultz]

On 05/02/2017 10:44 AM, rickman wrote:
> Thanks. Seems David typed >R at the beginning of a line which my
> newsreader saw as a quoted line. There are many issues when trying to
> communicate with Forth code in the message. It can really mess up
> punctuation and vice versa.
>

Sorry about that. I forget that these modern newreaders do things to
format code for presentation.

I like being able to copy things to folders in Thunderbird but I kind of
miss trn.

I also apologize for the late response. Earthlink foobared their Usenet
access on Monday (outsourced to GigaNews) and restored it today.

[David Schultz]

On 05/01/2017 08:20 PM, Elizabeth D. Rather wrote:
> Um, no, actually, this is all of it, including the assembler, compiler,
> text editor, source printing utility, metacompiler, and code for the
> kernel. We wrote a bunch of completed applications with it.

I don't see any code for the kernel, source or binary. I see a screen
with addresses for a bunch of code in the first block but nothing else.
For example, CZ is at address 0xff but what code is there?

[David Schultz]

On 05/02/2017 07:43 PM, HAA wrote:

> There's no bug. When referencing a disk block, BLK is 16 bits.
> However as BLK and IN represent 3 contiguous bytes, a mix of
> C@ C! ! @ were needed to save/restore/zero both BLK and IN.
>

How does that work?

If BLK is zero then input is from the terminal. This implies that the
high byte of IN is also zero. Which would be fine.

But if BLK is non-zero then IN cannot be used as is to index into the
block. Something else must be done. It could be as simple as "IN 1+ C@"
but that means that the code to interpret a disk block is different from
the code to interpret a line from the terminal.

Kind of making that saving one byte of user variable storage moot.

Of course if ALL of the code were present we could see how it is done.

[David Schultz]

On 05/02/2017 04:11 AM, Andrew Haley wrote:
> From what I remember COSMAC disk drives were about 80k bytes.
>

The standard 8" SSSD disk at the time was 250K. Which matches precisely
the storage capacity listed in the 1982 RCA Microboards manual for the
CDOS dual disk system.

That and "F9F DROP" (DROP later replaced by MIN) establishes an upper
limit on BLK of 3,999 decimal. DR1 is defined on a later screen to store
2,000 into OFFSET.

Or two disks with 250K each.

[Elizabeth D. Rather]

On 5/4/17 12:03 PM, David Schultz wrote:
> On 05/02/2017 07:43 PM, HAA wrote:
>
>> There's no bug. When referencing a disk block, BLK is 16 bits.
>> However as BLK and IN represent 3 contiguous bytes, a mix of
>> C@ C! ! @ were needed to save/restore/zero both BLK and IN.
>>
>
> How does that work?
>
> If BLK is zero then input is from the terminal. This implies that the
> high byte of IN is also zero. Which would be fine.
>
> But if BLK is non-zero then IN cannot be used as is to index into the
> block. Something else must be done. It could be as simple as "IN 1+ C@"
> but that means that the code to interpret a disk block is different from
> the code to interpret a line from the terminal.
>
> Kind of making that saving one byte of user variable storage moot.
>
> Of course if ALL of the code were present we could see how it is done.
>

Depending on endianness, you can define either

BLK 1+ CONSTANT IN or IN 1+ CONSTANT BLK

No need to do the 1+ on every fetch.

[HAA]

David Schultz wrote:
> On 05/02/2017 07:43 PM, HAA wrote:
>
> > There's no bug. When referencing a disk block, BLK is 16 bits.
> > However as BLK and IN represent 3 contiguous bytes, a mix of
> > C@ C! ! @ were needed to save/restore/zero both BLK and IN.
> >
>
> How does that work?
>
> If BLK is zero then input is from the terminal. This implies that the
> high byte of IN is also zero. Which would be fine.
>
> But if BLK is non-zero then IN cannot be used as is to index into the
> block. Something else must be done. It could be as simple as "IN 1+ C@"
> but that means that the code to interpret a disk block is different from
> the code to interpret a line from the terminal.

QUIT suggests TIB is 80 chars in which case BLK= 16 bits, IN= 8 bits
would work without fuss. There must however be an 'other' reason IN
was defined as a 16 bit entry (Appendix A Tech Manual).

>
> Kind of making that saving one byte of user variable storage moot.

microFORTH is like SwiftX in that target apps will likely never use
BLK IN WORD BLOCK etc (the code for these don't reside in the
nucleus). You then have an incentive to keep user area to a
minimum e.g. BASE is 1 byte.

>
> Of course if ALL of the code were present we could see how it is done.

That or a disk dump. Addresses for the nucleus routines 00-01FF are
given in screens 51/52. Headers, interpreter and other code will be
residing elsewhere.

[Jurgen Pitaske]

Now, 6 years later,
I just wonder if there is anybody here who has recently used microFORTH.
So all of the parts are there.
There seem to be conflicting views if the data on the Forth INC. website is complete or not.
The interest here is general, not for project work.
I was able to save some of the old Forth material over the last 10 years
and it is now available on amazon.
https://www.amazon.co.uk/Juergen-Pintaske/e/B00N8HVEZM%3Fref=dbs_a_mng_rwt_scns_share

But this bit is missing unfortunately as part of this collection.