emjej@uokvax.UUCP (01/06/84)
#R:ihnss:-171500:uokvax:3500024:37777777600:887 uokvax!emjej Jan 4 13:49:00 1984 The Compuserve CoCo SIG is starting to carry discussion (of a blue-sky nature) of a truly portable 6809/OS-9 based machine. I'd say that such a beast could be *quite* nice (Level Two and 128K, a good on-board modem, serial and parallel ports, clock, and nice display, if they could be had). Evidently Hitachi has come out with a CMOS (and hence not needing much power--hardware folks, please correct me if I'm wrong) 6809, and this is what prompted the discussion. James Jones To further comment on why not a 68000: I suppose you could, but then what with estimates on net.micro of the 68000s and 8087 stooping to emulate a 370 running at an effective .1 MIP, I'd say that a largely byte-oriented machine that runs at .4 MIP (see Terry Ritter's article in *System 68* on the 6809 instruction set and his arrival at this average number for a 2 MHz 6809) could do pretty well...
mpackard@uok.UUCP (10/07/84)
Thats what I like to see, documentation that answers the users questions.
emjej@uokvax.UUCP (11/01/84)
/***** uokvax:net.micro.6809 / sask!mcdonald / 8:09 am Oct 4, 1984 */ Does anyone know if there is a Lisp available for OS-9 running on the CoCo? Negative responses are welcome as well as positive ones. /* ---------- */ Gee--I forgot to mention something. At Des Moines, there were a couple of Japanese fellows there from Seikou Electronics, Ltd. (not to be confused with some rather famous watchmakers). They were the ones who had the Fujitsu FM-11 there that everyone was gaping at (and I pause here to once again express my disgust at how they sell Intel garbage in the US but not the good stuff). Anyway--they were demonstrating, aside from the excellent windowing and graphics software for the FM-11, their Lisp package (Lisp-09, they called it). It supports graphics, gives you access to the OS (via a SHELL function, rather reminiscent of BASIC09), has a function editor, and does various stuff that I, as a non-Lisp person (but trying to fix that), can't really comment well on. Their address, prefaced with the disclaimer that I don't know these folks from Adam, much less have any connection with them: Seikou Electronics Co. Ltd. Hasegawa Bldg., 6-5-11 Sotokanda Chiyoda-ku Tokyo 101 Japan phone: (03)832-6000 Telex: 0265-5633 seikoh j It might be worthwhile to address letters to either their president, Mitsuyuki Hoshi, or their general manager, Hiromu Asai. James Jones
emjej@uokvax.UUCP (12/31/84)
/***** uokvax:net.micro.6809 / wlbr!steve / 5:56 pm Nov 7, 1984 */ Howdy! Steve Childress here-- I'm new to this net, so please forgive errors of protocol and admonish freely! Here's a quick Bio for you OS9 fans... /* ---------- */ Speaking of errors of protocol, I'm making one here, I suppose, but several attempts at sending mail have failed. Steve--I'd very much like to correspond. I'm definitely interested in PD software exchange. James Jones UUCP: ctvax!uokvax!emjej USnail: 413 West Eufaula Norman OK 73069
emjej@uokvax.UUCP (emjej) (01/02/85)
/***** uokvax:net.micro.6809 / qumix!stoner / 8:19 am Dec 1, 1984 */
In trying to compile your listc.c program I found out that I don't
have #include files:<sys/types.h> and <sys/stat.h>. What I was wondering
was,are these standard include files that you renamed or newer created
files that aren't?
If they aren't standard files could you send me these files via mail?
/* ---------- */
I post this in case others could use the info:
<sys/stat.h> contains the moral equivalent of a subset of what Microware C
users will find in <direct.h> and <modes.h>, namely what corresponds to
the stuff in the file descriptor sector, along with the values for various
access modes. <sys/types.h> contains typedefs and such for Unix system
internals, some of which are used in <sys/stat.h>.
Therefore, you don't need copies of them; just include <direct.h> and
<modes.h>.
Now, the author of listc.c may have used stat() or fstat() (net.sources
is locked here, so I don't know). The OS-9 operation that corresponds to
that is a GetStat 14 (read file descriptor sector). Unfortunately, it's
not documented in some versions of the manuals; look in <os9.h> or
OS9Defs (I think--it's the file with all the defines for system calls,
error codes, etc.; among them are the S$*, which are the Get/SetStat
codes). Note that this doesn't correspond exactly to fstat(), since you
have to have the file open (you specify it by path number, not by name).
James Jonesemjej@uokvax.UUCP (emjej) (01/05/85)
[when you send some mail/and you want it truncated/who ya gonna call?...] /***** uokvax:net.micro.6809 / ihnss!knudsen / 6:14 pm Nov 28, 1984 */ I have finally proven to myself that the putc(char, channel) function in the stdio library is defective in Coco OS9 C. Namely, it strips off the high-order (sign) bit 7 when going to stdout. This makes it unusable for feeding graphics coordinates to CCIO, since these must range all the way up to 255 (or -128 thru -1, in C's viewpoint). /* ---------- */ Just wanted to confirm that this is a CoCo-ism; it does not happen elsewhere in Microware C. I can't help but think that somebody at RS is hosing things severely...first the device drivers, now this...oy! James Jones
jejones@ea.UUCP (12/26/85)
With luck, sometime in 1Q86, my previous response on this topic will be *way* out of date. According to messages posted in the CompuServe OS-9 SIG (by its sysop), the following should happen: In 1Q86 (or 2Q86 at the latest), OS-9/68000 for the Amiga and the 520ST. Some time between March and May 1986, CoCo 3 with reasonable display, 512K RAM, and OS-9 Level Two. The latter's been expected for quite some time now, so I can understand a certain amount of skepticism. The former is simply something that's LONG overdue, and should have been done by the folks who brought out the boxes. James Jones
emjej@uokvax.UUCP (01/20/86)
Thanks to Bob Larson and Mike Knudsen for the answer, which I put here for posterity: prof.c has in it sample versions of the functions that are called on entry and exit when you compile with the -p option. What tripped me up was that the version I had (which appeared in clib.l) did NOT have an _eprof function. I stuck in a trivial one, and all was well. You can, of course, roll your own profiling functions, perhaps including some tracing information as well...just be sure not to compile them with -p (whirr). James Jones
emjej@uokvax.UUCP (04/12/86)
/* Written 6:03 pm Apr 2, 1986 by knudsen@ihwpt.UUCP in net.micro.6809 */ I just got the dhrystone C program source from net.sources and have edited it for the Coco OS9 C. When/if I get results, they'll show up here the next day. Anyone else want to try, and compare results? /* End of text from net.micro.6809 */ Mike mailed me the source--I ran it on a 2 MHz 6809 system (SSB Chieftain, OS-9/6809 Level II v. 1.2). Since the getime() doesn't give you closer resolution than a second anyway, I just conditionally uncompiled all the timing code and did this: cc <options> dhry.c load date; load dhry date t; dhry; date t The form in which I got the code provided for conditional compilation with local variables and formal parameters declared register (though Microware C honors only one such per function). I added code to allow conditional compilation with scalar global variables requested especially to be on the direct page. Here's what I got-- regs? DP? raw delta t Dhry/sec N N 4:02 207 Y N 3:58 210 N Y 3:59 210 Y Y 3:21 (!) 249 There were few global variables, so I could understand the relatively small difference DP variables alone would make, but I was REAL startled by the effect of using BOTH registers and DP variables. Whether such maneuvers are "kosher" for Dhrystone benchmarking is for others to decide, though the eighty-eighty-sucks systems listed, with only one ex- ception, were directed to generate "small model" code, so...But frankly, who cares? Just remember it when *you* write C programs for OS-9. It's essentially trivial to make "direct" go away when you recompile for OS-9/68000 or other, lesser, systems :-) --so why not take advantage of it? James Jones
emjej@uokvax.UUCP (05/05/86)
/* Written 10:41 am Apr 22, 1986 by ingoldsby@calgary.UUCP in net.micro.6809 */
One final question: Is it permissible to do system calls within
a device driver?
Terry Ingoldsby
/* End of text from net.micro.6809 */
Yes, indeed, one can. I once asked Kim Kempf (God, I'm starting to sound
like Jerry Pournelle!) and he said yes, in fact, Seikou Electronics, the
folks who do nice things in Japan, do just that. Qualifying data: the
particular system calls they did were doing I/O calls from within a device
driver (though I've seen a device driver that does a request for memory
with no sweat, so there's another example), and if you try that, remember
to use *system* path #s, not the 0, 1, 2, ... relative to the process that
you may have in mind. Further qualifying--the reason I asked is that I
wanted to make up for a FLEXoid nerd processor (SCREDITOR III) asking for
sole control of the printer by setting up a device that when opened would
fork the spooler and feed things written to it to the spooler. Kim wasn't
sure whether that would actually work, and I haven't tried it (because I
would have to write a file manager, and I can't find docs for the entry
points for 6809 file managers and where parameters are kept), so I don't
know either.
James Jonesemjej@uokvax.UUCP (05/28/86)
> The question is: What advantage is held by a computer running OS-9 if > the CDI standard becomes a success? ... > 6- that OS-9 is really great, independent of CDI, and that you > come out ahead even without any of the above panning out. > jimm "I can think o' one right off." --Scotty, "By Any Other Name" The two things that come to mind for me is 1. This should be a good source of $$$ for Microware, and thus assure its continued existence even if the general public continues to drool over the International BM. 2. It means that one of my fears about CD-ROM, namely that some scumbag International BM format would be adopted as a "standard" so that, thanks to the heavy startup cost of getting stuff on CD, we OS-9 users would be deprived of CD-ROM, is fairly unlikely. James Jones
emjej@uokvax.UUCP (06/03/86)
You go about joining the OS-9 Users Group by sending a check for $25, along with info about what variety of OS-9 you run (6809 Level I/II, 68000), and what kinds of floppies you can read, so they can send you the disk that goes out to all new members, to the following address: OS-9 Users Group Attn: Membership 9743 University Avenue, Suite 330 Des Moines IA 50322 James Jones
mikey@bbimg.UUCP (06/18/86)
How about a simple approach, order service manual! Mike Yetsko trsvax!techsup!bbimg!mikey
mikey@bbimg.UUCP (07/08/86)
Please note that the 68HC11 is a 48 pin device, and that the 6801 is a 40 pin. I don't think that makes them that compatible. From a software standpoint, I believe the 68HC11 is upward compatible, but a lot of the newer instructions are two bytes instead of 1. Mike Yetsko trsvax!techsup!bbimg!mikey