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 ; 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 ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 26

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

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

    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.



  2. 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.


    Look for the version of hForth for CP/M ... it is a Forth-94 Forth
    that includes the standard Forth-94 file handling words. Some early
    Forth for CP/M will have been Forths developed for other Z80 systems
    ported to CP/M.

    I believe there may be a copy at Taygeta .... I haven't checked in a
    while. The info file still works (I just now checked that)

    ftp://ftp.taygeta.com/pub/Forth/Comp...h/hfz80v99.txt

    Try:

    ftp://ftp.taygeta.com/pub/Forth/Comp...h/hfz80v99.zip

    I don't know if the Z80 version of hForth is under active development,
    but when I last tried it, it worked fine.

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

    In "John Crane" writes:

    > [...]
    > 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).
    > [...]


    My version of Z80 fig-FORTH (and Z280 fig-FORTH) uses files for screen
    storage. If you want the source, just drop me a line.

    Eddi
    --
    e-mail: dk3uz AT darc DOT de | AMPRNET: dk3uz@db0hht.ampr.org
    If replying to a Usenet article, please use above e-mail address.
    Linux/m68k, the best U**x ever to hit an Atari!

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

    On Wed, 19 Mar 2008 12:02:30 -0600, 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).


    Most Forth systems use disk blocks, no matter if that disk blocks are
    managed by a filesystem or are located on some sort of raw device and
    there is nothing screwy about this. To avoid destroying disk data I have
    modified the early FigFORTH systems for CP/M to leave drive a: alone and
    use only drive b: for their disk blocks. This is easy to do and avoids
    destroying the CP/M filesystem by accident.

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


    I use the following Forth Systems on CP/M that use a file as block storage:

    FORTH-83 Version 2.0
    Z80 fig-FORTH 1.1g
    DX-Forth Version 1.0
    Z80 UNIFORTH

    I also use Z80 CamelForth Version 1.2, but that one doesn't implement any
    disk storage at all.

    A harddisk image with this Forth implementations and a Z80 emulator to play
    with this stuff is available at http://www.unix4fun.org/z80pack/

    Udo Munk
    --
    The real fun is building it and then using it...


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

    On Wed, 19 Mar 2008 22:09:57 +0000, Edmund H. Ramm wrote:

    > In "John Crane" writes:
    >
    >> [...]
    >> 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).
    >> [...]

    >
    > My version of Z80 fig-FORTH (and Z280 fig-FORTH) uses files for screen
    > storage. If you want the source, just drop me a line.
    >
    > Eddi


    Eddi,

    the latest version of your Z80 figForth i was able to find with sources
    is Z80 fig-FORTH 1.1g. If there is any later version I would be
    interested. I also would be interested in fig sources for Z80 that still
    use the disk device, because all versions I got so far are for the 8080
    and maybe you have an earlier Z80 source?

    Thanks,
    Udo Munk
    --
    The real fun is building it and then using it...


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


    "Udo Munk" wrote in message
    newsan.2008.03.20.19.48.08.531999@unix4fun.org...
    > On Wed, 19 Mar 2008 12:02:30 -0600, John Crane wrote:
    >
    > Most Forth systems use disk blocks, no matter if that disk blocks are
    > managed by a filesystem or are located on some sort of raw device and
    > there is nothing screwy about this. To avoid destroying disk data I have
    > modified the early FigFORTH systems for CP/M to leave drive a: alone and
    > use only drive b: for their disk blocks. This is easy to do and avoids
    > destroying the CP/M filesystem by accident.
    >
    >
    > A harddisk image with this Forth implementations and a Z80 emulator to
    > play
    > with this stuff is available at http://www.unix4fun.org/z80pack/
    >
    > Udo Munk



    Looks nice Udo, but I'm not looking for a UNIX file to run with an emulator.
    I need something that will run on a *REAL* Z-80 with CP/M. I don't even
    think my machine can uncompress/whatever a *.tgz file anyway.

    I get the block thing now. But it still seems pretty weird/foolish to
    simply abandon the OS's filesystem for something as primitive as disk
    blocks. The enhancement you made seems to me to be the reasonable way to
    approach it - still use blocks at the user lever, but have those blocks go
    into a file - is that it?


    -John



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

    John Crane wrote:
    > "Udo Munk" wrote in message
    > newsan.2008.03.20.19.48.08.531999@unix4fun.org...
    >> On Wed, 19 Mar 2008 12:02:30 -0600, John Crane wrote:
    >>
    >> Most Forth systems use disk blocks, no matter if that disk blocks are
    >> managed by a filesystem or are located on some sort of raw device and
    >> there is nothing screwy about this. To avoid destroying disk data I have
    >> modified the early FigFORTH systems for CP/M to leave drive a: alone and
    >> use only drive b: for their disk blocks. This is easy to do and avoids
    >> destroying the CP/M filesystem by accident.

    ....
    > Looks nice Udo, but I'm not looking for a UNIX file to run with an emulator.
    > I need something that will run on a *REAL* Z-80 with CP/M. I don't even
    > think my machine can uncompress/whatever a *.tgz file anyway.
    >
    > I get the block thing now. But it still seems pretty weird/foolish to
    > simply abandon the OS's filesystem for something as primitive as disk
    > blocks. The enhancement you made seems to me to be the reasonable way to
    > approach it - still use blocks at the user lever, but have those blocks go
    > into a file - is that it?


    The early Forths (and many today on embedded systems) ran fully native,
    with no OS. Blocks were a very simple, fast, and reliable way of
    accessing disk. On a native Forth, a block# was a computable function
    of head/track/sector physical location -- very reliable, as there was no
    disk directory to get clobbered.

    Forths that ran under an OS (CP/M, DOS, and later OSs) put blocks into
    host OS files for compatibility with native Forths. Nowadays, most
    Forths on modern OSs (Windows, *nix) have dispensed with blocks and just
    use simple text files.

    Quick answer (omitting historical background): yes, that's it.

    Cheers,
    Elizabeth


    --
    ==================================================
    Elizabeth D. Rather (US & Canada) 800-55-FORTH
    FORTH Inc. +1 310-491-3356
    5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
    Hawthorne, CA 90250
    http://www.forth.com

    "Forth-based products and Services for real-time
    applications since 1973."
    ==================================================

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

    On Thu, 20 Mar 2008 15:25:15 -0600, John Crane wrote:


    > I get the block thing now. But it still seems pretty weird/foolish to
    > simply abandon the OS's filesystem for something as primitive as disk
    > blocks.


    Primitive lets you do things with the disk that the os won't allow.

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

    On Mar 20, 5:25 pm, "John Crane" wrote:
    > Looks nice Udo, but I'm not looking for a UNIX file to run with an emulator.
    > I need something that will run on a *REAL* Z-80 with CP/M. I don't even
    > think my machine can uncompress/whatever a *.tgz file anyway.


    This file ...

    ftp://ftp.taygeta.com/pub/Forth/Comp...h/hfz80v99.zip

    .... includes an emulator, but the Forth is for a real CP/M ... after
    all, if it didn't run on CP/M, it wouldn't run on the emulator.

    However, I would be surprised if its the early version of .zip that
    has a CP/M unzip utility. It would have to be decompressed on a DOS,
    Windows, Linux or Mac system, and the decompressed files copied.

    > I get the block thing now. But it still seems pretty weird/foolish to
    > simply abandon the OS's filesystem for something as primitive as disk
    > blocks.


    What Elizabeth said. Where I am very interested in Blocks, for
    example, is in accessing SPI serial flash RAM from a Commodore 64,
    where the Blocks system would be accessing the memory directly. Since
    the Forth-94 most widely available for the C64 is a Block-based
    system, it makes for a very natural fit with the smallest possible
    cost in terms of codespace.

    But the Forth-94 system I used on a regular basis on my Linux laptop
    only has Blocks if you elect to use Blocks ... I can go months without
    using its Blocks words.

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

    Bruce McFarling wrote:
    > On Mar 20, 5:25 pm, "John Crane" wrote:
    >> Looks nice Udo, but I'm not looking for a UNIX file to run with an emulator.
    >> I need something that will run on a *REAL* Z-80 with CP/M. I don't even
    >> think my machine can uncompress/whatever a *.tgz file anyway.

    >
    > This file ...
    >
    > ftp://ftp.taygeta.com/pub/Forth/Comp...h/hfz80v99.zip
    >
    > ... includes an emulator, but the Forth is for a real CP/M ... after
    > all, if it didn't run on CP/M, it wouldn't run on the emulator.
    >
    > However, I would be surprised if its the early version of .zip that
    > has a CP/M unzip utility. It would have to be decompressed on a DOS,
    > Windows, Linux or Mac system, and the decompressed files copied.
    >
    >> I get the block thing now. But it still seems pretty weird/foolish to
    >> simply abandon the OS's filesystem for something as primitive as disk
    >> blocks.

    >
    > What Elizabeth said. Where I am very interested in Blocks, for
    > example, is in accessing SPI serial flash RAM from a Commodore 64,
    > where the Blocks system would be accessing the memory directly. Since
    > the Forth-94 most widely available for the C64 is a Block-based
    > system, it makes for a very natural fit with the smallest possible
    > cost in terms of codespace.
    >
    > But the Forth-94 system I used on a regular basis on my Linux laptop
    > only has Blocks if you elect to use Blocks ... I can go months without
    > using its Blocks words.


    Somewhere, I have POLYforth for 8080 that I ran under CP/M, I still have
    5-1/4" disks that can probably be read, and STD Z-80 hardware to run it
    on. I also ran it, IIRC, without C{P/M, and I also ran (and have) AForth
    for the same hardware. The POLYforth is mine, but I can't give it away
    without permission. The AForth might as well be public domain; no one is
    left to claim it.

    Jerry
    --
    Engineering is the art of making what you want from things you can get.
    ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ

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

    On Mar 20, 5:25 pm, "John Crane" wrote:
    > Looks nice Udo, but I'm not looking for a UNIX file to run with an emulator.
    > I need something that will run on a *REAL* Z-80 with CP/M. I don't even
    > think my machine can uncompress/whatever a *.tgz file anyway.


    I have unzipped the Z80 hForth 0.99 package, and put the files at:

    http://groups.google.com/group/niclo...forth-94/files

    .... which is a Google Group that was going to get created sometime
    this summer. It is, in any event, _apropos_ to what the group will be,
    as hForth for Z80 makes an excellent test-bed for compatibility in the
    setting of a free standing small system ... running BMW on it revealed
    several portability problems with BMW.

    The Google Groups file uploader balks at uploading .COM files, so the
    file HFZ80RAM.CPM should be renamed HFZ80RAM.COM for a CPM system. For
    a native CP/M system, there is no need for the HFZ80RAM.DCM file,
    which is a renamed DOS .COM file.

    I have done a straight in-browser copy and paste of HFORTH.HTM to the
    text file HFORTH.TXT ... this comes out as an "Apple style"
    "paragraph=line" text file, so in CP/M is best read with VDE, which
    can word wrap these files to fit the appropriate column margin for the
    display screen of the CP/M system.

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

    On Thu, 20 Mar 2008 15:25:15 -0600, John Crane wrote:

    >
    > "Udo Munk" wrote in message
    > newsan.2008.03.20.19.48.08.531999@unix4fun.org...
    >> On Wed, 19 Mar 2008 12:02:30 -0600, John Crane wrote:
    >>
    >> Most Forth systems use disk blocks, no matter if that disk blocks are
    >> managed by a filesystem or are located on some sort of raw device and
    >> there is nothing screwy about this. To avoid destroying disk data I have
    >> modified the early FigFORTH systems for CP/M to leave drive a: alone and
    >> use only drive b: for their disk blocks. This is easy to do and avoids
    >> destroying the CP/M filesystem by accident.
    >>
    >>
    >> A harddisk image with this Forth implementations and a Z80 emulator to
    >> play
    >> with this stuff is available at http://www.unix4fun.org/z80pack/
    >>
    >> Udo Munk

    >
    >
    > Looks nice Udo, but I'm not looking for a UNIX file to run with an emulator.
    > I need something that will run on a *REAL* Z-80 with CP/M. I don't even
    > think my machine can uncompress/whatever a *.tgz file anyway.


    This all are Forth systems that run on real 8080 or Z80 CP/M systems. I
    just don't want to mess with the old hardware anymore, I grew up with the
    stuff and used it enough for this life. So nowadays I prefer an emulated
    Z80 system to run all the old software.

    The Forth systems I mentioned can be found on the Internet with search
    engines, I just put them on a harddisk image ready to use for my emulator.
    It is quite some work to find out how to uncompress all the different
    archives used and get files onto floppy disks for using it on some kind of
    system. That is one nice thing about emulation, you plug a disk image into
    the emulated system and just use it.

    > I get the block thing now. But it still seems pretty weird/foolish to
    > simply abandon the OS's filesystem for something as primitive as disk
    > blocks. The enhancement you made seems to me to be the reasonable way
    > to approach it - still use blocks at the user lever, but have those
    > blocks go into a file - is that it?


    Forth includes it's own OS in form of handling block devices and using the
    secondary storage as virtual memory. The block device can be anything that
    can be addressed by reading/writing a block, like floppy disk, harddisk,
    volatile or non volatile memory, tape, whatever.
    When Forth is implemented on top of another OS you usually have 2 choices,
    using raw devices of the machine, or use the filesystem of the host OS. In
    the later case the blocks just go into a file, yes. If you work in Forth
    that all doesn't matter because you just use screens or blocks, wherever
    and however they are stored. If one uses blocks on a disk device, one
    can't handle this disk with the host OS anymore, and that is what seems to
    confuse people somehow.

    Udo Munk
    --
    The real fun is building it and then using it...


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

    On Mar 21, 9:55 am, Udo Munk wrote:
    > Forth includes it's own OS in form of handling block devices and using the
    > secondary storage as virtual memory. ...


    To be more precise, traditional Forth included its own OS ... modern
    Forth's are often designed to work directly with the OS file system,
    including plain text files as source. Some modern Forth's do not
    implement BLOCKs at a low level at all, since it is simple enough to
    include source for a file-based BLOCK system.

    Still, it *is* handy to have a common, simple, and well-developed
    system for working with buffered storage that can be implemented in a
    wide variety of ways, from direct access to the underlying hardware
    through to files in a file system, and so Forth-94 does standardize
    BLOCK words in an optional wordset.

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

    > I don't even
    > think my machine can uncompress/whatever a *.tgz file anyway.


    If you're running Windows 98 | 2000 | XP | NT ,
    you can use Winzip. It will handle tar'red and gzip'ped
    files, and is very handy in general (faster than XP's
    'compressed folder' utility; nice GUI and wizards,
    an add-on for command line support).

    If you're worried about handling *nix line-endings,
    I recommend notepad2 - it's light like notepad, but
    features syntax highlighting, line-ending conversion,
    a few more tidbits.

    Winzip:
    www.winzip.com/downwz.htm

    Notpad2:
    http://www.flos-freeware.ch/notepad2.html

    There may be others as well, not to mention using
    Cygwin, but from what I can ascertain of your daily
    use, Winzip seems to fit the bill.

    HTH and TTFN,
    Tarkin
    --
    All your database are belong to DBIII

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


    "Bruce McFarling" wrote in message
    news:2f01148e-c34c-4140-a3a9-8cd259d4d174@b64g2000hsa.googlegroups.com...
    > On Mar 20, 5:25 pm, "John Crane" wrote:
    >> Looks nice Udo, but I'm not looking for a UNIX file to run with an
    >> emulator.
    >> I need something that will run on a *REAL* Z-80 with CP/M. I don't even
    >> think my machine can uncompress/whatever a *.tgz file anyway.

    >
    > This file ...
    >
    > ftp://ftp.taygeta.com/pub/Forth/Comp...h/hfz80v99.zip
    >
    > ... includes an emulator, but the Forth is for a real CP/M ... after
    > all, if it didn't run on CP/M, it wouldn't run on the emulator.
    >



    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
    pretty much standard in Forth. I tried it in 22Nice as well as an Osborne
    01. Even downloaded it twice. Perhaps someone can correct me on this -
    but my understanding of the process to read in Forth code is:

    1) Make the text file in an editor.
    2) Start up Forth
    3) OPEN
    4) 1 LOAD

    Step 4 should load in the first screen of the file.

    -J




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

    On Mar 21, 12:19 pm, "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
    > pretty much standard in Forth. I tried it in 22Nice as well as an Osborne
    > 01. Even downloaded it twice. Perhaps someone can correct me on this -
    > but my understanding of the process to read in Forth code is:
    >
    > 1) Make the text file in an editor.
    > 2) Start up Forth
    > 3) OPEN
    > 4) 1 LOAD
    >
    > Step 4 should load in the first screen of the file.


    No, if you make a text file in an editor, it won't be screens of code
    in a BLOCK file, it will be a sequence of lines in a text file.
    Normally BLOCK files distributed in a file system have an ending
    like .BLK and if it has an ending like .F or .FS, they are Forth
    source in normal text files.

    So you would load code with

    S" myfile.F" INCLUDED

    or if it has INCLUDE (1),

    INCLUDE myfile.F

    (Note 1. ... though a 16-bit system might have even that loaded from
    source, because you never know how small you want the base system that
    you start with when you are going to make something that loads and
    runs as a binary application.)

    One or the other will work with hForth, and you would use it to load
    the hForth extensions that you want.

    I don't remember if hForth has BLOCKS ... I wasn't using it for that.
    Its a modern Forth-94 implementation, originally written for the 8086
    and ported to the Z80 to testbed the portability of the implementation
    model ... so if it has BLOCKs, I would expect it would be in source
    code in an extension file.

    Its not something that would have concerned me when I was using it for
    a 16-bit file-oriented Forth-94 system to check BMW, since BMW was a
    text file editor, so it was restricted to systems that had text files.

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


    "Bruce McFarling" wrote in message
    news:fc21ca65-4ec1-416c-adfb-3f2865d764cd@a1g2000hsb.googlegroups.com...
    > On Mar 21, 12:19 pm, "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
    >> pretty much standard in Forth. I tried it in 22Nice as well as an
    >> Osborne
    >> 01. Even downloaded it twice. Perhaps someone can correct me on
    >> his -
    >> but my understanding of the process to read in Forth code is:
    >>
    >> 1) Make the text file in an editor.
    >> 2) Start up Forth
    >> 3) OPEN
    >> 4) 1 LOAD
    >>
    >> Step 4 should load in the first screen of the file.

    >
    > No, if you make a text file in an editor, it won't be screens of code
    > in a BLOCK file, it will be a sequence of lines in a text file.
    > Normally BLOCK files distributed in a file system have an ending
    > like .BLK and if it has an ending like .F or .FS, they are Forth
    > source in normal text files.
    >
    > So you would load code with
    >
    > S" myfile.F" INCLUDED
    >
    > or if it has INCLUDE (1),
    >
    > INCLUDE myfile.F
    >

    Thanks for setting me straight. Looks like I was on the wrong track. I
    tried these, but got "undefined word" error on INCLUDE, and "interpreting a
    compile-only word" on S" . So, I put S" into a colon definition, but then
    got "undefined word" on INCLUDED. I think the gods of Forth have it out for
    me!

    -J



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

    On Fri, 21 Mar 2008 16:19:01 -0000, John Crane "> wrote:


    > 1) Make the text file in an editor.
    > 2) Start up Forth
    > 3) OPEN
    > 4) 1 LOAD
    >

    LOAD is for screen files which have a format of 16x64 char lines (1k) and
    no control characters. The commands for loading text files in hForth
    should be as Bruce described.

    Older CP/M Forths that used text files were written before file-handling
    words were standardised, so each goes its own way. There were two common
    workarounds: pipe input from file instead of the keyboard, or run it
    through a utility to convert it to screen file format.

    There are some advantages to screen files for older hardware. Because it
    deals with 1k records the editor is internal to forth and it is simple to
    modify it to do exactly what you need. For an authentic 1980's experience
    I recommend Laxen & Perry's F83, which is comprehensive, well documented,
    and with a good interface to CP/M

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

    On Mar 21, 2:01 pm, "John Crane" wrote:
    > "Bruce McFarling" wrote in message
    > > S" myfile.F" INCLUDED
    > > or if it has INCLUDE (1),
    > > INCLUDE myfile.F


    > Thanks for setting me straight. Looks like I was on the wrong track. I
    > tried these, but got "undefined word" error on INCLUDE, and "interpreting a
    > compile-only word" on S" . So, I put S" into a colon definition, but then
    > got "undefined word" on INCLUDED. I think the gods of Forth have it out for
    > me!


    Serve me right for going by memory ... I don't now see how this gets a
    file source in any way other than doing a submit, just like Camel.
    There is a custom word << that is used to load files in hForth for
    DOS, and if you load enough files that gets to the point of getting to
    INCLUDED (and INCLUDE) ... but that custom word is not present in CP/
    M.

    After looking more closely at the hForth extension source files for
    the z80 and 8086, it may have been hForth for DOS that I was using.
    The non-interpeting-S" idiom of

    BL PARSE MULTI.F INCLUDED

    is something that definitely rings a bell, and I can't find an
    "INCLUDED" in the z80 source.

    Indeed, I would have to experiment to see whether hForth for z80 works
    with the SUBMIT facility ... the following is how the process works
    for CamelForth Z80:

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

    QUOTE

    Disk I/O is not yet supported under CP/M. However, CamelForth v1.2
    will
    accept commands from a CP/M SUBMIT file using the XSUB utility. The
    SUBMIT file should contain the commands

    XSUB
    CAMEL80
    ...Forth source code...

    This will run CamelForth/80 under XSUB, which will feed the rest of
    the
    file to CamelForth as terminal input. You can automatically return to
    CP/M by putting the CamelForth BYE command in the file. Then you can
    save the modified CamelForth image with the CP/M command

    SAVE nn CAMELNEW.COM

    'nn' is the decimal number of pages occupied by the CamelForth
    dictionary. You can determine this value while in CamelForth with the
    statement

    DECIMAL HERE 0 256 UM/MOD NIP .

    Unfortunately, at the moment there's no way to totally automate this
    as
    part of the SUBMIT file. And I'm reluctant to add SAVE to CamelForth
    when CP/M has a perfectly good SAVE command.

    UNQUOTE

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

    On Mar 21, 12:19 pm, "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
    > pretty much standard in Forth.


    One thing to be aware of is that with Forth sometimes fitting in some
    very tight spaces, a Forth-94 system has to have a fairly small
    collection of fundamental words, but most of the standard words are in
    optional wordsets ...

    .... a "big" Forth-94 system like gforth, Win32Forth or the ones from
    the commercial Forths will have all of the wordsets either in the base
    system or a library file away ... but a "small" Forth-94 system will
    have CORE words and whichever optional words it needs for the task at
    hand.

    For example (something I had completely forgotten about in the eight
    years or so since I last used it), if you have an interpreted S" word,
    the standard says how it has to behave ... but there is no requirement
    to have an interpreted S" word. An interpreted S" word required a
    buffer, and a Forth in very tight quarters might simply not wish to
    allocate that buffer if it doesn't need to.

    So all through the hForth files you see the phrase to take a string
    directly from the current source buffer and hand it to included ...
    like

    BL PARSE MULTI.F INCLUDED

    > I tried it in 22Nice as well as an Osborne
    > 01. Even downloaded it twice. Perhaps someone can correct me on this -
    > but my understanding of the process to read in Forth code is:
    >
    > 1) Make the text file in an editor.
    > 2) Start up Forth
    > 3) OPEN
    > 4) 1 LOAD


    I've looked at hForth for Z80 again, and I got confused in my head
    what I did with hForth for CP/M, which was probably testing the
    portability of some portable text-facility games like Sokoban and
    Tetris, and what I did with hForth for DOS.

    The FILES words are in DOS, not in the CP/M, so even after I work out
    again how to get source files loaded in

    .. hForth for CP/M does have a ``bdos'' call, but at the moment the
    Forth-94 FILES wordset is still "exercise left to the reader".

    That being the case, the best easily available Forth for CP/M that
    sits comfortably in a CP/M system is F83 by Perry and Laxen. It can be
    found at the cpm.z80.de site:

    http://www.cpm.z80.de/download/forth80.zip

    This is block oriented, but uses .BLK block files (of course, the
    actual extension is whatever took the author's fancy ... there is an
    important block file in the distribution containing the full screen
    editor with an .F83 extension).

    So for this system, the process is:

    1) Start up Forth
    2) Load whatever blocks are needed to build the Forth block editor
    3) Edit a block file with the Forth block editor
    4) xxx LOAD

    where xxx is whatever the location of your load block is.

    The full screen editor may, of course, require some tuning for your
    terminal characteristics ... but its worth it. The lowest level block
    editor relies on single character words and commands like:

    A L

    to "list the shadow block".

    If you are not used to working with block source, it can get
    confusing, especially if you want to store a collection of sources in
    a single block file. OTOH, it is a "genuine CP/M Forth experience" ...
    F83 was the top-shelf public domain CP/M Forth system in the mid-80's.

    For any source in a block file, its best to have a single "LOAD BLOCK"
    which will load the blocks that make up the source, so that you do
    ``xxx LOAD'' and the load block takes over. It will normally consist
    of a comment line and one or two lines looking like

    xxx yyy THRU

    to load blocks ``xxx'' through ``yyy''. F83 block files are normally
    organized with a set of source screens then a parallel set of
    "shadow", commentary screens, so when loading the full file "yyy" is
    sometimes computed from half the CAPACITY of the block file.

    If there is a collection of sources ... say, sample programs from
    working through "Thinking Forth" ... in a single block file, a good
    system is to have a "master load block" that defines the different
    load block locations as named constants, so that "xxx LOAD" is a name
    of a load block constant rather than a number. By convention, the main
    load block for a block file is block 1, with block 0 used for
    descriptive text.

    So, yes, with block files you often say, ``1 LOAD'' as part of the
    process ... but if you wrote the block file, it only works if you set
    it up that way.

    F83 also has a SAVESYSTEM word of some form, so that when you have a
    set-up that is good for a particular set of tasks, you can SAVESYSTEM
    and generate a .COM file once its set-up the way you want it.

    With that facility, the utility to convert a block file to a text
    file, for example, is simply a copy of F83 that has loaded the forth
    source to copy out a block file as a text file and then saved that
    system.

+ Reply to Thread
Page 1 of 2 1 2 LastLast