[comp.sys.atari.st] OS9/68000 for Atari ST

pete@wlbreng1.UUCP (Pete Lyall) (01/14/87)

Well, well....

It appears that TLM going out of business turned out to be a
pseudo-blessing for the OS9/68000 users on the ATARI ST. The following
is a message left by Microware's (authors of OS9) Bill Moore on
CompuServe:

======================================================================

#: 38868 S13/Atari ST
    12-Jan-87  10:48:41
Sb: Atari OS9 Support
Fm: B. Moore 73105,1265
To: All
.
MICROWARE ASSUMES SUPPORT OF OS-9/68000
FOR ATARI 520 AND 1040 ST PERSONAL COMPUTERS
.
Microware Systems Corporation will assume support for the Atari
ST version of OS-9/68000 Operating System.  This software was
previously distributed by TLM Systems Inc., which has apparently
ceased doing business.  Microware will provide interim support to
users who previously obtained the software from TLM.
.
Microware also plans to introduce Personal OS-9 Version 2.0 for
the Atari ST in the near future.  This will be marketed directly
by Microware to Atari dealers and end-users.  Those who
previously purchased the TLM package will be offered an
opportunity to upgrade at minimal cost.
.
In order to qualify for interim support service and the future
upgrade, Atari ST users should register with Microware as soon as
possible.  As proof of purchase, both of the following items
should be sent to Microware:
.
     (1)  The greyfront cover of the OS-9/68000 User's Manual,
.
     (2) A photocopy of the original OS-9 distribution diskette
    as supplied by TLM to the customer.
.
These should be mailed to:
.
     Microware Systems Corporation
     Customer Support Department
     1900 N.W. 114th Street
     Des Moines, Iowa 50322
.
Microware intends to very actively support the Atari ST community
in the future with a wide variety of advanced system software,
programming languages, and software tools.  We sincerely regret
any inconvenience the TLM situation may have caused to OS-9/Atari
ST Users.

==================================================================


-- 

                                                   Pete Lyall

Usenet:     {trwrb, scgvaxd, ihnp4, voder, vortex}!wlbr!wlbreng1!pete
Compuserve: 76703,4230 (OS9 SIG Sysop)
OS9 (home): (805)-985-0632 (24hr./1200 baud)
Phone:      (818)-706-5693 (work 9-5 PST)
----------------------------------------------------------------------

atwell@utah-cs.UUCP (Bart L. Atwell) (01/16/87)

Is there any information on how much OS-9 will cost from the new company?
I remember the old price being pretty steep.

Maybe OS-9 can solve the 40 folder situation!

Bart

alexande@drivax.UUCP (01/20/87)

In article <4170@utah-cs.UUCP> atwell@utah-cs.UUCP (Bart L. Atwell) writes:
>Maybe OS-9 can solve the 40 folder situation!

I'm sure it can, but it wouldn't do you much good if you wanted
OS/9 to be disk-file-system-compatible with TOS, which I doubt it is.
(Can somebody verify this?)

It also wouldn't do you much good if you still wanted
to run your TOS/GEM programs, unless someone went to all
the trouble of writing a TOS front end for OS/9 and ported
all of GEM, which I also doubt.
-- 
Mark Alexander	...{hplabs,ucbvax!decvax}!decwrl!pyramid!amdahl!drivax!alexande
"This then is my story.  I have reread it.  It has bits of marrow
sticking to it, and blood, and beautiful bright-green flies."  --Nabokov

jtr485@umich.UUCP (01/27/87)

In article <797@drivax.UUCP>, alexande@drivax.UUCP writes:
> In article <4170@utah-cs.UUCP> atwell@utah-cs.UUCP (Bart L. Atwell) writes:
> >Maybe OS-9 can solve the 40 folder situation!
> I'm sure it can, but it wouldn't do you much good if you wanted
> OS/9 to be disk-file-system-compatible with TOS, which I doubt it is.
> (Can somebody verify this?)
WRONG!  Even if it is disk compatible(which I doubt) the directory logging
does not have to be the same.  That 40 folder limit is a product of the op
system IMPLEMENTATION not the file system.  IBM PC's don't have that limit
and the whole ST disk system is a bad crib of PC/MS-DOS (very bad crib!).
> It also wouldn't do you much good if you still wanted
> to run your TOS/GEM programs, unless someone went to all
> the trouble of writing a TOS front end for OS/9 and ported
> all of GEM, which I also doubt.
So.  You keep two systems for the machine.  Big deal.
Keep TOS/GEM to play games.  Use OS9/68K to do everything else.
If the price for ST OS9 was reasonable I would seriously recommend this to every
ST owner and every new system purchaser.  As it is, it is NOT reasonable!
OS and REAL language cost more than the hardware--ouch!
--j.a.tainter
>Mark Alexander{hplabs,ucbvax!decvax}!decwrl!pyramid!amdahl!drivax!alexande

jimomura@lsuc.UUCP (01/28/87)

In article <797@drivax.UUCP> alexande@drivax.UUCP (Mark Alexander) writes:
>In article <4170@utah-cs.UUCP> atwell@utah-cs.UUCP (Bart L. Atwell) writes:
>>Maybe OS-9 can solve the 40 folder situation!

     Yes, it does.

>I'm sure it can, but it wouldn't do you much good if you wanted
>OS/9 to be disk-file-system-compatible with TOS, which I doubt it is.

     Quite correct.  The disk format is different but
I'm not quite sure how important this is to you.  For me
it is getting less important constantly.  The first problem
I had was that I had no way to get *anything* from TOS to
OS-9 or backwards.  Now I can do it via an intermediate
computer using Kermit.  In a little while, I should be able
to do it direct disk to disk by writing a TOS format driver
under OS-9.  This should be particularly simple since I
Obviously just have to disassemble the TOS driver and re-
assemble it with fairly minor changes under OS-9 (which
comes with an assembler).  For most purposes I'll also
need a LineFeed stripper and a utility to add LF's after
CR's because OS-9 only needs a CR for EOL.

>It also wouldn't do you much good if you still wanted
>to run your TOS/GEM programs, unless someone went to all
>the trouble of writing a TOS front end for OS/9 and ported
>all of GEM, which I also doubt.

     This may not be necessary.  I found out recently from
Avy Moise that OS-9 sits *beside* GEM in memory and doesn't
overwrite the previously used memory.  This has its advantanges
and disadvantages.  The advantage is that it should be fairly
easy to write a utility which returns you to GEM intact at
the point where OS-9 was called.  Furthermore, it may be
possible to run GEM under OS-9 with a relatively simple
"utility".

     Ironically, what's proving to be more difficult for me
right now is just disassembling an OS-9 driver.  I won't
go into that right now though.  Let's just say it's not
all that difficult, but I can't do it right now.



Cheers! -- Jim O.