🚀 go-pugleaf

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)