klieb@tekigm2.MEN.TEK.COM (Kurt Liebezeit) (12/23/88)
(... up on the soapbox...)
Am I alone in thinking that Microware's pricing strategies are out of line
with the supposed home computer market? I have been running OS-9/68k version
1.2 at home on my Uniquad 2, and a couple of months ago I got the upgrade
to 2.1. The upgrade cost me $75 from the board manufacturer, which was
reasonable; however, the upgrade did not come with manuals, nor were they
available from Hazelwood or Frank Hogg Labs. That left Microware as the
only source.
I called Microware, only to find out that the cheapest way to get a current
technical reference and user's guide was to buy some package (strictly
paper manuals, mind you) for $150!! Good grief, who can really afford $225
for a software+manuals UPGRADE? Is this any way to popularize an operating
system? Suppose the manuals have 300 sheets. Say that the upgrade doesn't
come with a binder. Suppose that each sheet costs between 3 and 5 cents;
printed sheets will be the former, and photocopies the latter. In any case,
the reproduction costs can't be more than $10 or $15 dollars. Triple that,
or even quadruple it, and you still don't get anywhere near $150. To me,
$150 says "We don't want your business. Go away."
Along the same lines I inquired about C compiler updates; to go from 2.0 to
3.0 would be $100; this is a little on the high side, but at least it includes
a compiler manual. The gentleman I spoke with mentioned that version 3.0
supports this Great New Source-Level Debugger. Later on in the conversation
it occurred to me to ask whether the Debugger was part of the compiler
upgrade; no, he said, that costs SEVEN HUNDRED FIFTY dollars more! Yipes!
Looks like I'll be debugging in 68k assembler for the foreseeable future. Once
again, $750 says "We don't want your business. We're doing nicely selling
OS-9's real time features and rom-ability to big corporations that can
afford it. Go away." Oh well, Real Programmers(tm) don't use source level
debuggers anyway...
I just can't believe that Microware couldn't sell more than six times as
many debuggers at one sixth the price ($125). Who really buys an OS-9 system?
I think that you'd find that, excluding embedded application licenses, the
average OS-9/68k owner bought OS-9 to use as a programming platform. Probably
Unix was too slow, bloated and cryptic. That means, on average, every single
non-embedded license is a potential sale for a debugger. We're not talking
about an information appliance like a Mac, where I would guess that 1 in
50 Mac owners needs a debugger.
A recent issue of Byte featured Steve Ciarcia answering a reader's query
about why he didn't design a 68000 into any of his projects. Part of his
reply was that the development tools for 68000 were too expensive, and he
mentioned OS-9 specifically by name. Is there a Microware marketing manager
in the house? Jerry Pournelle, whom I can't stand otherwise, made the same
comment in an earlier issue.
It is reasonably common knowledge that OS-9 is far more popular in the real-
time embedded applications market than in the home computer "compete with
low-end Unix" market. Yet, when I purchased my Uniquad in January of 1986
I sensed that OS-9 was breaking out of that mold: it became available for
the Atari, Microware announced support for the GKS graphics standard and
the 63484 ACRTC, and Sony/Microware announced their joint intent to develop
the CD-ROM with OSK. By continuing to milk the high end of the price vs.
demand curve I am forced to conclude that it was all an illusion. OS-9 is a
quality product: it provides a clean, Unix-like platform for programmers.
But when you look at the bare facts about their pricing, even for manuals,
upgrades, and technical support, you have to conclude that those of us who
aren't developing software for toasters are simply along for the ride. We really
aren't their main customers, to such an extent that I have to question why
we are here.
========= and now some quizzing of the audience, in which the host inquires
========= of his listeners their opinions.
This brings me to my first question, gentle denizens of the net: are the
bugs (as yet undiscovered by me) in 2.0 of the OSK C compiler worth paying
$100 to trade for the bugs (perhaps small, and hopefully few) in version 3.0?
Or was the version change to 3.0 mainly to support the Great New Source-Level
Debugger, priced beyond the reach of ordinary mortals?
The overall cost of upgrading my Uniquad to more bug-free levels is pretty
high, all in all:
OSK software upgrade to 2.1 $75
Manuals for above $150
C compiler upgrade (maybe) $100
Stylo upgrade w/ manuals $65
Total: $390
Worst of all, I'm told that OSK version 2.1 is pretty buggy, so I'm looking
at another $75 to go to 2.2. Why am I doing this? Why don't I give up and
start over with GNU, or Minix, or something similar? Why? Why? Why? Even
Messy-DOS, Microsoft C, and Codeview is looking better and better.
The second question is: how bad are the bugs in OSK 2.1? Worth going to 2.2?
Wait for 2.3? Punt?
More questions: has the user group gone down the tubes or what? Were the money
problems so bad that we'll never see another MOTD published? Or are they
suffering from a lack of volunteers to write articles, etc? Did I jump on a
sinking ship by buying OS-9/68k in 1986? Will OS-9/68k ever break out of the
mold of running on a host of industrial controllers and a few scattered home
-brew machines and/or Ataris? Will the long-awaited Sony/CD rom machines ever
come out? Is anyone out there running OS-9/68k other than TOP? (which, by
the way, is a beam of light in an otherwise silent and murky software world).
What about the rumored graphical interface for OSK (along the lines of what
the Coco III has)?
I'm about ready to start my own user group, with first priorities given to
(a) illegal manual duplication {|^), and (b) software bug reporting.
Not that Microware's bugs have been numerous, or devastating; part of support
is knowing what is really a bug, and what is simply operator error. The
problem, once again, is that it costs a lot for support capable of serving
both the beginners and the competent. Good manuals with examples and a monthly
bug list are worth more than a hotline to me. If the bug list were electronic
it would doggone cheap, too. Does the OS-9 conference on Compu$erve have bug
lists? Wait, I know, we'll write a BBS that calls all the members in a tree-
like fashion at 3am every week or so. We'll distribute it free to anyone
who wants it. For point to point mail it will call directly to the destination
and the computer will only answer the phone between 03:00 and 03:02, that way
no one except the sender gets charged... yeah, it'll be compatible with uucp
and news... all you have to do is click on the letter and drag it over to
the mailbox... I'm starting to babble again.
(... sound of thud ...)
Well, that's enough rambling for now.
Kurt Liebezeit klieb@tekigm2.TEK.COM ...!tektronix!tekigm2!klieb
Yep, I said that. Tektronix didn't.schultz@mmm.UUCP (John C Schultz) (12/27/88)
>(... up on the soapbox...) > >Am I alone in thinking that Microware's pricing strategies are out of line >with the supposed home computer market? I have been running OS-9/68k version >1.2 at home on my Uniquad 2, and a couple of months ago I got the upgrade >to 2.1. The upgrade cost me $75 from the board manufacturer, which was >reasonable; however, the upgrade did not come with manuals, nor were they >available from Hazelwood or Frank Hogg Labs. That left Microware as the >only source. > How about porting GNU compilers etc. for OS9? The price is right - free. We have compiled code on SUN and downloaded to standalone 68000s which run OS9 so the changes should be minor. What needs to be done is a method of getting the executable header from OS9 so that GCC can generate executable files for OS9. It would be nice if Microware realized that they are wasting their time with their C compiler/debugger and simply began supporting GNU GCC and GDB. I would think such a decision would actually save them money since GCC is already better (e.g. GCC correctly compiles floating point and complex function calls) than the OS9 C compiler. OS9 would then also have a C++ compiler in the form of G++. GDB is at least as good as SUNs DBXTOOL. I am impressed by its ability to modify source code values and print the value of complex expressions. And before someone says "Well why don't you do it?", it is in my do-on-your-own-time queue but down quite aways behind wife, children, house, work I get paid for, ... -- john c. schultz schultz@mmm.3m.UUCP (612) 733-4047 3M Center, Bldg 518-1-1, St. Paul, MN 55144-1000 The opinions expressed herein are, as always, my own and not 3M's.
vandys@hpcupt1.HP.COM (Andrew Valencia(Seattle)) (12/28/88)
/ hpcupt1:comp.os.os9 / schultz@mmm.UUCP (John C Schultz) / 6:18 pm Dec 26, 1988 /
>How about porting GNU compilers etc. for OS9? The price is right - free.
Someone got gcc over to the Atari ST running MINIX. Seems like it
should be pretty close--why not give a shout over on the comp.os.minix group?
Andyblarson@skat.usc.edu (Bob Larson) (12/29/88)
In article <3979@tekigm2.MEN.TEK.COM> klieb@tekigm2.MEN.TEK.COM (Kurt Liebezeit) writes: >Am I alone in thinking that Microware's pricing strategies are out of line >with the supposed home computer market? No. >This brings me to my first question, gentle denizens of the net: are the >bugs (as yet undiscovered by me) in 2.0 of the OSK C compiler worth paying >$100 to trade for the bugs (perhaps small, and hopefully few) in version 3.0? There were a lot of improvements between 2.0 and 2.2, making it closer to a modern C compiler, and I think there are more in 3.0. (I'm still running 2.2 on osk 2.1.) There were also a number of bug fixes, but nothing major enough to compel an upgrade. cstart.r must be modified to get the 2.0 compiler working under osk 2.1. (Elinate the unused reference to the non-existant routine in cstart.a and reassemble.) >Worst of all, I'm told that OSK version 2.1 is pretty buggy, so I'm looking >at another $75 to go to 2.2. I find 2.1 quite usable. >The second question is: how bad are the bugs in OSK 2.1? Worth going to 2.2? >Wait for 2.3? Punt? You should probaby check out the Microware area on compuserve, they list both information on new releases (new features) and bugs fixed. >More questions: has the user group gone down the tubes or what? Were the money >problems so bad that we'll never see another MOTD published? MOTD is being published at irregular intervals. The money situation is not great, but I understand it is gradually improving. > Or are they >suffering from a lack of volunteers to write articles, etc? I think they could certainly use more. > Did I jump on a >sinking ship by buying OS-9/68k in 1986? I hope not, I'm sitting beside you. >Is anyone out there running OS-9/68k other than TOP? (which, by >the way, is a beam of light in an otherwise silent and murky software world). With Mg, C-Kermit, patch, hack, and a few other goodies, I don't think I've been exactly idle. TOP picked up a few of my things (without specific permission) but I wish they would distribute source. >I'm about ready to start my own user group, ... Well, one of my projects is getting usenet running on os9, and starting an os9/68k oriented bboard on my system. (Source archive and some usenet groups are planned.) I think lack of reliable source distribution is the major problem with the users group. Over 6 month turnaround from submission to availability is just to long, and compuserve is to expensive (and their software is user hostile) to take seriously. Pete's archives are oriented to os9/6809. Bob Larson Arpa: Blarson@Ecla.Usc.Edu blarson@skat.usc.edu Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson Prime mailing list: info-prime-request%ais1@ecla.usc.edu oberon!ais1!info-prime-request
blarson@skat.usc.edu (Bob Larson) (12/29/88)
In article <1196@mmm.UUCP> schultz@mmm.UUCP (John C Schultz) writes: >How about porting GNU compilers etc. for OS9? The price is right - free. Actually, I have started playing with such a port. Microware's C (2.2) realy isn't up to handling the bootstrap. >We have compiled code on SUN and downloaded to standalone 68000s which >run OS9 so the changes should be minor. I actually have Gnu cpp (cccp) running. Here are a few examples of "minor": Gcc uses looooooooong lines. Microware C chokes on 512 characters, some gcc macros ten times that, and some constant strings are longer as well so simple line breaking isn't enough. Gcc gobbles memory. I doubt it will ever work on a system with less than a megabyte. Gcc has no apperent way to generate code without absolute addresses. Gcc uses structure valued functions, bit fields, void, and other features not yet present in Microware C (as of 2.2). Gcc's argument passing does not match Microware's. Gcc assumes a unix library is available. Microware's malloc is broken, and cccp exersises the bug. > What needs to be done is a >method of getting the executable header from OS9 so that GCC can >generate executable files for OS9. This isn't a problem, since the header is documented. Convincing Gcc to arange things compatable with the header is more of a problem. >It would be nice if Microware realized that they are wasting their >time with their C compiler/debugger and simply began supporting GNU >GCC and GDB. I would think such a decision would actually save them >money since GCC is already better (e.g. GCC correctly compiles >floating point and complex function calls) than the OS9 C compiler. >OS9 would then also have a C++ compiler in the form of G++. It might save them money, but it would not directly make them money either. Since Microware is in the software business, I don't expect them to do this. >And before someone says "Well why don't you do it?", it is in my >do-on-your-own-time queue but down quite aways behind wife, children, >house, work I get paid for, ... Well, if anyone wants a outdated but mostly-working osk gnu cpp, and will continue the project... Bob Larson Arpa: Blarson@Ecla.Usc.Edu blarson@skat.usc.edu Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson Prime mailing list: info-prime-request%ais1@ecla.usc.edu oberon!ais1!info-prime-request
wilker@batcomputer.tn.cornell.edu (Clarence W. Wilkerson Jr.) (12/29/88)
Why not consider GENIE as an archive spot? It's worked well for CPM. The line access charge is $5/hour at 1200 baud off peak. I don't know what kind of volume they need to have a separate area. There exists some os-9 for the Tandy coco already under the Tandy area. .
rusty@cadnetix.COM (Rusty) (01/01/89)
In article <14338@oberon.USC.EDU> blarson@skat.usc.edu (Bob Larson) writes: >... >Actually, I have started playing with such a port. Microware's C (2.2) >realy isn't up to handling the bootstrap. >... >Bob Larson Arpa: Blarson@Ecla.Usc.Edu blarson@skat.usc.edu Well, actually, I would suppose the project would be MUCH easier if you used gcc to compile itself, and made changes to it to generate os9 stuff. Then, use the native one on your unix machine to compile the changed one and you have yourself a cross-compiler. Now, compile yourself one more time -- ta-da! a os9 gcc. I think. Would that not be MUCH easier than any fooling around with Microware C? ----- Rusty Carruth UUCP:{uunet,boulder}!cadnetix!rusty DOMAIN: rusty@cadnetix.com Cadnetix Corp. (303) 444-8075x681 \ 5775 Flatiron Pkwy. \ Boulder, Co 80301 Radio: N7IKQ 'home': P.O.B. 461 \ Lafayette, CO 80026
mellin@lan.informatik.tu-muenchen.dbp.de (Reiner Mellin) (01/10/89)
[sorry for answering so late, but out vax didn't get news over Xmas time :-)), don't read new but celebrate ?] In article <14338@oberon.USC.EDU> blarson@skat.usc.edu (Bob Larson) writes: >In article <1196@mmm.UUCP> schultz@mmm.UUCP (John C Schultz) writes: >>How about porting GNU compilers etc. for OS9? The price is right - free. > >Actually, I have started playing with such a port. Microware's C (2.2) >realy isn't up to handling the bootstrap. Well, With a modified CPP (decus or GNU) you can even bootstrap GNUGCC, the only thing which is essential is the <long-line-bug> of the c68 (he cant digest line which are longer than 512/1024? Bytes; i fixed the decus cpp that he will emit a <CR> when outputting a line bigger than 400 Chars, which will happen with this LOOOONNGGGG GNU-macros). I used the Version 2.2 of c68, and had to change only some enums inside a structure). >>We have compiled code on SUN and downloaded to standalone 68000s which >>run OS9 so the changes should be minor. > >I actually have Gnu cpp (cccp) running. Here are a few examples of >"minor": > Gcc uses looooooooong lines. Microware C chokes on 512 >characters, some gcc macros ten times that, and some constant strings >are longer as well so simple line breaking isn't enough. with the newst version of my port of the decus-cpp (will be on TOP Release 2 in source :-)), you can forget that problem <sigh>. :-) > Gcc gobbles memory. I doubt it will ever work on a system >with less than a megabyte. Yep, about 380kb of code and the same amount of dynamic memory. > Gcc has no apperent way to generate code without absolute >addresses. THe MAIN POINT !!! I got GNU-GCC up and running, but it generated sun-assembler with *absolute* addressings. I suspended the Porting since my Version was too old (1.18) and i got Version 1.31.(But, i have no time at the moment ). > Gcc uses structure valued functions, bit fields, void, and >other features not yet present in Microware C (as of 2.2). that was not a problem (i got an intermediate version of 2.2, between orig. 2.2 and 3.0). > Gcc's argument passing does not match Microware's. > Gcc assumes a unix library is available. well, the older Verion i used (1.18) couldn't pass parameter in registers, the newer Versions of GCC seems to be able to do that (influence of sparc-port etc ??). > Microware's malloc is broken, and cccp exersises the bug. nver experienced that on my Osk-2.1 .....(a problem of 2.0 or its library ?). >>It would be nice if Microware realized that they are wasting their >>time with their C compiler/debugger and simply began supporting GNU >>GCC and GDB. I would think such a decision would actually save them >>money since GCC is already better (e.g. GCC correctly compiles >>floating point and complex function calls) than the OS9 C compiler. >>OS9 would then also have a C++ compiler in the form of G++. > >It might save them money, but it would not directly make them money >either. Since Microware is in the software business, I don't expect >them to do this. neither me, but a real full-fledged compiler (and C++) would be fantastic (at an REASONABLE PRICE !!!!!). >Well, if anyone wants a outdated but mostly-working osk gnu cpp, and >will continue the project... The State of my `Port': - GCC compiles under OSK and generates sun-asm--output with *absolute* addressings. - the compile-speed is comparatable to the duo c68/o68 but need far more memory ! - The generated size is about 30% smaller and 20-30% faster than microwares (hand-translation of sun-asm.ouput to microware-asm). So, There are Two major steps to take: - getting GCC output *relative* addresses instead of absolute. - if the parameter passing in registers fails, a new clib have to be written (maybe we can adopt the Library of the ST-port of GCC? or the MINIX-port?). optimistic Greetings Reimer Mellin -- | Reimer Mellin | mellin@lan.informatik.tu-muenchen.dbp.de | | Sulenstr. 8 | pyramid!tmpmbx!ramsys!ram (home) | | D-8000 Muenchen 71 | Technische Universitaet Muenchen |