Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!lth.se!kberg!svante
From: svante@kberg.se (Svante Gellerstam)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: OS Graphic Card Support: Part II!
Message-ID: <1991Feb13.203535.343@kberg.se>
Date: 13 Feb 91 20:35:35 GMT
References: <28532.27b759c9@kuhub.cc.ukans.edu>
Organization: Karlberg & Karlberg AB, Lund, Sweden
Lines: 107

In article <28532.27b759c9@kuhub.cc.ukans.edu> 2fmlhiccup@kuhub.cc.ukans.edu writes:
>A)  The graphics that come with the Amiga currently are wonderful for many
>users that would not want to pay extra for 24-bit graphics standard.

The standard in itself is not expensive - the actual implementation
is. Ie: the machine can be prepared to use 24-bit gfx, but might not
be equipped with it. 

>B)  There are users that want and need 24-bit graphics and shy away from the
>Amiga because it does not support higher graphic modes that are not standard,
>but can be added on via a card.  
>
>The problem is that because there is no real option to improve the graphics on
>the Amiga, people consider it inferior to other computers that do.  If the
>Amiga OS is not written to support better graphic modes with standardized
>libraries, then it is really pointless to buy a graphics card.

All current implementations (bar a rare few) of gfx cards for the
Amiga are niche implementations, solving specific problems. They
provide what people need in a few branches of the market.

Presently there is nothing for the rest of us - better gfx, or rather
the possibility to better gfx, for the majority of the software.

>Why isn't the OS being improved to handle higher resolutions/ more bitplanes,
>etc?!?!

It draws resources to design and keep a standard up to date. The only
single party in the market who can device a standard for this is
Commodore and they have a lot to do right now. Maybe there is not
enough resources to research into the subject?

Whatever the answer might be, it will cement the current approach to
handling gfx on the Amiga. This is sad because a lot of good cards
exist, but cannot reach the masses (and the low Amiga friendly prices)
due to the lack of a generalized interface.

The importance of a standard software interface towards the system can
be studied in the hard disk arena... In the beginning all HDs were slow
and expensive; with FFS, HDs became expensive(ish) and fast; now hard
drives are approaching the same prices as for other platforms, but are
generally a lot faster.

A well defined software interface lets the HW developers concentrate
on HW design, without the worries of small series, special solution
and software designed from scratch.

>Solution (IMHO)
>   Have all graphic card developers include a STANDARDIZED method of
>communicating to the OS what resolutions the card supports, how it is stored in
>memory(the image, hopefully in a rasterport compatable format), and how to
>modify the pallette, etc.
>   Have the Amiga OS call these routines to determine what modes are availabe. 
>Add routines that a program may call to determine these modes.  Have the Amiga
>OS be able to work with non-standard modes if they exist...
>
>NOTE:  The program does not directly communicate with the card to find the
>modes available, etc.  This is done by THE OS...  Therefore, one can put any
>kind of graphic card in the machine, the OS can determine what it is...and any
>program can use it because the program does not have to know how it works...

I am leaning towards the device.driver type of interface. The card may
contain som AutoBoot ROMs which tells the system what kind of bits per
pixels and gfx memory layout to expect.

This driver should contain a basic set of graphics IO commands. The
main idea is to allow accelerated gfx boards use the gfx processor for
vanilla operations. How about:

 * Read / Write pixels
 * Draw lines
 * Draw areas
 * Set Drawing Mode - JAM1 | COMPLEMENT etc
 * Draw Text

The basic Draw(), *Pixel(), Area*()and so on commands would simply map
to call to the device driver with a very modest overhead. Maybe
operations could be queued up for a driver by the system and then
executed in batch with very low overhead by some kind of GfxSync()
call a la X-windows.

If one abstracts the Amiga gfx subsystem of today, it consists of a
graphics processor and a lot of shared memory. It is possible to create
the Amiga windowing system without having the CPU touching CHIP. But
for providing the gfx data the gfx processor needs. The CPU doesn't
need to write pixels and such stuff.

Refine this model, and all gfx functions can be made through a single
IO port, leaving the gfx subsystem with all the bandwidth it needs,
and the processor going full tilt in its own memory. High CPU
performance and gfx troughput.

The idea does not exclude the use of shared memory and BitMap in CPU
addressable space. The driver takes care of those details.

If the OS then would allow for multi WB-screen setups, we would have
the base for all graphics processing / composing systems.

Here's my first draft of a working idea. Let's take it apart and
improve it. No comments are bad comments, merely a statement of
interest in the issue...

>Jason Wilson - An Aspiring Amiga Programmer...


-- 
Svante Gellerstam		svante@kberg.se, d87sg@efd.lth.se