pa1132@sdcc15.ucsd.edu (pa1132) (11/08/88)
Well, everybody is tired of waiting for Atari to improve the ST, right? Atari is hopeless. Then, why not improve it by ourselves? In the Amiga world, they have something called "ARP", short for "Amiga-DOS Repleacement Project", which some Amiga developers wrote to replace the dump Amiga DOS. Their idea worked. So, perhaps it is time for us Atari people to have a TOS Replacement Project--to write a new, but compatible operating system to replace the old brain-damaged TOS. The new operating system should be called "STOS", short for "SmarTer Operating System", meaning an OS smarter then TOS. Any comments?
keithj@ux1.lbl.gov (Keith J Groves) (11/08/88)
I for one agree with this idea. It's been far too long waiting
for Atari to get in to the act. I suggest we all pool our resources
and come up with a list of what should be considered for STOS.
There just has to be a better way.
Keith Grovesdaveh@cbmvax.UUCP (Dave Haynie) (11/09/88)
in article <700@sdcc15.ucsd.edu>, pa1132@sdcc15.ucsd.edu (pa1132) says: > Summary:a proposal > Sender:pa1132@sdcc15.ucsd.edu > Keywords:TOS, replacement project, STOS > Well, everybody is tired of waiting for Atari to improve the ST, > right? Atari is hopeless. Then, why not improve it by ourselves? > In the Amiga world, they have something called "ARP", short for > "Amiga-DOS Repleacement Project", which some Amiga developers wrote > to replace the dump Amiga DOS. Their idea worked. But make sure you're talking about the same thing. ARP on the Amiga does bascially two different things. First of all, it provides functional look-alikes for many of the AmigaDOS shell commands. The commands supplied by Amiga have a few faults -- not all handle wildcards where appropriate, they're not perfectly symmetric in their argument handling, and may of them are written in the BCPL language, which makes them large. ARP commands are written in assembly, which makes them much smaller. So floppy based users can fit more DOS commands on a disk, and everyone who uses them gets commands that operate much faster. The second thing ARP does for you, which is also another reason the ARP commands are smaller, is provide a toolbox of functions in a shared library called "arp.library". As in all Amiga shared libraries, the code for the library exists only once, no matter how many programs are currently using it, and it generally only must be loaded into memory the first time an ARP commands is used (it'll get thrown out if no one's using it and the space it takes up is needed). Anyway, the ARP library contains functions useful in writing programs that aren't provided by the supplies Amiga OS. Things like a wild card pattern matcher, a standard file requester, some resource tracking stuff, etc. So in one sense, ARP replaces part of Amiga DOS in that it replaces the DOS commands a user normally uses to interact with the machine. And the user have the source to these commands available. In another sense, that of the ARP library, ARP is really an addition to the Amiga's operating system. > So, perhaps it is time for us Atari people to have a TOS Replacement Project-- > to write a new, but compatible operating system to replace the old > brain-damaged TOS. The new operating system should be called > "STOS", short for "SmarTer Operating System", meaning an OS smarter > then TOS. Any comments? I don't know much about TOS, but if you're really planning to actually replace the ST's operating system, as in the operating kernel, not just a bunch of DOS commands on disk, you're getting into something that sounds very much more complicated that what ARP is. If that's necessary, good luck -- it probably can be done if you can muster enough support from the ST community. If it works in other respects like ARP -- you give it away and it gives you extra functionality and takes nothing away from what you already have, perhaps it'll work. -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
cmcmanis%pepper@Sun.COM (Chuck McManis) (11/09/88)
In article <700@sdcc15.ucsd.edu> pa1132@sdcc15.UUCP () writes:
[Suggests users write a new version of TOS.]
I have another suggestion that may work better in this case.
One of the reasons that ARP on the Amiga has been successful
is that a lot of the DOS internals are documented and the
technical folks are usually quick to give in depth technical
answers to developer questions. (both on Usenet and on BIX where
they reside "officially") Unfortunately a similar situation does
not exist for the ST developer community.
There is hope though, in that now MINIX is available for the ST
and it should be possible to build a window system on top of MINIX
that would be a good substitute for TOS. If TOS compatible library
calls could be implemented then you have a shot at replacing it
with something that a) doesn't require Atari support, and b) has
all or most of the source code available for it. (It is also
multitasking which is a *big* win when you are programming
window systems)
So maybe this might be an alternate tack that could yield some
quite successful results for everyone.
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.ugbernie@cs.Buffalo.EDU (Bernard Bediako) (11/09/88)
Check out NeoDesk from Gribnif... It got everything you ever wanted
in your desktop (version 2.0 not 1.0)
--
------------------------------------------------------------------------
Bernard Bediako SUNY/Buffalo Computer Science
UUCP: ..!{ames,boulder,decvax,rutgers}!sunybcs!ugbernie
Internet: ugbernie@cs.Buffalo.EDU BITNET: ugbernie@sunybcs.BITNETacm@valhalla.cs.ucla.edu (Association for Computing Machinery) (11/09/88)
In article <700@sdcc15.ucsd.edu> pa1132@sdcc15.UUCP () writes: [...] >brain-damaged TOS. The new operating system should be called >"STOS", short for "SmarTer Operating System", meaning an OS smarter >then TOS. Any comments? I have a comment. Why not adopt MINIX as that new OS? Some people could possibly write a "gem" program for it that would allow regular ST software to run compatibly. If this could be done then I think MINIX should be first on the list since: * MINIX can be succesfully used with other processors. I remember a case a while ago in which someone using MINIX replaced the 68K with a 68020. There wasn't much of a speed increase, but then I don't think he went "all the way" with the hardware (i.e. a faster clock for the CPU and for the separate board of memory and/or an SRAM cache). I guess if you had to run true-blue GEM programs you could just toggle a switch. * MINIX multitasks. I have thought about it for a while, and have come to the conclusion that in order to implement powerful networking for the ST, a multitasking OS would make things much, much easier. Of course there are other benefits to multitasking, but that is an exercise left to the reader. * MINIX already includes the source! That means that if there is a bug, YOU have the chance to fix it without waiting on anyone. Having the source to the OS also opens up other worlds of possibilities, like implementation of sockets (am I dreaming?), an added dimension to debugging (e.g. if you want to find out what the OS does during disk writes, you just look and read the comments!), a boost towards being able to make it TOS compatible, and many other advantages. * MINIX is robust. This is a second source opinion as I don't have MINIX yet. However, most of the bug reports I've seen in comp.os.minix have been pretty piddly-type things. Shake well and give time for setting of contents. * etc... For your convenience, I include here what someone in comp.os.minix had to say: > I have been using/playing with Minix for the ST for a couple of weeks > now, I think that it beats gemdos by a mile, even though it, at this point, > does not support all of the st's hardware. I have a few questions I hope [rest deleted] So far I have not come across someone that has HATED it. Will anyone who has MINIX already care to comment or provide the disadvantages? Plinio Barbeito P.S. It really would have been best for me to post something like this AFTER I had my copy of MINIX, but as long as you were asking for people's 2 cents... --- UUCP: ...!{...}!ucla-cs!acm ARPA: acm@cs.ucla.edu VOICE: (213) 825-5879, 825-7597
covertr@gtephx.UUCP (Richard E. Covert) (11/09/88)
In article <2545@cs.Buffalo.EDU>, ugbernie@cs.Buffalo.EDU (Bernard Bediako) writes: > > Check out NeoDesk from Gribnif... It got everything you ever wanted > in your desktop (version 2.0 not 1.0) > Yes, but does Neodesk 2.0 allow you to display your desktop files as text?? That lack was the reason that I don't use Neodesk 1.0. And the large amount of RAM that it uses. So, let's see how NEodesk 2.0 looks when it comes out next month (???). rc
keithj@ux1.lbl.gov (Keith J Groves) (11/10/88)
What are the differences between version 2.0 and 1.0 of Neodesk.
I have version 1.0 and it is somewhat of a memory hog in addition
to a few other peculiarities. Do you know what the upgrade cost is?
This apprently is another one of those software companys that fail
to let the users of it's software upgrades despite the registration
card you mail to them.
Keith Grovesdavid@bdt.UUCP (David Beckemeyer) (11/10/88)
If this project really gets off the ground, I would probably be willing
to contribute the work I did to develop Micro RTX. And then we could
have a Multitasking-STOS, TOS replacement.
Some of you may remember when we were considering making the binaries
to Micro RTX PD. That idea is not dead.
If there appears to be enough interested parties that want to devote
lot's of work on Gnu-type ST projects like this, I say GO FOR IT!
I think you should even try to get Atari to contribute resources
like *information*, but if they won't do that, make them give
you $$$$. They claim to have plenty of that!
--
David Beckemeyer (david@bdt.UUCP) | "Lester Moore - Four slugs from a .44
Beckemeyer Development Tools | no Les, no more."
478 Santa Clara Ave. Oakland, CA 94610 | - Headstone at Boot Hill
UUCP: {uunet,ucbvax}!unisoft!bdt!david | Tombstone, AZugwright@cs.Buffalo.EDU (Norman Wright) (11/10/88)
NeoDesk ver 2.00 has many new features, I saw the new version at the Toronto Atari fair just last weekend. Here is a list of some of the new features. Batch File Support. Move files. Faster file & disk operations. Editable Icons with edtor. Enhanced 'show as text' dsplay, can have different size text in window + more. Show without sorting, to see the real order of the files on the disk. Replace Desktop pattern with a Picture. Has a Corner Clock, Screen Saver, and Blitter control. Printer Que, you can change the order of the que. Multiple icons for floppy, hard, and ram disks plus batch and printer. Warm and Cold boot from keyboard. Takes up as little as 24K, It is larger but reduces its' self when needed. I hope this helps a little, there is much more than that but the list would be much longer. The lst price for this product is $ 49.95 I do not know about the upgrade policy. .....Storman Norman
hase@netmbx.UUCP (Hartmut Semken) (11/10/88)
In article <5196@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >in article <700@sdcc15.ucsd.edu>, pa1132@sdcc15.ucsd.edu (pa1132) says: >> Well, everybody is tired of waiting for Atari to improve the ST, >> right? Atari is hopeless. Then, why not improve it by ourselves? Yea! Right! A lot of people already started (here in Germany an in France). Turbodos seems to be an replacement for GEMDOS, David Beckemeyers RTX replaces BIOS, XBIOS (and GEMDOS?)... A german guy hacked TOS functions to act exactly like theit MsDOS counterparts.... First we need a list of (documented :-) features, we would like (my list below), later we'll just write a new operating system from it... Do not misunderstand me (if You understand my "English" at all): to build a new operating system featuring TOS compatibility, multitasking, 020 support, fast code, no bugs and so on, would take forever, right? But that would be half the time, we wait for Atari to give it to us... Well, let's try! hase -- Hartmut Semken, Lupsteiner Weg 67, 1000 Berlin 37 hase@netmbx.UUCP In a space in the forest, on an empty patch of wet ground between a circle of craning trees, appeared quietly and without fuss a plain white door.
hase@netmbx.UUCP (Hartmut Semken) (11/10/88)
In article <17702@shemp.CS.UCLA.EDU> acm@cs.ucla.edu writes: >In article <700@sdcc15.ucsd.edu> pa1132@sdcc15.UUCP () writes: >[...] >>brain-damaged TOS. The new operating system should be called >>"STOS", short for "SmarTer Operating System", meaning an OS smarter >>then TOS. Any comments? >I have a comment. Why not adopt MINIX as that new OS? >Some people could possibly write a "gem" program for it that would >allow regular ST software to run compatibly. If this could be done Very tricky! There could be just one gem task (and YUR favourite program will probably not run under the new enviroment... ) >then I think MINIX should be first on the list since: As far as I know (don't have Minix right now), Minix is no speed demon (wha do You exspect from an operating system written in C?). It could be build anew (in Assembler of course), but that will take some time... (and will not be portable anymore). First have a look at it. I like OS/9 pretty much (run it on an 020 VME BUS machine) and would like to have it on my ST at home as well... hase -- Hartmut Semken, Lupsteiner Weg 67, 1000 Berlin 37 hase@netmbx.UUCP In a space in the forest, on an empty patch of wet ground between a circle of craning trees, appeared quietly and without fuss a plain white door.
maverick@Portia.Stanford.EDU (Steve Whitney) (11/10/88)
Instead of having a completely independent version of TOS, it seems that TOS might be reformed from within. Atari claims that they don't have the resources to fix everything that needs fixing (actually, to be fair, most of it would be considered enhancements). maybe Atari could let someone come in and fix the TOS source code for a cut of any profit Atari made from it -- no risk. Unfortunately, I've forgotten the name of teh guy at Michtron who wrtoe juggler, but he seems a likely candidate. We could have a Multi-TOS which multitasks, has more that 8 windows, more that 6 desk accessories, and a reasonably fast screen device driver! --Steve
jeff@polyof.UUCP (A1 jeff giordano ) (11/11/88)
Don't we already have a replacement for TOS? MINIX by Andy Tanenbaum. Yes, i know it doesn't run regular st progs. But, who cares if i want to play a game i'll boot on the game disk. if i want to write programs i will boot MINIX. Based on my reading of comp.os.minix, MINIX is infinitely better supported by the user community, than TOS is by Atari. Geoffrey Giordano student at University known as Polytechnic jeff@polyof ...!trixie!polyof!jeff
jeff@polyof.UUCP (A1 jeff giordano ) (11/11/88)
sorry my address is: jeff@polyof.poly.edu ...!trixie!polyof!jeff I knew that it looked wrong.
rona@hpdml93.HP.COM (ron abramson) (11/11/88)
I agree that a user developed operating system is a great idea. I wish that I had enough knowledge to be of help. I can, however, make suggestions concerning improvements: 1. Increase maximum partition size and the maximum number of partitions possible. 2. Allow processes to be run in the background like the & modifier in UNIX. I hope some of you gurus make a go of it. Ron Abramson "There is nothing new under the sun." -- King Solomon
hyc@math.lsa.umich.edu (Howard Chu) (11/11/88)
In article <17702@shemp.CS.UCLA.EDU> acm@cs.ucla.edu writes: >So far I have not come across someone that has HATED it. Will anyone who has >MINIX already care to comment or provide the disadvantages? > > >Plinio Barbeito >P.S. >It really would have been best for me to post something like this AFTER I had >my copy of MINIX, but as long as you were asking for people's 2 cents... >--- >UUCP: ...!{...}!ucla-cs!acm >ARPA: acm@cs.ucla.edu >VOICE: (213) 825-5879, 825-7597 I've got it, I like it, it's really nice. But heck, I'm a Unix nut by trade and I like hacking. And, nice as the system is, it really isn't usable for much other than hacking right now. No support for the serial port yet, no real applications, nothing more than (!) a Unix programming environment. The idea of building TOS compatibility into it is interesting, since a successful attempt would yield a lot of usable applications in one fell swoop. I really dislike TOS. Really. Intensely. But many of my reasons are pretty trivial. For example, one thing that drives me absolutely nuts is using the backslash as a directory separator. I wish this were a modifiable system variable. It's so amazingly inconvenient... But also amazingly trivial. I haven't given up TOS yet, because my favorite application, Uniterm, onl;y runs under TOS. Ah well... But that's all kind of irrelevant. Minix offers a lot - multitasking, I/O redirection, inter-process communications (pipes), more flexible filesystem, other good stuff. If there was any networking hardware to speak of on the market, it'd be a cinch to turn an ST running Minix into a decent workstation in its own right. Hmm... Trying to get back to the main point... "Right out of the box," there's almost nothing for a computer "user" to gain from Minix. For a (group of?) dedicated programmer(s), it has a lot of potential. TOS, on the other hand, has an established user base, established suite of applications, etc. However, I don't see very much in the future for TOS. (What can you expect from a system that looks so much like MSDOS, another doomed dinosaur?) -- / /_ , ,_. Howard Chu / /(_/(__ University of Michigan / Computing Center College of LS&A ' Unix Project Information Systems
wheels@mks.UUCP (Gerry Wheeler) (11/12/88)
In article <17702@shemp.CS.UCLA.EDU>, acm@valhalla.cs.ucla.edu (Association for Computing Machinery) writes: > In article <700@sdcc15.ucsd.edu> pa1132@sdcc15.UUCP () writes: > >The new operating system should be called > >"STOS", short for "SmarTer Operating System". > I have a comment. Why not adopt MINIX as that new OS? I wonder if MINIX on the ST will take on the same role as OS-9 on the Radio Shack Coco. It appeared there as an exotic, third-party product. Then Radio Shack adopted it as one of their own products. Now, many Radio Shack games are released on OS-9 disks. In the case of MINIX, it has the added advantage of the source code distribution. -- Gerry Wheeler Phone: (519)884-2251 Mortice Kern Systems Inc. UUCP: uunet!watmath!mks!wheels 35 King St. North BIX: join mks Waterloo, Ontario N2J 2W9 CompuServe: 73260,1043
kirkenda@psu-cs.UUCP (Steve Kirkendall) (11/13/88)
In article <1683@netmbx.UUCP> hase@netmbx.UUCP (Hartmut Semken) writes: >In article <17702@shemp.CS.UCLA.EDU> acm@cs.ucla.edu writes: >>I have a comment. Why not adopt MINIX as that new OS? > >As far as I know (don't have Minix right now), Minix is no speed demon >(wha do You exspect from an operating system written in C?). >It could be build anew (in Assembler of course), but that will take some >time... (and will not be portable anymore). Factors that slow Minix down (at least on PCs) are: 1) The compiler that comes with Minix produces bad code. 2) The Minix kernal is divided into several tasks which must communicate with each other by passing messages. Message passing is slow. 3) The disk I/O is not multi-tasking, so the system stops processing when your disk is busy. The bad C compiler could be replaced with a better one, such as Sozobon C. The kernal could be divided into fewer tasks to reduce message passing overhead; one big help would be to compile device drivers as part of the file system task. That single-tasking disk I/O is a real bummer. One problem with Minix: It is not freely redistributable. Cheap, yes; free, no. I suspect a PD operating system would have a much better chance of catching on; can you imagine a typical Atari salesman explaining to a typical Atari customer why s/he should spend money to replace something as technical as an OS? >I like OS/9 pretty much (run it on an 020 VME BUS machine) and would >like to have it on my ST at home as well... I've tried running OS9 on my ST. Very disappointing. Microware's hard disk driver & support software don't work with my Supra drive. I managed to get it running by using somebody else's driver, but the system crashes about every hour and a half. Reliability issues aside, OS9 is EXPENSIVE. The C compiler costs $500, and other software is priced similarly. Also, OS9 seems a lot slower than it should be -- perhaps because of its redundant CRC checking, or because the kernel makes many recursive system calls, I don't know. I like the Minix idea, or a PD *NIX clone. Hey, Atari! What kind of support would you be willing to give to a project like this? Yes, I understand that you all think TOS 1.4 is the greatest thing since 3.5" disks... but DEC feels the same way about VMS, and a lot of us customers want an alternative. Please post a response. -- Steve Kirkendall
shao@ai.toronto.edu (Sherwin Shao) (11/13/88)
In article <700@sdcc15.ucsd.edu> pa1132@sdcc15.UUCP () writes: >Well, everybody is tired of waiting for Atari to improve the ST, >right? Atari is hopeless. Then, why not improve it by ourselves? >In the Amiga world, they have something called "ARP", short for >"Amiga-DOS Repleacement Project", which some Amiga developers wrote >to replace the dump Amiga DOS. Their idea worked. So, perhaps it >is time for us Atari people to have a TOS Replacement Project--to >write a new, but compatible operating system to replace the old >brain-damaged TOS. The new operating system should be called >"STOS", short for "SmarTer Operating System", meaning an OS smarter >then TOS. Any comments?
shao@ai.toronto.edu (Sherwin Shao) (11/13/88)
Newsgroups: comp.sys.atari.st Subject: Re: A proposal--TOS Replacement Project Summary: Expires: References: <700@sdcc15.ucsd.edu> Followup-To: Distribution: Organization: Department of Computer Science, University of Toronto Keywords: TOS, replacement project, STOS In article <700@sdcc15.ucsd.edu> pa1132@sdcc15.UUCP () writes: >Well, everybody is tired of waiting for Atari to improve the ST, >right? Atari is hopeless. Then, why not improve it by ourselves? >In the Amiga world, they have something called "ARP", short for >"Amiga-DOS Repleacement Project", which some Amiga developers wrote >to replace the dump Amiga DOS. Their idea worked. So, perhaps it >is time for us Atari people to have a TOS Replacement Project--to >write a new, but compatible operating system to replace the old >brain-damaged TOS. The new operating system should be called >"STOS", short for "SmarTer Operating System", meaning an OS smarter >then TOS. Any comments? The whole problem with Atari is their lack of recognition for the importance of software in the system. The success of the IBM was largely due to Microsoft's undying support, and the success of Apple is due to amazing internal software guru's and Microsoft again. A better operating system would be great. We know the hardware's potential. Magic Sac has proven that it is faster than even the Mac. But ST software itself will never amount to much. (ie, challenge IBM or Apple) Unless of course the Tramiels wake up and realize that Software IS everything!!! And then a new smarter OS will be useful. Several things can be done: 1. If Atari started giving away development info. So that all poor (but highly intelligent) hackers will be in on it. And we do know that lots can be produced by unknowns... (Yes, for free. As an investment for the future...) 2. If great PD software would be recognized and incorporated into the operating system. (ie, DCFormat can be put in place of that awful formatter in the Desktop.) 3. (you think of something, and post it!!)
Dave_Ninjajr_Flory@cup.portal.com (11/14/88)
re. wheterh Neodesk 2.0 allows displaying files on the desktop in text mode the answer is yes, on a mono system you have a choice of the 24 line and the 48 line font, also. They haven't stopped working on it and they are good conscientious folk. That was one of the first complaints I had about v1.0 and they promised the change and have made good. Gibnif and Codehead, tho' funny sounding, could well be emulated by MANY larger software companies in the areas of quality, after market support and user responsiveness. EA, no I didn't think you were listening anyway.....
"Hugh_Messenger.EuroPARC"@XEROX.COM (11/14/88)
pepper!cmcmanis@sun.com (Chuck McManis) writes: >There is hope though, in that now MINIX is available for the ST >and it should be possible to build a window system on top of MINIX >that would be a good substitute for TOS. What about X Windows? Not the worlds best windowing environment (which is, of course, the Xerox Development Environment :-), but a damn sight better than GEM. I've just got hold of Minix, and intend to investigate porting X as a (very) background task over the next year (or two, or three ..). I expect that this will be a somewhat, um, non trivial task, but it could be kind of fun in a masochistic sort of way. -- hugh
perand@ttds.UUCP (Per Andersson) (11/15/88)
In article <1226@psu-cs.UUCP> kirkenda@psu-cs.UUCP (Steve Kirkendall) writes: >In article <1683@netmbx.UUCP> hase@netmbx.UUCP (Hartmut Semken) writes: >>In article <17702@shemp.CS.UCLA.EDU> acm@cs.ucla.edu writes: >>>I have a comment. Why not adopt MINIX as that new OS? { part deleted } > >One problem with Minix: It is not freely redistributable. Cheap, yes; free, no. >I suspect a PD operating system would have a much better chance of catching on; >can you imagine a typical Atari salesman explaining to a typical Atari customer >why s/he should spend money to replace something as technical as an OS? > { part deleted } > >I like the Minix idea, or a PD *NIX clone. > >Hey, Atari! What kind of support would you be willing to give to a project >like this? Yes, I understand that you all think TOS 1.4 is the greatest thing >since 3.5" disks... but DEC feels the same way about VMS, and a lot of us >customers want an alternative. Please post a response. > > -- Steve Kirkendall Well everybody if you feel like dropping the floppy-disc OS one might consider GNU when it becomes ready. It is supposed to be a full-blown UNIX type operating system with all the utilities one might need. It will probably demand something like 1.5-2MB ram in its initial form but that might be possible to change. It has preparations to make people unable to restrict further distribution. -- WHOAMI : Per Andersson WHERE : Royal Institute of Technology, Stockholm UUCP : perand@tds.kth.se SUNET : perand@meta.sunet.se, meta::perand
david@bdt.UUCP (David Beckemeyer) (11/17/88)
In article <1184@ttds.UUCP> perand@ttds.UUCP (Per Andersson) writes: >Well everybody if you feel like dropping the floppy-disc OS one >might consider GNU when it becomes ready. It is supposed to >be a full-blown UNIX type operating system with all the utilities >one might need. It will probably demand something like 1.5-2MB ram >in its initial form but that might be possible to change. It's my understanding that GNU is a virtual memory based system. I don't think it would be possible to port GNU to the Atari ST without making hardware hacks or *major* software hacks. GNU is an emulation of a BSD type demand paging system I believe. The ST has no hardware mechanism to support demand paging (neither does the 68000 CPU). You might be able to port many of the GNU UNIX commands (some already have been ported), but I don't think you'll be able to port the GNU kernel to the ST. -- David Beckemeyer (david@bdt.UUCP) | "Lester Moore - Four slugs from a .44 Beckemeyer Development Tools | no Les, no more." 478 Santa Clara Ave. Oakland, CA 94610 | - Headstone at Boot Hill UUCP: {uunet,ucbvax}!unisoft!bdt!david | Tombstone, AZ
V61@DHDURZ1.BITNET (Ronald Lamprecht) (11/17/88)
I definitely like the idea of a TOS replacement and am willing to contribute.
But the first thing we have to do is to discuss the philosophy of this 'new'
OS (and not details or the name of it) and unify those who are willing to do
some (a lot of) work. Then those people should decide what they are willing
to do.
Therefore I will discuss 4 categories of possible replacements:
1) TOS like replacements:
a) Patching bugs, abolishing limitations, minor additions:
- the result would be the same 'doomed dinosaur (Howard Chu)'
- its not worth while rewriting everthing
- keeping parts would conflict with copyrights
- should only be done if Atari supports us/one of us with all sources
(I have no fear - they will never do it)
b) Multitasking TOS, Pipes, new Desktop,... ,but the same OS structure:
- a lot of non multitasking features will remain: what should be done
with programs that switch to supervisormode, change exceptions vectors
and ... in a legal way ? And what should be done with funny programs
that access the devices with BIOS bypass methods ?
- should GEM remain still a single task feature ?
- should we keep the brain-damaged memory management ?
- I personally hate the disk structure: 2 identically old fashioned
INTELligent FATs stored directly one after the other - once GEMDOS
succeeded in deleting both including the rootdirectory of one of
my harddisk partitions - there was no chance of a recovery,...
- To summarize: you can't really use the multitasking - you can only
try to run 'old' programs in a multitasking environment
- It would be a lot of work, but you probably couldn't port it to other
or new (I didn't say explicitly NeXT) computers. - An OS without
future.
- there may be still problems with copyrights.
2) Minix as the replacement:
I didn't receive my MINIX order yet. So I cannot go into details - but
some general remarks:
- the advantage of MINIX is the fact that it is computer and processor
independent - and that should be kept !
- a window system should be implemented for MINIX - but it should be
processor independent besides the real drivers
- I don't believe that it is possible to put a compatible GEMDOS
environment onto any other existing OS without introducing the bombs
or restricting the original features:
It starts with the problem that the OS calls may be 'identical' (same
Trap calls) and ends with the problems discussed in 1b) (supervisormode,
exceptions,VBL slots,...)
- MINIX isn't public domain - we couldn't distribute binaries. But the
average user isn't able to patch and compile sources and wouldn't be
willing to buy a new OS.
I personally will use MINIX and will make my contributions to it. But
MINIX will remain an OS for C and *NIX 'freaks' for quite a while, until
there exist not only OS utilities but real application programs. Then it
may develop to a real standard, because it will be one of the best
debugged OS.
3) New processor dependent OS with OS9/RTOS/MIRAGE/EUMEL like features and
GEMDOS as a subsystem:
Let me start with remarks concerning OS9, because it has been mentioned
by Hartmund Semken and Steve Kirkendall:
bad features of OS9:
- all Managers are a catastrophy: SCF is archaic, the RBF with it
brain-damaged disk structure and access slows down the whole system
- Unix incompatability: CR as EOL (end of line) character, standard
directory structure,make,...
- there exists 'no' software, only the 'famous' SCRED and uEMACS
editor,...
- industry prices,...
exceptional good features of OS9:
- modularity
- kernel,file-manager,driver concept
- TRAP handler concept
- resulting short codes of the OS and well written programs
Now my proposal (please read it to the very end before you judge it as
impossible):
- totally new OS based on 680xx processors (supporting 00 -- 30 + 70)
- main parts and timecritical parts in assembler (kernel,managers,drivers)
rest in C (shell,utilities)
- real mutitasking, only OS runs in supervisor mode; pipes, redirection,...
- realtime (RTOS - has anyone experience with the new RTOS for
multiprocessors ?)
- total modularity, modules may be preloaded
- all new written programs reentrant, relocatable,...
- a complete set of new multitasking OS calls
- the OS9 TRAP handler concept: TRAP handlers are modules that provide
common 'library' subroutines. They are reentrant and are therefore
loaded only once into the memory. Example Math-Traphandler: According
to your hardware (68881 or not) there exist several traphandler modules
with identical software interfaces. The compiled programs call the
appropriated loaded traphandler instead of linking its own large library
subroutines to every program. The programs are smaller and independent
from the hardware configuration !
- compatibility in binaries even to other OSs (see below), that's what
the average user needs
GEMDOS as a subsystem:
- Let us write 5 traphandlers supporting the BIOS/XBIOS/GEMDOS/LINE A/GEM.
They will make use of the more capable OS calls
- they all will be multitasking, even GEM: you will have an OS window
for each GEM program running or the output may be directed to different
devices.
- due to the fact that all programs have to work in the usermode some
GEMDOS/XBIOS calls can't be directly supported (see 1b):
Let us execute all 'clean' programs in the multitasking mode discussed
above. Let only the supervisor allow to start 'dirty' programs in a
single task mode where the status of all drivers will be saved (if
necessary a core dump could be made) first (a small shut down).
Execute the dirt and reinitialize the system afterwards.
By this method it should be possible to run all version independent
GEMDOS programs.
If you start a dirty program in normal mode the OS exception handler
will stop it when it tries to switch into supervisor mode !
- the main OS should be as far as possible UNIX compatible (slash,LF,...),
the GEMDOS traphandlers will use old fashioned backslash,CR LF,...
Future advantages:
- By the same method of traphandlers 'emulators' for other 680xx operating
systems could be added and executed in parallel - you would have
GEMDOS in one window, a MAC in another (provided that the MAC system
calls are also TRAP calls - could someone help ?). Even if other OSs use
the same TRAP calls as GEMDOS that wouldn't be a contradiction ! Every
program may call another traphandler with the same TRAP exception
(see OS9) !
This sounds like writing an VM (virtual machine) but it isn't - only the
68010/12/20/30 are VM processors and a PMMU should also be provided.
- it would also be possible to port the system to other computers (MAC,
Amiga,... and future ones !!). So the work wouldn't be in vain if
we (those who would have written the OS) would change to another
computer (provided it's an 680xx - very likely for 680xx freaks)
- there should be no difficulties with copyrights
Disadvantage:
- it's a lot of work: I think it could only be done if there are 5 - 10
freaks (assembler and C, GEMDOS,OS9,UNIX,RTOS,...) who are willing
to do a lot of work, but :
During my time at the university I disassembled the whole OS9 system
(besides the Network-File-Manager) on the search for bugs. Of course
I cannot and will not publish these listings. But long ago I started
rewriting and replacing a lot of crazy subroutines in the kernel, total
file managers, and adding a lot of drivers. There will be no copyright
on these parts and I'm willing to contribute them as well as my knowledge
and experience.
Please let us discuss and come to a decision within a few (2) weeks. A lot
of work is waiting and it should be finished before the last ST dies.
If no one else will do it, I would collect the opinions and addresses of
those who are willing to contribute.
Bitnet: V61@DHDURZ1 Ronald Lamprecht
UUCP: ...!unido!DHDURZ1.bitnet!V61 Theoretische Physik
ARPAnet: V61%DHDURZ1.BITNET@CUNYVM.CUNY.EDU (Heidelberg, West Germany)exodus@mfgfoc.uucp (Greg Onufer) (11/18/88)
From article <8811171507.AA19122@ucbvax.Berkeley.EDU>, by V61@DHDURZ1.BITNET (Ronald Lamprecht):
> [[[ ... ]]]
I have had a project on the back burner (so to speak) for quite some
time now. It may interest somebody, maybe somebody who would want to
help get it done.
What I have been thinking about was a replacement for the GEM/TOS file
system. I want to intercept the calls to all disk operations and
either 1) pass them through to TOS if they reference a TOS partition
(ie, hard disk partition formatted by TOS, or Floppy disk formatted
by TOS), or 2) use my own routines with something similiar to the
Berkeley Fast File System. The new file system routines should have
interfaces to actually make them transparent to the end user, ie. they should
keep the same 8+3 file name restrictions, and basically still read/write,
etc, the same as TOS. Only the underlying disk accesses would be different
(superblocks, inodes, buffering, 8k + partial blocks in the file system,
speed!!!)...
I can see the speed improvement being very helpful, and if done right,
programs shouldn't be able to tell the difference unless they read the
raw disk expecting it to be TOS (so Disk Doctors, etc, will fail miserably,
but that is what fsck is for :-)
I can also see many trashed hard drives while testing this beast. Which
means many backups and restores.
I was going to start this project just for the eduactional reasons, to see
if it could be done, and to make the Atari more liveable in general.
Any comments? Suggestions? (Forget the flames)
--greg
--
Greg Onufer // Focus Semiconductor // University of the Pacific
exodus@cheers.uucp (daver!cheers!exodus@Sun.COM) 415-965-0604david@bdt.UUCP (David Beckemeyer) (11/22/88)
Having written a TOS compatible multitasking operating system with
real pipes etc. and knowing that the vast majority of ST programs
cheat like hell, you're going to have a very tough time implementing
GEMDOS as a sub-layer under a "clean" OS and still maintain very much
compatibility with the current assortment of ST software. It's
possible to a certain degee, but unfortunately the system has to
have a strong GEMDOS "flavor" if you want the "not so well-behaved"
programs to work.
Again, if there really is interest in this project, I will contribute a
certain amount of the work I did to develop RTX and MT C-Shell. How
much I contribute depends on the level of support and interest this
project generates from Atari, other commercial software developers, and
the ST user community in general.
It doesn't sound like anyone's too interested in really doing this yet.
--
David Beckemeyer (david@bdt.UUCP) | "Lester Moore - Four slugs from a .44
Beckemeyer Development Tools | no Les, no more."
478 Santa Clara Ave. Oakland, CA 94610 | - Headstone at Boot Hill
UUCP: {uunet,ucbvax}!unisoft!bdt!david | Tombstone, AZejohanss@wang7.UUCP (ejohanss) (11/24/88)
it seems to me that we may have the basis for stos already. it is called st-minix. stminix is a supported product, and the source is available. all it needs is a couple of device drivers (windowing system and rs-232) and a gem compatability library for running tos programs. --- eric johansson
ejohanss@wang7.UUCP (ejohanss) (11/25/88)
In article <2579@wang7.UUCP>, ejohanss@wang7.UUCP (ejohanss) writes: > > it seems to me that we may have the basis for stos already. it is called > st-minix. stminix is a supported product, and the source is available. > all it needs is a couple of device drivers (windowing system and rs-232) > and a gem compatability library for running tos programs. > > --- eric johansson hmmm, i seam to have comitted novice mistake #152, not reading all your news before replying. Having read the arguments against using st-minix as the basis for Stos, I find that st-minix is the best possible start we can have. The prentis-hall license issue can be gotten around in a few creative ways. for example: P-H could permit limited distribution of binary images of stos perhaps on a shareware basis. If Stminix was romable, P-H could sell or license the roms. As a measure of last resort, we could distribute just the diffs that turn st minix into a tos compatable os my point is that there is no technical reason why we should not use st minix. there are some legal and license stumbling blocks but it is easier to get around them than writing a new os and file system. (not as much fun, but definitly easier :) --- eric johansson ...ima!wang7!ejohanss 508-967-6027