Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!samsung!rex!ukma!hsdndev!cmcl2!uupsi!sunic!isgate!krafla!adamd From: adamd@rhi.hi.is (Adam David) Newsgroups: comp.sys.atari.st Subject: Re: How is Atari doing in Europe? Message-ID: <3300@krafla.rhi.hi.is> Date: 26 Jun 91 06:42:02 GMT 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> Organization: University of Iceland Lines: 81 Thanks Claus for stating a different side to what I said. In restrospect I see that some of my wording was not entirely clear. csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) writes: >adamd@rhi.hi.is (Adam David) writes: vvvvvv >>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? I think a little explanation is in order. Maybe junked was a rather unwise choice of words. The point I intended was more in the sense of recycling. I sincerely believe that both TOS and GEM have outlived their allotted lifespan as the central OS foundation in ROM (where indeed they take precious space and considerable chunks are often replaced by RAM resident routines anyway). I did not say they had outlived their usefulness. I'm sorry if I implied that. To put things in perspective I still use CP/M on Z80. I don't get rid of a thing which still has some use in it. 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 usable. TOS is useful. >And personally, I think GEM is a real gem. It has all the potential >to rival the MacOS. >And with the advent of Atari Unix we also have a full-featured SysV.4. >Think about it. Nice stop-gap :-) :-) :-) [explanation: In a few years time look back with nostalgia and say "I still use Unix"] >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? Wouldn't it be sensible to have reasonable control over disk format built into the desktop? Shouldn't a decent ramdisk be included in the ROM? A simple text editor would not be out of place in the ROM. >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. 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. 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. Enough said for now. This is meant as constructive criticism. -- Adam David. (adamd@rhi.hi.is)