rhealey@digibd.com (Rob Healey) (05/20/91)
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-9020bdb@becker.UUCP (Bruce D. Becker) (05/24/91)
In article <1991May20.050025.29148@digibd.com> rhealey@digibd.com (Rob Healey) writes: | | 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: |[...] | 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. On the other hand, it sure would be nice to have a reasonable porting base for AmigaDos application code. DpaintIII under Unix would be pretty interesting... Also, a lot of problems you discuss are already handled well by AmigaDos system constructs. The implementation of Resources would be very useful for example. I do agree however, that cloning Intuition will be, uh, daunting... | 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. Well I assume they're busy working on MS-DOS and AmigaDos file systems, etc. etc. - right, guys? Or do we PD types have to do that stuff ourselves too?... | 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. "MGR" is a PD window system from Bell labs - it's available on a lot of systems. It seems to have a great deal of functionality - its method uses the concept of an extended console driver with escape codes to handle the window stuff, rather similar in part to AmigDos CON: device. It's easily connected too, just the ticket for porting to AmigaDos and using the serial port... -- ,u, Bruce Becker Toronto, Ontario a /i/ Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu `\o\-e UUCP: ...!utai!mnetor!becker!bdb _< /_ <--- net.gumby having a vowel movement
logan@netxcom.netx.com (Jim Logan) (05/25/91)
In article <1991May20.050025.29148@digibd.com> rhealey@digibd.com (Rob Healey) writes: # # 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? Actually, that was my next project after porting g++. I wanted to make some noise on my Amiga, and since Commodore won't let me install a device driver of my own making, I was going to make a daemon. I was kindof thinking of taking NeXT's approach to device drivers. # 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. Agreed. # 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. Pretty much what I had in mind. # 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. I don't have much interest in AmigaDOS compatibility, unless I can run commercial software, al la Apple's Finder-under-A/UX. THAT I would pay money for! (Are you listening, Commodore?) # 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. Even if Commodore doesn't want to help with something like that, I am interested in doing the design AND implementation with input from others. # So, what can we do NOW to avoid a nasty, obfusicated, # uncooperating mass of Amiga specific code in the future?? Let's define what low-level functionality we want and how it should work via a mailing list. My machine isn't fit to handle the list and Usenet News, until /dev/ser is fixed. Can anyone else start a mailing list for this? -Jim
ahh@moji.uucp (Andy Heffernan) (05/26/91)
In article <104379@becker.UUCP> bdb@becker.UUCP (Bruce D. Becker) writes: >In article <1991May20.050025.29148@digibd.com> rhealey@digibd.com (Rob Healey) writes: [...] >| 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. > > "MGR" is a PD window system from Bell labs - > it's available on a lot of systems. It seems Minor correction -- MGR is from Bellcore, not Bell Labs. -- $BJ8;z(J Andy Heffernan This is Unix ( )- ahh@moji.uucp (uunet!glyph!moji!ahh) This is your brain on Unix (o)- Any questions?