[comp.lang.forth] LMI Forth

dunn@uhccux.uhcc.hawaii.edu (John Dunn) (12/05/89)

Actually the LMI Z80 Forth, along with the early PC-Forth, was a
considerable bargain.  You not only got a very clean FIG Forth, but
you also got lots of clear and well commented example programs and a
manual that was far and above better than anything out there I ever
saw.  Especially noteworthy was the explanations of Forth iteration
constructs. 

Although I ended up using a version of Fig-Forth that I wrote myself
for my rather large commercial graphics application, the money I
spent on Ray Duncan's LMI offerings was *very* well spent for the
education it gave and for the utilities such as the very complete and
robust assembler that was included.

Alas, the current LMI Forth documentation, while complete, does not
include an upgraded version of that excellent overview documentation
& tutorial.  Can't say why.  

What I can say though is that UR/Forth currently offered by LMI is an
amazing product.  It uses a proprietary hashing technique for FIND,
which makes it compile even monster programs in a blink.  The 386
version now uses Phar Lap's VMM for state-of-the-art virtual memory
management: never again run out of dictionary space.  

My original intention was to again use LMI Forth, along with Dr.
Ting's updated book and the reams of PD Forth source to roll my own,
but the robustness and speed and compatibility between 32-bit 386 and
16 bit 8086 versions, not to mention LMI's long-term (10 years in
this industry is about as good as it gets) commitment to maintaining
and upgrading the product convinced me to put my time into the
application and let LMI to the Forth engine. 

The question of why pay more than $50 for a commercial Forth is along
the lines of why pay for good tools.  Answer: if you are a
professional, the money you invest in your tools is trivial compared
to the value of your time spent using them.  This is so obvious it
got me to wondering why it was even asked.  I think it might have
something to do with the issue of why do people use Forth at all when
the professional programming community is now so well supported by C.

I personally have come full circle with Forth: a decade ago I wrote a
Forth application that grew into a company.  When it came time to
write Version 2 of the application, it was done to my specifications
by the company's programming staff.  And it was written in C, not
Forth.  Now I have left the company to once again write original
applications solo and - after a year of mushing about in various
Lisp's - I am back to writing in Forth.

Thinking is greatly affected by the language we think in, and to no
small extent is limited by that language's limitations.  Procedural
languages such as C and Pascal and (horrors) Ada are just the ticket
when you are following a blueprint, or when you are hiring other
people to follow your own design.  But if you are doing original,
creative work you need the malleability of a self modifing language
such as Forth (or Lisp or Smalltalk).  Forth ends up being the best
of these because you can easily strip away the language support and
have the application running on its own, lean and mean.

So my answer to "Why Forth?" is, if the project is well defined so
that there is little creative design work involved, Forth is *not*
the best language.  You need something that narrows your focus, that
works to keep you from coloring out of the lines.  Barring other
considerations (such as military job specs), C is probably the
language of choice for such a project.

But if you are doing creative programming, where the end result is
being defined in an iterative process as you write and rewrite, Forth
seems to be the best (although far from perfect) choice.  Perhaps this
is why Forth seems to appeal to the fringe crowd: creative people
have always been considered fringe.  It goes with the territory.

ForthNet@willett.UUCP (ForthNet articles from GEnie) (01/12/90)

 Date: 01-11-90 (10:13)              Number: 252
   To: ALL                           Refer#: NONE
 From: RAY DUNCAN                      Read: (N/A)
 Subj: UR/FORTH 1.1 FOR MS-DOS       Status: PUBLIC MESSAGE

 UR/FORTH version 1.1 for MS-DOS will be released on February 1.  This
 version brings the UR/FORTH for MS-DOS into improved symmetry with the
 OS/2 16-bit protected mode and 80386 32-bit protected mode versions. 
 The graphics drivers and fonts have now been embedded in the Forth
 executable file, so that there is no longer any need for the separate
 TSR graphics driver and/or font utilities that were used in MS-DOS
 UR/FORTH 1.03.  The Intel 8087 and 80287 coprocessor floating point
 packages have also been extensively rewritten and there is a drastic
 improvement in the performance of transcendental instructions such as
 FSIN, FCOS, and FTAN.

 Along with the release of UR/FORTH 1.1 for MS-DOS there will be a change
 in UR/FORTH packaging.  The 16-bit UR/FORTHs for MS-DOS and OS/2, along
 with their object module compilers and libraries, will be combined in
 the same package and share the same manual.  The price will remain $350
 for now, although it will probably be raised after July 1.  Registered
 owners can purchase an update to the new version (with new manual) for
 $75.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'

ForthNet@willett.UUCP (ForthNet articles from GEnie) (01/17/90)

 Date: 01-16-90 (10:02)              Number: 280
   To: RAY DUNCAN                    Refer#: NONE
 From: YVES LAFOND                     Read: 01-16-90 (21:06)
 Subj: COMMENT                       Status: PUBLIC MESSAGE

 TECHNICAL SUPPORT DEMAND TO RICHARD WILTON OR ANYONE ABLE TO ANSWER!
 FROM YVES LAFOND & DENIS LAMBERT, COLLEGE OF SHERBROOKE, QC, CANADA
 WE HAVE PC/FORTH 3.2 (SERIAL 6088) AND FORTH METACOMPILER (SERIAL 470)
 PC/FORTH HAS 1 ANNOYING BEHAVIOUR: IF ANY ERROR OCCURS WHILE USING THE
 INTERPRETER, IT COMES BACK WITH DATA STACK POINTER AT THE ORIGIN, ETC.
 IT IS QUITE IRRITATING, ESPECIALLY WHILE WE ARE USING THE MULTITASK!
 WE MUST (IN FACT OUR STUDENTS!) START ALL THE TASKS ALL OVER AGAIN; AND\
 SINCE THEY'RE STUDENTS, ERRORS OCCUR QUITE OFTEN...
 HOW CAN WE CHANGE THIS BEHAVIOUR? CONSULTING THE METACOMPILER FORTH
 SOURCE CODE, ON SCREEN 65 AND 76, WE NOTICE THAT "QUIT" AND "ABORT" 
 DO A RE-INITIALIZATION OF THE STACK POINTERS. WOULD MODIFICATIONS TO 
 THOSE WORDS BE SUFFICIENT? HOW COULD WE CHANGE THAT SPECIFIC BEHAVIOUR
 OF THE ERROR HANDLING ROUTINE? WE ARE WAITING FOR AN ANSWER!
 YOURS TRULY, YVES LAFOND AND DENIS LAMBERT.
 P.S. WE WILL PHONE BACK IN A FEW DAYS TO CHECK IF ANY ANSWER IS 
 AVAILABLE.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'

ForthNet@willett.UUCP (ForthNet articles from GEnie) (02/12/90)

 Date: 02-10-90 (20:06)              Number: 416
   To: ALL                           Refer#: NONE
 From: PHIL BASFORD                    Read: (N/A)
 Subj: TICKER                        Status: PUBLIC MESSAGE

 I am in need of a faster TICKER definition to replace the 
 one in UR/FORTH ver. 1.03.  
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'

ForthNet@willett.UUCP (ForthNet articles from GEnie) (02/16/90)

 Date: 02-13-90 (18:38)              Number: 425
   To: RAY DUNCAN                    Refer#: 392
 From: PETER MURPHY                    Read: 02-13-90 (23:47)
 Subj: UR/F DICTIONARY               Status: PUBLIC MESSAGE

 Will the 386 version work on a 286 machine?  Or do you mean that the
 best way to gain dictionary space with UR/F is to give up on 286
 totally?  I mean, what are the hardware requirements for 386 UR/F?

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             

 Date: 02-13-90 (23:47)              Number: 426
   To: PETER MURPHY                  Refer#: 784
 From: RAY DUNCAN                      Read: NO
 Subj: UR/F DICTIONARY               Status: PUBLIC MESSAGE

 The 386 version requires a 386 or 486 processor.  I realize that in the
 short term this is not practical for many people, but at the rate that
 entry level systems are shifting from 286s to 386SXs the situation will
 be much different within a year.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'

ForthNet@willett.UUCP (ForthNet articles from GEnie) (02/19/90)

 Date: 02-17-90 (06:53)              Number: 437
   To: ALL                           Refer#: NONE
 From: BOB JENNER                      Read: (N/A)
 Subj: INCLUDING FROM ARCHIVES       Status: PUBLIC MESSAGE

 I've been working with a fairly large system (28 screen
 files / 860k or so), and wanted to move it to a laptop, but it
 wouldn't fit on a floppy and some ramdisk.
 .
 In kicking the problem around with Andrew Wilcox, we came up with
 the notion of modifying INCLUDE to get a screen file out of an
 ARC (or ZIP) file, include it, and then delete it.  The ARC in
 this case is about 240k, so there's plenty of room.  And running
 this INCLUDE out of a ramdisk is almost as fast as running off a
 garden variety hard drive.
 .
 I've uploaded it as INC_COMP.ARC

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'

ForthNet@willett.UUCP (ForthNet articles from GEnie) (02/19/90)

 Date: 02-17-90 (14:53)              Number: 439
   To: RAY DUNCAN                    Refer#: 426
 From: PETER MURPHY                    Read: NO
 Subj: UR/F DICTIONARY               Status: PUBLIC MESSAGE

 What about PCF+ for more memory.  Martin Tracy suggested that as an
 alternative.  How much of a speed reduction is there compared to URF on
 a 286 for example?

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'

ForthNet@willett.UUCP (ForthNet articles from GEnie) (02/20/90)

 Date: 02-18-90 (14:33)              Number: 442
   To: PETER MURPHY                  Refer#: 439
 From: RAY DUNCAN                      Read: NO
 Subj: UR/F DICTIONARY               Status: PUBLIC MESSAGE

 PC/FORTH+ is a reasonable alternative for increased dictionary, with two
 provisions:
 1) all your code defs will have to be rewritten
 2) there is a 50% or greater speed hit, unless your application is
 primarily disk bound or screen bound (the screen stuff is in assembler
 anyway so isn't appreciably slower, while disk stuff is DOS-limited
 rather than Forth-limited).

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'

ForthNet@willett.UUCP (ForthNet articles from GEnie) (02/24/90)

 Date: 02-21-90 (15:43)              Number: 455
   To: ALL                           Refer#: NONE
 From: PAUL MOORE                      Read: HAS REPLIES
 Subj: PCFORTH SUPPORT               Status: PUBLIC MESSAGE

 Please help.  I am upgrading some older software to v3.2 and am having a
 bit of a problem with the DOS File Interface.  I have defined HCB's and
 loaded a vaild drive:path\filename into them. The next magical act would
 be to FOPEN the file.  My result so far is always negative.  I have been
 feeding a mode = 0 since the only explanation of mode that I can find,
 under the FMAKE command would suggest that this is the correct value.  I
 have also tried without the drive and path specified, without any luck. 
 Please help me get to that zero flag so I can continue this task. 

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'

ForthNet@willett.UUCP (ForthNet articles from GEnie) (02/24/90)

 Date: 02-21-90 (16:04)              Number: 456
   To: PAUL MOORE                    Refer#: 838
 From: RAY DUNCAN                      Read: 02-22-90 (07:26)
 Subj: PCFORTH SUPPORT               Status: PUBLIC MESSAGE

 Take a look at the utility programs T2S and S2T which are provided in
 source form in the file FORTH.SCR.  These use DOSINT and provide working
 examples of FOPEN, FMAKE, N>HCB, etc.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'

ForthNet@willett.UUCP (ForthNet articles from GEnie) (03/01/90)

 Date: 02-27-90 (08:27)              Number: 475
   To: ALL                           Refer#: NONE
 From: FRANK RUSSO                     Read: (N/A)
 Subj: CROSSREF UTIL                 Status: PUBLIC MESSAGE

 I have developed a Forth Utility to Crossreference screen files
 identifying Variables and definitions and all of its occurances.
 It is almost complete and I will be uploading it within the next 
 2 weeks.  If interested please let me know.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'

ForthNet@willett.UUCP (ForthNet articles from GEnie) (03/02/90)

 Date: 02-28-90 (16:03)              Number: 482
   To: RAY DUNCAN                    Refer#: 164
 From: PAUL PRICE                      Read: 02-28-90 (18:15)
 Subj: EXECUTION TABLES              Status: PUBLIC MESSAGE

 I got the pc-forth and the metacompiler rev levels confused.
 The HEX problem arose in the following form:
   : ABORT
        S0 @ SP!
        HEX
        STATE OFF
        MAIN ;
 Where MAIN is my system's endless loop.   After compiling and
 blowing a prom, NOTHING worked.  The system was totally lost, in an
 embedded controller aplication with NO emulator.
  I subsequently went back to the application and recompiled with the
 base in ABORT left in decimal and individually selected HEX where
 needed, and the thing worked just fine.  If you have the answer, it
 would help my curiosity, but probably won't make me change my code
 again.     Thank you, Paul N. Price  c/o Decom Systems, Inc.
 Sorry about the delay, but I've been in Germany doing a system 
 installation........ (160,000 lines of FORTH on a 68010)

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'

ForthNet@willett.UUCP (ForthNet articles from GEnie) (03/16/90)

[ I'm posting this because I'm not able to tell whether it is of
  enough general interest to post, or whether it is just plain
  advertisement and should be suppressed.  Send your votes to the
  address at the end of this message and I'll tally them.  I'll also
  tally votes posted.  Perhaps a discussion about the various members
  of comp.lang.forth would like to see along these lines would be helpful?
  -Doug]

 Date: 03-14-90 (23:30)              Number: 504 (Echo)
   To: ALL                           Refer#: NONE
 From: RAY DUNCAN                      Read: (N/A)
 Subj: UR/FORTH 1.1                  Status: PUBLIC MESSAGE

 The update to UR/FORTH version 1.1 for MS-DOS is now being shipped.

 As of version 1.1 we have changed the packaging somewhat.  The DOS
 UR/FORTH, OS/2 UR/FORTH, object module compiler, and libraries are being
 shipped as a single bundle.  All purchasers will now receive the obj
 compiler and libraries whether they want them or not.  The MS-DOS and
 OS/2 versions have been brought into much closer symmetry.  The graphics
 drivers for the MS-DOS version, as well as the fonts, are now embedded
 in the UR/FORTH EXE file and no separate TSR graphics driver is needed.
 Support for 80x50 and 80x43 text modes has been added to the VGA driver.

 The price of the update to the new bundled version is $75; this includes
 the new manual which has been expanded to about 600 pages.  The price
 for new copies of the bundled UR/FORTH is still $350 but will soon be
 going up (July 1).

 The new versions are available for downloading on the LMI Forth Board,
 but we strongly recommend that you purchase the update disks and manual
 as the download files are *very* large.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'

ForthNet@willett.UUCP (ForthNet articles from GEnie) (05/09/90)

 Date: 05-05-90 (09:13)              Number: 575 (Echo)
   To: ALL                           Refer#: NONE
 From: RAY DUNCAN                      Read: (N/A)
 Subj: METACOMPILER 3.0              Status: PUBLIC MESSAGE

 LMI is now shipping a completely new, ROMable, 32-bit Metacompiler
 target for the 680x0 processor family.  The target source code adapts
 itself for the 68020 and 68332 processors by conditional compilation,
 and also includes the source code for a ROMable 68020 assembler. 

 This new Metacompiler target is posted for downloading in conference 5,
 directory 1.  We invite all current owners of the 16-bit and 32-bit
 680x0 targets to download and use this new target.  We intend to phase
 out the existing 16-bit 68000 target.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'

ForthNet@willett.UUCP (ForthNet articles from GEnie) (05/25/90)

 Date: 05-22-90 (20:53)              Number: 596 (Echo)
   To: JERRY SHIFRIN                 Refer#: 594
 From: JOHN SOMERVILLE                 Read: NO
 Subj: UR FORTH                      Status: PUBLIC MESSAGE

 Thanks Jerry, I have seen it up there, but have been reluctant to 
 download it because of its size. Of course compared to Roedy's original 
 it is puny ( in size ). I tinkered with Abundance but went on to other 
 things for some reason. Probably it would be a good thing for me to 
 write my own B-TREE. Of course if it is available on LMI...
 . 
 Are you going to Rochester this year? I had thought of going, but 
 chickened out at the last minute. I have arthritis, and the thought 
 of being without my usual panaceas, no matter how puny, usually makes me
 choke. Thus I always pull out.
 .
 As I recall you use UR. Is that correct?

 regards j

 NET/Mail : British Columbia Forth Board - Burnaby BC - (604)434-5886   
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu

ForthNet@willett.UUCP (ForthNet articles from GEnie) (05/27/90)

 Date: 05-24-90 (20:42)              Number: 600 (Echo)
   To: JERRY SHIFRIN                 Refer#: 597
 From: JOHN SOMERVILLE                 Read: NO
 Subj: UR FORTH                      Status: PUBLIC MESSAGE

 Thanks for the offer, you may be letting yourself in for more than your 
 bargained for. I got away from FORTH  for a while and was doing quite a 
 bit with PASCAL, but found that object oriented stuff ended up with some
 pretty large files. Some of the stuff I was working on ate up 90 K just 
 to create a menu, in addition I bought a 386 to get compile times down
 to something reasonable. You don't need a 386 for run of the mill
 stuff in FORTH.
    .
 Right now I am putting together tools for databases. As I mentioned 
 earlier, I thought of looking at someone else's code for ideas. However 
 sometimes it is just easier to write one's own from scratch. 
 .
 I like UR. It performs as advertised and I have had little trouble 
 getting it to do what I want. The biggest error I made was jumping into 
 assembler prematurely. I got rather a bad burn on one thing I was doing 
 so I went and hid in a corner for a while. 

 regards j

 NET/Mail : British Columbia Forth Board - Burnaby BC - (604)434-5886   
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu

ForthNet@willett.UUCP (ForthNet articles from GEnie) (05/27/90)

 Date: 05-24-90 (10:41)              Number: 601 (Echo)
   To: RAY DUNCAN                    Refer#: NONE
 From: BOB BARTLOME                    Read: 05-24-90 (18:15)
 Subj: SCSI/386                      Status: PUBLIC MESSAGE

 Hi, you have been very helpful in the past, so here goes:
 I am interfacing a digital audio tape (DAT). A 386 (DOS 3.3) is being
 used as a test-bed to exercise the DAT for the Quality Control
 Department.  The results of final test will be stored on disk and
 available for printout in  a number of formats. I have both a Future
 DOmain SCSI interface card and an Adaptec Interface card. Neither
 company supplies (or has available) a device driver for MS-DOS.  They
 assume that the device hooked to it will be the system disk drive and
 use the standard dos driver for disks? I need to be able to send
 individual commands (load, goto BOT, read, write, unload, etc.) to the S
 SCSI device.  Programming to be done in Forth 3.2+.  Once I can issue
 commands to the SCSI/DAT, everything else is a piece-of-cake(relative).

 Do you have any examples of forth code drivers, DMA drivers, any hints,
 suggestions? Any recommended books on the subject?  If I can get the
 SCSI/DAT to respond to commands and xfer simple data, then it will be a
 successful project and another accomplishmnet for Forth! 

 Right now, just a little confused about even rudimently forcing a
 command to the device.  ANY help or comments greatly appreciated. Time
 is very short. Thanks in advance...

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu

ForthNet@willett.UUCP (ForthNet articles from GEnie) (05/27/90)

 Date: 05-24-90 (18:15)              Number: 603 (Echo)
   To: BOB BARTLOME                  Refer#: 1267
 From: RAY DUNCAN                      Read: NO
 Subj: SCSI/386                      Status: PUBLIC MESSAGE

 I don't know anything about these particular SCSI drives.  I would
 suspect that they have a ROM BIOS on the adapter which translates
 traditional ROM BIOS function calls into SCSI commands.  They might also
 support a direct interface for SCSI control (IBM does on their card, I
 believe they use Int 4BH).  I don't see any alternative to calling up
 the company and asking them for technical documentation e.g. a ROM BIOS
 listing for their adapter.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu

ForthNet@willett.UUCP (ForthNet articles from GEnie) (05/31/90)

 Date: 05-28-90 (20:22)              Number: 604 (Echo)
   To: JOHN SOMERVILLE               Refer#: NONE
 From: JOHN SOMERVILLE                 Read: 05-28-90 (20:29)
 Subj: LMI PHONE NO.                 Status: PUBLIC MESSAGE

 A while ago I phoned the long distance operator to get the LMI phone 
 number, (my manual was at home). The number they gave me was wrong, it 
 was for LMI in Marina del Rey, but not " THE LMI ". Today the other LMI 
 called me, and I discovered the error. Scratch 4 calls (and $6) to an 
 answering machine. 

 " Thank you for calling with ATT " 

 Seems the number is still (213) 306-7412 as it was before the move. 
 Confirmation please.

 regards j

 NET/Mail : British Columbia Forth Board - Burnaby BC - (604)434-5886   
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu

ForthNet@willett.UUCP (ForthNet articles from GEnie) (06/01/90)

 Date: 05-29-90 (21:02)              Number: 605 (Echo)
   To: JERRY SHIFRIN                 Refer#: NONE
 From: JOHN SOMERVILLE                 Read: NO
 Subj: URABUN                        Status: PUBLIC MESSAGE

 I decided to tempt fate and download URABUN. After 389 K ( out of 493 ) 
 something hung up somewhere: a time out error. I should have trusted my 
 instincts. I looked through what I did pull down and of course none of 
 the files would compile. 

 Actually I may just use an index for the database that I'm making. It 
 is pretty small, less than 1,000 records. What I want to do is generate 
 reports which contain names that map onto multiple categories. There are
 80 categories and approximately 700 names. I suppose I could reserve 10 
 bytes match strings with a numerical index and OR entries to the 
 categories. Reports could be generated using a mask, for only one 
 category need be reported at any one time. 

 Any comments?

 regards j.

 NET/Mail : British Columbia Forth Board - Burnaby BC - (604)434-5886   

 Date: 05-29-90 (21:24)              Number: 606 (Echo)
   To: JERRY SHIFRIN                 Refer#: NONE
 From: JOHN SOMERVILLE                 Read: NO
 Subj: 10 BYTES YIKES                Status: PUBLIC MESSAGE

 What am I thinking of. Its UR I'm using not ERR.

 regards j

 NET/Mail : British Columbia Forth Board - Burnaby BC - (604)434-5886   
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu

ForthNet@willett.UUCP (ForthNet articles from GEnie) (06/01/90)

 Date: 05-29-90 (09:51)              Number: 607 (Echo)
   To: JOHN SOMERVILLE               Refer#: 604
 From: RAY DUNCAN                      Read: NO
 Subj: LMI PHONE NO.                 Status: PUBLIC MESSAGE

 Yes, the phone number has never changed: voice is 213-306-7412.  We paid
 the phone company extra to keep the same number!!  So I don't know why
 they gave you so much hassle...

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu

ForthNet@willett.UUCP (ForthNet articles from GEnie) (06/01/90)

 Date: 05-29-90 (20:54)              Number: 609 (Echo)
   To: ALL                           Refer#: NONE
 From: SCOTT SCHAD                     Read: (N/A)
 Subj: WINDOWS?                      Status: PUBLIC MESSAGE

 I'd like to port some of my software to run under Windows, but don't
 want to use C to do it.  Does UR4th allow you develop Windows programs,
 or is it really for OS/2?  I've got PC Forth at the moment, and am
 trying to decide on an upgrade path.  <STS>
 /ex

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu

ForthNet@willett.UUCP (ForthNet articles from GEnie) (06/02/90)

 Date: 05-30-90 (18:28)              Number: 612 (Echo)
   To: JOHN SOMERVILLE               Refer#: 605
 From: TED GOSSTYLA                    Read: NO
 Subj: URABUN                        Status: PUBLIC MESSAGE

 I expect to have the UR/Forth 1.10 DOS version of URABUN complete within
 the next couple of weeks.

 The Q and A segments have been attached to the .OVL file with
 appropriate modifications made to START.OBJ and SAVE, BSAVE and BGET
 in ELECTIVE.SCR.

 Unlike the current version no changes are required to the Nucleus,
 other than linking the revised START.OBJ.

 Several new data structures have been added and the xdb SQL API has
 been refined.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu

ForthNet@willett.UUCP (ForthNet articles from GEnie) (06/02/90)

 Date: 05-30-90 (22:38)              Number: 614 (Echo)
   To: SCOTT SCHAD                   Refer#: 609
 From: RAY DUNCAN                      Read: NO
 Subj: WINDOWS?                      Status: PUBLIC MESSAGE

 We don't have an UR/FORTH version for Windows at this point --- only for
 plain DOS, for OS/2, and for 80386 32-bit protected mode.  However, now
 that I have the Win 3 toolkit, I am thinking seriously about creating a
 Win 3 version of UR/FORTH.  This is because Win 3 relieves all the
 memory problems that made implementing a Forth under the old versions of
 Windows very painful.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu

ForthNet@willett.UUCP (ForthNet articles from GEnie) (06/02/90)

 Date: 05-30-90 (22:39)              Number: 615 (Echo)
   To: JOHN SOMERVILLE               Refer#: 605
 From: RAY DUNCAN                      Read: NO
 Subj: URABUN                        Status: PUBLIC MESSAGE

 If you want to send us a high-density disk and a couple of stamps, we'll
 be glad to send you URABUN on the disk so you won't have to spend all
 that money downloading it.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu

ForthNet@willett.UUCP (ForthNet articles from GEnie) (06/04/90)

 Date: 05-31-90 (21:01)              Number: 616 (Echo)
   To: JOHN SOMERVILLE               Refer#: 605
 From: JERRY SHIFRIN                   Read: NO
 Subj: URABUN                        Status: PUBLIC MESSAGE

 JS>Actually I may just use an index for the database that I'm making. It
 JS>is pretty small, less than 1,000 records. What I want to do is generate

 For a small, quick 'n dirty database, it's pretty easy to use
 Forth blocks.  Just dedicate a couple of blocks in the beginning
 as an index and off you go.  What could be easier?
 ---
  ~ EZ 1.29 ~ 
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu

ForthNet@willett.UUCP (ForthNet articles from GEnie) (06/10/90)

 Date: 06-07-90 (09:14)              Number: 634 (Echo)
   To: JACK CREASEY                  Refer#: 633
 From: RAY DUNCAN                      Read: NO
 Subj: UPGRADE TO MY FORTH           Status: PUBLIC MESSAGE

 If you already own the Metacompiler, the cost of an additional target is
 $500.  Otherwise, the cost for the Metacompiler with 8051 target is
 $750.  There isn't any discount or "upgrade" deal for owners of CFORTH
 or PC/FORTH or 8086 FORTH --- the Metacompiler is a completely separate
 product.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu

ForthNet@willett.UUCP (ForthNet articles from GEnie) (06/16/90)

 Date: 06-12-90 (06:34)              Number: 642 (Echo)
   To: KEITH MUND                    Refer#: 641
 From: MICHAEL HAM                     Read: 06-12-90 (15:41)
 Subj: WINDOWS                       Status: PUBLIC MESSAGE

 There is a debugger in the UR/FORTH conference you can download.
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu

ForthNet@willett.UUCP (ForthNet articles from GEnie) (06/16/90)

 Date: 06-12-90 (17:29)              Number: 643 (Echo)
   To: JOHN SOMERVILLE               Refer#: 635
 From: TED GOSSTYLA                    Read: NO
 Subj: URABUN                        Status: PUBLIC MESSAGE

 UR/Abundance has the following sorting facilities:
 1. SORT as defined in Roedy's Abundance for arrays. It is an 
    internal sort.
 2. A variation of Roedy's <<<BTREE is also supported. However, we
    adapted INDEX+ to UR/Abundance instead of providing hooks to
    Btrieve.  <<<BTREE objects are stored in files.
 3. <<<SQL is provided in UR/Abundance. It supports the Forth API I
     wrote for xdb's SQL engine.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu

ForthNet@willett.UUCP (ForthNet articles from GEnie) (06/27/90)

Category 1,  Topic 46
Message 85        Tue Jun 26, 1990
R.BERKEY [Robert]            at 22:00 PDT
 
  Topic: portability, input stream standardization

Ray Duncan writes (to Robert Berkey), 900618:

  RD> Since the ANSI process mandates that standards be built on
  RD> existing practice, I'm surprised that you have not taken the
  RD> trouble to research how the current, commercially available
  RD> systems are already handling these problems.

I don't see a need to respond to this statement beyond noting that it is
emotive and ad hominem.

 RD> In LMI systems, the variables >IN, BLK, etc. are read-only to the
 RD> application.

In (at least some) LMI systems, the variable >IN is read/write, with the
variable BLK being nominally read-only.  As for BLK , here is an example of
LMI-based application code, being used as part of restoring BLK :

   : SOURCE! 14964 2! ;

The point is not what this means or does, but that applications store into BLK
on LMI systems, however cryptic the process.

  RD> This allows a much more efficient implementation of the
  RD> interpreter/compiler, particularly in WORD.

A code fragment to check for a modified BLK :

 MOV AX, DEFAULT-BLK
 CMP AX, BLK
 <> IF

This code fragment constitutes about 13 cycles on an 80286.  At 10Mhz this is
less than two microseconds per token, i.e., more than 500,000 tokens per
second.

  RD> If you allow the application to twiddle these variables, the
  RD> system is forced to check BLK each time it reads a token off the
  RD> input stream to make sure the input stream has not been moved
  RD> behind its back.

I agree as far as saying I think that it is preferable to standardize ways
other than storing into BLK for setting the input stream.  If LMI has offered
X3.J14 any proposals I'm not aware of it.

  RD> The existence of a word with the functionality of EVALUATE
  RD> completely eliminates any need for the application to twiddle >IN
  RD> etc. to manipulate the input stream.

Not when the source is on BLOCKs--EVALUATE has multiprogramming impact, and
portable programs must allow for multi-tasking.  Additionally, if EVALUATE is
pointed at source on a BLOCK , there is a problem when such code needs to know
the real value in BLK , as opposed to the 0 found there from within an
EVALUATE .  Thirdly, directly setting the input stream pointers is more
efficient than EVALUATE for passing a <name> to CREATE , as this bypasses the
interpreter and vocabulary mechanisms.

 RD> But I can tell you from a *practical* standpoint, from experience
 RD> with Forth systems that have thousands of users, that making >IN
 RD> BLK etc. read-only works perfectly well *if* you provide with a
 RD> superior alternative such as EVALUATE.

Meanwhile, code won't port to LMI systems, and LMI user's must work around the
problem.  Which gets back to the original question to LMI users: What's needed
to run QUOTE-TO.SCR on LMI products?

Robert

-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu

ForthNet@willett.UUCP (ForthNet articles from GEnie) (06/29/90)

 Date: 06-26-90 (22:06)              Number: 673 (Echo)
   To: ALL                           Refer#: NONE
 From: JOHN SOMERVILLE                 Read: (N/A)
 Subj: UR...UMMMMMM                  Status: PUBLIC MESSAGE

 MU/MOD is not documented. The stack picture is ( d n 0 drem ), actually
 it seems that you might get away with ( n n -- garbage drem ). Comments.
 regards j

 NET/Mail : British Columbia Forth Board - Burnaby BC - (604)434-5886   

 Date: 06-26-90 (22:21)              Number: 674 (Echo)
   To: ALL                           Refer#: NONE
 From: JOHN SOMERVILLE                 Read: (N/A)
 Subj: UR...UMMM PART 2              Status: PUBLIC MESSAGE

 The stack picture for MU/MOD is ( d n -- rem dquotient ) rather than
 what I gave in the previous message.
 regards j

 NET/Mail : British Columbia Forth Board - Burnaby BC - (604)434-5886   
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu

ForthNet@willett.UUCP (ForthNet articles from GEnie) (07/01/90)

 Date: 06-28-90 (09:04)              Number: 679 (Echo)
   To: R.BERKEY [ROBERT]             Refer#: 676
 From: RAY DUNCAN                      Read: NO
 Subj: LMI FORTH(S)                  Status: PUBLIC MESSAGE

 The code   xxx 2!  is not storing to BLK but to the storage area of a
 2EQU which defines the start and length of the input stream.  This 2EQU
 has a header with the name SOURCE, it is documented in our manuals, and
 it can be modified by any user code (see, for example, the source code
 for INCLUDE which may be found in ELECTIVE.SCR).

 You are correct, >IN can be modified in our systems, it's BLK that is
 read-only.  Your cycle counts are meaningless because I was not
 referring to the action of loading BLK itself but the stuff that must
 depend on it in systems where BLK is changeable ---

    BLK @ ?DUP IF BLOCK ... ELSE TIB #TIB @ ...

 The execution of BLOCK is typically relatively slow because (in systems
 with more than one block buffer) it must scan all buffers and compute
 the address of the base of the desired block (if already in memory) or
 actually hit the disk (if the block buffer has been reassigned).

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu

ForthNet@willett.UUCP (ForthNet articles from GEnie) (07/01/90)

 Date: 06-28-90 (10:26)              Number: 681 (Echo)
   To: RICHARD BARNHART              Refer#: 678
 From: RAY DUNCAN                      Read: 06-28-90 (22:30)
 Subj: UR FORTH INSTALL              Status: PUBLIC MESSAGE

 There is no reason why UR/FORTH must run on drive C:.  It doesn't care
 where it is running from.  You can change all C: to E: in the
 INSTALL.BAT file if you want, there will be no harmful side effects.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu

ForthNet@willett.UUCP (ForthNet articles from GEnie) (07/01/90)

 Date: 06-28-90 (10:32)              Number: 682 (Echo)
   To: R.BERKEY [ROBERT]             Refer#: 676
 From: RAY DUNCAN                      Read: NO
 Subj: LMI FORTH(S)                  Status: PUBLIC MESSAGE

    >...proposals other than BLK for setting the input stream.  If
    >LMI has offered... any proposals I am not aware of it...

 This is because, as far as we are concerned and for all of our existing
 source code, the inclusion of EVAL (aka EVALUATE) in ANS Forth would
 take care of our needs to manipulate the source stream.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu

ForthNet@willett.UUCP (ForthNet articles from GEnie) (07/16/90)

 Date: 07-12-90 (05:20)              Number: 711 (Echo)
   To: KEN JANDA                     Refer#: 701
 From: CHARLES WILSON                  Read: NO
 Subj: UR/FORTH ASSEMBLER            Status: PUBLIC MESSAGE

 The top of stack is stored in EBX which is why you actually interchanged
 the next two items on the stack.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             

 Date: 07-12-90 (08:15)              Number: 712 (Echo)
   To: KEN JANDA                     Refer#: 701
 From: RAY DUNCAN                      Read: NO
 Subj: UR/FORTH ASSEMBLER            Status: PUBLIC MESSAGE

 In UR/FORTH, the logical top of stack is actually in EBX at all times.
 This is explained in the assembler section of the manual, and also
 demonstrated in the example CODE definitions in the manual.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu

ForthNet@willett.UUCP (ForthNet articles from GEnie) (07/17/90)

 Date: 07-14-90 (16:12)              Number: 3508 (Echo)
   To: CINDY BARTORILLO              Refer#: 3492
 From: MICHAEL HAM                     Read: NO
 Subj: HELP FOR BEGINNER             Status: PUBLIC MESSAGE

 LMI has conferences that are for customers only (registration of
 purchased product allows entry to conference), but when you sign on you
 are in the public conference.  On the LMI board the SYSOP is RAY DUNCAN
 (whom can also be reached on ForthNet with that name).  The LMI BBS is,
 so far as the public is concerned, open to everyone with a 1200 bps
 modem.  Ray sent me a message last week that the book is in the final
 stages of production.

 Regarding the compatibility of Forth and MS-DOS:  I know exactly what
 you mean, and that is what brought me to LMI's Forth some years ago. 
 UR/FORTH is very comfortable with MS-DOS, with Windows, and with OS/2. 
 Ray has do7- a fantastic job of implementation, and I say that not
 because he is publishing the book.  I picked LMI Forth for a major
 project long before I even thought of doing a book.  It has been great
 and LMI support (via the BBS) is equally fine.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu

ForthNet@willett.UUCP (ForthNet articles from GEnie) (07/20/90)

 Date: 07-17-90 (13:50)              Number: 718 (Echo)
   To: RAY DUNCAN                    Refer#: NONE
 From: JIM DAVIS                       Read: NO
 Subj: 68KFORTH+ VER 2.2, 3.0        Status: PUBLIC MESSAGE

 Hi Ray,
 It appears there is a problem with the old version of the metacompiler.
 ver 2.2 for 68k FORTH+ ( uses 32 bit token table, 16 bit word ptrs )
 Will not generate .IMG file for size over 64K, Error message returned
 when writing object file is " can't write object file ". Disk space
 is ~ 8 Mb free on 110 Mb drive. size of .IMG file written is
 Actual size of image - 65536 and the first part of the image file
 appears ok. I guess a 16 bit pointer was used to maintain the object
 code buffer area. I am unable to use the latest versions 3.0 due to some
 restrictions on the size of the image.i.e. Using 16 bit word pointers
 appears to restrict total code space to 64Kb.
 Questions:
 1) Is it possible to fix?
 2) Will LMI Assist us in resolving this problem?
 3) Is version 3 really restricted to 16 bit relative addressing
 4) Know of and other workarounds?
 Our application is currently in the 60-70 Kb range ( object )
 and we planned on dding major inhancments to the system. I expect the
 system to eventually reach the 100-150 Kb Before the next release.
 Were really between a rock and a hard place at the moment, I have other
 projects coming on line in a few weeks and have to get this out the door
 before all my other schedules start to slip. We also have two other
 projects ( one for the Air force and one for the British Navy ) that
 will be using the Ver 2.2 imbedded FORTH.
 If you can't come up with a workaround, Would it be possible ( with
 the proper non-disclosure agrement ) to aquire the meta compiler source
 for version 2.2? I Will have my boss contact you after I receive your
 reply.   Thanks Again,
 Jim Davis @ RTE ( 509 ) 773-3796 ( voice ) , 773-5682 ( FAX)

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu

ForthNet@willett.UUCP (ForthNet articles from GEnie) (07/26/90)

 Date: 07-23-90 (22:03)              Number: 727 (Echo)
   To: JIM DAVIS                     Refer#: NONE
 From: RAY DUNCAN                      Read: NO
 Subj: BUG IN 68K+ / AND /MOD        Status: PUBLIC MESSAGE

 I don't have the 68000 metacompiler with me.  But I don't see a problem
 with the example you gave, unless the assembler is generating the wrong
 code.  The flags get set by the  (SP) D1 MOVE, in  the definition of /,
 then the bottom byte of D2 gets initialized by the SMI instruction in
 wm/mod then sign extended to 16-bits then 32-bits.  It looks kosher from
 here; if there is something I don't understand about how the MOVE
 instruction sets flags and SMI responds to the flags, could you please
 explain the bug to me further and give me an example of which math
 operation fails.  I thought I tested all the divide operators for all
 the possible combinations of signs etc. but if you can give me a
 specific set of arguments and results that are incorrect I'll get it
 fixed for you right away.  Don't forget we are Forth-83 compliant so
 division is floored.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu

ForthNet@willett.UUCP (ForthNet articles from GEnie) (07/29/90)

 Date: 07-25-90 (10:02)              Number: 731 (Echo)
   To: GARY SMITH                    Refer#: 723
 From: RAY DUNCAN                      Read: NO
 Subj: LMI FORTH(S)                  Status: PUBLIC MESSAGE

 Windows uses cooperative rather than preemptive multitasking.  So while
 your application is in control it can have all the CPU cycles it wants,
 for all practical purposes.  The graphics primitives in Windows are very
 well optimized and they are much more sophisticated than in our
 MS-DOS UR/FORTH .

 Windows offers all sorts of interesting graphics operations like
 bit-blitting with stretch or shrink, as well as a variety of fonts in
 all sizes and styles, that would be impractical to implement in the
 normal MS-DOS UR/FORTH.

 As we are currently looking at this, UR/FORTH will create a main or
 "frame" window which will ordinarily be used for drawing by the
 application.  During the development cycle it will also create an
 accessory "interpreter" window where all interactive commands and
 editing will occur; this window will not appear in the final
 application.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu

ForthNet@willett.UUCP (ForthNet articles from GEnie) (07/29/90)

 Date: 07-25-90 (09:57)              Number: 730 (Echo)
   To: PAUL PRICE                    Refer#: NONE
 From: RAY DUNCAN                      Read: 07-25-90 (20:39)
 Subj: COMMENT                       Status: PUBLIC MESSAGE

 We have to see what the committee produces first.  Their original
 charter was to create a standard based on Forth-83.  If the final result
 is reasonably upward-compatible with Forth-83 then we'll implement it.
 If the final result is hopelessly incompatible with Forth-83 and would
 cost our customers thousands of man hours of conversion time, then we
 won't implement it.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu

ForthNet@willett.UUCP (ForthNet articles from GEnie) (08/07/90)

 Date: 08-05-90 (12:00)              Number: 742 (Echo)
   To: RAY DUNCAN                    Refer#: 731
 From: GENE LEFAVE                     Read: NO
 Subj: LMI FORTH(S)                  Status: PUBLIC MESSAGE

 RD>Windows offers all sorts of interesting graphics operations like
 RD>bit-blitting with stretch or shrink, as well as a variety of fonts in

 Have you seen the MacForth package from CSI, particularly the Sibley editor.
 As my kid woulvqay,   AWESOME!

 I've got to believe that a FORTH package on windows with a complete windows 
 interface would be well recieved. 

 Gene

 ---
  ~ EZ-Reader 1.13 ~ 
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu

ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (08/13/90)

 Date: 08-08-90 (07:06)              Number: 743 (Echo)
   To: RAY DUNCAN                    Refer#: NONE
 From: PETE KOZIAR                     Read: 08-08-90 (17:37)
 Subj: 8751 FORTH                    Status: PUBLIC MESSAGE

 Hi there.  I'm working on a project for which an 8751 Forth would be tre
 nice.  I understand you guys have such a beast; if so, can you tell me
 about it (including the bottom line)?

 My development environment would be a Compaq 386/25.

 By the other way, do y'all have anything for Windows 3.0?

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us

a684@mindlink.UUCP (Nick Janow) (08/13/90)

ForthNet@willett.UUCP (GENE LEFAVE) writes:

> Have you seen the MacForth package from CSI, particularly the Sibley editor.
> As my kid would say,   AWESOME!

I haven't used anything other than MacFORTH Plus, so I guess I've been taking
the editor (and the rest of it) for granted.  It hadn't occured to me that the
rest of FORTH users might be putting up with unfriendly editors.

Should I be feeling sympathetic towards non-MacFORTH users?  :-)

ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (08/23/90)

 Date: 08-20-90 (21:43)              Number: 755 (Echo)
   To: RAY DUNCAN                    Refer#: NONE
 From: RON FARRER                      Read: 08-20-90 (23:39)
 Subj: COMMENT                       Status: PUBLIC MESSAGE

 Help! Curently I am running urforth. I need some way of running urforth
 out of Windows 3.0. I understand about protected mode operation. The
 best way I know how to do it is a file (.BAT?), the would exit windows
 and start urforth. Any ideas? Thanks... Ron

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us

ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (08/23/90)

 Date: 08-20-90 (23:37)              Number: 757 (Echo)
   To: RON FARRER                    Refer#: 1602
 From: RAY DUNCAN                      Read: NO
 Subj: COMMENT                       Status: PUBLIC MESSAGE

 You should be able to run UR/FORTH in a Windows 3.0 full-screen session
 without any trouble; I have done this often.  Just double-click on the
 DOS icon, then run UR/FORTH.  Or you can double-click on FORTH.COM and
 run it directly from the program manager or file manager, but you may
 need to set up a PIF file to tell Windows that Forth needs to run
 full-screen and so on.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us

ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (09/12/90)

 Date: 09-07-90 (08:55)              Number: 765 (Echo)
   To: ALL                           Refer#: NONE
 From: RON TOLER                       Read: (N/A)
 Subj: MEMORY AVAIL TO MALLOC        Status: PUBLIC MESSAGE

      I'm currently rewriting a memory allotment routine by using
 the MALLOC and REALLOC commands.  Is there any method whereby I
 can determine the amount of free memory available to MALLOC without
 actually having to assign it to my program.  I use this value as
 an indication of when it is neccessary to 'flush' memory of past
 used files that are at present resident but inactive.


 Ron Toler
 Visiontech
 3160  W. Kearney
 Springfield  MO  65803
 (417)  862-8100


 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             

 Date: 09-08-90 (23:01)              Number: 766 (Echo)
   To: RON TOLER                     Refer#: 765
 From: RAY DUNCAN                      Read: NO
 Subj: MEMORY AVAIL TO MALLOC        Status: PUBLIC MESSAGE

 There isn't a straightforward way to do this.  We want code that uses
 MALLOC to be portable across all our systems, and in some environments
 (such as OS/2) MALLOC won't fail until the system's virtual memory is
 exhausted.  If you plan to run only under DOS, use the INT86 operator to
 call MS-DOS Int 21H Function 48H with BX=FFFFH; this will always fail,
 but upon return you'll see the number of paragraphs of actual memory
 available in register BX.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us

ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (09/14/90)

 Date: 09-11-90 (13:33)              Number: 767 (Echo)
   To: RAY DUNCAN                    Refer#: NONE
 From: RON TOLER                       Read: NO
 Subj: MEMORY AVAIL TO MALLOC        Status: PUBLIC MESSAGE

     The INT86 command will work for now.  We have discussed using
 some other operating system but for now we plan to stick with DOS but
 have been looking at using extended memory cards for placing our
 file data instead of the computers primary memory, but as of yet we
 will probably use the INT86.
     Thanks   Ron Toler

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us

ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (09/15/90)

 Date: 09-12-90 (15:24)              Number: 768 (Echo)
   To: RAY DUNCAN                    Refer#: NONE
 From: KEN BOWERS                      Read: 09-12-90 (22:45)
 Subj: COMMENT                       Status: PUBLIC MESSAGE

 RE:VM386  THE PROBLEM IS THAT THE APPLICATION WILL ONLY START IF THE
 FORTH PROGRAM IS IN FOREGROUND. WHEN THE SYSTEM IS BOOTED AND THE FORTH
 PROGRAM IS IN THE BACKGROUND, IT WILL NOT START, BUT HANGS WAITING. AS
 SOON AS THE VIRTUAL MACHINE IS BROUGHT TO THE FOREGROUND, THE
 APPLICATION BEGINS AND CONTINUES NORMALLY IN BACKGROUND. THE FORTH
 PROGRAM DOES NOT FORCE A SWITCH, BUT MUST BE SWITCHED INORDER TO START.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             

 Date: 09-12-90 (22:45)              Number: 769 (Echo)
   To: KEN BOWERS                    Refer#: 1664
 From: RAY DUNCAN                      Read: NO
 Subj: COMMENT                       Status: PUBLIC MESSAGE

 Sounds like the video mode switch to 80x25 text mode that Forth requests
 when it starts up is causing your problem then.  I suppose VM386
 requires the mode switching session to be in the foreground to simplify
 the task of virtualizing the display.  You can revector the IDENT word
 so it doesn't call VINIT (see the "internals" section of the manual
 which lists the vector locations).

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us

ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (09/17/90)

 Date: 09-14-90 (15:04)              Number: 770 (Echo)
   To: RAY DUNCAN                    Refer#: NONE
 From: PETER JAMES                     Read: 09-14-90 (15:50)
 Subj: WINDOWS3.0 SUPPORT            Status: PUBLIC MESSAGE

 Ray, I received your message about no expert systems. I would still like
 to know when and if you plan to have Windows3.0 support. I am working on
 a big project at HP and would like to use your forth put need Windows3.0
 support. Also I would be willing to willing to do this interfacing if
 you won't have it soon. Would you like to resell this. I have a complete
 distributed database, 4GL language, hypertext editor and many
 applications already written. On the Macintosh I have developed an
 interface drawing tool that I would like to use to drive Windows3.0. 

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             

 Date: 09-14-90 (15:13)              Number: 771 (Echo)
   To: RAY DUNCAN                    Refer#: NONE
 From: PETER JAMES                     Read: 09-14-90 (15:50)
 Subj: EXECUTING PROGRAMS            Status: PUBLIC MESSAGE

 I have another question. I am trying to execute a program from within
 forth+. I tried to modify the Run command in the 16 bit version.(ie.
 stk_ptr ADDR>S&O 10000 / DW, instead of stk_ptr DW,) but it doesn't
 work. Is there a word that does this in FORTH+.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us

ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (09/17/90)

 Date: 09-14-90 (15:50)              Number: 774 (Echo)
   To: PETER JAMES                   Refer#: 1671
 From: RAY DUNCAN                      Read: NO
 Subj: EXECUTING PROGRAMS            Status: PUBLIC MESSAGE

 See the file RUN32.ARC in directory 6.  This is written for PC/FORTH+
 3.1 but should also be compatible with 8086 FORTH+.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us

ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/21/90)

   To: ALL                           Refer#: NONE
 From: RAY DUNCAN                      Read: (N/A)
 Subj: 80386 UR/F INTERRUPTS         Status: PUBLIC MESSAGE
 Several of our users have asked me for an example of an interrupt
 handler for 80386 UR/FORTH 1.15 that could execute high level code
 during an interrupt service.  Example code is provided below.  This
 code can be downloaded from the LMI BBS conference #4 in the file
 URTIM386.ZIP.

 *** CAVEAT PROGRAMMER *** If virtual memory is enabled, and a page
 fault occurs during an interrupt service, the only clue might be a
 hard reset of the machine.  You may find it easier to disable the VMM
 if you are going to write your own interrupt handlers.  Also beware
 of slow high level code executed at interrupt time; the effect of
 nested interrupts can be unpredictable.

 *** CAVEAT PROGRAMMER *** Take extreme care when executing high level
 code during an interrupt; many UR/FORTH video, graphics, and compiler
 words are NOT reentrant.

 ASM  FORTH DEFINITIONS HEX

 01C CONSTANT INT_#              \ timer tick interrupt

 2VARIABLE PREV_PVEC             \ prev prot mode int vector
  VARIABLE PREV_RVEC             \ prev real mode int vector
 2VARIABLE OLDSTACK              \ store SS, ESP at ISR entry
  VARIABLE HANDLER               \ CFA of high level handler

  CREATE DSTACK 400 ALLOT        \ data stack for ISR
  CREATE RSTACK 400 ALLOT        \ return stack for ISR

  0. PREV_PVEC 2!  0 PREV_RVEC !  0 HANDLER !

 \ --- ;  this routine terminates execution of threaded code,
 \ restores registers to their state at the ISR entry, and
 \ executes the interrupt return.
 CODE INTRET SS, OLDSTACK MOV                 \ restore old stack
             ESP, OLDSTACK 4 + MOV
             GS POP  FS POP  ES POP   DS POP  \ restore registers
             EBP POP  EDI POP  ESI POP
             EDX POP  ECX POP  EBX POP  EAX POP
             IRETD    END-CODE                \ 32-bit int return

 \ This is the low-level or machine interrupt handler.
 \ We service the interrupt in protected mode regardless of
 \ the mode that the interrupt occurred in.
 PROC INTSVC EAX PUSH  EBX PUSH  ECX PUSH  EDX PUSH       \ save
             ESI PUSH  EDI PUSH  EBP PUSH            \ registers
             DS PUSH ES PUSH FS PUSH GS PUSH
             EAX, # DS0 MOV              \ PharLap data selector
             DS, AX MOV  ES, AX MOV         \  (always the same)
             OLDSTACK , SS MOV              \ save old stack ptr
             OLDSTACK 4 + , ESP MOV
             SS, AX MOV                      \ set up new stacks
             ESP, # DSTACK 400 + MOV   EBP, # RSTACK 400 + MOV
             CLD                          \ clear Direction flag
             EAX, HANDLER MOV  EAX, EAX OR   ' INTRET JZ
             EAX JMP  END-PROC               \ branch to handler

 \ This word captures the real mode and protected mode vectors
 \ so that the interrupt will always be serviced in prot mode.
 \ --- ; initialize interrupt vector
 : TRAP      PREV_PVEC D@  OR  0=
             IF   INT_# regECX !         \ get prev prot mode vec
                  2502 regEAX !  21 INT86
                  regES @  regEBX @  PREV_PVEC D!
                  INT_# regECX !         \ get prev real mode vec
                  2503 regEAX !  21 INT86
                  regEBX @  PREV_RVEC !
             THEN
             XS0 regDS !  INTSVC regEDX !         \ set protected
             INT_# regECX !   2506 regEAX !        \ mode handler
             21 INT86 ;

 \ This word releases the interrupt vectors.
 \ In general, you ALWAYS need to restore the original interrupt
 \ vector before your application exits.  In this particular
 \ case, however, UR/FORTH automatically restores the timer tick
 \ vector when it terminates (because the multitasker uses it)
 \ so execution of UNTRAP isn't strictly necessary.
 \ --- ; release interrupt vector
 : UNTRAP    PREV_RVEC @ regEBX !         \ prev real mode vector
             PREV_PVEC D@            \ prev protected mode vector
             regEDX !  regDS !
             INT_# regECX !
             2507 regEAX !  21 INT86 ;      \ restore old handler
 DECIMAL

 \ EXAMPLE of a high level interrupt handler.  It increments TEST-VAR
 \ each time a timer tick occurs, then performs an interrupt
 \ return.  Load this code,  then enter:  TEST-VAR @ .  
 \ repeatedly to watch variable incrementing.
 VARIABLE TEST-VAR

 : TEST-HANDLER  1 TEST-VAR +!  INTRET ;

 ' TEST-HANDLER   HANDLER !    \ install the high-level handler
 TRAP                        \ capture the timer tick interrupt


 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp

ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/21/90)

   To: ALL                           Refer#: NONE
 From: RAY DUNCAN                      Read: (N/A)
 Subj: 80836 UR/F INTERRUPTS         Status: PUBLIC MESSAGE
 If you are going to service interrupts in a 80386 UR/FORTH application,
 you should LOCK DOWN the pages that contain the handlers in order to
 avoid a page fault at interrupt time.  If you are going to execute HIGH
 LEVEL Forth code during the execution of an interrupt, then you should
 lock down the entire code and data segment up to HERE to eliminate the
 possiblity of a page fault.  Page locking requires a direct call to the
 Phar Lap DOS Extender interface via the INT86 word.  If you need further
 information on the page locking function, we can FAX you the appropriate
 pages from the Phar Lap DOS Extender manual.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530             
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp

ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (11/08/90)

 Date: 10-11-90 (12:10)              Number: 128 of 157 (Echo)
   To: BRIAN BUCALO                  Refer#: 1747
 From: GENE LEFAVE                     Read: NO
 Subj: COMMENT                       Status: PUBLIC MESSAGE
 Conf: FORTH (58)                 Read Type: GENERAL (+)

 I've converted some PC/FORTH code to poly FORTH.  It helps that I have
 both PC/FORTH and PC/FORTH+.  I've found it pretty easy to do except
 for some of the assumptions in PC/FORTH regarding strings and I/O.

 The biggest problems occur if you're sharing the code in a multi-user
 enviornment.

 I'd be glad to give some pointers.  But you might be better off just
 buying PC/FORTH.

 Gene
 ---
  ~ EZ-Reader 1.13 ~

 NET/Mail : East Coast Forth Board -- McLean, VA -- 703-442-8695
 <<<>>>
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp

ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (11/08/90)

 Date: 10-31-90 (09:36)              Number: 149 of 157 (Echo)
   To: RAY DUNCAN                    Refer#: NONE
 From: CHARLES WILSON                  Read: 10-31-90 (17:34)
 Subj: URF386                        Status: PUBLIC MESSAGE
 Conf: FORTH (58)                 Read Type: GENERAL (+)

 Is it possible to run 386 UR/FORTH in Windows 3.0 386 Enhanced Mode?

 I know the the current version is not linked with the latest Phar Lap
 Extender conforming to the Microsoft protected mode scheme, but does
 their latest version allow running a protected mode program that way?

 Trying to figure out the best way to port an application over to
 Windows, (still can't decide whether to be windows specific or not), and
 want to use the 386 Enhanced Mode (allowing task context switching,
 etc).  The Micrdocumentation seems to fall short in some  areas
 pertaining to  non-windows applications.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530
 <<<>>>
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp

ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (11/08/90)

 Date: 10-31-90 (17:34)              Number: 150 of 157 (Echo)
   To: CHARLES WILSON                Refer#: 1814
 From: RAY DUNCAN                      Read: 11-01-90 (07:33)
 Subj: URF386                        Status: PUBLIC MESSAGE
 Conf: FORTH (58)                 Read Type: GENERAL (+)

 Not possible to run 386 UR/FORTH in Windows 3 enhanced mode.  This can't
 be done until we get a DPMI-compatible version of the Phar Lap DOS
 EXTENDER, and such a version will not be shipping for several more
 months at least.  The only people that I know of who are presently
 shipping a DPMI-compatible DOS Extender are Rational Systems (and that's
 a 286 extender, not a 386 extender).

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530
 <<<>>>
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp

ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (11/27/90)

 Date: 11-24-90 (09:56)              Number: 272 of 281 (Echo)
   To: RAY DUNCAN                    Refer#: NONE
 From: TOM BALDWIN                     Read: 11-24-90 (10:30)
 Subj: DSP FORTHS                    Status: PUBLIC MESSAGE
 Conf: FORTH (58)                 Read Type: GENERAL (+)

 I have heard a rumor that LMI has some sort of Forth support for a DSP
 chip. Is this true, and if so, what DSP is supported and what is the
 product called?

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530
 <<<>>>
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp

ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (11/27/90)

 Date: 11-24-90 (10:30)              Number: 274 of 281 (Echo)
   To: TOM BALDWIN                   Refer#: 2073
 From: RAY DUNCAN                      Read: NO
 Subj: DSP FORTHS                    Status: PUBLIC MESSAGE
 Conf: FORTH (58)                 Read Type: GENERAL (+)

 We do not support any of the DSP chips, sorry.  We support the TI 34010
 which is sometimes confused with the TI DSP chip that has a similar
 product number.  Forth systems for DSP chips do exist though; I know
 Forth Inc. sells one, and I've seen a Forth for the AT&T DSP chip
 advertised too.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530
 <<<>>>
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp

ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (12/06/90)

 Date: 12-01-90 (19:40)              Number: 344 of 359 (Echo)
   To: ALL                           Refer#: NONE
 From: MICHAEL HAM                     Read: (N/A)
 Subj: TIMER PROGRAM                 Status: PUBLIC MESSAGE
 Conf: FORTH (58)                 Read Type: GENERAL (+)

 The file TIMER.ZIP I just uploaded has a program TURNKEYed from UR/FORTH
 with the clone video driver, so it should work on most MS DOS machines.
 It is a timer for exercises like Yoga and stretching, where you have to
 hold a position for x seconds.  This allows you to set the x, counts
 repetitions, beeps every x seconds, with a special beep every 10 reps.
 I wrote it because I was going crazy counting seconds for my knee
 exercise I'm supposed to do.  Hope you enjoy it.  Pass it along.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530
 <<<>>>

 [When this file officially shows up in the library listings there
  will be another message and an opportunity for email access -dwp]
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp

ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (12/11/90)

 Date: 12-08-90 (13:30)              Number: 422 of 429 (Echo)
   To: JACK WOEHR                    Refer#: 416
 From: RAY DUNCAN                      Read: NO
 Subj: FORTH-83I96 ON THE WAY!       Status: PUBLIC MESSAGE
 Conf: FORTH (58)                 Read Type: GENERAL (+)

 I'd like to remind network readers that LMI has had a PC-based
 cross-compiler for the 8096/97/196 family available for several years.
 This cross-compiler generates a complete interactive Forth system to run
 on the 80x96 including an assembler in ROM.  The ROMbased system can
 also use the PC as a disk server.  Like Jax, I find the 80x96 to be a
 neat chip and a good host for a Forth virtual machine.  The architecture
 is, luckily, nothing like the Intel 80x86 series.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530
 <<<>>>
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp

ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (02/22/91)

 Date: 02-19-91 (14:15)              Number: 1250 of 1262 (Echo)
   To: RAY DUNCAN                    Refer#: NONE
 From: CHARLES WILSON                  Read: 02-19-91 (14:39)
 Subj: UR/FORTH ->WINDOWS?           Status: PUBLIC MESSAGE
 Conf: FORTH (58)                 Read Type: GENERAL (+)

 Any chance that a preliminary version of UR/FORTH for Windows 3.0 will
 be available in the near future?  Getting ready for the Mother of all
 software conversions, and was hoping to be able to use some familiar
 tools.  I am hooked on interactive development, and would hate to have
 to go back to compile, link, etc.

 I like the editor. I probably should start using ANSI.SYS, or some other
 terminal emulation mode.  Right now using st-240 with DEC terminal
 emulation set to VT-100.
 ---
  * Via ProDoor 3.1R

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530
 <<<>>>
-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp

ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (02/22/91)

Date: 02-19-91 (14:39)              Number: 1251 of 1262 (Echo)
  To: CHARLES WILSON                Refer#: 3229 From: RAY DUNCAN             
Read: NO Subj: UR/FORTH ->WINDOWS?           Status: PUBLIC MESSAGE Conf:
FORTH (58)                 Read Type: GENERAL (+)

We are working on the Windows version.  The user interface is coming along
nicely.  I am currently looking at the new Watcom tools to see if they will
help me get a 32-bit 386 version up under Windows 3.0 quicker than I can do it
on my own by the brute force method.

NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530 <<<>>>
-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp