Conference hydra::amiga_v1

    Just some general observations, since I'm not an expert in this
    area. The Amiga 500 has a feature called "extra half-bright" which
    provides 64 colors: the 32 you select in the usual way, and 32 more
    that are dimmer.  I don't know if this feature is accessible from
    AmigaBasic.  HAM mode is quite hard to program; if 64 colors are
    enough you might be better off going the extra half-bright direction.
    
    The Amiga comes with a set of graphics libraries, which can be called
    from C.
        John Sauter

    The libraries can also be called from basic, but I havn't done it
    yet.
    So you should be able to access any feature from basic if you convert
    the library and call it correctly.
    Tom

   In 640x400 mode I believe you can have 16 shades of grey. 32 shades
    in lower resolutions.

    
    If you can live with composite video output, the A500 ill display
    4096 shades of grey in HAM mode.
    
    Ed. 

    re: .0
    
    some other tricks to get more colors:
    
    1. dithering (instead of a solid color, use a pattern of dots)
    2. patterns, like cross-hatching, instead of solid colors
    
    The Amiga's 4096 color comes from 16x16x16 RGB.  Could that be
    where your 16 levels of grey are coming from?
    
    One other trick that is easy to do, but hasn't been used much,
    is copper list interrupts to change the palatte while it is
    drawing the screen.  That could give you 4096 colors without
    using HAM mode, but that would have palette usage limited by
    scan line instead of the adjacent color as in HAM mode.
    
    -dave

    re: last couple.
    
    32 shades of gray -- sort of.  4096 -- no way!  Here's why.
    
    The hardware allows only 16 shades of each color: red, green and
    blue.  Gray/white shades are usually composed of equal values of
    each color, i.e. [0,0,0] through [15,15,15].  The luminance
    value of each of these is the vector sum, that is, the square root
    of the sum of squares of each color value.  This gives a luminance
    range of 0 to 26 in 16 steps.
    
    Now add Extra Half Bright.  This feature of the Amiga chipset cuts
    each color output value in half (I think).  All the odd-numbered
    values of gray would have new output values, but all the even-numbered
    values would map to existing values, so you get maybe 24 shades
    of gray.  The new shades fall in the blacker half of the scale.
    
    If you use the composite output to drive a black and white monitor, you
    can get more shades by using unequal values of R, G and B. With careful
    choice, a 32-color screen can become a 32-gray shade screen. But the
    number of possible shades is the number of RGB permutations, not
    combinations. Color [7,8,9] has the same luminance as [9,8,7] or
    [7,9,8].  So the real maximum is more like one-sixth of the HAM
    palette, or about 680 unique values.  Some of those will likely
    be indistinguishable because their luminance values are very close.
    
    One project I tried a while back was to choose Workbench screen
    colors which all had about the same luminance, so an interlaced
    Workbench wouldn't flicker.  I generated all 4096 luminance values
    with a short BASIC program, then sorted them by decreasing luminance.
    Trouble is, all the combinations I tried looked pretty awful :-).
    
    So the hardware guy's answer (  :-) ) is that you can count on 16
    shades of gray, 24 unevenly spaced with EHB, and 32 up to a few hundred
    if you choose your color map v-e-r-y carefully. 
    
    Wes

Re: .6

Wes is right on the money except for one glitch.  Extra half brite mode
does not increase the number of colors in the Amiga's palette.  The shifting
of R-G-B values occurs before output to the monitor so it is merely a
mapping from one color in the palette to another (possibly identical)
color in the palette.

Since there are only 16 shades of gray in the Amiga's palette, both extra
half brite and ham can only display 16 shades of gray.  Although, as others
have pointed out, using the monochrome output jack on a 500 or 2000 produces
more shades of gray by mapping the entire color palette into a somewhat
smaller (but still large) palette of grays.

Re: .0

About HAM mode:  writing code to display a HAM picture is not any harder
than code to display any other type of image.  However, since HAM is
basically a clever encoding of bitplanes (make six bitplanes do most of
the work of twelve), it is fairly hard to write a HAM paint program.
The problem is working out the encoding.

It isn't clear what your proposed application is going to do.  If you
plan on simply being able to display images created with a paint program
or digitizer, you might as well go for HAM rather than any other 
type of picture.  If your application is simply going to be some sort
of database that mixes imported pictures with text, there are several
commercial programs that can do that sort of thing.

Archaeology, huh?  I saw a short segment on the news about how all of
the construction going on in London was making it a banner year for
English Archaeologists.

How HAM mode works is documented in the "Hardware Reference Manual."
The HAM files use the same format as any other bitplane based image:
an ILBM IFF file.  The HAM file is just a Interleaved Bit Map File that
specifies six bit planes and has a CAMG hunk that specifies the viewport
should be HAM (as opposed to extra half brite).

The IFF standard is available from Commodore, but your easiest source is
the ENET.  The IFF standard was also distributed by Fred Fish on fish
disk 64 (an earlier version was on disk 16).  I believe that this disk
or a later IFF disk has been uploaded.  Perhaps someone will volunteer
its location.

    Well, I'm shocked.....
    
    Having only just joined DIGITAL UK, I was not fully aware of the
    speed at which one can get answers to queries.  How can a company
    go wrong with such an amazing facility as Notes?
    
    Thanks to everyone for your help, it seems like I could be investing
    some of my first months wages in a few Amiga Reference Manuals.
    
    Thanks again,
    
    Steve P

    re location of FF64...see  mvcad3::user0:[amiga]FRED-FISH.HELP...
    
    each Fish disk in seperate subdir....
    
    
    Directory USER0:[AMIGA]
    
    FF05.DIR;1          FF100.DIR;1         FF101.DIR;1         FF102.DIR;1
    FF105.DIR;1         FF107.DIR;1         FF110.DIR;1         FF111.DIR;1
    FF112.DIR;1         FF113.DIR;1         FF114.DIR;1         FF115.DIR;1
    FF116.DIR;1         FF117.DIR;1         FF118.DIR;1         FF119.DIR;1
    FF120.DIR;1         FF121.DIR;1         FF122.DIR;1         FF123.DIR;1
    FF124.DIR;1         FF125.DIR;1         FF126.DIR;1         FF127.DIR;1
    FF128.DIR;1         FF28.DIR;1          FF33.DIR;1          FF44.DIR;1
    FF58.DIR;1          FF63.DIR;1          FF64.DIR;1          FF68.DIR;1
    FF76.DIR;1          FF77.DIR;1          FF92.DIR;1          FF93.DIR;1
    FF94.DIR;1          FF95.DIR;1          FF96.DIR;1          FF97.DIR;1
    FF98.DIR;1          FF99.DIR;1          
    

On the Atari, there are a few programs out there that get more than the
usual 16 colors on the display by sneaking into the color map during
horizontal retrace time and changing the numbers.  You get only 16 per
scanline, but lots more different colors on the screen.

Re: .10

>On the Atari, there are a few programs out there that get more than the
>usual 16 colors on the display by sneaking into the color map.

You can play this sort of game on the Amiga by programming the Copper
to load color registers on the fly.  However, no one ever seems to
have bothered using this feature simply to increase the number of
colors being displayed (well, there is a copy protection buster program
that uses this hardware to get a beautiful rainbow background on the
controlling screen).  I suspect that the existence of HAM mode on the
Amiga makes this technique unattractive.

This type procedure can not increase the size of the palette.  So it
doesn't solve the "other" problem of not enough displayable gray levels.

    re: .11
    
    I suspect the reason you don't see it more is because of the learning
    curve on the Amiga.  
    
    It seems to go in the following steps:
    
    1. "Just give me a memory map and a description of the registers
        to poke"
    
    2. After getting stomped on for suggesting that, then there is a
       period of trying to be a good citizen in a non-protected
       multitasking environment.
    
    3. Then they realize you don't need to do step 2 if you justify
       it by saying you had critical timing problems or don't want
       any user programs running at the same time.
    
    Copper list programming fits on the hairy edge of step 2, since
    there is a way to merge your custom list with what the system is
    doing, but other programs also playing with the Copper might
    not like it.
    
    I suspect you will be seeing lots more step 3 style programming
    for games.  The copper isn't limited to just changing color
    registers.  And it is very simple to program, see Rainbow.c
    on a Fred Fish disk.
    
    -Dave
    

Re: .12

Naw.  I still think that HAM mode killed off using the copper to
modify the color table on the fly.  Since programs have gotten very
good at computing a color table that allows HAM to work without
the "confetti".  Although, using such a technique would allow high
res displays with more colors....


>    3. Then they realize you don't need to do step 2 if you justify
>       it by saying you had critical timing problems or don't want
>       any user programs running at the same time.

Sort of hard to justify for just another "display a picture" program.
And I've noticed I seem to use the games more that I can play while
waiting for the big compile to finish.  So, I sort of wish there was
less of that attitude in general.

    re: .12
    
    32/16 color registers & HAM mode is what reduced the need to play
    around with the color table.  The ST's 16/4 and no HAM is why
    they have Spectrum 512 and friends now.
    
    CBM hasn't been encouraging folks to do Copper list stuff, but it
    is documented in the RKMs.  Seems like they want to reserve that
    for things like Intuition's pull down screens and the Hedley
    Monitor.  
    
    I'm hoping that Spectrum 512 wakes up Amiga developers to the power
    of raster interrupts.  Then they can learn how much nicer custom 
    display lists can be.  Think of what a combination of the Copper and
    the Bimmer could do...
    
    -Dave