HAM6 on AGA in WinUAE displays incorrectly

Photon · 25 March 2016, 02:39

(I'm sorry, I don't have latest beta but maybe someone can help me verify if this is still valid?

So Toni doesn't waste time.)

This thread brought it to my attention just now, and I get the same short lines in the face there as ahemm on the rump of the naked lady in Frazetta, and a few more. Since it worked on A500 and A1200, I just didn't notice it. I tested now that it also works on A500 emu in WinUAE. But not on A1200 in WinUAE.

We all know there's some rounding down below $8 and rounding up >=$8 on AGA but I just don't see the lines on my A1200 with CRT.

mark_k · 25 March 2016, 02:45

Yep, problem caused by same mistake in init_ham_decoding() and decode_ham() in drawing.cpp. Fairly obvious once you see it.

Toni Wilen · 25 March 2016, 08:55

I never fixed that "obvious" bug because it supposedly was correct and I never bothered to confirm it myself.

mark_k · 25 March 2016, 11:54

Well, I meant fairly obvious once you're aware the problem exists, and that some pixels in HAM6 images on AGA have $x0 colour components instead of $xx.

For anyone that's interested, the bug was this code:

Code:

} else { /* AGA mode HAM6 */
    while (unpainted_amiga-- > 0) {
        int pv = pixdata.apixels[ham_decode_pixel++] ^ bplxor;
        switch (pv & 0x30)
        {
        case 0x00: ham_lastcolor = colors_for_drawing.color_regs_aga[pv] & 0xffffff; break;
        case 0x10: ham_lastcolor &= 0xFFFF00; ham_lastcolor |= (pv & 0xF) << 4; break;
        case 0x20: ham_lastcolor &= 0x00FFFF; ham_lastcolor |= (pv & 0xF) << 20; break;
        case 0x30: ham_lastcolor &= 0xFF00FF; ham_lastcolor |= (pv & 0xF) << 12; break;
        }
    }
}

Instead of RGB components being modified to (hex) $xx, corresponding to $x OCS/ECS 4-bit values, the component was set to $x0.

The image defect will persist along the scanline, possibly getting worse if more than one component gets modified, until a pixel which is one of the sixteen base colours is reached.

The fix would be to change the expression (pv & 0xF) to, for example, ((pv & 0xF) * 0x11), so:

Code:

case 0x10: ham_lastcolor &= 0xFFFF00; ham_lastcolor |= (pv & 0xF) * 0x11; break;
case 0x20: ham_lastcolor &= 0x00FFFF; ham_lastcolor |= (pv & 0xF) * 0x11 << 16; break;
case 0x30: ham_lastcolor &= 0xFF00FF; ham_lastcolor |= (pv & 0xF) * 0x11 << 8; break;

Photon · 25 March 2016, 15:21

You may have a bug in your init code on top of this, but that doesn't change the fact that the same CF card booted in WinUAE displays these error lines with an A1200 config when a real A1200 doesn't. Running the same .exe.

In other words, there's a diff between emu and real Amiga and you can run Frazetta to verify it.

Toni Wilen · 25 March 2016, 15:28

Perhaps there is some misunderstanding (it is a bug and it is already fixed) but I only said that that code was supposed to be correct (and AGA was supposedly to work that way in HAM6) and thats why I never touched it even if it looked a bit suspicious.

Obviously it is wrong now that finally someone finally confirmed the difference (or more like lack of difference) using real hardware. That is the only thing that matters, nothing will be done unless something is real hardware confirmed.

Photon · 25 March 2016, 16:54

I think the confusion was caused by involving software. I think there's also a danger of compensating back and forth and get even more confused

Certainly a picture exported for HAM6 should not be changed just because it is shown by the AGA chipset, and I don't change any RGB color values after loading the pic to make it display correctly on AGA. The difference is still that it displays correctly on A1200-060 but not on emulated A1200-060 (both cold boot, no s-s).

It's quite visible, and also affects horizontally adjacent shades close to white. While the MODified component could still go across $8, I think the simple description is that AGA displays and handles HAM6 as OCS.

If it's fixed, I can't verify it, latest beta freezes on my PC. But just run Frazetta. It should not look like the pic in attachment.

Gallery --> here.

|
| EDIT: Got latest beta running, this seems to be fixed since October. Bah, lots of testing for nothing. I will still leave this here to say don't modify your HAM6 pictures or palette for display on AGA.
|

Foebane · 25 March 2016, 19:15

So the problem only occurs when displaying HAM6 images on HAM8 mode in AGA, and not in HAM6 mode in AGA, right?

mark_k · 25 March 2016, 21:11

Quote:

Originally Posted by Photon

| EDIT: Got latest beta running, this seems to be fixed since October. Bah, lots of testing for nothing. I will still leave this here to say don't modify your HAM6 pictures or palette for display on AGA.
|

You sure you tested with an AGA config? The problem is present in 3.3b9, fixed in latest winuae.7z (archive dated 2016-03-25 09:28).

Quote:

Originally Posted by Foebane

So the problem only occurs when displaying HAM6 images on HAM8 mode in AGA, and not in HAM6 mode in AGA, right?

No, it happened with HAM6 mode and emulated AGA chipset. Basically anything using HAM6 mode, when run on an emulated AGA machine could/would have had slightly wrong colours. (Not sure what you meant by displaying HAM6 images in HAM8 mode.)

Foebane · 25 March 2016, 21:35

Quote:

Originally Posted by mark_k

No, it happened with HAM6 mode and emulated AGA chipset. Basically anything using HAM6 mode, when run on an emulated AGA machine could/would have had slightly wrong colours. (Not sure what you meant by displaying HAM6 images in HAM8 mode.)

What I meant is I'm assuming that the AGA chipset has separate HAM6 and HAM8 display modes, and you simply use the right one depending on the image's colour bit depth and data?

Toni Wilen · 25 March 2016, 21:59

Yes.

HAM on/off is separate enable bit.

Technical detail: OCS/ECS HAM is always enabled when HAM enable bit is set, bitplane count is ignored. (for example some demos use "HAM4" or "HAM5" modes) but AGA only enables HAM mode if HAM enable bit is set AND bitplane count is 6 (=OCS/ECS compatible HAM6 enabled) or 8 (=AGA HAM8 enabled).

ReadOnlyCat · 29 March 2016, 04:54

Quote:

Originally Posted by Toni Wilen

Technical detail: OCS/ECS HAM is always enabled when HAM enable bit is set, bitplane count is ignored. (for example some demos use "HAM4" or "HAM5" modes) but AGA only enables HAM mode if HAM enable bit is set AND bitplane count is 6 (=OCS/ECS compatible HAM6 enabled) or 8 (=AGA HAM8 enabled).

Oh...
Does this mean HAM4 & HAM5 do not exist on AGA machines?

Toni Wilen · 29 March 2016, 08:44

Quote:

Originally Posted by ReadOnlyCat

Oh...
Does this mean HAM4 & HAM5 do not exist on AGA machines?

Yes, unfortunately. Only HAM6 or HAM8. Any other plane count with HAM bit set will not enable HAM mode.

25 March 2016, 02:39	#1
Photon Moderator Join Date: Nov 2004 Location: Eksjö / Sweden Posts: 5,602	HAM6 on AGA in WinUAE displays incorrectly (I'm sorry, I don't have latest beta but maybe someone can help me verify if this is still valid? So Toni doesn't waste time.) This thread brought it to my attention just now, and I get the same short lines in the face there as ahemm on the rump of the naked lady in Frazetta, and a few more. Since it worked on A500 and A1200, I just didn't notice it. I tested now that it also works on A500 emu in WinUAE. But not on A1200 in WinUAE. We all know there's some rounding down below $8 and rounding up >=$8 on AGA but I just don't see the lines on my A1200 with CRT. Last edited by Photon; 25 March 2016 at 02:45.

25 March 2016, 11:54	#4
mark_k Registered User Join Date: Aug 2004 Location: Posts: 3,333	Well, I meant fairly obvious once you're aware the problem exists, and that some pixels in HAM6 images on AGA have $x0 colour components instead of $xx. For anyone that's interested, the bug was this code: Code: } else { /* AGA mode HAM6 / while (unpainted_amiga-- > 0) { int pv = pixdata.apixels[ham_decode_pixel++] ^ bplxor; switch (pv & 0x30) { case 0x00: ham_lastcolor = colors_for_drawing.color_regs_aga[pv] & 0xffffff; break; case 0x10: ham_lastcolor &= 0xFFFF00; ham_lastcolor \|= (pv & 0xF) << 4; break; case 0x20: ham_lastcolor &= 0x00FFFF; ham_lastcolor \|= (pv & 0xF) << 20; break; case 0x30: ham_lastcolor &= 0xFF00FF; ham_lastcolor \|= (pv & 0xF) << 12; break; } } } Instead of RGB components being modified to (hex) $xx, corresponding to $x OCS/ECS 4-bit values, the component was set to $x0. The image defect will persist along the scanline, possibly getting worse if more than one component gets modified, until a pixel which is one of the sixteen base colours is reached. The fix would be to change the expression (pv & 0xF) to, for example, ((pv & 0xF) 0x11), so: Code: case 0x10: ham_lastcolor &= 0xFFFF00; ham_lastcolor \|= (pv & 0xF) * 0x11; break; case 0x20: ham_lastcolor &= 0x00FFFF; ham_lastcolor \|= (pv & 0xF) * 0x11 << 16; break; case 0x30: ham_lastcolor &= 0xFF00FF; ham_lastcolor \|= (pv & 0xF) * 0x11 << 8; break;

25 March 2016, 16:54	#7
Photon Moderator Join Date: Nov 2004 Location: Eksjö / Sweden Posts: 5,602	I think the confusion was caused by involving software. I think there's also a danger of compensating back and forth and get even more confused Certainly a picture exported for HAM6 should not be changed just because it is shown by the AGA chipset, and I don't change any RGB color values after loading the pic to make it display correctly on AGA. The difference is still that it displays correctly on A1200-060 but not on emulated A1200-060 (both cold boot, no s-s). It's quite visible, and also affects horizontally adjacent shades close to white. While the MODified component could still go across $8, I think the simple description is that AGA displays and handles HAM6 as OCS. If it's fixed, I can't verify it, latest beta freezes on my PC. But just run Frazetta. It should not look like the pic in attachment. Gallery --> here. \| \| EDIT: Got latest beta running, this seems to be fixed since October. Bah, lots of testing for nothing. I will still leave this here to say don't modify your HAM6 pictures or palette for display on AGA. \| Attached Thumbnails Last edited by Photon; 25 March 2016 at 17:07.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
HAM6 output different on AGA vs OCS (UAE)	alpine9000	Coders. Asm / Hardware	30	03 May 2019 01:22
Batch conversion of Truecolour images to HAM6	earok	support.Apps	0	20 May 2015 11:02
Converting JPG to HAM6/EHB with ImageStudio	jman	support.Apps	0	21 June 2011 17:42
FIXED: Blob (Unpacked incorrectly)	rare_j	project.Killergorilla's WHD packs	10	13 September 2007 10:42
Displays	BippyM	support.WinUAE	3	17 August 2003 14:34

25 March 2016, 02:45	#2
mark_k Registered User Join Date: Aug 2004 Location: Posts: 3,333	Yep, problem caused by same mistake in init_ham_decoding() and decode_ham() in drawing.cpp. Fairly obvious once you see it.

25 March 2016, 08:55	#3
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,502	I never fixed that "obvious" bug because it supposedly was correct and I never bothered to confirm it myself.

25 March 2016, 15:21	#5
Photon Moderator Join Date: Nov 2004 Location: Eksjö / Sweden Posts: 5,602	You may have a bug in your init code on top of this, but that doesn't change the fact that the same CF card booted in WinUAE displays these error lines with an A1200 config when a real A1200 doesn't. Running the same .exe. In other words, there's a diff between emu and real Amiga and you can run Frazetta to verify it.

25 March 2016, 15:28	#6
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,502	Perhaps there is some misunderstanding (it is a bug and it is already fixed) but I only said that that code was supposed to be correct (and AGA was supposedly to work that way in HAM6) and thats why I never touched it even if it looked a bit suspicious. Obviously it is wrong now that finally someone finally confirmed the difference (or more like lack of difference) using real hardware. That is the only thing that matters, nothing will be done unless something is real hardware confirmed.

25 March 2016, 19:15	#8
Foebane Banned Join Date: Sep 2011 Location: Cardiff, UK Age: 51 Posts: 2,871	So the problem only occurs when displaying HAM6 images on HAM8 mode in AGA, and not in HAM6 mode in AGA, right?

25 March 2016, 21:59	#11
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,502	Yes. HAM on/off is separate enable bit. Technical detail: OCS/ECS HAM is always enabled when HAM enable bit is set, bitplane count is ignored. (for example some demos use "HAM4" or "HAM5" modes) but AGA only enables HAM mode if HAM enable bit is set AND bitplane count is 6 (=OCS/ECS compatible HAM6 enabled) or 8 (=AGA HAM8 enabled).

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)