COMPL2.THD --- Copyright 1988 by Phil Wheeler An original compilation of Compuserve Model 100 Forum messages for use by Forum members only. A few compilers exist for the Model 100/102 -- very few! These messages discusses the Basic compiler available here and some other options. the final part of this thread file deals with Forth for the Model 100, including the Chipmunk-supporting Forth available in the Forums Data Libraries. Message range: 172925 to 173257 Dates: 8/15/88 to 8/21/88 Sb: #COMPILER FOR 102 Fm: ROBERT SCARBORO 72627,1721 To: SYSOP I NEED A BASIC COMPILER FOR THE TANDY 102, IS THERE ONE AVAILABLE ANYWHERE? Fm: Tony Anderson 76703,4062 To: ROBERT SCARBORO 72627,1721 Not a fully featured one. The one we have here in Library 8, TCOMP, is a "tiny compiler" which operates on a subset of BASIC statements. It works fine, but doesn't have any string manipulation capability. There is no other known compiler that will work IN the Model 100. But there are cross-compilers that work in a PC, yielding a program that will run in the Model 100 family. Unfortunately, they are expensive, being sold commercially as "Development Systems". But I believe there is also one that is either sahreware or public domain... see the file TASM.USE in Lib 8 for some leads. Fm: Mo Budlong 76167,3310 To: ROBERT SCARBORO 72627,1721 Robert, I have two BASIC compilers for the M100. One is finished and being tested and the other is in development. In developing the compilers, I keep bouncing off of three major issues, and I would dearly love some user input on what is important. The primary problem is constantly a trade-off between size and speed, the third factor is ROMability. For example, the compiler that is finished allows BASIC programs to be ROMed or compiled to CO programs. It's primary goal was to make programs ROMable. As such it really produces semi-interpreted code. Partially compiled, partially interpreted. The result is about the same size as the original BASIC program but you only gain a very small speed advantage. The real compiler produces genuine assembly language translations of the BASIC code and runs like lightning compared to BASIC, but the final .CO file is larger than the original BASIC by 20-30%. This situation in compiler design is not a problem in larger machines. A program compiled in MS QuickBasic is as much as 3 times larger than the original GWBASIC source code file but of course no one cares on a PC. On the M100 I am constantly bouncing off this problem and would love to hear from anyone on the subject. Do you want a speed improvement, or a size improvement? I have struggled to provide both, and it doesn't seem possible. Mo. Fm: Bill Brandon [DPTRAIN] 76701,256 To: Mo Budlong 76167,3310 Speaking for myself, Mo, the size improvement would be more useful. I use the 100 in situations in the field where speed is less important than the practical problems imposed by limited memory. Perhaps I would feel differently if I used a memory enhancer like the BP, with a meg of RAM, or a bubble memory unit with 10 megs. To date, I have chosen not to upgrade my 100 that way; I have desktops at home and at work where the bulk of my work is done, and the 100 is used more as a vademecum. Again, I might feel differently if it were my only machine. What do you bet you get equal responses for size and speed? Depends on one's philosophy about laptops, I bet! Fm: Mo Budlong 76167,3310 To: Bill Brandon [DPTRAIN] 76701,256 Bill, Thanks for the response re the BASIC Compiler. You're probably right about the 50-50 split. That's about what I've had so far on the people I have asked. Interestingly enough, commercial developers who intend to use this system are primarily interested disguising their source code so that they don't have to give everything away when they sell a package. Fortunately both of the Model 100 BASIC compilers provide that, but the first time a developer said that it through me. "I don't care if it's bigger or faster, I just want to keep my design protected". I had been gnawing fingernails over the size versus speed issue and suddenly someone asked for something that I could provide either way. What a relief! Any way your response is duly noted and logged, and I appreciate it. It, along with any other responses will affect the design of the second compiler. Mo. Fm: SCOTT T. SCHAD 73720,1166 To: Bill Brandon [DPTRAIN] 76701,256 I've used most of the large-ram expansions for my 102, and I'll add that what ultimately limits a model 100 is the speed of its processor, not ram. The Booster Pac I presently have contains 256K of ram, but only lets you manipulate up to 30K files. Having done a bit of work with 30K files recently, I find thescreen jump and scroll response get quite lethargic toward the end of the files. I can imagine how grim it gets if working on a 100K file (which the Gold card system might make possible). But most of my needs are adequately served by 30K or less, and having all my programs handy without needing a disc drive is worth the extra bulk. One fine solution I resorted to for a while was to take a Psion Organiser calculator and burn all my M102 programs into a Psion eprom chip (which the calculator can do all by itself). Then all I needed to Rdo to get a program into the 102 was hook the Psion to it with a null modem cable and shoot the file across at 9600 baud. If a basic program, you can even load it directly into basic (no intermediate TEXT conversion required) by typing LOAD "COM:88N1E" while in BASIC before sending the file. BTW--did you ever talk to Tim? Fm: Bill Brandon [DPTRAIN] 76701,256 To: SCOTT T. SCHAD 73720,1166 Hello again, Scott! That's a pretty novel solution you came up with, using the Psion. The speed of the 100 (or lack of speed, to be more exact) really IS a drawback if you are trying to do much recall and manipulation of information. It was one of the main reasons I modified my philosophy of laptopping. My only remaining "wanna" is to get a Forth system custom-built for the 100, maybe burning it into a prom, and then convert my most-used programs to that language. That's the only way (I believe) to have a practical, fast, and reasonably compact solution to somewhat larger scale business computing needs within the constraints of the 100's architecture. But I haven't the time these days to do much on the project. Yes, I talked to Tim shortly after we exchanged notes last. He says the beard is trimmed, and he is doing his doggondest to avoid taking any business away from the yard-care entrepreneurs! Fm: SCOTT T. SCHAD 73720,1166 To: Bill Brandon [DPTRAIN] 76701,256 Good for him! Glad to hear Tim is still doing well. As to your desire for a Forth rom for the 100, move over. I've wanted to do something like that for years. If I had to pick a favorite language, Forth would be it... although I've nowhere near mastered it. In a way, the programming language in the Psion is quite Forth-like. You define a "word" or program in a completely structured way and can call other program names from it, even to passing them global or local parameters. I'd be quite happy to see the Psion's OPL language on the M100 too, but Forth is a better possibility. Have you experimented with the Forth available in the Forum DL's? Fm: Bill Brandon [DPTRAIN] 76701,256 To: SCOTT T. SCHAD 73720,1166 I've fooled around a bit with the Forum Forth, found it interesting but not very useful at this point. The first version uploaded here four years or so ago, was a direct and complete transfer of the fig-Forth for the 8080. Thus, it wastes a lot of space on code for disk access which is useless to a Model 100. The second version didn't really correct this, though there are hints as to how it could be done. I that a Model 100 Forth should be written to allow use of either model TDD or a tape recorder as a mass storage device. (Another version might be required for use with a memory extension or Chippy, but I don't have either of them, so they aren't real high on my priority wish list.) It should also have a set of words built in to make use of the modem, BCR, and alternate ROMs/System bus easily managed. This could be a very long term project, given my (nearly non-existent) skills in assembly language, and my current 60-70 hour weeks sweating out a contract training development job. With luck, the 100 will still be around and supported by the time I get done! However, if successful and ROM-able, this project could lead to an exceedingly useful portable system, capable of doing things which the MS-DOS lappers may never approach. I am thinking specifically of applications in device control, data collection, and yes, even analyzing well logs real-time and on-line in the field. Why not give Tim a call? I'm sure he'd enjoy hearing from you directly, rather than second-hand through me! Fm: Denny Thomas 76701,40 To: Bill Brandon [DPTRAIN] 76701,256 A point of clarification: The first implementation of Forth uploaded here has code for disk access, but that code was modified for the Chipmunk. It works very well with the Chipmunk. (FORTH.4TH, Lib 8) It's rather interesting in that you can have Forth screens saved to disk in the first part of the disk, and use the rest of the disk for normal Chipmunk operation. The two operating systems don't see each other, but do live together well. Fm: Bill Brandon [DPTRAIN] 76701,256 To: Denny Thomas 76701,40 I was trying to be concise in my remarks, so of course didn't include all the history of the implementation. You've filled in the gap nicely! I had actually considered buying a Chippy for a while, just for the Forth, but better sense (my wife's) prevailed. So what I'm aiming at now, in my bumbling fashion, is an implementation which can run off of the PDD1. Should work, since early Forth used cassette tapes for mass storage - and if #that# was an OK solution, so should the PDD1 be. I hadn't meant to demean the implementation, and it's still true that what the author did was to just take the entire 8080 fig-Forth and port it over. The code doesn't take advantage of any of the 100's features and ROM, as far as I can tell. My impression is that the thing could be somewhat more elegant, leaner, and meaner. Fm: Denny Thomas 76701,40 To: Bill Brandon [DPTRAIN] 76701,256 Actually, I'd guess that both implementations have been ported without changes. (they're both so huge) Since the first one already has code for disk (the only commented sections) it might be easier to convert to TDD. As it is, the second implementation is just too large to allow any DOS (like POWR-DOS) to live with it and still have enough room for a significant number of screens. Other developments lately should make it less painful to develop this system, like DTEXT (POWR-DOS) which will allow disk-based editing of the large source; ADSM, a fast, disk-based assembler; etc. Now, do you have a completion date planned? (grin) Fm: Bill Brandon [DPTRAIN] 76701,256 To: Denny Thomas 76701,40 Denny, when I get a completion date figgered out, you'll be the first to know! Actually, I was going to "cheat" and do all the source editing on my trusty Model 4. There has got to be a way to build the thing so that an 8K implementation doesn't eat up ALL of the RAM, which is what the present ones do. Fm: SCOTT T. SCHAD 73720,1166 To: Bill Brandon [DPTRAIN] 76701,256 That's interesting about the history of the Forum Forth. Maybe I can hone some assembler skills and try the job myself, also schedule permitting. And I may give Tim a call to see how the old boy is faring.