FORTH.THD --- Copyright 1988 by Phil Wheeler An original compilation of Compuserve Model 100 Forum messages for use by Forum members only. These messages are a dialog on Forth for the Model 100 -- features, status, capabilities, etc. Will there be a ROM version of Forth for the Model 100? Watch this space! <> Message range: 176816 to 176219 Dates: 11/13/88 to 11/30/88 Sb: #new model 100 Forth Fm: SCOTT T. SCHAD 73720,1166 To: Bill Brandon Bill Boyd has just uploaded a new FIGForth to DL8 which is text-file-based instead of screen-based. You use the normal TEXT editor to create source code, then " FILENAME" LOADF while in the Forth environment to compile it. Works like a charm and happily coexists with my Booster Pac. I can load files to or from the Pac or the workspace, and haven't run into any conflicts. We're getting closer to that F-83 rom all the time! I've put both David Rowell and Bill Boyd in touch with Mo Budlong, the man behine the new "C" compiler for the model 100, because Mo is interested in putting a nice controller language in rom for the model 100. Something good is boud to result from all this for us Forthers. If you don't want to hassle with downloading Boyd's hex file and then converting it, let me know and I'll email you the binary .CO version. Fm: Bill Brandon [DPTRAIN] 76701,256 To: SCOTT T. SCHAD 73720,1166 Thanks for the quick "review", Scott! I saw the notice early this morning (like about 10 after midnight), but the system hadn't merged the new file yet. Needless to say, I am even now on my way to pick up same. Hex file is no problem; I do all my downloading to a Model 4 at 1200 baud with XMODEM, then transfer over to the 100 via serial port. Were you aware that SOTA has released its version of figFORTH as Shareware? I also saw MVSFORTH on a local bbs the other night. If you would like to try the latter out (former only runs on Mod 4's) on your PC without a long distance call, let me know. I can download to the 4 and convert to a PC file with Supercross, then mail the disk to you. Looks like the word is spreading once again! Fm: SCOTT T. SCHAD 73720,1166 To: Bill Brandon [DPTRAIN] 76701,256 MVSForth? For the model 100? I don't mind the long distance call, if you can tell me how to find the bbs and if they will let me on to download the first call. Fm: Bill Brandon [DPTRAIN] 76701,256 To: SCOTT T. SCHAD 73720,1166 I must have said that incorrectly, Scott - it was MVSForth for the IBM PC. I agree - that would be a pretty good critter to have running on the 100! Fm: SCOTT T. SCHAD 73720,1166 To: Bill Brandon [DPTRAIN] 76701,256 You can't blame me for getting excited. I've got Mo Budlong and Bill Boyd at least talking about romming F-83 for the model 100...so the near future could bring glad tidings for us Forth language fans. Wouldn't it be great to have an F-83 standard implementation in rom, with lots of extras, so one could design M100 code that would run unchanged on a desktop as well? Fm: SCOTT T. SCHAD 73720,1166 To: Bill Brandon [DPTRAIN] 76701,256 While I'm thinking about it, I've got a couple of PD Forths for MS-DOS. One is the Laxen/Perry F-83 standard (of course), but the other is the "Uniforth" sampler. It is a subset of the full Uniforth package, but it still has lots more than vanilla F-83, including transcendental math functions, etc. I tried to buy the full copy but Uniforth seems to have gone out of business. Uniforth also lets you FLOAD a text file of code. Want a copy? Fm: Bill Brandon [DPTRAIN] 76701,256 To: SCOTT T. SCHAD 73720,1166 Exciting? Absolutely! I guess, though, that any "standard" implementation would need to be one of the existing dialects (MVSForth, or perhaps PolyForth - short words save RAM and screen space), done by one publisher. Otherwise we'll be stuck with a pair of incompatible linguistic cousins. Fm: Bill Brandon [DPTRAIN] 76701,256 To: SCOTT T. SCHAD 73720,1166 Thanks for the offer, Scott, but I'm one of those non-conforming folks. I don't own a PC/MS-DOS machine; places I contract with generally do, but for my personal use, I prefer the trusty Model 4. You have to do a little searching, but every application available for IBM/Apple systems is available for the old TRS80's. With memory expansion and a speedup board, they can surprise a lot of people. Having said all that, I wonder who holds the current rights to Uniforth? If it's a good package, perhaps it would be worth looking at as a basis for ROM? Fm: SCOTT T. SCHAD 73720,1166 To: Bill Brandon [DPTRAIN] 76701,256 I just got David Rowell's Forth disc in the mail today, and it is chock full of goodies. But I find Bill Boyd's Forth simpler to use because I favor text files for my source code over blocks. What Boyd needs to do (or what I should do) is include some more words for entering the editor directly from Forth, as in: " filename" edit. Then you wouldn't lose the current dictionary, could take advantage of the model 100's superb editor, and could edit on the fly/forget the word/reload as you do with blocks. I think we're on to something here. Could be a solid filebased Forth could be on the market soon. Fm: SCOTT T. SCHAD 73720,1166 To: Bill Brandon [DPTRAIN] 76701,256 Probably would be overkill. Uniforth does list a CP/M version in the hype, but it would be better to start over with the idea of optimizing the compiler to the model 100, instead of a retrofit kludge. Come to think of it, that term might apply to most all FIG-forth implementations... I too confess to not using an MS-DOS computer at home. Most of my day at work is spent in front of a 386 clone, and I don't need more at home than my model 100. Fm: Bill Brandon [DPTRAIN] 76701,256 To: SCOTT T. SCHAD 73720,1166 I've been sort of occupied with wrapping up a client's project this week, and so haven't been able to try out Boyd's Forth - should be able to do some fooling around with it this weekend. It sounds as if the editor in it differs from the usual Forth arrangement. Hmmm. Fm: Bill Brandon [DPTRAIN] 76701,256 To: SCOTT T. SCHAD 73720,1166 Actually, what I was thinking about was the linguistic structure of the language, rather than the way the compiler itself works. For example, MUMPS (a database language) runs on many, many machines, micro, mini, and mainframe, but is absolutely the same "language" on all of them. I have a friend who writes MUMPS programs on an ancient S-100 computer, and then ports them over to IBMs, DECs, etc. Most FORTHs, on the other hand, even the ones which are ostensibly "F83" standard, seem to be different in every implementation - they share the required word sets, but then add "optimized" words which are difficult to duplicate on other machines. Fm: SCOTT T. SCHAD 73720,1166 To: Bill Brandon [DPTRAIN] 76701,256 He uses standard text files. I much prefer that, and as we speak, I'm encouraging him to make it even more convenient. By typing " filename" EDIT, for example, one might go directly into a source file with the native editor, then return to Forth. And Boyd thinks he may be able to use his " filename" LOADF statement within other files--in effect giving you the same utility as the LOAD command within standard blocks. It's about time Forth moved away from its wimpy block editor, and the model 100 editor is simple and intuitive enough that it could be a good model to standardize on for other Forths. At the very least, Forth on the model 100 is evolving into a heckuva lot of fun! Fm: SCOTT T. SCHAD 73720,1166 To: Bill Brandon [DPTRAIN] 76701,256 But it is in the nature of Forth to customize. One can get carried away, of course, like the 20-bit implementation in HP's Forth rom for the 71B. What else would one expect for a "nibble-based" 4-bit processor, than 20-bit integers? Logical, if hard to learn. Talk about playing havoc with existing Forth programs! I use LMI's Z80 Forth on my HP 86 CP/M machine at home, and can directly port the source code to the LMI PC/Forth running on the MS-DOS machine at work. Of course their is more in PC/Forth (graphics, for example). At least I'll say Forth remains truer to its syntax across machines than does BASIC. There are so many dialects of BASIC that you might as well start from scratch trying to port programs from one computer to another. I gave up trying to move my old HP-BASIC programs to other machines, because I used ON KEY GOSUB branches where other BASICs only provided ON KEY GOTOs...if they provided such statements at all. HP concatenates statements with @, Microsoft BASIC with a ":". True Basic doesn't allow concatenation at all, and even forces you to type "LET" before any equivalence (i.e.- LET A=B). Forth at least plays by the same rules on most machines. My reason for preferring the F-83 syntax for a model 100 Forth (should I prevail in persuading Mr. Boyd to implement it), is that several major changes took place in the F-83 revision. Floored division was affected, along with things as simple as the number returned for a "true" flag. And I believe that a model 100 Forth will only be commercially viable if it adheres to the currently reigning standard. The point is: of course no one will be using Forth on the model 100 for major software applications: the model 100 market is too dog-eat-dog for applications programs. But it could be the ideal controller, and the ideal companion for Forth programmers who need to work while away from their desktops and still maintain a margin of compatibility with their desktop Forths. The model 100 with Forth in rom would also be the ideal Forth teaching/learning tool...especially with a simple-to-understand text-file-based editor. Fm: SCOTT T. SCHAD 73720,1166 To: Bill Brandon Bill Boyd has been busy. If you want to see a very elegant bit of coding, check out his ETCH4.DO file in DL8. This little sketch program demonstrates just how powerful (and Fast) Forth can be on the model 100. Maybe he should write the 4th article for Port. 100 instead of me (maybe he'd have better luck getting paid...) Since Bill has been soliciting ideas for a "wish list" to see in his model 100 Forth, I have a suggestion. My HP-71B calculator had HP's F-83 rom for a while. It took advantage of the host BASIC interpreter in the calculator, and defined a ton of nifty floating point and transcendental math and statistics functions that basically were just rom calls to the various BASIC routines. One could even pass an algebraic expression from Forth to BASIC as a string, and retrieve the result back into Forth. If Bill could adopt a similar strategy with the Model 100, he could instantly have a powerful set of math and floating point words at Forth's command. Let's hear what your wish list might contain too, since this is the all -important design phase. Fm: Bill Brandon [DPTRAIN] 76701,256 To: SCOTT T. SCHAD 73720,1166 Well, my wish list would involve string-handling capabilities. What you could use in math and fp words (since you're the scientist in this group), I could use in TEXT applications. Specifically, as a writer who has to format output to suit lots of different clients (everybody has their own idea of what a lesson plan and course materials should look like!), I need a set of words which would support the following phases of course development: Task analysis, training progression design, and production of various materials. The whole thing would bear functional similarities to a data base and to a word processor. (Sounds like I need to think this through a little more!) If I could stash formatted string output in RAM or on the TDD and then bring it back in to paste into a document, that would be very useful. Add the capability to do same via RS-232 (to the Model 4), modem (to CIS, for FAX to clients), and to cassette (why not? would allow emulation of two drives, albeit sloooow), I'd be a happy camper. Will think about it some more, and get back to you. Enjoy your turkey and cranberries, Scott! (By the way, you been deer hunting yet? Our deer here are pathetic this year - will have to buy -bleah- venison for Christmas in all probability.) Fm: Bill Brandon [DPTRAIN] 76701,256 To: SYSOP I have just uploaded TIP005.4TH to Library 8. It contains some words for use with Bill Boyd's RAM4TH - makes it possible to VLIST the dictionary to the printer, for example. Fm: Bill Brandon [DPTRAIN] 76701,256 To: SCOTT T. SCHAD 73720,1166 Scott, I have just uploaded a TIP file to Lib 8. It contains a half-dozen words which resulted from my obsessive needs for clean screens and printed output. One of the words, for example, will give you a printed dictionary listing (to save your eyes from the perils of trying to read the result of VLIST as it rips across the LCD). Noticed that there is a TIP file already in Lib 8 which contains words to implement floating point in the Chipmunk-based implementation of figFORTH for the 100. Have you looked at it as a possible fix for your need for f.p.? Fm: Bill Brandon [DPTRAIN] 76701,256 To: SCOTT T. SCHAD 73720,1166 Thot about the design wish-list some more after dinner yesterday. I would like to be able to select between running the 100 in its own native mode, calling RAM4TH from the menu and using text files as we can do now, and running the 100 as a native FORTH system. In the latter case, I would like to be able to have the use, from a menu like the native 100 system, of TEXT, TELCOM, NOTE, and ADRS. (Perhaps these could be enhanced, to include the functions everyone wishes the 100 ROM had built into it, such as margins and page length in TEXT, and a more complete Data Base system.) Since my other interest in FORTH on the 100 has to do with Artificial Intelligence applications, the ability to access files on disk is critical. I looked up an AI program written in FORTH which appeared in a book a couple of years ago; it emulates LISP and PROLOG functions to provide a simple expert system. The code would probably take 10K as a RAM4TH-style text file, which probably means it could not be run on the 100 if the source had to be resident in RAM. There wouldn't be enough room left for the dictionary and the stack. A solution would be to have a LOADF command which could have the syntax " :filename " LOADF, so PowrDOS (or whatever DOS) could bring the file in a la Powr-Text for FORTH to compile. (Sorry if that isn't crystal clear - I OD'd on cranberries and BBQ'd turkey yesterday, so the Muse has her work cut out for her in getting me to communicate.) To make a long story endless, if a very simple expert system (too simple for what I ultimately have in mind) won't work as a RAM-based entity, disk access from the proposed F83 chip would be essential. I agree that text files are easier to work with than the 1K screen arrangement usual with FORTH, at least where the 100 is concerned. My remaining reservation about text files has to do with the effect on portability: most FORTHs seem to have stayed with screens, rather than files. Fm: SCOTT T. SCHAD 73720,1166 To: Bill Brandon [DPTRAIN] 76701,256 There's a FP file for the chipmunk 4th eh? I'll check it out, and your "tips" file as well. Fm: SCOTT T. SCHAD 73720,1166 To: Bill Brandon [DPTRAIN] 76701,256 True, true, and true. But text files are a snap if you've got lots of ram. And much easier to move around. My thoughts on text files in ram versus screen (excuse me, "block") filing is that you may not want to tie up your serial port with the TPDD. Perhaps the best solution is to do what most commercial MS-DOS Forth's have done, and provide both means of storage. But I totally agree that a Forth not running under the native O/S and in total control of the machine could make the model 100 a thing to behold. I've got a perfect parallel on my old HP86 system. I have an old FIG-Forth implementation which takes over the machine and provides access to all kinds of things, then I've got the official F-83 LMI Z-80 Forth which runs under CP/M. I can plug the CP/M coprocessor in the back of the CPU and boot up CP/M, then boot up Forth, and lose both the direct access and mass storage speed I had with the older FIG version. I could swap screens around on ramdisc with FIG, but am limited to screens taken as 1-k chunks from CP/M text files with LMI's F-83. Both have their place, but a custom program would be cleaner and easier to use under the old Forth. I can see you are thinking much more ambitiously than I am. Dave Rowell's disc-based Forth is also a candidate for Mo Budlong's postulated rom, and progress may be made their shortly as well. Cross your fingers (and hope the developers are taking heed of our suggestions). Fm: Bill Boyd 75715,70 To: SCOTT T. SCHAD 73720,1166 I wrote ETCH4.DO purely because I was frustrated with graphics from BASIC being so slowww and graphics from machine language being rather involved. Basically, ETCH4.DO shows off BPLOT, which is a word implemented in machine language to do the real work. I think BPLOT provides a nice foundation for serious graphics work on the 100. Fm: Bill Boyd 75715,70 To: Bill Brandon 76701,256 I have a couple of tips about TIP005.4TH: In TO.LPT, and TO.LCD, I don't think 4227 CALLX is necessary or accomplishes anything. I like to start my files with BASE @ and end them with BASE ! if I change the base, so that the user returns to the base he started with. While running RAM4TH, try pressing CTRL-P, then typing VLIST. That should send output to both the screen and printer. Can't actually say I've tried it, though. (My printer is connected to my PC!) Another CTRL-P should toggle echo mode back off. Fm: Bill Brandon [DPTRAIN] 76701,256 To: Bill Boyd 75715,70 4227 CALLX calls RST4. If you don't use it, you don't get any printed output. If you have Oppedahl's book on the 100, he explains it better than I can. Just setting the byte at F675 don't cut it - in fact, my machine taught me that, by cold-starting twice to protest my rudeness in NOT calling RST4. I like the business about BASE @ and BASE ! - I'm real new to FORTH, so haven't gottenotally acclimated to the information-hiding techniques you pros use. I will try the CTRL-P thing; the purpose of VLISTP was more to illustrate how to use TO.LPT and TO.LCD, though it did solve my problem of not being able to read fast enough to keep up with the scroll rate! Thinking a bit more about the disk access business. It would probably be better to build words in FORTH to handle those functions, than to rely on always having some other DOS loaded. Once a FORTH ROM appears (yours, Scott's, Mo Budlong's, or - if necessary - mine), I intend to eschew "native 100" and BASIC forever. My biggest problem now is lack of time to do the job quickly. Working as an independent training developer and raising two sports-minded adolescents does not leave much time for other pleasures. Fm: Bill Brandon [DPTRAIN] 76701,256 To: SYSOP I have entered an updated version of TIP005.4TH to Library 8. This incorporates ideas suggested byregarding the use of BASE @ and BASE ! to restore the user's base to what it had been. Also extended the comments to help those newer to FORTH than I am. Fm: Bill Brandon [DPTRAIN] 76701,256 To: Bill Boyd 75715,70 I tried the CTRL-P, and it works. However, it is very slow - gives you one screen line, loads next line into buffer, prints line, etc. The TO.LPT word is much faster and does not pause at the end of each line. Also ththod gives you an extra line feed between lines, which TO.LPT does not. I have uploaded a revision to TIP005.4TH which incorporates your suggestions regarding BASE. Much cleaner! Speaking of clean - as soon as I figure out how GETLINE works, I'm going to upload a set of words which will remove the comment lines from a text file. You gotta have 'em to document what you did, but you don't need the historical notes in the file you keep in the computer. Cleaning out the comments by hand takes too long, so whyhave FORTH clean it up for you? Shorter files also load faster.