Newsgroups: comp.sys.amiga.advocacy
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!mintaka!geech.gnu.ai.mit.edu!rjc
From: rjc@geech.gnu.ai.mit.edu (Ray Cromwell)
Subject: Re: (Video) Hardware Idiots ?
Message-ID: <1991Jun10.111312.15747@mintaka.lcs.mit.edu>
Sender: news@mintaka.lcs.mit.edu
Organization: The Internet
References: <1991Jun10.040317.25396@ncsu.edu> <1991Jun10.065129.4135@mintaka.lcs.mit.edu> <1991Jun10.091140.15163@ncsu.edu>
Date: Mon, 10 Jun 91 11:13:12 GMT
Lines: 61

In article <1991Jun10.091140.15163@ncsu.edu> kdarling@hobbes.catt.ncsu.edu (Kevin Darling) writes:
>In <1991Jun10.065129.4135@mintaka.lcs.mit.edu>
> rjc@wookumz.gnu.ai.mit.edu (Ray Cromwell) writes:
>However, for my view, I'm thinking of those who'd like to see true DIG
>available even for such cards as HAM-E, DCTV, FC24, CB, ULowell, etc...
>which have radically different data interface methods.

  I see your point. I'm starting to see an inbetween solution:
Commodore divides displays into classes

1) Chunky Pixmap
  a) Dumb - Basically a few DACS, some memory, some logic
    1.) + sprites
    2.) + genlockable 
    3.) + beamsyncable (copper or decendent)
    4.) + datamover (it will have to specify how many channels it has,
                     logic operations, maximum copy size, etc)
  b) intelligent
    1) Commodore will standardize a microkernel that all intelligent
     boards will handle, autoconfig(tm) will handle the rest
     this kernrel should include the basic geometric primitives plus
     extras like 3d rendering of vectors
    Autoconfig will link in the gfxlib primitives with the onboard
    kernel, some error handling will check which calls the board does
    and does not support.

2) Bitmap pixmap
   (same as the above)

3) non-standard
   (DYUV, HAM, A2024, Colorburst)
   These boards will provide a .library which will render data according
   to C='s microkernel specifications

To the above add in another specification that signals a board as
palette mapped or CLUT.

  The standard for storing bitmaps will have to be changed to
a superset of ILBM which contains the CLUT not as a 12bit color
value, but as red_color/65536, green_color/65536, and blue_color/65536
this way intensity information can be properly scaled to any
colormap (even 24bit).

  While were at it, let's create new audio.device functions which
handle 8/16/32bit sample ranges and audio.device drivers so
audio will work flawlessy on stuff like the DSP56001 Sunrize boards.
(actually, the audio DIG will be much easier than the video DIG)
Also, let's make a new SANA standard that handles remote procedure
calls and remote framebuffers. And let's add a CD-I.library that
plays CD-I discs when you have a CD-I display card and CD-ROM installed.
And... :)


>cheers - kevin <kdarling@catt.ncsu.edu>


--
/ INET:rjc@gnu.ai.mit.edu     *   // The opinions expressed here do not      \
| INET:r_cromwe@upr2.clu.net  | \X/  in any way reflect the views of my self.|
\ UUCP:uunet!tnc!m0023        *                                              /