Newsgroups: comp.sys.atari.st
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!fauern!faui43.informatik.uni-erlangen.de!csbrod
From: csbrod@immd4.informatik.uni-erlangen.de (Claus Brod)
Subject: Re: How is Atari doing in Europe?
Message-ID: <1991Jun26.124900.5744@informatik.uni-erlangen.de>
Organization: CSD., University of Erlangen, Germany
References: <1991Jun14.010821.9903@noose.ecn.purdue.edu> <5360@syma.sussex.ac.uk> <1991Jun17.190053.7342@clinet.fi> <3283@krafla.rhi.hi.is> <1991Jun21.104233.24151@informatik.uni-erlangen.de> <3300@krafla.rhi.hi.is>
Date: Wed, 26 Jun 1991 12:49:00 GMT
Lines: 92

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

>From a historical viewpoint, TOS started off as a RAM based OS probably because
>it was still being written. It stabilised into TOS 1.0 the first ROM version.
>Since then we have had infrequent updates usually with only minor changes. A few
>bugfixes are made (sometimes in the wrong direction :-() and a few utilities
>added. Suddenly in recent times versions 2.x and 3.x appear with a few more
>bells and whistles. A completely new GDOS is arriving (in RAM of course). TOS
>and GEM almost became fossils in ROM. Some of the material in the ROM should
>(IMHO) rather be made RAM resident so that updates can be made available and
>to give better system flexibility. Manipulation of system-specific hardware
>obviously belongs in ROM but I would like to be able to load GEM when I need
>it, and reclaim its space when I don't.

TOS is making its way in just the direction you're pointing at; it is
becoming more modular. MetaDOS essentially replaces GEMDOS. GDOS is
disk-based and allows for external screen drivers. (NVDI is such a
GDOS/screen driver combo.) In fact, TOS is quite modular in itself due
to the hierarchical architecture.

If you like, you can work without GEM on your ST today. Just place a
command shell into your AUTO folder. Isn't MiNT meant just for purposes
like these?

>>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?

>Yes. The low-level stuff for this is all in place, as it should be. Only very
>recent versions have a GEM format option for other than a simple choice
>between single and double sided disks. IMHO the only sensible sector size to
>use on HD disks is 1024 bytes (except for MSDOS compatibility when needed).
>If I understood correctly, only the first and latest versions have been able to
>handle these. In which version number was it fixed?

The current TOS versions cannot handle a physical sector size of 1024
bytes. It's not unreasonable to suppose that this won't ever find its
way into TOS again due to compatibility problems. Older TOS versions
won't understand the new format. It isn't even sure that new machines
will have a 1772 built-in that offers such capabilities.

As I stated a while ago, I tested a third-party floppy driver some time
ago which offered 1024-bytes-per-sector support. I also haven't given up
the idea of writing a floppy driver on my own. It's not impossible.
The German magazine 'ST-Computer' recently had a full-featured listing
of a replacement for the standard floppy driver allowing for up to
ten disk drives connected to one ST.

>Wouldn't it be sensible to have reasonable control over disk format
>built into the desktop?

A choice between 9, 10, 18 and 20 sectors per track would be nice, yes.

>Shouldn't a decent ramdisk be included in the ROM?

Dunno. I don't like the idea very much to include such a beastie into
ROM. I would like to have some more RAM disk support in TOS when it comes
to making memory reset-resident.

>A simple text editor would not be out of place in the ROM.

I disagree. This would be completely out of place. Except perhaps as
a new GEM object type. (NeXTStep offers things like this.)

>It could be worked on in-house as a non-optimised version and then run through
>an optimiser for production. Both speed and space are at a premium even in these
>days of multi-megabyte accelerated systems (Whoever thought back then that 4 MB
>wouldn't be enough RAM). Optimisation could be made almost automatic, the only
>handwork necessary would be to mark which parts of the code must not be changed
>because they are in some way critical.

The time-critical sections are already written in assembler, especially
the BIOS and the lower screen driver routines. They could and should 
be faster, however.

>Just eliminating redundant reassignment of variables and making absolute long
>references into absolute short where possible would save enough space to fit
>STE TOS versions into older ST computers without having to move ROMbase to the
>newer (and lower) address.

D'accord again.

>Enough said for now. This is meant as constructive criticism.

And, IMHO, it is!

----------------------------------------------------------------------
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
----------------------------------------------------------------------
