Newsgroups: comp.unix.amiga
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!sdd.hp.com!wuarchive!uunet!digibd!rhealey
From: rhealey@digibd.com (Rob Healey)
Subject: Standards for /dev/amiga and Co.
Organization: DigiBoard Incorporated, Eden Prairie, MN
Distribution: na
Date: Mon, 20 May 91 05:00:25 GMT
Message-ID: <1991May20.050025.29148@digibd.com>
Sender: rhealey@digibd.com (Rob Healey)

	First, for the many Dorephores and pedants out there who have gotten
	ruffled feathers over my use of the word Amix in place of the
	rather wordy Amiga System V Release 4.0 Version 1.x UNIX I
	shall use the phrase "Amiga UNIX" from now on despite bitter
	protests from my fingers. B^).

	Now, up on my philosophical soap box I go:

	I realized today that our AmigaDOS brethern, and sisteren, have
	one very important advantage over us poor Amiga UNIX souls:

	Standard methods, API if you wish, of accessing and controlling
	Amiga hardware so nasty interference doesn't take place betwix'd
	tasks.

	What we need is a standard set of library functions, maybe in
	/usr/lib/libamiga.{so,a} for controlled and simplified access
	to /dev/amiga. If there isn't a standard put out by C= then
	all of us will end up creating oodles of different "standards"
	and that will require grand reunification at some painful point
	in the future. 2.0 seems to be a good place to start a standard
	for safe access to /dev/amiga by multiple programs.

	Some thoughts:

	1) Sound, speech and video "servers" would sit in user, kernel
	   or a mix of both modes and listen on IPC ports for requests
	   to do something. They would prevent processes from stomping
	   on each other when it comes to /dev/amiga access. If a user
	   didn't need to use /dev/amiga toys then they wouldn't
	   start up the servers and take the performance hit caused by
	   the servers real time nature. Maybe the real time/configurable
	   scheduler in Amiga UNIX could be used here too?

	2) A library would provide the way to access /dev/amiga features,
	   a program wouldn't be aware that the lib was mmap'ing
	   /dev/amiga and doing the necessary bookkeeping. From the
	   program point of view this would all look like neat little
	   function calls.

	3) It would probably be best to implement all this on top of
	   /dev/amiga so that no more kernel or system hooks are
	   needed. Maybe a "super server" could do the mmap call
	   on /dev/amiga and then take IPC requests from the
	   Amiga library code.

	4) We should avoid trying to create an AmigaDOS compatability
	   library since this would probably create a complex monster
	   that's a bugger to maintain. Rather, a basic set of functions
	   should be drawn up and put into the library. Obviously
	   graphics and sound are the two main catagorys. Under sound
	   we have music, noise and speech. Under graphics, the
	   various modes and graphic operations. Initially, create
	   the most basic functions that can be used to build
	   complex stuff. Maybe make it, "object oriented". If we
	   can define the basics for 2.0, then later releases can
	   add increasingly higher level functionality.

	   So, what do people think? Should we create some common
	   interface to /dev/amiga so a buzillion uncompatable
	   programming interfaces to /dev/amiga don't arise?

	   Can C= take the lead? Maybe provide guide lines and a
	   very basic library, for starters, in 2.0 Amiga UNIX?
	   Later versions of the OS could slowly build on the
	   basic library routines.

	   X provides some graphic solutions to problems but it
	   seems like a less bulky way of accessing Amiga hardware
	   should be available. Plus, there's no sound, music or
	   speech capability in X.

	   So, what can we do NOW to avoid a nasty, obfusicated,
	   uncooperating mass of Amiga specific code in the future??

	   Pondering yet more Amiga mysterys,

		-Rob
-- 

Rob Healey                                          rhealey@digibd.com
Digi International (DigiBoard)
Eden Prairie, MN                                    (612) 943-9020