Path: utzoo!attcan!uunet!cbmvax!jesup
From: jesup@cbmvax.UUCP (Randell Jesup)
Newsgroups: comp.os.minix
Subject: Re: Amiga version of Minix
Message-ID: <5704@cbmvax.UUCP>
Date: 17 Jan 89 01:34:59 GMT
References: <22766@pbhya.PacBell.COM> <1877@ast.cs.vu.nl> <299@wn2.sci.kun.nl> <3663@cs.Buffalo.EDU>
Reply-To: jesup@cbmvax.UUCP (Randell Jesup)
Organization: Commodore Technology, West Chester, PA
Lines: 87

In article <3663@cs.Buffalo.EDU> ugkamins@sunybcs.UUCP (John Kaminski) writes:
>In article <299@wn2.sci.kun.nl> janhen@wn2.sci.kun.nl (Jan Hendrikx) writes:
>>I wouldn't call the Amiga 'poorly documented hardware'. There is
>>something called '(Commodore-Amiga) Hardware Reference Manual',
>>published by Addison/Wesley, that contains (almost) all information
>>you normally should not want to know. And besides, the Amiga already
>>has a proper multitasking operating system.
>>
>>-Olaf Seibert
>
>I agree that C-A has the Hardware Ref. and that *should* point out all the
>necessary details to get any OS ported.  I have not had the fortune of laying
>my eyes upon this doc, but if it is anything like the manuals I *DO* have,
>it may be quite cryptic or incomplete in its presentation.  For instance,
>after reading over the (fairly thick) Libraries and Devices doc, the
>serial.device docs are the only ones (that I remember anyway) that mention
>that the I/O request block is returned not only by the I/O call itself
>(by referencing through the pointer it is handed and depositing the results
>there) but also to the message port mentioned in the I/O request block.
>I'm not entirely sure, but I'm pretty sure all the device handlers do that,
>but the serial.device is the only one that mentions it explicitly (again, the
>only one that I recall that mentions it).

	The hardware manual has everything you need to know about the hardware.
The discussion of devices assumes you've read the Exec section on how IO
devices on the amiga work, the individual chapters on each device mainly
outline the differences, and give examples.

>I also agree that the Amiga has a multitasking operating system.  What con-
>stitutes "proper" is all relative.  If you are looking for just
>anything to run the machine, fine.  If you would like to be UNIX (tm)
>compatible, you must opt for something else.  I wonder if you have program-
>med with Lattice C at all.  The lc.lib has all sorts of UNIX-like calls,
>but, of course, they are not true UNIX.  For example, there is an open()
>call, but you must hand it a legal AmigaDOS filename.  A UNIX filename like
>"../userdata/mydat.txt" simply won't do.

	So?  It's not unix, and doesn't pretend to be.  We offer Sys V.3 Unix
for the Amiga (requires A2620 68020 board with MMU).  The Amiga OS is, however,
realtime; it can do a number of things better/faster than unix can.  This is
required to get reasonable performance on a 68000, and the LWPs (light weight
processes) make writing multi-tasking programs much more feasible.  In return,
it is more vunerable than a protected unix to poorly written programs (and in
the early releases (1985), the OS - certainly no longer true).  This is more
a factor of no MMU than OS design, though.  What happens with ST Minix is
a program goes off with a stray pointer?

	Sure, Lattice C has a Unix-like library.  So does every ANSI-compliant
compiler I know of.  Very very few that don't run on unix would handle unix
file names.  If you make assumptions about where things live on unix, such
things will break on different Unixes as well.

>  Also, UNIX is superior in many ways,
>the least of which is that any program may be asynchronously aborted or at
>least signalled that an abort is desired, compared to just setting one of the
>signal bits in the Amiga task control structure (it must always be polled).

	An amiga program must release it's own resources.  This is because
full resource tracking was considered too expensive, and a headache when
resources may be passed from task to task.  You don't have to poll signal
bits, you can have them cause exceptions to execute (ala signal handlers
in unix).  Caveat is that exception handlers can't modify the process state
too much, or call many OS functions, since the main process may be in the
middle of an OS call, and have resources locked.

>I imagine the only major thing you would lose (at least until someone hacks
>a solution) is the nice window and screen system (For the non-Amiga-ites on
>the net, Amiga's graphic interface, Intuition, maintains virtual screens of
>any hardware-legal composition (resolution, colors, etc.) that can be
>"dragged" up or down, being rendered in layers.  This means if you have a
>screen with twice the vertical resolution (interlaced mode) pulled down
>half way on the workbench (default) screen, you will see half a monitor of
>regular screen and half a monitor of interlaced screen.  This is really nice
>in many circumstances).

	Screens (virtual displays that can be depth arranged and dragged)
are a wonderous concept, and make a windowing system much nicer (and less
cluttered).  You'd also lose all use of 3rd party hardware (though you MIGHT
be able to hack up an equivalent to the expansion.library, that configures
expansion boards, to get ram into the system.)  3rd party drivers would break,
so no HD, no serial ports, etc.  You'd be in the same position as our Unix
port team: having to write everything from scratch (I think they should have
made the unix kernal run under (a slightly modified) version of exec, etc.  But
that was their groups decision.  It does reduce interactions.)

-- 
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup