EHB, HAM6 and HAM8 demonstration pictures?

[alpine9000]

I tried my custom HAM6 converter on your source image. This is interlaced.

[TroyWilkins]

Originally Posted by Minuous

The claim on that page that HAM8 only supports 262144 colours is incorrect.

Ahh, ok, thank you, any idea what the correct number would be? That was the number I remember being used by everyone back in the day.

Originally Posted by khph_re

there is also sliced ham on OCS i think? as well as overscan and interlace to increase the resolution.

Yes, true. Not sure about sliced HAM, as I'll be honest and say I don't know anything about that, but yes, overscan and interlacing exist. I guess the HAM6 image could be changed to be interlaced, like the pic below.

Originally Posted by alpine9000

I tried my custom HAM6 converter on your source image. This is interlaced.

Oh wow, that's impressive, thank you!

Thank you everyone for your valued input!

[Thorham]

Originally Posted by alpine9000

I tried my custom HAM6 converter on your source image.

Very impressive Want to share the algorithm?

[alpine9000]

Originally Posted by Thorham

Very impressive Want to share the algorithm?

https://github.com/alpine9000/amiga_...tools/imagecon

The algorithm is pretty simple, It does a brute force search of the starting palette, so takes a LONG time to do the conversion even on a really fast i7.

[robinsonb5]

Originally Posted by TroyWilkins

Ahh, ok, thank you, any idea what the correct number would be? That was the number I remember being used by everyone back in the day.

Technically HAM8 can access all 16,777,216 colours - though not in a way that's particularly useful.

In HAM8 mode every pixel can either select a base colour (in which case all eight bits per component of the base colour are used), or it can modify just the upper six bits of either the red, green or blue component. The lower two bits aren't touched, so they remain however the last base colour left them.

What this means is that once you've set a base colour, you can modify the upper 6 bits of each gun and access 262,144 colours in total. To access the colours in between you need to change the lowest two bits of each component, and you can only do that by selecting a different base colour. If you set the lower 2 bits of each component uniquely for all 64 colours in the base palette, it's possible for HAM8 mode to access any of the AGA chipset's 16,777,216 colours - but in practice this isn't particularly useful.

[B14ck W01f]

EHB = a poor man's HAM

[ajk]

Also consider that a 640x512 image has less than 330 thousand pixels; even if each individual pixel in the image had a different colour you wouldn't come close to using all 16 million. Any real world photo is likely to display just fine with far less, as long as they are appropriately chosen.

[Thorham]

Originally Posted by alpine9000

https://github.com/alpine9000/amiga_...tools/imagecon

Thanks

Originally Posted by TroyWilkins

Ahh, ok, thank you, any idea what the correct number would be? That was the number I remember being used by everyone back in the day.

Although 262144 is technically not entirely accurate, it's the number that's most relevant.

[thomas]

Originally Posted by TroyWilkins

perhaps the AGA images should remain in the source resolution, although to be fair, on a 15khz screen, in interlaced mode they'd flicker badly

AGA can output 30kHz, i.e. 640x400 without flicker.

And Interlace only flickers if you use the wrong monitor.

[Thorham]

Originally Posted by thomas

AGA can output 30kHz, i.e. 640x400 without flicker.

Aga can output more than 30khz.

Originally Posted by thomas

And Interlace only flickers if you use the wrong monitor.

Interlace flicker depends on the update frequency and phosphor layer of the CRT monitor.

[thellier]

Hello

>262144 [...] the number that's most relevant.

In fact there is 256 values possibles for each R, G or B channels (any value from 0 to 255)

Lets see HAM8:
Among them 64 can be obtained when "M"odifying an pixel (like 0 4 8 12 16 etc...)
But also the palette can be defined to use 64 other values (like 1 2 3 5 6 7 9 etc...)
those can be obtained when "H"olding a pixel to the palette

So the total is 64+64 values values possibles for each R, G or B channels
So 128*128*128 = 2097152 = 2 mega pixels not 16 as often said...

Alain Thellier

[khph_re]

But you can change the base palette per line, so both HAM modes can achieve more than that. In fact, if you screen drag one HAM picture down to reveal another in workbench, that's exactly what you are doing.

[Thorham]

Originally Posted by thellier

So the total is 64+64 values values possibles for each R, G or B channels

Not exactly.

A HAM pixel can do any of the four following things:

1. Be set to a palette color.
2. Take on the color of the pixel to the left, and set the red component.
3. Take on the color of the pixel to the left, and set the green component.
4. Take on the color of the pixel to the left, and set the blue component.

For the first pixel type this means 4 bits per channel in HAM6, and 8 bits per channel in HAM8.

For pixel types 2, 3 and 4 you can set 4 bits of the changing component in HAM6, and 6 bits in HAM6.

Since most pixels in a HAM image are usually of types 2, 3 and 4, most of the pixels are usually 6 bits per channel in HAM8. A big factor here is the fact that there are only 64 palette colors in HAM8, making it hard to use the extra bits you can get from the palette, hence the number 262144 being the most relevant.

When you start using palette slicing in HAM8 and use the right conversion algorithm, it may be possible to make better use of the palette color's 8 bit channels.

So basically HAM8 pixels can have 8 bit components, but they usually become 6 bits rather quickly.

[thellier]

@Thorham

I reread your post and I dont see exactly what you wanted to add to my post:
Types 2,3,4 allow to adjust 64 values and the 64 palette colors (if well defined like greys with only "other" values) allow to set (type1) 64 other values

So: " the total is 64+64 values values possibles for each R, G or B channels
So 128*128*128 = 2097152 = 2 mega pixels"

@khph_re
I agree ...

Alain Thellier

[pandy71]

Originally Posted by thellier

@Thorham

So: " the total is 64+64 values values possibles for each R, G or B channels
So 128*128*128 = 2097152 = 2 mega pixels"

Isn't better to define problem that 2 LSB are from CLUT and 6 MSB are dynamically changed by HAM.
So going with your approach it will be like 2+2+2=6 bits and 6+6+6=18 ; 6+18 =24.

[TroyWilkins]

I found this, which looks to be a good reference: http://shanson.com/spencer/Amiga-AA-Chipset.pdf

[thellier]

Hello

@pandy71
>Isn't better to define problem that 2 LSB are from CLUT

No because you can access only 64 colors from the palette in Ham8 so you cant recover ALL the possibles values from 0 to 255 but only 64 ones

>2+2+2=6 bits and 6+6+6=18 ; 6+18 =24.
This formula would let suppose that if it have been load a color palette (so with a 8 bits precision) in a pixel then you can modify in the next pixel ONLY the 6 MSB bits for (say) the red channel: but this is not the case because it REPLACE the (say) red channel so you lose the 2 LSB bits

Alain

[alpine9000]

I think the maximum number of theoretical colours you can display in HAM is a moot point.

Because of the "rules" of ham for any given pixel you are selecting the best colour from a relatively small number of colour options.

So unless you construct an image that perfectly matches the ham constrainsts you will never get anywhere near that maximum number of colours.

Am I missing the point of this discussion?

[pandy71]

Originally Posted by thellier

This formula would let suppose that if it have been load a color palette (so with a 8 bits precision) in a pixel then you can modify in the next pixel ONLY the 6 MSB bits for (say) the red channel: but this is not the case because it REPLACE the (say) red channel so you lose the 2 LSB bits

Nope, HAM modify only 6 MSB, 2LSB are left unchanged so if you keep 2LSB in CLUT and change it by HAM then you can create all 24 bits on screen. Side to this with clever CLUT selection this doesn't sacrifice HAM quality as CLUT content doesn't need to be only 2LSB, also CLUT banks can be switched relatively inexpensive (cycles) way on AGA.

Originally Posted by alpine9000

So unless you construct an image that perfectly matches the ham constrainsts you will never get anywhere near that maximum number of colours.

If you can create bitplane 4096x4096 then you can display all 24 bit but in real life CHIP RAM have no 24 bit size.
So all this discussion is purely academic (display HW probably can be bend in clever way to have 4096 pixels in line and for sure you may have 4096 lines but RAM will be main limitation as we have only 2MB CHIP not 24MB).

[TroyWilkins]

Well this has been very interesting, thank you everyone! I appreciate all the input. That's a good point about RAM usage, can anyone let us know what the ram usage for a 320x200 ham8 screen? I'm not entirely sure how to calculate it to be honest, is it an 8-bitplane screenmode?