Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!ucbvax!DHDURZ1.BITNET!V61 From: V61@DHDURZ1.BITNET (Ronald Lamprecht) Newsgroups: comp.sys.atari.st Subject: A proposal -- TOS Replacement Project Message-ID: <8811171507.AA19122@ucbvax.Berkeley.EDU> Date: 17 Nov 88 15:59:55 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 166 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)