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

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

Path: grafix.xs4all.nl!john.hendrikx
Date: Sun, 04 Feb 96 16:11:49 GMT+1
Newsgroups: comp.sys.amiga.programmer
Distribution: world
Subject: Re: Demo/game to OS friendly part II
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
From: [e-mail] (John Hendrikx)
Message-ID: <[e-mail]>
Organization: Grafix Attack BBS Holland

In a message of 03 Feb 96 Peter McGavin wrote to All:

 >>> 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.

 PM> I have to admit I'm skeptical about AT "adding" memory protection to
 PM> AmigaOS.  It seems to me that full memory protection would either double
 PM> the size of AmigaOS or make AmigaOS almost totally incompatible with

Full memory protection would certainly not double the size of AmigaOS (ie, the
parameter checking and the new functions added).  I'm not suggesting however to
check all parameters (although a 'checksum' could be calculated over critical
structures for 'easy' parameter checking).  But even memory protection which
just protects programs from each other by not allowing them to share the same
memory would kill our current message system.  I think copying messages isn't
as big an impact as some people think, after all, a good copying routine can
copy over 200K every 1/50 of a second.

 PM> existing Amiga software.  In the former case AmigaOS loses its size

I'm not convinced about this either.  I always found that adding memory
protection should be done ONLY for -new- programs.  These -new- programs would
have more strict rules and aren't allowed to call some of the older AmigaOS,
instead they have to use the new ones provided to basicly the same thing.  The
old programs would all get run by a special task.  This special task is
actually a -new- program which runs all the old programs.

 PM> advantage over other OSes.  In the latter case we'd might as well move
 PM> to another OS.  In both cases AmigaOS loses its performance edge over
 PM> other OSes.

I would stay with Amiga even if only 25% of all non-game software would run,
with a HUGE step like this (ie, to PPC) I think that's worth it.  Besides, a
lot of software could simply need a recompile to get back running again; the
step to PPC really requires a good recompile anyway (or be stuck with emulated
680x0 code).

Also the new software will be far superior to any of the old software so soon
you will be looking at your old software as if it was a program still using a
GUI looking like Kick 1.3.

I don't think AmigaOS could ever lose its performance edge given what's out
there, all I know is that memory-protection is a MUST for an OS which wants to
be a serious alternative in the OS market, especially one due for release in
1997.

If AT don't add memory protection in the new version of the OS they should
atleast considerably change the rules and provide new functions so memory
protection could be added easy later on.  Memory protection is coming sooner or
later, you can't go around it, so I sincerely hope AT takes this into account
now, before it truly becomes impossible to add memory protection.

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

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

They can write their own kernel just as easily, and then they can adapt it to
fit into the current AmigaOS structure more easily.  Kernels are hardly
difficult to write.  Some people even seem to think that multitasking is
somekind of obscure magic which Amiga and some other OS-es 'invented' and isn't
documented anywhere.

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

See above.

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

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

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

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

There are less radical approaches.  Myself I probably would have gone for a two
step approach.  First release a new OS, with new functions to replace some of
the 'problem' functions for a mem-protected system.  Also give this new OS a
new set of rules to ensure a smooth transition later.

This first release (OS4.0) would not be mem-protected at all (although if you
use the new allocmem functions provided you could get protected memory
already).  This first release could have parameter checking in some functions
already (especially the newer functions) but there wouldn't yet be any memory
protection.  The primary function of this first release would be to get as much
programs to start following the new rules, and use the new functions and
totally avoid the old functions which the new functions replace.  The new rules
would of course be rules designed to reduce problems with the transistion to a
mem-protected system.

Then after 1 or 2 years (ie, in 1998/99) the 2nd release (OS4.1) of AmigaOS
would have full memory protection.  At that moment NO old programs will
function anymore (ie, programs designed for OS3.1 and earlier).  The OS4.0
programs which use the new functions and follow the new rules will have a VERY
good chance to run on the new OS4.1 with mem-protection.

This gives software writers a span of 1-2 years in which they can make their
program OS4.0 compliant (so they would need to modify and recompile their
programs a bit, so 1-2 years should be quite a reasonable time-span).  OS4.0
would basicly be the OS which runs both OS3.1 programs and OS4.1 programs.
OS4.1 would only run OS4.0 compliant programs and all new programs.

 >> 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.

 PM> I can't tell whether you're talking about QBlit() or high-level gfx
 PM> functions here.  QBlit() is too low-level because it insists on poking

I'm not sure, but I think that graphics.library uses QBlit() internally for a
lot of its functions.

 PM> hardware registers.  Ability to queue high-level functions is what I'm
 PM> talking about.  In the current implementation, only one high-level
 PM> function can be queued at a time, unless the application starts a task
 PM> to process longer queues.  Why not let the OS do this and save the
 PM> programmer the trouble?

Why?  Well, I don't really see any advantage in this.  What is there to gain?

 >> 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.

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

My vision of RTG is a bit simpler.  It would be a library based system (but I'm
sure they don't have to be libraries). It would consist of 3 layers:

 * Low-level gfx-card specific library
 * Medium-level RTG library
 * High-level RTG graphics.library (ie, an enhanced graphics.library)

The low-level library would be a collection of basic gfx-operations.  Each
low-level library has the same structure, and the same function entry points.
So the 'plot-pixel' function is always found at the same negative offset.  This
low-level library would have 2 entry points for each available function.  One
for sync, and one for async operation.  It would also have a few standard
functions to query the library.

Now, the medium-level RTG library is the library which distinguishes which
low-level library the calls it gets are to be passed to.  As each function is
passed a rastport, or some other kind of structure this could be very fast.
Infact, it could be nothing more then grabbing the low-level library base out
of the structure and calling the appropriate function.  This medium-level layer
is provided however so that low-level functions not available can be emulated
by the medium-level RTG library by calling several low-level functions.

This medium-level should be documented well as programs might want to use it
directly.  The low-level libs are not to be called directly ever.

The high-level graphics library should offer you a good way to do synchronous
or asynchronous gfx on top of the functionality it provides now.

 PM> I think the system could incorporate both methods.  However a program
 PM> which uses framebuffer-allocation and direct hardware access will only
 PM> work properly on memory-mapped devices (in the right format).  It won't

Of course, the framebuffer has to be linear mapped, none of that segmented
crap.

 PM> work on things like OpalVision (which isn't memory-mapped) or networks
 PM> (except perhaps with slow emulation).

No true, but programs which require framebuffer direct access to get speed (why
use it otherwise?) wouldn't run nicely on OpalVision, or some of the segmented
Z-II cards anyway.

Grtz John

-----------------------------------------------------------------------
 [e-mail]   TextDemo/FastView/Etc... development
-----------------------------------------------------------------------
-- Via Xenolink 1.981, XenolinkUUCP 1.1