NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/programmer/2641

Internet Message Format | 1996-08-05 | 5.7 KB

Path: Hermes.grace.irl.cri.nz!maths!peterm
From: [e-mail] (Peter McGavin)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Demo/game to OS friendly part II
Date: 03 Feb 1996 01:32:20 GMT
Organization: Industrial Research Ltd
Distribution: world
Message-ID: <[e-mail]>
References: <[e-mail]>
NNTP-Posting-Host: tui.grace.cri.nz
In-reply-to: [e-mail]'s message of Tue, 30 Jan 96
    18:51:40 GMT+1

[e-mail] (John Hendrikx) writes:
>In a message of 29 Jan 96 Peter McGavin wrote to All:
> PM> Personally I would like to see what seems a completely opposite approach
> PM> (for RTG).  That is, I think gfx should be implemented something like
> PM> DOS.  Gfx primitives like Draw(), SetAPen(), Text(), etc, internally
> PM> should use message-passing and packets.  The Amiga has a big advantage
> PM> over other platforms that messages don't have to be copied.
>
>This advantage is likely to go away in the near future with a new OS
>version or soon after that.  AT would be wise not to rely too much on
>these 'side-effects' of a system which is not memory-protected.

I have to admit I'm skeptical about AT "adding" memory protection to
AmigaOS.  It seems to me that full memory protection would either
double the size of AmigaOS or make AmigaOS almost totally incompatible
with existing Amiga software.  In the former case AmigaOS loses its
size advantage over other OSes.  In the latter case we'd might as well
move to another OS.  In both cases AmigaOS loses its performance edge
over other OSes.

If AT are serious about implementing full memory protection then I
think a straightforward approach is:

  o  Throw away exec and all device-drivers.  Start again with the
     kernel and device drivers from another OS like Unix, WinNT or
     some research OS instead.

  o  Tweak the interface to look as much like exec as possible within
     the constraints of full memory protection.

  o  Port other libraries.  Graphics, DOS and maybe other libraries,
     require a major redesign and rewrite because they can no longer
     use public structures.

  o  Port WorkBench, shell commands, prefs, as many applications as
     possible, etc.

OK another approach, that would be just as (in)compatible, is to
implement an AmigaOS lookalike API over Unix or WinNT.  About the only
thing that might be impossible this way (and possible by the first
approach) is the concept of multiple simultaneous Screens in different
resolutions and frequencies.

Either approach would probably take years longer than a straight port
of AmigaOS to PPC and practically all compatibility with existing
software would be lost.

> PM>     [...]Another scenario is that the application
> PM>     queues only a few, large operations, such as a single, large,
> PM>     WritePixelArray8() which operates with async DMA and uses no
> PM>     CPU time.  Thus, gfx coprocessors and DMA can be better
> PM>     utilised;
>
>The blitter is a good example of this in Amiga right now.  It is
>async, when you draw a line with the blitter usign DrawLine() there is
>no guarantee that when the function returns that the line is already
>drawn.  You have to wait for the blitter to make sure.

Yes, but I think there are several problems with the current
implementation.  WaitBlit() only waits for the Amiga blitter, so there
are problems implementing async drivers for gfx-cards with other
coprocessors.  Apps can't synchronise reliably.  WaitBlit() is
CPU-intensive for large blits.  Multi-plane operations often wait
internally for all except the last plane instead of queuing the
operation and returning immediately.

> PM>  o  Gfx redirection across networks would be relatively trivial
> PM>     (much like X11).
>
>Well, this would be none too hard even in the current system if NOBODY
>used the hardware but used the provided functions.  These could then
>be patched to pass on their info to another machine via a network.

I don't want to see network software using SetFunction().  It would be
much better for networks to plug in at the gfx-card device-driver
interface, or maybe at some intermediate layer.

> PM>  o  It is more straightforward to share the same hardware between
> PM>     multiple tasks this way.
>
>Yes, but it would also involve passing a message for each gfx-action,

I should have mentioned in my earlier post that a single message could
request many gfx operations.

>while the current system, although less straightforward can just queu
>gfx-actions in a list (some current blitter functions do this) which
>achieves much the same effect.

I can't tell whether you're talking about QBlit() or high-level gfx
functions here.  QBlit() is too low-level because it insists on poking
hardware registers.  Ability to queue high-level functions is what I'm
talking about.  In the current implementation, only one high-level
function can be queued at a time, unless the application starts a task
to process longer queues.  Why not let the OS do this and save the
programmer the trouble?

>I think RTG will do what you want just fine, what you're suggesting
>would just make things even slower although it has some advantages.

We're talking about different implementations of RTG here aren't we?
not RTG vs non-RTG.  Indeed, maybe your framebuffer allocation isn't
RTG and message-passing is!  A message-passing implementation won't
always be slower, quite often faster.

I think the system could incorporate both methods.  However a program
which uses framebuffer-allocation and direct hardware access will only
work properly on memory-mapped devices (in the right format).  It
won't work on things like OpalVision (which isn't memory-mapped) or
networks (except perhaps with slow emulation).
--
Peter McGavin.   ([e-mail])