English Amiga Board Amiga Lore


Go Back   English Amiga Board > Support > support.WinUAE

 
 
Thread Tools
Old 25 March 2016, 02:39   #1
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,437
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.
Photon is offline  
AdSense AdSense  
Old 25 March 2016, 02:45   #2
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,483
Yep, problem caused by same mistake in init_ham_decoding() and decode_ham() in drawing.cpp. Fairly obvious once you see it.
mark_k is offline  
Old 25 March 2016, 08:55   #3
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,565
I never fixed that "obvious" bug because it supposedly was correct and I never bothered to confirm it myself.
Toni Wilen is online now  
Old 25 March 2016, 11:54   #4
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,483
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;
mark_k is offline  
Old 25 March 2016, 15:21   #5
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,437
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.
Photon is offline  
Old 25 March 2016, 15:28   #6
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,565
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.
Toni Wilen is online now  
Old 25 March 2016, 16:54   #7
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,437
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
Click image for larger version

Name:	107b.png
Views:	237
Size:	37.4 KB
ID:	48012  

Last edited by Photon; 25 March 2016 at 17:07.
Photon is offline  
Old 25 March 2016, 19:15   #8
Foebane
Registered User
 
Join Date: Sep 2011
Location: Cardiff, UK
Posts: 442
So the problem only occurs when displaying HAM6 images on HAM8 mode in AGA, and not in HAM6 mode in AGA, right?
Foebane is offline  
Old 25 March 2016, 21:11   #9
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,483
Quote:
Originally Posted by Photon View Post
| 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 View Post
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.)
mark_k is offline  
Old 25 March 2016, 21:35   #10
Foebane
Registered User
 
Join Date: Sep 2011
Location: Cardiff, UK
Posts: 442
Quote:
Originally Posted by mark_k View Post
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?
Foebane is offline  
Old 25 March 2016, 21:59   #11
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,565
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).
Toni Wilen is online now  
Old 29 March 2016, 04:54   #12
ReadOnlyCat
Code Kitten

 
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 46
Posts: 1,005
Quote:
Originally Posted by Toni Wilen View Post
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?
ReadOnlyCat is offline  
Old 29 March 2016, 08:44   #13
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,565
Quote:
Originally Posted by ReadOnlyCat View Post
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.
Toni Wilen is online now  
AdSense AdSense  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
HAM6 output different on AGA vs OCS (UAE) alpine9000 Coders. Asm / Hardware 29 05 April 2016 19:03
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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 22:16.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.27757 seconds with 12 queries