Conference hydra::amiga_v1

    Hi,

    Pretty new to the Amiga myself but I'll try to answer your questions,

    Kickstart is the low level operating system code (i.e. the stuff not
    dealing with providing the user with a text or graphical user
    interface). Kind of the operating system kernal. In the A1000 it was
    loaded into RAM from a floppy but in the new 500 and 2000 machines it's
    in ROM (which although allowing for faster boots makes upgrades a bit
    more tricky). Intuition is term for the graphical user interface the
    Amiga makes use of (along with that component of the system software
    that supports this interface). Intuition is a WIMPS interface like the
    MAC or SUN. Ordinary user programs can make use of the intuition stuff
    to provide a consitent style across operating system and applications,
    and hence Intuition is not the Amiga operating system. Another layer of
    software can sit on top of the Intuition stuff, and this is the
    Workbench. The Workbench is a high level graphical interface to the
    Amiga operating system and it makes use of Intuition and what can be
    considered the actual Amiga operating system, AMIGAdos. Amigados is the
    operating system for the Amiga in the same way that MSDOS is the
    operating system for PC-clones. It performs the similar kind of
    functions (but throws in multitasking as well). Amigados itself makes
    use of the stuff in kickstart.

    Hope that's sorted out the operating system question a bit. Oh yes, and
    kickstart, amigados, intuition and the workbench all come as standard
    with all Amigas (along with a whole lot more !).

    As for what you need to make it productive - well that's a pretty big
    question but for me the first major purchase which I felt I just had to
    make to use the machine was an additinal 3.5" disk drive. I personally
    do not feel that the Amiga is a 'useable' machine with out two drives.
    Additional memory is nice but I think you can get along with 512K. A
    hard-disk really can make the Amiga a productive machine but you can
    probably live without one (like me).

    Anyway hope that helped,
	Colin.
    

    Yes to all your questions.  This is a little tricky, so please bear
    with me, and others active in the notesfile are welcome to correct
    my mistakes.
    
    The Amiga operating system has no overall name.  It comes in three
    parts:  AmigaDOS, Intuition and CLI.  AmigaDOS is the basic disk
    operating system, derived from an English OS called TRIPOS.  Intuition
    handles the great bulk of system tasks, including graphics.  The
    Workbench is the icon and menu-driven screen you use on top of
    Intuition.  Finally, the Command Line Interface (CLI) is a
    text-oriented command shell much like the Unix shell, the MS-DOS
    command interpreter, etc.  The pieces are not strictly layered on one
    another, but use each other in interesting ways. You can use the
    desktop or the CLI, or both together, depending on your preferences. 
    
    The Kickstart ROM (was a disk in the Amiga 1000) holds the DOS and
    some of Intuition.  The rest of the OS is loaded at boot time from
    a "Workbench disk."  All commands are disk-resident, i.e. commands
    like DIR and COPY are not permanently loaded, but must be read from
    disk with each use.
    
    All of the above comes with the machine except for CLI documentation,
    which is found in a separate book published by Bantam.  Full software
    technical documentation is published by Addison-Wesley.  OS upgrades
    have cost $15 in the past, but will undoubtedly be somewhat higher
    now that Kickstart is in ROM.
    
    Oh, yes, the Amiga does multitasking.  In fact, except for games,
    99.9% of all programs on this machine coexist quite happily.
    
    As for your question on what is needed to be productive, please
    expand on what you want to do with the machine.  Microsoft BASIC
    and three editors come on the operating system disks, as well as
    demo programs and some utilities.  Application software, development
    software and games in any category are probably available, though
    from fewer sources than for the IBM PC or Macintosh.  Software prices
    are comparable to those for the other machines.
    
    The best way to find out more about the machine is to visit a dealer,
    see the machine in action and borrow Commodore's promotional videotape.
    What area do you shop in?  Then come see one of us Amiga fanatics...
    An Amiga 500 with internal drive and 512K RAM, plus a color monitor,
    can be found for under $1000 almost anywhere.  

    Hope this answers some of your questions.
    
    Wes

    Thanks for the quick and useful responses.
    
    As to the "Productive" question - you actually answered it by pointing
    out that Amigados,kickstart, Inuition, and Workbench come with the
    system. I guess I had assumed that they might need to be bought
    separatly, and therefore, I was asking you to tell me which I needed
    in order to work easily with the machine.
    
    By productive, I meant that, for example, without VMS (or UNIX),
    I would be pretty unproductive with a VAX. Once I get VMS, then
    I can do anything I want - every other product I would need can
    be layered onto VMS, but they would be useless without VMS.
    
    			Gregg

    re: .3
    
    Ah yes... the traditional ibmpc market, OS for extra $$$.
    
    The low end has traditionally liked proprietary OS, preferably burned
    into ROMs.  The Amiga sort of has half of the OS on the workbench disk.
    The essentials are in ROM on the 500/2000.  The loadable libraries,
    device drivers, fonts, etc. are on the workbench disk.
    
    A "useful" system is generally 2 3.5" floppy disk drives,
    512K-1MEG RAM, and an Analog RGB monitor.  At least that seems to
    be the current default configuration most software expects to see.
    
    -Dave

Re: .2

I really like Wes's response: he hit the nail on the head when he said
the it is the "OS with no name."  Probably, most people call the Amiga's
operating system "AmigaDOS"  (this the name most popular with people
who know better).  The second most popular name is probably "Kickstart"
followed by that distant third "Workbench."  I have even heard some
people use the name "Intuition" as the name of the OS, but the general
consensus is that such people are confused (but hey, why should they
be any different from the rest of us).

However, I disagree about Wes's taxonomy of the part of the OS, so I'll
kick off the "How do you think the Amiga's OS is divided into parts?"
contest.

This is no small problem.  The designer's of the Amiga's software very
early adopted a very elegant grand design.  They viewed an operating
system as a collection of co-operating tasks that communicate and
divide up the work by passing "messages" to each other.  For example,
a PRINT statement in BASIC results in a message being sent to a file
system task who determines the physical layout of the file on the
disk.  The file system task in turn send a message to a device driver
task that knows the detains of reading and writing physical blocks
on the I/O device, but doesn't know anything about the structure of
files on the disk.  Similarly, various interesting events like
menu selections or clicking on a window gadget result in messages
being passed through the system.

The advantages of such a design is that it is very modular with
clean interfaces between different components thus allowing components
to be replaced or upgraded easily.  It also provides hooks that
applications can use to fit cleanly into the system.  For example,
consider those "macro" utilities popular with all brands of pcs.
These applications allow the user to record keystrokes and play
them back on the touch of a function key.  On most pc operating
systems, these programs do pretty dirty things to the system.  They
usually lobotomize part of the operating system and use undocumented
interfaces to pass information to other parts.  On the Amiga, a
process can request to be placed in the message chain between all
of the low level input events (like a key press or mouse click)
and the part of the system that assigns meanings to those events.
That process can then look at all the key presses, treat whichever
ones chooses specially, and pass all the others, plus any it generates
itself, on to the rest of the system for normal processing.

All of this is fine, but it means that your operating system becomes
a collection of tasks instead of some monolithic piece of software
that you can point a finger at.  It also means that it is hard to
tell those pieces of the operating system that are essential from
the luxuries.  For example, if you don't think being able to use
certain I/O devices is essential, you could consider that their
drivers (and in some cases, their file systems!) are not part of
the operating system.  If you don't like windows and gadgets, you
don't have to consider the window manager (Intuition) part of the
operating system.  If you only cared about windows and low level
I/O through interprocess communication, you could even consider
the part of the system known as AmigaDOS proper to be extraneous!

Anyway, here is how I divide up things:

The Exec.  This is the lowest level of Amiga software.  It contains
the system routines used for message passing, memory management,
system hardware configuration, and task scheduling.

The Graphics library and Intuition.  Together these make up the
windowing and user interface portion of the system.  The graphics
library controls the Amiga's custom graphics hardware and implements
Quickdraw-like graphics routines.  Intuition manages windows, menus,
gadgets, and the like.

Various Exec device drivers.  These drivers are accessed via messages,
and control various physical and abstract devices.  For example,
the floppy device driver controls the floppies on the system, but
the "narrator" device accepts strings of phonemes and "writes" them
by converting them to spoken English using the Amiga's audio hardware.

AmigaDOS proper.  This layer of software is the conceptually highest
on the system as it provides the filesystem and top I/O layer for
the rest of the system.  It provides about 20 routines.  Most of
these routines deal with I/O, but a handful deal with AmigaDOS processes
(which is an Exec managed task with some additional status information).
The command line interface and its associated utilities I lump in
with AmigaDOS because they were written by the same outside company
and the CLI is very tightly tied to some peculiarities of AmigaDOS.
I also lump in the DOS device drivers because the make up the file
system and convert high level I/O routines into commands to Exec
device drivers.

The Workbench.  This really just a normal Amiga application that is
a Window-Icons-Menu-Pointer command "shell" to the system.

The other stuff.  The Amiga contains lots of dynamically loaded shareable
libraries to perform all sorts of useful functions.

I left something out of my .5 message.  I don't consider Kickstart
to be any particular piece of the operating system.  Kickstart is
a collection of all the parts I talked about .5 in a ROM image (a
real ROM in the new Amigas, write-protected memory in Amiga 1000s).

The Amiga's OS is written in such a way that you don't have to know
if parts of it are memory-resident or pulled in from disk.  Kickstart
contains enough of the OS that the machine would be able to run
without any additional operating system files from the disk.  For
example, the ROM contains a font or two so you can see text, but most
of the Amiga's fonts are stored on disk.  The CLI and workbench
are stored in ROM, but the utilities they call are on disk.

    re .6

    >The Amiga's OS is written in such a way that you don't have to
    >know if the parts of it are memory-resident or pulled in form disk.
    
    The parts wich will be pulled from disk, are they loaded at boot
    time? Or on a 'when needed' base?
    
    The first is for me the most sensible because the seconde methos
    will result in loading all kinds of information from disk at  the most
    unlikely moments. This results in a lot of frustration on the side
    of the user. With the first method you can build your one copy of
    the OS depending on your needs.
    
    This discussion about the OS is very intressting, as I like to know
    as much as possible about the various OS's on different computers.
    
    regards,
    
    Renato.
    

    Re: *.5; *.6
    
    Randy, I've been following these notes for a while now, I've said
    it before, I might have to say it again: You ought to write a book!
    
    Tim 8^)

    re: .5, .6
    
    Better than I could ever have said it!
    
    re: .7
    
    >The parts wich will be pulled from disk, are they loaded at boot
    >time? Or on a 'when needed' base?

    Apparently some of each.  The absolutely necessary stuff, and anything
    in the file s/startup-sequence are loaded or run at boot time. Commands
    are always run from disk.  Support libraries needed to run programs are
    loaded when needed, but may later be unloaded if more RAM space is
    needed by a task and the library in question is not currently being
    used.

    Add to this the RAM: disk feature, which turns RAM into a virtual disk,
    and the recent program REZ, which allows commands to stay memory
    resident.  Confusing, eh? 
    
    Wes

    

    Speaking of Libraries, I'm sure that most of you know that a library,
    once loaded into memory, will remain there until some other application
    needs the space and kicks it out.
    
    One little known trick for purging libraries is to load WorkBench
    with the argument 'debug', ie;
    
    LoadWB -debug
    
    from your startup-sequence.  Now, when Workbench is loaded, there
    will be a fourth drop down menu. The second item in the menu is
    FlushLibs.
    
    Ed.

    Speaking of Amy's operating system, I've read several articles
    describing 1.3; they all seem to suggest that Commodore will release
    it early this year.  Has anyone seen it offered publicly yet?

Re: .7

As other people replies have stated, the disk resident parts of the OS
are pulled into memory as needed, but once there, if free memory permits,
they stay there.

In general though, this dynamic loading isn't much of a problem even
for one disk owners.  The AmigaDOS keeps track of disks by their volume
ID.  The volume ID is the volume name of the disk plus the time in
microseconds that the disk was named.  So each disk has a unique name
that the operating system can use to identify it.  Anytime an attempt
is made to read or write a volume that isn't in a drive, the operating
system puts up a "requester," a little window telling you to please
insert volume <whatever> into a drive.  So, occasional prompts to
insert the system disk back into a drive aren't very intrusive.

This I/O error requester is controlled by the low level parts of
AmigaDOS (I am talking about AmigaDOS proper, the file system layer,
in this case).  These requesters give the user the option of correcting
the problem and continuing onwards or giving up an canceling the operation.
Since all of this is invisible to the program that was doing the I/O, if
the user successfully corrects the problem, the program never sees
that anything ever went wrong.  If the user selects "cancel," then
the system returns an appropriate failure code from the I/O system
call to the program.

All of this is a very nice feature.  For example, occasionally when
working on a large program with many modules, I will manage to completely
fill up the disk in the process of recompiling everything.  At that
point, the system will put up a "Disk full.  Continue  Cancel"
requester.  At this point, I can take my time, browse through the files
on the disk, and see what files I can delete or move to a different disk.
Since the system is multitasking, I may format a new disk to hold the files
I wish to move.  I might look at some files using the editor, or diff
different versions of the files.  When I finally finish freeing some
space on the floppy, I can click the mouse on continue, and the compiler
will continue writing object files as if nothing had happened.  It's great!

    re flushlib...I also seem to remember a program to do the same...
    
    yup...see mvcad3::user0:[amiga.usenet]flushlib.sh  (a unix shar
    file)    
    
    aint multitasking great!
    
    scott.