ForthNet@willett.UUCP (ForthNet articles from GEnie) (02/22/90)
Date: 02-20-90 (02:39) Number: 1598 (Echo) To: ALL Refer#: NONE From: GENE LEFAVE Read: (N/A) Subj: X-WINDOWS Status: PUBLIC MESSAGE I was wondering what would be required to run an X-window terminal from a FORTH system. Does anyone have an idea as to where one could get the specs for the beast. . I would think that since most UNIX terminals are connected via ASCII serial lines that the X-window protocol must be serial, so that one could make a nice FORTH front end. . 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@gateway.sei.cmu.edu'
ForthNet@willett.UUCP (ForthNet articles from GEnie) (03/03/90)
Date: 03-02-90 (01:13) Number: 501 To: ALL Refer#: NONE From: SID KNOX Read: (N/A) Subj: DMA ON AT MACHINES Status: PUBLIC MESSAGE On an AT class machine I have successfully used DMA Ch1 on the first 8237 for I/O to a custom module. However, I am not able to make Ch5, Ch6, or Ch7 operate. Aside from the obvious differences of port addresses and edge connector pinout, what is different about using this second 8237 ? 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.pgh.pa.us (ForthNet articles from GEnie) (10/05/90)
Date: 09-22-90 (08:04) Number: 3818 (Echo)
To: ALL Refer#: NONE
From: STEVE PALINCSAR Read: (N/A)
Subj: Passing commands to DOS Status: PUBLIC MESSAGE
The following code (which I translated into Forth - specifically
HS/Forth - from QuickBasic code published in PC Magazine this Spring)
can be used to chain execution from one program to another by placing
a string into the PC's keyboard buffer. Limitation is that only 15
characters max can be put there. That means a complex lengthy command
would have to be invoked with a batch file.
\ Pass a command to the PC keyboard buffer. Can be used to pass
\ execcution of an EXE, COM orr BAT file. Unlike using SHELL, this
\ program will not stay in memory. Can be used for creating a front-end
\ menu program. For HS/Forth, but can be used with any Forth that has
\ C!L ( n segmentaddr offset -- ). DUPC@ is a coded-together DUP C@;
\ 2* is a 2 *
DECIMAL
: ADD_RETURN ( $addr -- $addr )
\ Add an ASCII 13 to the end of a counted string
DUPC@ 1++ OVER C!
13 OVER
DDUPC@ + C!
;
: PASS_COMMAND ( $addr -- )
\ Place a counted string into the PC's keyboard buffer
ADD_RETURN
30 0 1050 C!L \ Update the ead & ttail
DUPC@ 2* 30 + 0 1052 C!L \ keyboard buffer pointers
DUPC@ 1+ 1 DO \ Loop thru the string
DUP I + C@ \ and copy i:hinto the
0 1052 I 2* + C!L \ keyboard buffer
LOOP
DROP \ annd then discard the string
;
: TEST
IN$ ( Prompts for string, places it at PAD )
PASS_COMMAND ( Place the string in thhe keyboardd buffer )
BYE ( and return to DOS. )
;
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (12/28/90)
Date: 12-23-90 (09:29) Number: 676 of 682 To: ALL Refer#: NONE From: STEVE PALINCSAR Read: (N/A) Subj: SHELLING TO DOS Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) I'm familiar with shelling to DOS out of forth and running an external program -- it's quite simple with HS/Forth: DOS" shells right out to the DOS prompt, and ( $addr -- ) SHELL runs an external program whose name is at $addr. *BUT* when you do this, you load a copy of the command processor on top of the forth system. You lose at least 50-60K, maybe a whole l more. I keep reading about menuing systems that let you shell out while leaving only an 80-byte "tail" in memory so you can return to the calling program when the child finishes running. Does anybody have any idea exactly how this is done? Is it something that could be done with forth? PCRelay:DCINFO -> #16 MetroLink (tm) International Network 4.10 DC Info Exchange MetroLink International Hub <<<>>> ----- This message came from GEnie via willett. You cannot Reply to the author using email. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, whatever). Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (12/29/90)
Category 3, Topic 6
Message 28 Thu Dec 27, 1990
D.RUFFER [Dennis] at 23:22 EST
Re: STEVE PALINCSAR
> ...leaving only an 80-byte "tail" in memory...
Steve, when any DOS program comes up, all memory is assigned to it. When you
shell back to DOS, you have to tell DOS that it can have back some of that
memory to do its thing. You can tell it that it can have all memory back, but
your program will get written over when DOS loads in anything new (also by the
DOS memory pointers but they are too hard to explain :). So, what you have to
do is have your "tail" down in the lowest part of your memory and release
everything else when you shell out. This "tail" would do the memory release
and shell call. Then, before you can return, the "tail" must request the
memory back again (it may no longer be contiguious) and load back in the rest
of the system from disk (did I forget to mention that you were supposed to
save it first :).
I haven't actually done it, but I don't see much of a problem doing it in
Forth. You had better have access to Forth's nucleus, but you might even be
able to load it on top. It all depends on how much memory you want to be able
to recover. To do it in 80 bytes means that it's going to need to be all in
machine code anyway, so why not put it on the bottom.
Let us know how it comes out. DaR
-----
This message came from GEnie via willett. You cannot Reply to the author
using email. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, whatever).
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (01/02/91)
Date: 12-30-90 (13:02) Number: 733 of 744 (Echo) To: GARY SMITH Refer#: 716 From: RAY DUNCAN Read: NO Subj: USER INTERFACE Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) Mitch Bradley writes: >I do know that ... I used a version of LMI Forth >that did not compile from text files... In this you are certainly correct, and I guess I misunderstood some aspects of your original message. I did not notice that you were drawing a distinction between file-based Forth systems and Forth systems that could compile ordinary text files. All of our systems since the original Z-80 FORTH for CP/M 2.2 in 1980 have been file-based, and have included a complete set of words that allow an application to open, create, read, and write any arbitrary file in the host file system. However, for a very long time we did not support compilation of Forth source code from ordinary text files. The interpreter/compiler always assumed that source code took the form of BLOCKs stored in a simple random-access text file, 1024 bytes per record, and it always had a "current" block file which was the target of Forth commands such as BLOCK, FLUSH, and so on. The user could change the "current" block file with the USING command. The ability to compile Forth source code from conventional ASCII text files was not added to LMI systems until circa 1986 (might be a year earlier or later; I don't have version information handy). We use the command INCLUDE for this type of compilation (although I don't claim that we thought up the term INCLUDE). Our INCLUDE can compile from either block files or text files and supports nested compilation (the number of nesting levels is user configurable). I must say that although our systems have supported compilation from text files for some years, I still find myself using blocks in files 99% of the time. I like the flexibility and the "random-access" character of blocks, I like using my own full-screen block editor which I can modify at will instead of an external text editor, and I like the ability to put a simple BLOCK/BUFFER/UPDATE/SAVE-BUFFERS/ EMPTY-BUFFERS/FLUSH interface in a ROM'd target system and use the PC as a BLOCK server over a serial link. I'll be the first to admit that this is simply a matter of taste, and that if I invested the time to write a text file editor in Forth and make our text file compilation facilities more powerful (e.g. the ability to "mark" a piece of text within a file and then compile it selectively) I might find Forth code in text files a more friendly environment. Your point about the lack of standardization in Forth file interfaces is certainly well taken. Our original file access word set was not very well thought out, and we didn't arrive at our current stdio-type interface until about 1986 after we had done a couple of custom ports to UNIX systems and saw the need for a file interface that would map easily onto DOS, UNIX, OS/2, Macintosh, Atari ST, and whatever else. I guess this was about the same time frame as you started promoting this concept at FORML etc. but since I don't attend Forth hobbyist events I didn't become aware of your work immediately. (By this I do not mean to imply that you are only a Forth hobbyist, but only that the papers at FORML and similar events often show a shocking ignorance of what people are doing with Forth in commercial systems.) In another message, you mentioned that the Forth Vendors Group Floating Point Standard has not been heard of lately. This is true but I believe (or at least hope) that the word set defined in that document is still widely used. We use it, anyway. 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 email. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, whatever). Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (01/02/91)
Date: 12-29-90 (18:15) Number: 735 of 744
To: STEVE PALINCSAR Refer#: NONE
From: IAN WATTERS Read: NO
Subj: SHELLING TO DOS Status: PUBLIC MESSAGE
Conf: FORTH (58) Read Type: GENERAL (+)
SP] ^C TSR libraries, I presume? Thanks for the info.
Pass on C -- was that a mispelling? :-)
I know several Turbo Pascal TSR libraries which swap. The one in Object
Professional has been released separately ("TSR's Made Easy" or such)
for $50ish and has TP source code.
//\/\/
---
~ SLMR 1.05 #109 ~ It's noisy next door. A Dr Herbert West lives there...
PCRelay:OLEF -> #181 RelayNet (tm)
4.10a15 The Node is OLEF, HUB is HUBOLEF1 in the UK
<<<>>>
-----
This message came from GEnie via willett. You cannot Reply to the author
using email. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, whatever).
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpwmb@MITCH.ENG.SUN.COM (01/03/91)
This is a followup to some information provided by Ray Duncan; the quoted parts are his. My goal in this followup is further support my contention that a published standard for the Forth language as a whole (e.g. ANS Forth) is the ONLY effective way to achieve widespread standardization of any aspect of Forth, including extensions. (I am not aware that Ray necessarily disputes this contention; I am simply using his comments as a springboard for mine.) > we didn't arrive at our current stdio-type > interface until about 1986 after we had done a couple of custom ports > to UNIX systems and saw the need for a file interface that would map > easily onto DOS, UNIX, OS/2, Macintosh, Atari ST, and whatever else. > I guess this was about the same time frame as you started promoting > this concept at FORML etc. ... Actually, I started in 1983 (wordset and portable implementation of Forth "standard I/O", including code for 2 processors and 2 operating systems, published in FORML 83. The implementation supports both data access and compilation.) > since I don't attend Forth hobbyist > events I didn't become aware of your work immediately. > ... > the papers at FORML and similar events often show a shocking > ignorance of what people are doing with Forth in commercial > systems. I'm not so surprised that people are ignorant of what is happening in commercial systems, because a lot of that information is not published except as part of products. Few people can afford to purchase one copy of every commercial system. The thing that surprises me is that people don't do literature searches, so even when something is published, people don't know about it. So, for whatever reasons, many people remain unaware of what is going on in other parts of the Forth community. The only document that every implementor seems to read is the latest Forth language standard. > In another message, you mentioned that the Forth Vendors Group > Floating Point Standard has not been heard of lately. This is true > but I believe (or at least hope) that the word set defined in that > document is still widely used. We use it, anyway. Yes, I use it too. I was very glad when it was published, because I didn't want to invent yet another FP interface wordset. In mentioning the FVG Floating Point wordset, I was not trying to deprecate it in any way. Instead, I was using it as an example of an "informal" standard that was published, implemented, and widely used, yet it appeared to largely unknown among ForthNet participants (at least nobody had mentioned it). Thus, I stand firm in my contention that: "grass roots" "standardization" is ineffective in the Forth community as a whole. This is one of my primary justifications for my efforts toward adding extension wordsets to ANS Forth. Mitch Bradley, wmb@Eng.Sun.COM
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (01/03/91)
Date: 12-30-90 (09:29) Number: 745 of 747 To: DENNIS RUFFER Refer#: NONE From: STEVE PALINCSAR Read: NO Subj: USER INTERFACE Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) I'm afraid that it's going to be way, way beyond my meager abilities. I think I'm going to rely on the choice between regular SHELLing & chaining via stuffing characters into the keyboard buffer & quitting, relying on a command in a called batch file to start the system back up again. But thanks for your thoughtful reply. --- ~ MetroLink: Data Bit NETWork * Alexandria, VA * (703) 719-9648 PCRelay:DCINFO -> #16 MetroLink (tm) International Network 4.10 DC Info Exchange MetroLink International Hub <<<>>> ----- This message came from GEnie via willett. You cannot Reply to the author using email. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, whatever). Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp