dirC: F83 68K : F83 BIN : META68 BLK : BASIC BLK : CLOCK BLK
kernel extend68.blkKERNEL?
dirC: F83 68K : F83 BIN : META68 BLK : BASIC BLK : CLOCK BLK C: CPU68000 BLK : EXPAND68 BLK : EXTEND68 BLK : HUFFMAN BLK : KERNEL68 BLK C: UTILITY BLK
kernel extend68.blkKERNEL?
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.......
ONLY FORTH ALSO DOS SAVE A:KERNEL.68K FORTH......
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......
a:pip kernel.68k=a:kernel.68kC: BILL83 68K : F83 BIN : META68 BLK : BASIC BLK : CLOCK BLK
dir
kernel extend68.blkInsufficient memory or bad file header
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
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 versionthat 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.
On 2/21/23 7:39 PM, Roger Hanscom wrote: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.
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
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
F83 has a built in editor. Clearly described in places like: http://forth.org/OffeteStore/1003_InsideF83.pdf
Would it be easier to edit the code? Don't know how to do that.
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?
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.
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)
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.
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--
The only trickery I noted in the
F83 tasker was the use of INT or RST instructions to effect task switch.
Folks loved F83 because it was everything Fig-Forth was not.
If you have any Forth Dimensions
articles to recommend, that would be nice.Take your pick
...
https://gforth.org/manual/Multitasker.html
Note that this documents the development version.
Take your pick ... What do you feel was missing from the stuff you
read? Implementations can be consulted if explanations are unclear.
Oh, neat! But the doc doesn't seem to describe the cooperative
multitasker.
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:
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?
Both F83 and Fig-Forth were ITC. Their speeds would have been comparable.
dxforth <dxforth@gmail.com> writes:
Both F83 and Fig-Forth were ITC. Their speeds would have been comparable.
IIRC we looked at the NEXT for the 8086 versions some time ago.
fig-Forth's 8086 NEXT used 8080-based register assignments, whereas
F83's NEXT made much better use of the 8086 instruction set.
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.
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.
Oh, not really — example: FPC. I recall how overwhelming it seemed I tried it first time…
It all depends on what one needs.
Sure, but how many didn't need a ready-to-run forth with editor, assembler, OS file-system support etc comparable in quality to systems LMI was selling? The Forth world including FIG had moved on with Forth-79 and then Forth-83. If there were vendors still offering systems based on Fig-Forth, it was because Laxen & Perry had threatened to go after anyone profiteering from their work. FWIW I thought F83 was over-bloated too.
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?).
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?
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.
If there were vendors still offering systems based on Fig-Forth, it was because Laxen & Perry had threatened to go after anyone profiteering from their work.
Both F83 and Fig-Forth were ITC. Their speeds would have been comparable.
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?
On the subject of multi-tasking on a flash based CPU.
There are c-based soc's intended for smart devices.
2 K flash and 16 K ram is more Forth-like.
They are ram starved. A task will have separate tib, data stack
and return stack.
bit cpu and the Forth had 32 bit cells. Also, 16 cells per stack might sometimes be too few. I guess that could be controlled at task
creation. Some tasks are more complicated than others.
I also wonder how interrupt handlers would fit into this.
The Forth world including FIG had moved on with Forth-79 and then Forth-83.
If there were vendors still offering systems based on Fig-Forth, it was
because Laxen & Perry had threatened to go after anyone profiteering from
their work.
On a second thought: wouldn't it be actually better solution for both them and
the Forth world simply to offer kind of agreement in case anyone would like to
use their work commercially?
They would have additional income — and their Forth would gain even more users.
On Friday, February 24, 2023 at 5:07:08 PM UTC-5, dxforth wrote:
Both F83 and Fig-Forth were ITC. Their speeds would have been comparable.
F83 compile times were much faster due to the hashed dictionary.
The Forth world including FIG had moved on with Forth-79 and then Forth-83.
One more: are you sure really many „moved on with Forth-79”? Longer time I was searching for any Forth-79 for DOS — actually just out of curiosity, to
take a look at it — it can nowhere be found, not present even on forth.org pages
(neither at Taygeta).
If I'm correct even for my C-64 I haven't got any Forth-79; several fig-s, two F83
(Blazin' Forth and UltraForth/VolksForth), one MVP Forth (Super Forth), one trying
to be ANS-compliant (Durex Forth, but this of course rather recent implementation)
— and that's about it. I've found that C64-Forth from Performance Micro has
79-STANDARD word present in its vocabulary, but anyway it uses, for example, fig-Forth's VARIABLE.
So even if I find one (or maybe, who knows, even two) in the future, it doesn't seem
that Forth-79 was that popular in the past. No trace!
I believe MVP updated to Forth-79.
albert@cherry.(none) (albert) writes:
On the subject of multi-tasking on a flash based CPU.
There are c-based soc's intended for smart devices.
2 K flash and 16 K ram is more Forth-like.
They are ram starved. A task will have separate tib, data stack
and return stack.
The 16k flash and 2k ram seemed ok to me, since the flash would in both
cases be mostly used for code. With 16 bit cells if you have 16 cells
for each stack, that's 64 bytes of stack per task. Plus you'd have a
few user variables and a TCB. There wouldn't be a TIB in an embedded >application, but even if there was, why have a separate one per task?
A Forth version of the Anduril app (flashlight controller written in C)
might have about 5 or so tasks, so a few hundred bytes of ram would
suffice. It originally ran on the ATTiny85 which iirc has 8KB of flash
and 512B of ram, but it has reached the limit of code space on that
part, and new lights have been using the ATTiny1616 (16KB flash, 2KB
ram) which is nicer in other ways too.
I guess the ram requirement would increase if the app migrated to a 32
bit cpu and the Forth had 32 bit cells. Also, 16 cells per stack might >sometimes be too few. I guess that could be controlled at task
creation. Some tasks are more complicated than others.
I also wonder how interrupt handlers would fit into this.
I can't wait to see a sensible application of multi-tasking on
a 2k RAM sbc. So I suspend disbelief till then.
I can't wait to see a sensible application of multi-tasking on
a 2k RAM sbc. So I suspend disbelief till then.
If the code of the application is going to reside in flash, and to use
the RAM just for its data — why not?
I can't wait to see a sensible application of multi-tasking on
a 2k RAM sbc. So I suspend disbelief till then.
I wonder if it is feasible to standardize a coroutine switch operation,
or at least add it to gforth. So that gives very minimal multitasking,
i.e. without separate stacks per task.
Tiny processors like the GA144
nodes implement it it in hardware.
If it does not have separate stacks, it's not coroutining.
Albert van der Horst's CO.
Tiny processors like the GA144 nodes implement it it in hardware.The cores of the GA144 have separate stacks, and they actually
genuinely run in parallel, unlike coroutines.
albert@cherry.(none) (albert) writes:
I can't wait to see a sensible application of multi-tasking on
a 2k RAM sbc. So I suspend disbelief till then.
I thought it had already been done in 8051 class mcu's, e.g. with
Chipforth. Maybe I'm wrong though.
I know that eForth on the STM8 (1k of ram) supports multitasking because
I played with it, but it only handles two tasks iirc.
There's a SwiftX for the Arduino. That's 32K flash and 2K ram.
SwiftX has an application stripper that weeds out unused code.
That should be enough flash for a serious application?
dxforth <dxforth@gmail.com> writes:
There's a SwiftX for the Arduino. That's 32K flash and 2K ram.
SwiftX has an application stripper that weeds out unused code.
That should be enough flash for a serious application?
16K flash is enough, really. That's what newer lights that run this app
are using. I don't pick the cpus. But, I think the ATMega parts with
32K flash only come in larger packages. The 1616 is chosen because it
is available in a 3x3mm QFN if I have the terminology right.
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
If it does not have separate stacks, it's not coroutining.
I thought so too, but the C++20 has taken issue with that, saying that
if C++20 coroutines had separate stacks, they would be called fibers.
That is apparently Microsoft-speak though.
Albert van der Horst's CO.
I'll see if I can find that. I have a copy of 4th downloaded, if that's
the right place.
I mean the F18A (individual core of the GA144) has its own coroutine
jump instruction. It swaps the top of the R stack with the current PC.
CO is probably similar. In a threaded Forth, it can be done with
R-stack manipulation, I suppose.
Elsewhere you mention ChipForth. Can't say I know anything about it.
Wasn't it a precursor to SwiftX ?
C++20 is not the first programming-language standard that deviates
from established terminology and won't be the last.
Unlikely. 4th is from Hans Bezemer.
Yes, IIRC that's what CO does. So it would be something like
: CO 2r> swap 2>r ;
albert@cherry.(none) (albert) writes:
I can't wait to see a sensible application of multi-tasking on
a 2k RAM sbc. So I suspend disbelief till then.
I thought it had already been done in 8051 class mcu's, e.g. with
Chipforth. Maybe I'm wrong though.
I know that eForth on the STM8 (1k of ram) supports multitasking because
I played with it, but it only handles two tasks iirc.
I wonder if it is feasible to standardize a coroutine switch operation,
or at least add it to gforth. So that gives very minimal multitasking,
i.e. without separate stacks per task. Tiny processors like the GA144
nodes implement it it in hardware. C++20 has something like it now, and >there are some C header libraries like protothreads that implement it
through preprocessor hacks. But it's not so easy to do in traditional
Forth.
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
If it does not have separate stacks, it's not coroutining.
I thought so too, but the C++20 has taken issue with that, saying that
if C++20 coroutines had separate stacks, they would be called fibers.
That is apparently Microsoft-speak though.
Albert van der Horst's CO.
I'll see if I can find that. I have a copy of 4th downloaded, if that's
the right place.
Tiny processors like the GA144 nodes implement it it in hardware.The cores of the GA144 have separate stacks, and they actually
genuinely run in parallel, unlike coroutines.
I mean the F18A (individual core of the GA144) has its own coroutine
jump instruction. It swaps the top of the R stack with the current PC.
CO is probably similar. In a threaded Forth, it can be done with
R-stack manipulation, I suppose.
Elsewhere you mention ChipForth. Can't say I know anything about it.
Wasn't it a precursor to SwiftX ?
That's unfair! I have some simple co-routines as well:Unlikely. 4th is from Hans Bezemer.Oops, I got 4th confused with another implementation.
On Mon, 27 Feb 2023 17:53:10 +1100
dxforth <dxforth@gmail.com> wrote:
Elsewhere you mention ChipForth. Can't say I know anything about it.
Wasn't it a precursor to SwiftX ?
chipFORTH networks 7,000 micros https://www.computer-solutions.co.uk/chipdev/lighting.htm
Links to missing pages
https://web.archive.org...
I can't wait to see a sensible application of multi-tasking on
a 2k RAM sbc. So I suspend disbelief till then.
dxforth <dxforth@gmail.com> writes:
Links to missing pages
https://web.archive.org...
Thanks for finding those, they help. They explain that ChipForth is a Polyforth derivative, and supports multitasking on the target with
overhead of 48 bytes of ram per task. That sounds like two 16-level
stacks plus a few registers and a TCB. It also mentions that the host communication module is < 256 bytes of code and doesn't have to be
included in a final build.
Paul Rubin <no.email@nospam.invalid> writes:
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?
Andrew Haley worked on it before he dropped out of the standardization effort. Now we have tasked Bernd Paysan with that, but I think he
wants to wrap up recognizers before taking this task on.
IIRC Andrew Haley produced some slides, not sure if there is something available online.
...
dxforth <dxforth@gmail.com> writes:
Elsewhere you mention ChipForth. Can't say I know anything about it.
Wasn't it a precursor to SwiftX ?
I have also been looking for info but it looks like most is gone from
the web. Forth Inc. sold it for a while but I don't think it was
related to SwiftX. It was a tethered Forth for 8051 and comparable
MCU's whether the text interpreter was entirely on a host PC.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 504 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 244:39:58 |
| Calls: | 9,891 |
| Files: | 13,794 |
| Messages: | 6,294,410 |