On Mar 22, 12:18 pm, Bruce McFarling wrote:
> I have never tried it, but I would expect the following utilities to
> compile with some available C compiler for CP/M:
>
> ftp://ftp.taygeta.com/pub/Forth/Tools/4th2txt.c
>
> ftp://ftp.taygeta.com/pub/Forth/Tools/txt24th.c

I mean, I've never tried it on CP/M. When I was doing this, I was
using PowerC for DOS and neither CP/M nor Small-C ... or any full-
fledged C compiler for CP/M, for that matter.

F83 has source to do this in one direction (block to text), but its
been a long time since I've used a Forth-83 system, and I've not the
time at the moment to extend it to run both ways.

In article ,
John Crane wrote:

>
>I tried this one before, and I think it's an incomplete/incorrect zip file.
>LOAD seems to be an undefined word for it. So is WORDS, which I thought was

Try VLIST



Groetjes Albert

--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

On Mar 19, 2:02 pm, "John Crane" wrote:
> I'm new to Forth and thought it would be a useful addition to my older 8-bit
> machines. I've tried a few Forth's from the Walnut Creek CP/M CD, but can't
> seem to find one that allows me to load Forth code that was previously saved
> to a disk file (with a generic text editor). The closest I've found was
> Forth83 (8080 Forth 83 Model V 2.1.0 from June 84) that actually mentions
> files in the docs. All the others talk about disk blocks - which cause
> screwy behavior (I guess nobody got around to connecting the early Forth's
> to the disk calls in BDOS).

> I think I must be missing something that's obvious. Because, it seems to
> me, just loading a text file from disk should be a very simple thing.

CP/M hForth has a bdos call primitive, but does not have FILES words
that use that. I am working on that, first to get INCLUDED built into
CP/M hForth and then, once it can load source code from files, source
that provides the FILES wordset.

This is working on hForth at the console, and then using the built-in
CP/M SAVE command to save an image as I go, so it seemed to me I may
as well put up the executable I have that include CP/M hForth and the
TOOLS and SEARCH core wordsets.

That's up at:

http://groups.google.com/group/niclo...le-development

No guarantees that the selected words (in the file OPTIONZ.FS) have
been transcribed flawlessly ... and, indeed, once I have INCLUDED up,
I will implement it in the core HFZ80RAM.COM binary and the words in
this hforthx.com will be loaded from source.

On Mar 19, 2:02 pm, "John Crane" wrote:
> I'm new to Forth and thought it would be a useful addition to my older 8-bit
> machines. I've tried a few Forth's from the Walnut Creek CP/M CD, but can't
> seem to find one that allows me to load Forth code that was previously saved
> to a disk file (with a generic text editor). The closest I've found was
> Forth83 (8080 Forth 83 Model V 2.1.0 from June 84) that actually mentions
> files in the docs. All the others talk about disk blocks - which cause
> screwy behavior (I guess nobody got around to connecting the early Forth's
> to the disk calls in BDOS).

> I think I must be missing something that's obvious. Because, it seems to
> me, just loading a text file from disk should be a very simple thing.

Also, for actually loading Forth code that was saved in a disk file,
on a Z80 Forth, get the Z80 CamelForth:

http://www.camelforth.com/page.php?5

Add the following two lines to the front of the source, save it as
a .SUB file, and use SUBMIT to run it:

XSUB
CAMEL80
.... forth source

As the directions there say, if you want to use that to define a new
Forth image with those words included, then at the end of the file add
the line:

DECIMAL HERE 0 256 UM/MOD . DROP BYE

That should display the page parameter for the CP/M SAVE command as
the last step of the SUBMIT file, which can be used immediately after
the SUBMIT file is run to save the image.

On Apr 9, 12:06 pm, Bruce McFarling wrote:
> CP/MhForthhas a bdos call primitive, but does not have FILES words
> that use that. I am working on that, first to get INCLUDED built into
> CP/MhForthand then, once it can load source code from files, source
> that provides the FILES wordset.

> This is working on hForth at the console, and then using the built-in
> CP/M SAVE command to save an image as I go, so it seemed to me I may
> as well put up the executable I have that include CP/MhForthand the
> TOOLS and SEARCH core wordsets.

> That's up at:

> http://groups.google.com/group/niclo...hforthx-for-co...

> No guarantees that the selected words (in the file OPTIONZ.FS) have
> been transcribed flawlessly ... and, indeed, once I have INCLUDED up,
> I will implement it in the core HFZ80RAM.COM binary and the words in
> this hforthx.com will be loaded from source.

First, there is a bug somewhere, that affects HERE ... I think its in
the DUMP word, which makes sense since its such a very long definition
in OPTIONZ.F and when transcribing by hand at the console, its long
definitions without an opportunity to test individual sections that
are most likely to hide bugs.

When INCLUDED is up and working, I will install INCLUDED in a
hfz80ram.com so that a debugged programming tools wordset can be
INCLUDED from source.

The current stage of the process is completion of a simple-minded
ALLOCATE FREE RESIZE wordset to support INCLUDED. It allocates chunks
of memory from below PAD working down, since CP/M hForth has memory
organized as:

[____^HERE ... PAD_____TIB____]^memTop

Its just a linked list of memory chunks with a char sized FREE flag.
FREEd memory chunks are marked, and if at the beginning of the dm-head
linked list, the head of the linked list is updated. This is fine for
a LIFO stack of memory chunks, which is what INCLUDED requires, but
when I install this into hfz80ram.com I'll want to make ALLOCATE
vectored so a smarter ALLOCATE can be installed that recycles memory
marked as FREE.