I'm trying to build a copy of F83 from the master file on github, but I'm lost. The command "F83 META68.BLK" doesn't work. I can "OPEN" that file and manually cut and paste the FORTH from screen #1. That gets me dialog as described in the github .MD, but only to a point:

ONLY FORTH ALSO DEFINITIONS ok
DOS ' NOOP IS HEADER ok
FENCE OFF FORGET OUT ok
WARNING OFF ok
: NLOAD CR .S (LOAD) ; ' NLOAD IS LOAD ok
3 21 THRU ( The Meta Compiler )
3
4
...
20
21 ok
ONLY FORTH DEFINITIONS ALSO ok
CR .( Meta Compiler Loaded )
Meta Compiler Loaded ok
FROM KERNEL68.BLK 1 LOAD
1
2
...
91
92
Unresolved references:

Statistics:
Last Host Address: 9596
First Target Code Address: AD00
Last Target Code Address: DC14

Now return to CP/M and type:
KERNEL EXTEND68.BLK <CR>
OK <CR> ok
bye
150 Pages
C>dir
C: F83 68K : F83 BIN : META68 BLK : BASIC BLK : CLOCK BLK
C: CPU68000 BLK : EXPAND68 BLK : EXTEND68 BLK : HUFFMAN BLK : KERNEL68 BLK
C: UTILITY BLK
C>kernel extend68.blk
KERNEL?
C>

There is no "kernel" in the directory! So, what am I doing wrong? The part in the instructions that leaves me scratching my head is "( your input )".. What input? Sorry, but as I said, I'm a FORTH newbie, but I'd really like to build an F83 version that I can run on my 68000 SBC that will load somewhere above $7B00. The version that I'm using (above) loads at $500 (on a different SBC) and that would collide with the 68K CP/M kernel on my target SBC.

I'd greatly appreciate some pointers!

Roger

On 22/02/2023 12:39 pm, Roger Hanscom wrote:
> C>dir
> C: F83 68K : F83 BIN : META68 BLK : BASIC BLK : CLOCK BLK
> C: CPU68000 BLK : EXPAND68 BLK : EXTEND68 BLK : HUFFMAN BLK : KERNEL68 BLK
> C: UTILITY BLK
> C>kernel extend68.blk
> KERNEL?
> C>
>
> There is no "kernel" in the directory! So, what am I doing wrong?

Did you try compiling from drive A ? That's where it's coded to save the kernel.

\ Target System Setup 19Apr84map
ONLY FORTH META ALSO FORTH
HEX A800 ' TARGET-ORIGIN >BODY ! IN-META DECIMAL
2 92 THRU ( System Source Screens ) HEX
CR .( Unresolved references: ) CR .UNRESOLVED
CR .( Statistics: ) CR .( Last Host Address: )
[FORTH] HERE U. CR .( First Target Code Address: )
META 500 THERE U. CR .( Last Target Code Address: )
META HERE-T THERE U. CR CR
DOS HERE-T 4E8 !-T
META 500 1C - THERE HERE-T 100 +
ONLY FORTH ALSO DOS SAVE A:KERNEL.68K FORTH
CR .( Now return to CP/M and type: )
CR .( KERNEL EXTEND68.BLK <CR> ) CR .( OK <CR> ) DECIMAL

On Tuesday, February 21, 2023 at 6:29:21 PM UTC-8, dxforth wrote:

> Did you try compiling from drive A ? That's where it's coded to save the kernel.
.......
> ONLY FORTH ALSO DOS SAVE A:KERNEL.68K FORTH
.......

No, I haven't tried that. Running out of room on A: . I might have to copy a bunch of files around to be able to use A: .

Would it be easier to edit the code? Don't know how to do that.

Also, would you tell me how to "execute" a .BLK file once it is opened?

Roger

On Wednesday, February 22, 2023 at 9:37:40 AM UTC-8, Roger Hanscom wrote:
> On Tuesday, February 21, 2023 at 6:29:21 PM UTC-8, dxforth wrote:
>
> > Did you try compiling from drive A ? That's where it's coded to save the kernel.
> ......
> > ONLY FORTH ALSO DOS SAVE A:KERNEL.68K FORTH
> ......

I looked in the A: drive and found a kernel.68k. So, as an alternative approach, I copied it to the C: drive, and tried to run it:

C>a:pip kernel.68k=a:kernel.68k

C>dir
C: BILL83 68K : F83 BIN : META68 BLK : BASIC BLK : CLOCK BLK
C: CPU68000 BLK : EXPAND68 BLK : EXTEND68 BLK : HUFFMAN BLK : KERNEL68 BLK
C: UTILITY BLK : KERNEL 68K
C>kernel extend68.blk
Insufficient memory or bad file header
C>

Now what??

Roger

On Wednesday, February 22, 2023 at 9:53:47 AM UTC-8, Roger Hanscom wrote:
.....
> I looked in the A: drive and found a kernel.68k. So, as an alternative approach, I copied it to the C: drive, and tried to run it:
......
> Insufficient memory or bad file header
> C>

Through some DDT68000 trickery, I got the KERNEL.68K to run, but I don't know how to pass the EXTEND68.BLK argument to it. There are a number of words that I'm familiar with that might help, but they are unknown. Some of the few base level operations that I'm familiar with do work:

ok
open extend68.blk OPEN ?
OPEN EXTEND68.BLK OPEN ?
words WORDS ?
WORDS WORDS ?
ok
1 triad TRIAD ?
1 TRIAD TRIAD ?
vlist VLIST ?
VLIST VLIST ?
1 2 + . 3 ok
: XYZ CR 11 0 DO CR I . LOOP ; ok
XYZ

0
1
2
3
4
5
6
7
8
9
10 ok

Roger

On 2/21/23 7:39 PM, Roger Hanscom wrote:

> There is no "kernel" in the directory! So, what am I doing wrong? The part in the instructions that leaves me scratching my head is "( your input )". What input? Sorry, but as I said, I'm a FORTH newbie, but I'd really like to build an F83 version that I can run on my 68000 SBC that will load somewhere above $7B00. The version that I'm using (above) loads at $500 (on a different SBC) and that would collide with the 68K CP/M kernel on my target SBC.

Getting it to work at a different address is tricky.

This version uses 16 bit addresses. The straight forward way of doing
that results in the address being sign extended when moved to an address
register. This gives a memory map of 32KB at the bottom of the address
space and 32KB at the top. ($8000 is actually $FF8000)

Looking at KERNEL68.BLK I see they went a different (slower) route.
Addresses get loaded (as 16 bits) into D7 and then there is a 32 bit
move from D7 to the address register. So the upper sixteen bits of D7
are critical to determining where it runs. If that is zero then you have
to be within the first 64KB of memory.

The cold entry point includes:
LONG D7 CLR WORD

Change that for whichever 64K chunk of memory you want to use.

--
http://davesrocketworks.com
David Schultz

On 23/02/2023 7:12 am, David Schultz wrote:
> On 2/21/23 7:39 PM, Roger Hanscom wrote:
>
>> There is no "kernel" in the directory!  So, what am I doing wrong?  The part in the instructions that leaves me scratching my head is "( your input )".  What input?  Sorry, but as I said, I'm a FORTH newbie, but I'd really like to build an F83 version that I can run on my 68000 SBC that will load somewhere above $7B00.  The version that I'm using (above) loads at $500 (on a different SBC) and that would collide with the 68K CP/M kernel on my target SBC.
>
> Getting it to work at a different address is tricky.

Vaguely recalled reading something about that. Chased it down:

'Relocatable F83 for the 68000' R.Eager, Forth Dimensions V9N6

On Wednesday, February 22, 2023 at 6:31:59 PM UTC-8, dxforth wrote:

> Vaguely recalled reading something about that. Chased it down:
>
> 'Relocatable F83 for the 68000' R.Eager, Forth Dimensions V9N6

Thanks! I grabbed the .pdf, and will be studying it.

Roger

On 2/22/23 11:37 AM, Roger Hanscom wrote:
> Would it be easier to edit the code? Don't know how to do that.

F83 has a built in editor. Clearly described in places like:
http://forth.org/OffeteStore/1003_InsideF83.pdf

--
http://davesrocketworks.com
David Schultz

David Schultz <david.schultz@earthlink.net> writes:
> F83 has a built in editor. Clearly described in places like:
> http://forth.org/OffeteStore/1003_InsideF83.pdf

There is also a great book called Inside F83, by C. H. Ting, in case OP
hasn't already seen it. I think there is a copy on forth.org somewhere.

For some reason I thought that F83 only ran on Z80 systems, but I see
mention here of a 68K version. Were there other ports as well? Is it
interesting to think about porting it to modern MCU's?

On 24/02/2023 7:54 am, Paul Rubin wrote:
> David Schultz <david.schultz@earthlink.net> writes:
>> F83 has a built in editor. Clearly described in places like:
>> http://forth.org/OffeteStore/1003_InsideF83.pdf
>
> There is also a great book called Inside F83, by C. H. Ting, in case OP
> hasn't already seen it. I think there is a copy on forth.org somewhere.
>
> For some reason I thought that F83 only ran on Z80 systems, but I see
> mention here of a 68K version. Were there other ports as well?

Original authors Laxen & Perry produced versions for CP/M-80, CP/M-68K
and CP/M-86/MS-DOS. Others then ported it to other CPU's and OS.

> Is it
> interesting to think about porting it to modern MCU's?

Folks loved F83 because it was everything Fig-Forth was not. However
it too succumbed to things like F-PC - which in turn succumbed to ANS.

dxforth <dxforth@gmail.com> writes:
> Folks loved F83 because it was everything Fig-Forth was not. However
> it too succumbed to things like F-PC - which in turn succumbed to ANS.

I thought that F83 had a bunch of utilities and features (editor,
multi-tasking, etc.) and F-PC had even more, while ANS is purely a
language standard. I use gforth which is ANS, but runs mainly on big
machines. And while it is a very complete language implementation, it
doesn't have stuff like multitasking. That's why I was wondering about
porting F83 to modern MCU's.

I think what I really want though is something like Chipforth, if it
works the way I think it does based on mentions of it here on CLF. I
sometimes think of trying to write such a thing, but it is likely a
rabbit hole of not much benefit.

On 2/23/23 9:02 PM, Paul Rubin wrote:
> I thought that F83 had a bunch of utilities and features (editor,
> multi-tasking, etc.) and F-PC had even more, while ANS is purely a
> language standard. I use gforth which is ANS, but runs mainly on big
> machines. And while it is a very complete language implementation, it
> doesn't have stuff like multitasking. That's why I was wondering about
> porting F83 to modern MCU's.
>
It took me a while to wrap my brain around mult-tasking using old issues
of Forth Dimensions but once I did, I added it to my eForth
implementations. (MSP430 and ARM)

--
http://davesrocketworks.com
David Schultz

David Schultz <david.schultz@earthlink.net> writes:
> It took me a while to wrap my brain around mult-tasking using old
> issues of Forth Dimensions but once I did, I added it to my eForth
> implementations. (MSP430 and ARM)

Cool. Brad Rodriguez has a few decent articles about it, but some
details are missing. Also, eForth has a minimal implementation, but
again I think stuff is missing. If you have any Forth Dimensions
articles to recommend, that would be nice.

Paul Rubin <no.email@nospam.invalid> writes:
>I use gforth which is ANS, but runs mainly on big
>machines. And while it is a very complete language implementation, it
>doesn't have stuff like multitasking.

https://gforth.org/manual/Multitasker.html

Note that this documents the development version.

- 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

On 24/02/2023 5:53 pm, Paul Rubin wrote:
> David Schultz <david.schultz@earthlink.net> writes:
>> It took me a while to wrap my brain around mult-tasking using old
>> issues of Forth Dimensions but once I did, I added it to my eForth
>> implementations. (MSP430 and ARM)
>
> Cool. Brad Rodriguez has a few decent articles about it, but some
> details are missing. Also, eForth has a minimal implementation, but
> again I think stuff is missing. If you have any Forth Dimensions
> articles to recommend, that would be nice.

Take your pick

05 2 A Simple Multi-Tasker - Duncan R.
05 2 Simple Forth Multi-Tasking Environment - Petri M.
05 4 Techniques Tutorial: Multi-Tasking 1 - Laxen H.
05 5 Techniques Tutorial: Multi-Tasking 2 - Laxen H.
07 4 Extending The Multi-Tasker: Mailboxes - Dobbins R.
09 6 Multi-Tasking Modem Package - Teza J.
11 5 Multitasking And Controlling Regular Events - Hendtlass T.
18 5 Can POSIX Threads Be Used As A Standard Forth Multi-Tasker? - Carter E.
20 4 How and Why to Use Multitasking - Sergeant F.

What do you feel was missing from the stuff you read? Implementations can
be consulted if explanations are unclear. The only trickery I noted in the
F83 tasker was the use of INT or RST instructions to effect task switch.
AFAIK that's not necessary and a loop would work equally well.

In article <2023Feb24.082528@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Paul Rubin <no.email@nospam.invalid> writes:
>>I use gforth which is ANS, but runs mainly on big
>>machines. And while it is a very complete language implementation, it
>>doesn't have stuff like multitasking.
>
>https://gforth.org/manual/Multitasker.html
>
>Note that this documents the development version.

The FIG tradition of easily modifiable Forth's is not dead!

All versions of ciforth have a multi tasker since time immemorial
after WANT THREAD-COT .
The pre-emptive multi-tasker was demonstrated with a parallel
prime counting program.
The cooperative multi tasking runs portably in all the versions
of ciforth including the 16 bit version. All task have separate
i/o thanks to user variables, and even a private dictionary
space to compile definitions known only with the thread.
The 16 bit version mina.com (MSDOS, windows with Dos Protected
Mode Interface) has 40 Kbyte to spare so I guess it is
possible to do something useful with it.

ciforth is in the FIG tradition of small Forth's, easily extensible.
Also it comes with an assembler source, that can be changed easily
by changing EQU's.

; -------------------
; MEMORY LAYOUT.
; Normally this is specified at the m4 configuration level.
; For a configured system these values can be changed at this single place.
NBUF EQU 8 ; No. of buffers, or screens
KBBUF EQU 1024 ; Data bytes per disk buffer
US EQU 0x40*CW ; User variable space, eats into next data stack, if any.
EM EQU 0x10000 ; Where the memory ends w.r.t. ORIG. 1)
EMP EQU (EM-1)/0x1000+1 ; Number of pages.
TAS EQU 0x0100 ;Size of unitialised area per task.
STACKSIZE EQU TAS/4 ;For both stacks.
TIBSIZE EQU TAS/4 ;TIB size.
; ; -------------------

Examples of changes :
EM can be changed to 0x8000 for a 32 kbyte system.
NBUF can be diminished to 4 (not advisable to go lower than that).

; This version can be assembled on a Linux system in behalf of a
; MS-DOS version by
; nasm -fbin ciforth.asm -o ciforth.com

And of course it builds on a true MSDOS system or a DOSBOX.
The computer factory (running on linux) can generate a version for
other assemblers, e.g. masm if wanted.

Groetjes Albert

>
>- anton
--
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 -

On 24/02/2023 9:06 pm, dxforth wrote:
>
> The only trickery I noted in the
> F83 tasker was the use of INT or RST instructions to effect task switch.

I forgot. F83 didn't have classic USER variables - it had a USER vocabulary.
Just to be different :)

> Folks loved F83 because it was everything Fig-Forth was not.

What you mean, in particular?

BTW I acquired a taste for that „outdated” fig-Forth because of its
simplicity. :) It may even be perhaps slowest of them all, but nowadays
(contrary to the 70s/80s) it's not that serious disadvantage on modern
CPUs, unless one „really really” needs the speed (like 3D-graphics?).

dxforth <dxforth@gmail.com> writes:
> If you have any Forth Dimensions
> > articles to recommend, that would be nice.
> Take your pick
> ...

FWIW, I added a source viewer for my ForthOS (it uses blocks with shadows
for all source):

https://vsta.org/cgi-bin/fview.py?path=/kernel/tasking.txt

Source plus comments on the shadow might be of interest.

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

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> https://gforth.org/manual/Multitasker.html
> Note that this documents the development version.

Oh, neat! But the doc doesn't seem to describe the cooperative
multitasker. It mentions the possibility of multitasking being
standardized. That is interesting too. Is it actually likely, in the
sense of progress being made? Are there any proposed standardization
specs around?

dxforth <dxforth@gmail.com> writes:
> Take your pick ... What do you feel was missing from the stuff you
> read? Implementations can be consulted if explanations are unclear.

Thanks, I will look at those. I previously mostly looked at Brad
Rodriguez's article and the eForth multitasker that was on Bill Muench's
old site. IIRC, Brad Rodriguez's article described single slot
mailboxes for task-to-task communication but said some implementations
were fancier. I don't remember if the eForth one had mailboxes at all.
So I wanted to know what facilities the fancier implementations offered,
and also a bit about usage techniques.

E.g. does a task PAUSE if the mailbox it wants to write to is already
full? Were there frequent problems with deadlock during development
because of this?

The new gforth multitasking docs look helpful and are more complete than
other stuff I've seen.

Paul Rubin <no.email@nospam.invalid> writes:
> Oh, neat! But the doc doesn't seem to describe the cooperative
> multitasker.

On reading the doc, it looks like the same words can control both
multitaskers, though some of them are only important for the preemptive
case.

The "Special User Variables" section has the confusing paragraph

Define a per-thread deferred word wait for all spawned tasks to
complete wait for a worker to become free, and spawn xt there wait
for a worker to become free, and spawn xt there, with one argument
wait for a worker to become free, and spawn xt there, with two
arguments

It looks there are some word headings missing from the middle of that by
accident. They seem to be for dealing with worker thread pools. Should
those really be primitives?

Are there parameters for the size of the event queue per task? What
happens if a queue fills up? Is the event queue system as described in
the doc part of a standardization proposal?

I find the event queue doc a bit confusing. Does event: let you give
arbitrary Forth code that is supposed to be executed in the receiving
task, i.e. something like an xt gets passed through the queue? If yes,
the doc should say so, and say how to pass an xt. Or is the definition
just supposed to be the events like elit, and friends? Do you use elit,
if you want to send an xt?

I expect it is the latter, and a typical event sequence would pass some
args and an event type. The receiving task would CASE on the event type
where each branch of the CASE would use the args for that type of event.
Does that sound right? But in that case why does EVENT: exist, instead
of using an ordinary colon definition? Why is there a maximum of 256
named events?

And if it is the former, how does one send a named event to another
task?

There are various defining words like event: which take names and create
objects with those names. Do they have factors that let you create the
objects anonymously?

It sounds like the event queue stuff might be gforth-specific, rather
than proposed or contemplated for standardization. That's fine, but it
would be nice if the doc identified words whose semantics might become
part of the standard.

I'm still interested in using this stuff on small MCU's (16KB program
flash, 1KB or 2KB ram), so I'm trying to figure out the resource
requirements of this multitasking scheme.

On 24/02/2023 11:26 pm, Zbig wrote:
>> Folks loved F83 because it was everything Fig-Forth was not.
>
> What you mean, in particular?
>
> BTW I acquired a taste for that „outdated” fig-Forth because of its
> simplicity. :) It may even be perhaps slowest of them all, but nowadays
> (contrary to the 70s/80s) it's not that serious disadvantage on modern
> CPUs, unless one „really really” needs the speed (like 3D-graphics?).

It's a rare person that turns down 'more' especially when it's free.
Both F83 and Fig-Forth were ITC. Their speeds would have been comparable.

On 25/02/2023 6:39 am, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> Take your pick ... What do you feel was missing from the stuff you
>> read? Implementations can be consulted if explanations are unclear.
>
> Thanks, I will look at those. I previously mostly looked at Brad
> Rodriguez's article and the eForth multitasker that was on Bill Muench's
> old site. IIRC, Brad Rodriguez's article described single slot
> mailboxes for task-to-task communication but said some implementations
> were fancier. I don't remember if the eForth one had mailboxes at all.
> So I wanted to know what facilities the fancier implementations offered,
> and also a bit about usage techniques.
>
> E.g. does a task PAUSE if the mailbox it wants to write to is already
> full? Were there frequent problems with deadlock during development
> because of this?

Presumably not otherwise folks wouldn't have used it. That the topic
rarely comes up suggests users were able to organize what they needed.
I'm not aware of any forth multitaskers that come with mailboxes
included. Someone with experience using multitaskers would be better
able to your answer questions (my interest stopped after I researched
and implemented them). I do recommend checking out the manual that
comes with the free version of SwiftX as it has a lengthy section on
multitaskers.