Z80 CP/M Forth & loading code from disk - CP/M

This is a discussion on Z80 CP/M Forth & loading code from disk - CP/M ; 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 ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 26 of 26

Thread: Z80 CP/M Forth & loading code from disk

  1. Re: Z80 CP/M Forth & loading code from disk

    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.


    OK, so after brushing the cobwebs out on the differences between
    hForth for CP/M and for DOS, and finding that in this particular case,
    it "was neither fish nor fowl, or in a word, red herring" the F83 is
    the one that you would want for this.

    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

    Usage documentation is in the source, and even so they are only 3K
    source files each, and I guess they use K&R declarations ...

    "main(argc,argv)
    int argc;
    char **argv;"

    .... they only use int and char (and char array) data types, and the
    only include is:

    #include

    .... so I'm thinking they would compile under Small-C.

    SO if you have a text editor that you would much rather use (which I
    can understand, having used VDE for DOS quite heavily when my home
    machine was DOS on a laptop discarded because the hard drive was fubar
    and the battery was close to gone) ...

    (1) Edit with line numbers on so you'll be able to see where block
    boundaries are (you might want a list of multiples of 16 on a
    reference index card), and

    (2) set your column width to 63 or less ...

    .... and you can edit in a text file editor, convert to a block file,
    and load that block file in Forth. You can also edit that block file
    further while in Forth ... F83 has a very good word source-index
    system which makes its straightforward, as well as the full screen
    editor, and if its only for doing small fixes even the primitive
    command line word editor is usable ... and then convert back to the
    text file.

    You'll be using the first block as a commentary description and the
    second one as a LOAD block ... in F83, I think that CAPACITY 1- is the
    last block number for the current block file (but bench test that
    first).

    If you use those text<->block utilities, the block to text utility has
    a command line option to put the block number in |xxxxx| format, which
    the text to block utility strips out again if converting. So a handy
    trick is to make a large empty text file (just carriage returns),
    convert it to a block file, than convert it back with the block
    numbering turned on. Then you have a blank text file to work on that
    has the block numbers in place.

    Of course, the text editor doesn't know those are blocks, so if you
    have a macro to copy or cut a whole block from one place to another,
    you'd want to run it through that cycle again to get the current block
    numbers before setting up a LOAD block. That's an advantage of THRU in
    a load block ... the individual BLOCK does not have to know what
    block# its in, so you can update that information all in one place.

  2. Re: Z80 CP/M Forth & loading code from disk

    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.

  3. Re: Z80 CP/M Forth & loading code from disk

    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


  4. Re: Z80 CP/M Forth & loading code from disk

    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.



  5. Re: Z80 CP/M Forth & loading code from disk

    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.

  6. Re: Z80 CP/M Forth & loading code from disk

    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.

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2