HAM6 output different on AGA vs OCS (UAE)

[alpine9000]

Hi,

So I have been playing with displaying laced ham6 images, and everything is working nicely on OCS configurations. When I tried it on an AGA configurations 1200/4000 I get slightly different colors.

A500/3000:


A1200/4000:


Behaviour seems the same on FS/WinUAE.

My app runs from the bootblock, zero OS, and runs only in chip ram, I don't have any specific code for the 4000 except reading back from COPJMP1 after installing the copper list (Seemed to have a slight flicker before I added that). My copper list just resets the bitplane pointers. Palette is set at the start, then forgotten. I switch copper lists for the interlaced bitplane pointers in the vblank isr, however this problem is the same in non-interlaced mode.

Is there some AGA specific thing I need to set up ? Or other pointers to where I am going wrong ?

[alkis]

AGA has 8 bits for color. You write the high-4 bits...maybe the OS keeps the low-4 bits at $F??? and you have to actually set those to #$0?

Don't have the knowledge, just guessing

[meynaf]

Originally Posted by alkis

AGA has 8 bits for color. You write the high-4 bits...maybe the OS keeps the low-4 bits at $F??? and you have to actually set those to #$0?

Don't have the knowledge, just guessing

When high bits are written, the same value is written in the low bits for compatibility.
So to the best of my knowledge there should be no difference in the image.

[alkis]

Originally Posted by meynaf

When high bits are written, the same value is written in the low bits for compatibility.
So to the best of my knowledge there should be no difference in the image.

That could be it then.
If you write $8 then in non-aga it's $8, but in aga $88 which is halfway between $8 and $9

[chaos]

Originally Posted by alkis

That could be it then.
If you write $8 then in non-aga it's $8, but in aga $88 which is halfway between $8 and $9

It doesn't work like that.

OCS/ECS has 12bpp output, which is 4bit/color. AGA has 24bpp output, which is 8bit/color. If you want the same color intensity, you are "supposed to" write the OCS 4bit value to both parts of the AGA 8bit color, which is exactly what the AGA hardware does. This allows you to reach full $FF intensity, which will match OCS full intensity value $F - otherwise you would get only $F0 as max value, which is $F0/$FF less than full intensity.

So, AGA $88 is the same as OCS $8. Of course taking into account that you made a small gain error in exchange for fixing the offset error, plus any possible non-linearity in play since gamma is not taken into account.

alpine9000: you are setting LOCT=1 in BPLCON3?

edit: actually, the gamma could be the cause of this. Did anyone ever look into what the video output of Amiga is encoded as? Is the output fully linear, or is it gamma encoded, perhaps in the DAC?

[mark_k]

alpine9000, what version of WinUAE/FS-UAE are you using?

Do you see the same difference when you boot your disk on an AGA config after selecting original or enhanced chipset in the boot menu?

Do both your ECS and AGA configs have the same settings for brightness/contrast/gamma?

Can you post/attach an example ADF file that shows the problem?

[alpine9000]

Originally Posted by chaos

It doesn't work like that.

alpine9000: you are setting LOCT=1 in BPLCON3?

I don't write to BPLCON3, so I am guessing it is LOCT=0. I can check with the debugger when I am at my machine.

Originally Posted by mark_k

alpine9000, what version of WinUAE/FS-UAE are you using?

Do you see the same difference when you boot your disk on an AGA config after selecting original or enhanced chipset in the boot menu?

Do both your ECS and AGA configs have the same settings for brightness/contrast/gamma?

Can you post/attach an example ADF file that shows the problem?

I am using the latest non development versions of FS/WinUAE.

Which boot menu do you mean ?

The configs were all 100% default for FS-UAE and WinUAE. So unsure of the gamma/brightness settings to be honest.

ADF is here:

https://github.com/alpine9000/amiga_.../slideshow.adf

There is a 10 second delay before the first image is displayed, so warp mode is your friend ;-)

Source code:
https://github.com/alpine9000/amiga_.../023.slideshow

[mark_k]

Originally Posted by alpine9000

Which boot menu do you mean ?

The early startup menu which appears when you hold down both mouse buttons when turning on the Amiga.

[alpine9000]

Originally Posted by mark_k

The early startup menu which appears when you hold down both mouse buttons when turning on the Amiga.

I can't get it to work on fs-uae (all I can try at the moment). Not sure if mac allows both buttons to be pressed at the same time with the trackpad.

[mark_k]

Assuming this isn't some kind of emulator bug...

Are you clearing bit 0 of BPLCON0 (to disable BPLCON3)?

I compared a couple of pixels that differ in the two images. Coordinates are based on screenshots with window border that I took not the images you uploaded.

H,V coord	R,G,B (decimal)	R,G,B (hex)
435,443		224,176,160	E0,B0,A0	AGA
		238,187,170	EE,BB,AA	ECS

612,394		176,153,136	B0,99,88	AGA
		187,153,136	BB,99,88	ECS

So for pixels that differ, it seems one or more components of the running-on-AGA image are zero instead of the low nybble being the same as the upper.

[mark_k]

Originally Posted by alpine9000

I can't get it to work on fs-uae (all I can try at the moment). Not sure if mac allows both buttons to be pressed at the same time with the trackpad.

Try remapping mouse buttons to keys on the Mac keyboard. Also, WinUAE has a "One second reboot pause" option, maybe try enabling that if FS-UAE has that too.

[mark_k]

After looking at the WinUAE code, I think you found an emulation bug! I'll write about what I think is the problem (in drawing.cpp) later today.

[Photon]

(Disregarding the inverted interlace phase in the screenshots.) Just tested this on a few versions old WinUAE vs A1200. Yes, there seems to be a difference between OCS and AGA emulation of HAM6. OCS emulation, real A500 and real A1200 looks correct, while stock A1200 in WinUAE gives rise to short horizontal lines (you can see them near the edge of the face). I've started an emulation bug thread, but if someone has the latest beta handy they could verify there.

I dealt with HAM6 lace in Frazetta, Jack Burton did accurate conversions of oil paintings (which are harder to get than oversaturated photos a la NewTek etc) in HamLab to the PCHG ilbm format.

There is the possibility of HAM6 lace specifically to go 15-bit over 12-bit, when someone writes a PCHG exporter that supports what the format already does.

When that happens, my converter will support it automatically. PCHG viewer/exporter to raw+copper lists plus source is on the disk there, please use them, this was the reason for the release.

[alpine9000]

Originally Posted by mark_k

After looking at the WinUAE code, I think you found an emulation bug! I'll write about what I think is the problem (in drawing.cpp) later today.

Thanks for spending the time looking into it. Because I am so new at this amiga thing, I just assumed it was my fault.

Originally Posted by Photon

(Disregarding the inverted interlace phase in the screenshots.) Just tested this on a few versions old WinUAE vs A1200. Yes, there seems to be a difference between OCS and AGA emulation of HAM6. OCS emulation, real A500 and real A1200 looks correct, while stock A1200 in WinUAE gives rise to short horizontal lines (you can see them near the edge of the face). I've started an emulation bug thread, but if someone has the latest beta handy they could verify there.

I dealt with HAM6 lace in Frazetta, Jack Burton did accurate conversions of oil paintings (which are harder to get than oversaturated photos a la NewTek etc) in HamLab to the PCHG ilbm format.

There is the possibility of HAM6 lace specifically to go 15-bit over 12-bit, when someone writes a PCHG exporter that supports what the format already does.

When that happens, my converter will support it automatically. PCHG viewer/exporter to raw+copper lists plus source is on the disk there, please use them, this was the reason for the release.

Ah, yes. I swapped the interlace order to see if that was backwards on the AGA machines for some reason then forgot to swap it back . The image did seem a little funky. Thanks for picking that up.

I know Frazetta well, I watched it again (not for the first time) just last week in fact .

I am generating the HAM6 raw data myself and am interested in improving my own converter. Can you expand on what you mean by going 15bit ?

[Photon]

There is a difference between Amiga and emu though, so perhaps best to await a resolution to that before changing code. Do you have an AGA Amiga? Maybe the problem goes away automatically then as it did for me.

HAMLab can output pictures with a copper list that changes 0-15 colors per scanline. This increases the number of actual distinct colors in a HAM pic from around 300 to around 1000-1500. Of course, it depends on the picture. A "color gamut test picture" will be able to show all 4096 colors.

15-bit increases the possible number of colors from 4096 up to 29791, with 5 bits per component, by swapping two individual copper lists adapted to each field of the interlaced picture in sync. Flickering close colors at 25 Hz will not cause a noticeable flicker, but seem to generate a steady color in between, say, $555 and $556.

Unfortunately in our tests, we couldn't get HAMLab to output two such hunks with adapted palette changes.

EDIT: run it in latest beta, it looks fixed to me!

[mark_k]

Could you elaborate on your 15-bit theory? From what you wrote, it sounds like you tried using different palettes/copperlists for odd and even fields of an interlaced image. Each list would have a slightly different palette.

But that wouldn't result in colour "mixing" because the colours of pixels in each field's lines would be constant. Unless you alternate between slightly different palettes for each field, but the colours would only change at 12.5Hz then. (i.e. odd field palette 1a, even field palette 2a, odd field palette 1b, even field palette 2b, odd field palette 1a etc. etc.)

Where you could use colour mixing is for non-interlaced images. Down-convert the 24-bit source image to non-interlaced (i.e. halve its height). Generate two non-laced HAM+copperlist images from that, colours chosen to look as close to the original as possible when mixed. For display, alternate between the two images & copperlists on alternate frames.

Of course writing a program to choose the two best/optimal palettes/copperlists might be tricky...

[alpine9000]

A few weeks ago I started writing an example that switched in a new palette every scan line:

https://github.com/alpine9000/amiga_...015.sliced_ham

Unfortunately it's not really there yet as it looks worse than the normal HAM version.

I think it has problems both in the simplistic algorithm I used to select each line's palette as well as the display implementation. (It's possible the copper list is not correctly synced up with the image data or some other problem).

At that stage I got bored with HAM so moved on :-)

I will revisit this at some stage, as it should be a pretty easy way to get heaps more colors.

[Photon]

It's untested due to lack of exporters.

As you say, it's impossible to have interlace and at the same time change "the same interlaced pixel" with only two copperlists. Some general info which I'm sure you know already and then some blurb how it might work.

Without two copperlists, actually an interlaced picture is forced to use the same 12-bit palette for two pixel lines. The first thing that two copperlists would do is cause less 12-bit color errors. This should work fine on all CRTs, deinterlaces such as WinUAE and flickerfixers.

On CRTs, because the raster beam is a fixed width of one lores pixel height, pixel line pairs would overlap by 50 percent and fade into each other. Also, pixels would melt into each other a bit as for lores, generally giving a more pleasant and forgiving picture, or simply a better picture. Not counting the flickering, obviously. But some flicker can be removed by running the exporter a bunch of times with slightly different settings and pre-processing of the picture to begin with (i.e. following the crap in crap out rule). (Normally such pre-processing can be things like blur, dither, avoiding adjacent dark/light swaths or patterns, selecting suitable motives, or using overcontrast/oversaturation or otherwise create blowouts. Generally Photoshop the shit out of it. This is typically what is done for f.ex. faces, like the one in OP.

15-bit is time dither. Swaths of the same color will hit the in-between color, and gradients too, they will be smoother. Edge pixels between such areas and generally chaotic areas and rapid adjacent color changes will not hit the in between color if the picture is full-res vertically in those areas. An exporter would have to identify those areas and apply a dither pattern to them, i.e. change the bitmap to look perceptually correct. As I see it, any dither would have to be applied together with this. Applying it beforehand would kill the concept. This is what should be solved if you don't want to go 12.5 Hz, two interlaced pictures, and 4 copperlists. But the swaths in between those edges would look good on all displays.

Obviously a HAM exporter specifically will already calculate different bitmaps between each field as it is, partly due to the original picture contents, but also adjust/not follow contents when mapping to get more than 15 colors out. Modify above means modify the calculation.

Maybe you could start with non-HAM modes and go from there, I don't know. But as I said, it's untested.

[alpine9000]

Originally Posted by Photon

EDIT: run it in latest beta, it looks fixed to me!

I patched my version of FS-UAE as per mark_k's post and it certainly is fixed.

A1200 AGA HAM6:

[mark_k]

About HAM dithering (this is mainly to Photon)...

Did you test/experiment with generating non-interlaced HAM images? Obviously vertical resolution is worse but on the plus side, no flicker. And you could (after someone writes a suitable conversion program...) output two images from the single source image. Alternate between them on alternate frames to get the dithering effect.

On real hardware with 50/60Hz CRT monitor I think that might look pretty good.