MUSIC [arf9]

[Andreas Arff]

Hello Moosers

I'm writing a small draft for the GUI part of MUSIC. This contains
the minimum commandset we need, and some things to think about
when implementating it. I don't know if it is a good thing to publish it
for all of you, since only a few of you are interested in this part. But
on the other hand, you are entitled to know.

--------------------------------------------------------
The standard primitives for MUSIC

We must find some sort of greatest common divisor, and I think we'll find
it in the VGA/MCGA system. I have some overall goals that I'll present here,
which I think we all can agree on.
- Vga compability
- Exchangeable gadgets/widgets
- 24 or 8 bit colors
- 3 standard viewports - Pixelated, Vectorbased, PostScriptbased.

About the colors, this is only theoretical, it will work equally good on
4 or 15 or 16bpp. I think it is important to provide several types of
viewports, a wysiwyg program might want to use a PS window/viewport, while
some would rather prefer to use vectors. Any other suggestions?


Now over to the primitives.
---------------------------
Different HW forces us to build an exchangeable layer with code for different
cards. The VGA is only a small part here.

            +------------------+
            | VGA | SVga cards |  <--- HW
            +------------------+
            |  Primitives      |  <--- SW
            +------------------+
            | Gfx - interface  |  <--- SW
            +------------------+

What I'll deal with is the primitives, and of course there are some
minimum requirements.
During my "research", I have found out that we need the following
functions.
A. 1. Change Active/Current Bank
   2. Wait for electron beam vertical retrace
   3. Mode setting
   4. Palette Set

B. 1. Put a pixel
   2. Get a pixel
   3. Move a pixel
   4. Clear screen

In addition we need a function to determine the resolution for the screen.
For a fast GUI we need block functions. I think we should come to an
agreement on what we mean with the word block. It can mean a square, or a
polygon. Maybe we should implement to kind of block functions, square and
polygon. There is a speed advantage using squares, and speed loss making
polygons out of squares:-).
We also need iterative functions.
C. 1. Draw a line
   2. Draw an arc

D. 1. Put a block
   2. Get a block
   3. Move a block
   4. Fill a block

Many cards also have support for special features as short vectors and HW-
sprite(s). I think we should implement these too in the minimum code, and
if a card doesn't support it, it could be supported using other primitives.
I use the XGA specification here as the base for the extras I think should
be standard.
E. 1. HW-cursor/sprite
   2. Short vectors

Each implementation will probably have other functions, but these should
be mandatory. A1-3 are card dependant, while A4 could be the same for
(almost?) all cards, since all of them has a DAC that works the same way. B3
could be discussed, but I think it is a good choice. (Remember how to make
sprites with a ZX81 spectrum:-).

A fast UI should also beware certain commands, such as Jnn, any math-function,
and IN's and OUT's. The time consuming MUL operation could be reduced with
95%. Of course the GUI primitives should be written in assembler (mostly), and
this part could be ready made in a large extent befor the the kernel.
I'll have done some asm. code for some of these commands already, so
interested people can get it, and finish it for their SVGA card. I currently
have oak, ati and paradise here (writing this mail on a VBE compliant box,
but I don't know enough about VBE, so that'll have to wait).
In the figure there is a part called gfx-interface, this part is the
interface for the application writers.


Have a nice day.

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--