Contents | < Browse | Browse >



- Chris Gordon is no longer with the team, he got a job offer and had to
go.  He used to be the design coordinator.

- Chris Yiannias will lose his connection soon, the old WWW site
( is obsolete and just contains a link to the new
site.  Also this site has been unavailable for ftp for quite some time now.

- Philippe Brand is the new WWW/Net coordinator.  The site has been up for
quite some time now:

  These WWW pages are mainly kept up to date by me.  A log of changes to
these pages is available from the main page.

- A German mirror of the WWW pages is availabe:


  An US based mirror will be available soon.

- Olaf Barthel is the new design coordinator.

- Maarten ter Mors has been very busy with other things, he should be
available again soon.

- Version 3.0 of the memberdatabase is available at the WWW/FTP site.


There is a lot of confusion about the status of the project, as can be seen
on the mailinglist.  The votes have determined the following:

- We will make a binary compatible clone of the OS, which should mean that
all _properly_ written programs should run on Amiga hardware.  More on this

- Memory protection should be added where possible.  It will not be
required, and can be turned off.  Under the existing OS it's impossible to
have full protection, and only new programs specifically written for it
will benefit to some extent.

- Virtual memory should be supported by the OS.  Again: old programs will
not benefit (an external program like a new version of VMM should provide
that) but new programs asking for it will get it whenever possible.

- Resource tracking: only available to new programs.  Having resource
tracking for old programs is very likely to break them.  It may be possible
to 'promote' some of the existing programs though, but we'll see about that

- Multiuser support will be added.  (comparable to what muFS does, but with
a little more security).  Having multiple concurrent users on the same
system can never be safe, but the files on the system should be rather safe
this way.  It is also very good for networking and multiple configurations
for programs.  Again it's possible to turn the multiuser support off, all
programs/files will then be executed/owned by root.

For a thorough discussion on the issues above, please read the IRC log.
It's available at the FTP/WWW site.

The OS will be able to run 'old' properly written programs on the Amiga
hardware *only*.  Other systems will never be able to run these programs,
unless these programs are modified and recompiled.  (Modifications required
should be small, like the Execbase offset can't always be on address 4 on
other systems).  We also planned to have very strict programming guidelines
to ensure compatibility between different systems.  Hardware hacking is
considered illegal.

The current API will be retained, improvements can only be made through new
interfaces in the API.  New features shall not break old programs that are
written properly.  Programmers using old API calls that can be considered
obsolete will be pushed very hard to remove these calls from their


Busy forming a team to work on the core of the system.  Hardly any design
is needed for this, since it's basically copying the API and writing the
underlying routines.  The only real design required (and that's true for
all of the OS) is the adding of new features.  Ofcourse, any designs are
appreciated for this, but these should fit the guidelines in this text.

This core (think of something like the bootstrap, expansion.library,
exec.library, dos.library and all other things required) is the base of the
system.  What it does is allow us to develop further on this core.

The core will:

- install some code that survives resets, if possible
- recognize the hardware of the system running on
- mount any filesystems available
- access the boot-filesystem to obtain the files it needs
- install available drivers
- bring the system to some sort of a default hardware state supported by
  all platforms commonly used
- start the 'real' booting of the system (execute s:startup-sequence)


- The language to use is ANSI-C.  *Only* code that can't be written in
ANSI-C should be written in assembly.  Optimizations can always be done
later, it's more important to have it working first and have the code as
portable as possible.

- All this talk about Object-Oriented programming is very nice, but it's
only possible to add an OO layer later on, otherwise the programming for
the OS could only be done through some specific language like C++.  OO can
and will be supported through things like BOOPSI.

- On the mailinglist people are talking about having intermediate code
created by some sort of compiler.  Upon installation this code should then
get it's final compilation stage for the specific target machine.  This is
currently not an issue, it can always be dealt with later, and even better:
Vidar Hokstad is already working on such a system.  Read the SDE files
available at the ftp site for more information.  Vidar should have some
initial testing done soon, by the way.

- As soon as we're able to establish contact with Escom, we'll see about
working with them on this project.  Several options are available, and any
or all will be considered.

The AMIGOS Announce mailing list   Post messages to:

To unsubscribe send mail to:
In the message the line    : delete <your email address>

Ideas           :
Submissions     :
Administration  :
Informationpack :