Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!think.com!snorkelwacker.mit.edu!ira.uka.de!fauern!faui43.informatik.uni-erlangen.de!csbrod
From: csbrod@immd4.informatik.uni-erlangen.de (Claus Brod)
Newsgroups: comp.sys.atari.st
Subject: Re: How is Atari doing in Europe?
Message-ID: <1991Jun21.104233.24151@informatik.uni-erlangen.de>
Date: 21 Jun 91 10:42:33 GMT
References: <1991Jun14.010821.9903@noose.ecn.purdue.edu> <5360@syma.sussex.ac.uk> <1991Jun17.190053.7342@clinet.fi> <3283@krafla.rhi.hi.is>
Organization: CSD., University of Erlangen, Germany
Lines: 51

adamd@rhi.hi.is (Adam David) writes:

>TOS has yet to be junked. In all seriousness Atari, why not have a REAL OS
>in ROM and the option to load TOS and GEM from disk for backward compatibility?
>There is nothing fundamentally wrong with the Atari hardware, though there are
>certain limitations which I feel should not be imposed.

TOS is usable. TOS is useful. TOS isn't more bug-ridden than other OS's.
And personally, I think GEM is a real gem. It has all the potential
to rival the MacOS. So don't junk TOS, Atari. Instead, give us MultiTOS
soon. Besides, you can run lots of other OS's on the Atari NOW: OS/9,
Minix, MacOS, QL OS, MS DOS, Mirage... just to name a few.
And with the advent of Atari Unix we also have a full-featured SysV.4.
Think about it.

>The TOS ROMs are a joke though. (Does anyone know which compiler they used?).
>I would guess 20% or more of the space in them is wasted because the C
>compiler didn't optimise the code. There is plenty in need of revision.
>It seems the same compiler has been used for all TOS versions up to at least
>1.62. Even recent TOS versions have backward compatibility to features of CP/M
>which have never been used on Atari ST/TT hardware products. Until very
>recently there has been no support for HD floppies. The list goes on ......

The XBIOS floppy routines worked with HD drives from the day they were
created, likewise for BIOS and GEMDOS. Now, isn't that a sign of
thoughtful design? You might start picking on other design mistakes
like the troublesome GEMDOS I/O redirection, but HD drive support
is a very bad example.

With machines speeding up considerably and speeders all over the place,
the need for fine-tuning the ROM code diminishes. It's more important
for Atari to have control over the various TOS development lines, and
this is near to impossible to do with hand-optimized code. And the only
reason why Atari does not use Turbo C officially (though developpers at
Atari Sunnyvale are said to be allowed to use their favorite dev
package) is that it is not available in the US - no English docs and such.
With the Turbo C developpers falling off from Borland and starting with
a new distributor, this situation may change soon.

>If the hardware wasn't useable and some good quality application software
>packages then I wouldn't have stuck with Atari. Despite their failings,
>the equipment (with third party support) is still a fair cut above the rest.

D'accord.

----------------------------------------------------------------------
Claus Brod, Am Felsenkeller 2,			Things. Take. Time.
D-8772 Marktheidenfeld, Germany		 	(Piet Hein)
csbrod@medusa.informatik.uni-erlangen.de
Claus_Brod@wue.maus.de
----------------------------------------------------------------------