authorplaceholder@gorgo.UUCP.UUCP (05/10/87)
Larry Harmon writes: > One of the minor complaints I have with OS9 level II is the >lack of a full screen editor. I purchased a copy of tsedit and tsword >for OS9 level I, but they don't seem to work with level II. Perhaps it >is because I have configured my system to use the window driver rather >than the vdu driver. I don't know. Even if tsedit can be made to work >under (over?) level II , would it take advantage of the 80 column video >hardware of the CoCo 3? How about tsword? I think tsword is one of the >easiest to use nroff type formatters ever written and I would love to see a >new improved version for use with level II OS9. Does Tandy have any plans >for releasing new versions of these programs? How about the original >author? Are there any other vi type editors available for level II? I believe that you are wrongly critical. OS9 Level II is a different operating system from OS9 Level I. It is only by lucky coincedence that Level I binaries run under Level II. More often than not level I binaries make assumptions that the entire address-space of the machine is available, when with hardware memory management, it is not. I believe that this is the fundamental problem with programs like tsedit and tsword. There is a variety of public-domain programs of this kind available from the OS-9 users group. I am rather fond of uEmacs which will compile and run quite nicely under Level II. Steve Blasingame (Oklahoma City) ihnp4!gorgo!bsteve
jimomura@lsuc.UUCP (05/17/87)
In article <58400005@gorgo.UUCP> bsteve@gorgo.UUCP writes: > >Larry Harmon writes: > >> One of the minor complaints I have with OS9 level II is the >>lack of a full screen editor. I purchased a copy of tsedit and tsword >>for OS9 level I, but they don't seem to work with level II. Perhaps it >>is because I have configured my system to use the window driver rather >>than the vdu driver. I don't know. Even if tsedit can be made to work >>under (over?) level II , would it take advantage of the 80 column video >>hardware of the CoCo 3? How about tsword? I think tsword is one of the >>easiest to use nroff type formatters ever written and I would love to see a >>new improved version for use with level II OS9. Does Tandy have any plans >>for releasing new versions of these programs? How about the original >>author? Are there any other vi type editors available for level II? > >I believe that you are wrongly critical. OS9 Level II is a different operating >system from OS9 Level I. It is only by lucky coincedence that Level I binaries >run under Level II. More often than not level I binaries make assumptions >that the entire address-space of the machine is available, when with hardware >memory management, it is not. I believe that this is the fundamental problem Whaaaaat? Where the heck did you get a silly set of ideas like this? The point of OS-9 is that the majority of code properly written following the OS-9 conventions are directly usable under both OS-9 Level I or Level II. This is possible because addressing within the program is all relative and addressing of data is all base register relative. Level II presumes a hardware Dynamic Address Translation which maps the final address to hardware address beyond the 64K limit of the 6809 processor. Under *neither* system would you assume that the entire 64K of addressing is available to the program space. Further, you can assume that you'll have more dataspace in a Level II system because the program space will not be conflicting with the dataspace. Practically speaking you can also assume greater program space as well for the same reason. Furthermore, system calls were maintained between Level I and Level II unless there was an absolute necessity for differences. You have added DAT related system calls under Level II, and some programs which report system status and thus may require the ability to look beyond the current processes address space need to be re-written to use these facilities. It's certainly no accident or matter of luck that code is portable between Level I and Level II. >with programs like tsedit and tsword. There is a variety of public-domain >programs of this kind available from the OS-9 users group. I am rather fond >of uEmacs which will compile and run quite nicely under Level II. Steve, it seems to me that you probably know better than what you seem to have said in this posting. I have a feeling you just said what you meant a bit vaguely. Don't consider my comments a "flame". They are not intended to be. I'm just confused by what you've said and I think people less knowledgable might find it even more confusing. As a point of interest, does anybody know what version of MicrEMACS the Users' Group has in their library? Is it still the Conway/Lawrence/Santy/ Larson port or is it the new MicroGNU, or something else entirely? Has anybody tried the MicroGNU on a 6809 machine yet? Cheers! -- Jim O. -- Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 ihnp4!utzoo!lsuc!jimomura Byte Information eXchange: jimomura
blarson@castor.usc.edu (Bob Larson) (05/18/87)
In article <1799@lsuc.UUCP> jimomura@lsuc.UUCP (Jim Omura) writes: > Whaaaaat? Where the heck did you get a silly set of ideas like >this? The point of OS-9 is that the majority of code properly written >following the OS-9 conventions are directly usable under both OS-9 >Level I or Level II. This is possible because addressing within the >program is all relative and addressing of data is all base register >relative. Level II presumes a hardware Dynamic Address Translation >which maps the final address to hardware address beyond the 64K limit >of the 6809 processor. Under *neither* system would you assume that >the entire 64K of addressing is available to the program space. Further, >you can assume that you'll have more dataspace in a Level II system >because the program space will not be conflicting with the dataspace. >Practically speaking you can also assume greater program space as well >for the same reason. Correction: os9 does not use separate address spaces for program and data. Under the best conditions, an Os9/6809 Level II program will have 64k total for both program and data. (Each will be rounded up to your memory alocation size (coco III 8kbyte, others 2 or 4 kB)) > As a point of interest, does anybody know what version of MicrEMACS >the Users' Group has in their library? Is it still the Conway/Lawrence/Santy/ >Larson port or is it the new MicroGNU, or something else entirely? As far as I know it is. I do plan on sending mg 1b in, but it won't replace the 6809 portion of the old microemacs. >Has anybody tried the MicroGNU on a 6809 machine yet? I assume you mean MicroGnuEmacs (mg). (GNU is an operating system, not an editor) Porting to a 64k machine would involve stripping out a lot of features. My preliminary work on mg 2 is making in better, smaller, frequently faster, and with more things conditionally compilable, but there are limits. I'm not going to spend time figuring out how to rip the guts out of mg, besides after you rip out most features it might be hard to tell microemacs versions apart. It might be better to start with something that doesn't require the whole file to be in memory for a 6809 editor. I should get around to ordiering my QT20x, 1/2 megabyte on my QT+ just isn't enough for a good editing session. -- Bob Larson Arpa: Blarson@Usc-Ecl.Arpa Uucp: (several backbone sites)!sdcrdcf!usc-oberon!castor.usc.edu!blarson seismo!cit-vax!usc-oberon!castor.usc.edu!blarson
jimomura@lsuc.UUCP (05/18/87)
Bob Larson suggested that we look at editors which aren't bound
by memory size for 6809 editors. Along that line, has anybody used ELLE?
I've got a part of it, but haven't heard much about it lately. If there's
a site close to Toronto with it, I might try to arrange for a copy.
About the memory limit: Thanks for the correction. My mind is slipping.
I started thinking about remote addressing on the 68K side, which is a
totally different issue. I gotta get more sleep. :-)
Cheers! -- Jim O.
--
Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880
ihnp4!utzoo!lsuc!jimomura
Byte Information eXchange: jimomuraauthorplaceholder@gorgo.UUCP.UUCP (05/18/87)
Jim Omura replies : > >>In article <58400005@gorgo.UUCP> bsteve@gorgo.UUCP writes: >> >>Larry Harmon writes: >> >>> One of the minor complaints I have with OS9 level II is the >>>lack of a full screen editor. I purchased a copy of tsedit and tsword >>>for OS9 level I, but they don't seem to work with level II. >>... >>I believe that you are wrongly critical. OS9 Level II is a different operating >>system from OS9 Level I. It is only by lucky coincedence that Level I binaries >>run under Level II. More often than not level I binaries make assumptions >>that the entire address-space of the machine is available, when with hardware >>memory management, it is not. I believe that this is the fundamental problem > > Whaaaaat? Where the heck did you get a silly set of ideas like >this? The point of OS-9 is that the majority of code properly written >following the OS-9 conventions are directly usable under both OS-9 >Level I or Level II. This is possible because addressing within the >program is all relative and addressing of data is all base register >relative. THIS IS NOT A SILLY IDEA. The outward structure is pretty much the same and in fact several system calls did change between the versions. Software vendors took advantage of the fact that the full address-space was available in level I. Programs written with portability to Level II in mind work just fine... This is to say that I can run the level I C compiler on my level II system. It just can be guarenteed to work unless the author of the software fails to stick to the rules. > It's certainly no accident or matter of luck that code is portable >between Level I and Level II. This is true. The mechanism for upward portability was built into both level I and level II. I wish more software authors had followed it. Folks need to know about this so that they don't get burned by it. Steve Blasingame (Oklahoma City) ihnp4!gorgo!bsteve
knudsen@ihwpt.ATT.COM (mike knudsen) (05/18/87)
> > One of the minor complaints I have with OS9 level II is the > >lack of a full screen editor. I purchased a copy of tsedit and tsword > >for OS9 level I, but they don't seem to work with level II. Perhaps it > >is because I have configured my system to use the window driver rather > >than the vdu driver. Yep. Must run it in a 32-col screen, which you can always create from a window by setting tmode type=0. Then TSEdit is fine. > > Even if tsedit can be made to work > >under (over?) level II , would it take advantage of the 80 column video > >hardware of the CoCo 3? Nope, still the handmade graphics hard-to-read 64-char screens. > I believe that you are wrongly critical. OS9 Level II is a different operating > system from OS9 Level I. It is only by lucky coincedence that Level I binaries > run under Level II. More often than not level I binaries make assumptions > that the entire address-space of the machine is available, when with hardware > memory management, it is not. No coincidence. Tandy & Mware worked hard to make the hard and sofware compatible. Mware has always kept different levels of OS9 as compatible as possible. Give credit where due. Yes, programs that assume too much in Level 1 will bomb in Level 2, but TSEdit seems to have done only two odd things. First, TSEdit writes directly to the (now "LoRes") graphics page, which was permitted under Level 1 and still supported under L-2. Other thing was POKEing the VDG chip (now GIME) with a hi-contrast color set, which, thanks to Tandy's hardware compatibility, still works (I'm just guessing about this). I doubt that HiRes screen under Frank Hogg's O-Pak would work in L-2, since it patches into CCIO in system space. > I am rather fond of uEmacs which will compile and run quite nicely > under Level II. So am I fond of Emacs. Have you got uEmacs patched for 80x24? User's Group owes me a disk; is 80x24 included yet? > Steve Blasingame (Oklahoma City) > ihnp4!gorgo!bsteve -- Mike J Knudsen ...ihnp4!ihwpt!knudsen Bell Labs(AT&T) Delphi: RAGTIMER CIS: <memory failure, too many digits> "Just say NO to MS-DOS!"
pete@wlbr.UUCP (05/26/87)
In article <58400009@gorgo.UUCP> bsteve@gorgo.UUCP writes: > (grunch of debated/rebutted comments removed) >THIS IS NOT A SILLY IDEA. The outward structure is pretty much the same and >in fact several system calls did change between the versions. Software >vendors took advantage of the fact that the full address-space was available >in level I. (more stuff whacked) > >> It's certainly no accident or matter of luck that code is portable >>between Level I and Level II. > >This is true. The mechanism for upward portability was built into both >level I and level II. I wish more software authors had followed it. Folks >need to know about this so that they don't get burned by it. > I have been running LII for around 2 years, and LI for around 4. I am painfully aware of the differences, but let me make this rash statement: Level 2 system calls are NOT different than level I system calls. There are *more* calls under level 2, but those that share the same name perform the same function. Also, what software vendors are you referring to?? All of my level I application stuff works just dandy under LII. The only place I know you get into trouble is when you rely upon information in the direct page. -- Pete Lyall Usenet: {trwrb, scgvaxd, ihnp4, voder, vortex}!wlbr!pete Compuserve: 76703,4230 (OS9 SIG Sysop) OS9 (home): (805)-985-0632 (24hr./1200 baud) Phone: (818)-706-5693 (work 9-5 PST) EATON Corp, IMSD, 31717 La Tienda Dr., Westlake Village, Ca. 91359 ----------------------------------------------------------------------