English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 16 January 2017, 12:10   #1
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 212
Question Colourswitching with BPLCON4 register in HAM-Mode (AGA)

I tried to code a vertical screensplit with two HAM8 160x256 pixel pictures put together on a 320x256 lo-res screen on a real A1200/020. The first (left) one should use colours 0-64 the second one colours 64-127. I’ve done this with the copper which waits twice per scanline to change BPLCON4’s contents. The first time at the beginning (BPLAM=0) and second time in the middle (BPLAM=64) of the scanline.

But the colourswitching doesn't work. The colours 64-127 are not used. Using BPLAM=64 the second (right) HAM8 picture uses the colours 0-63 but not in the right order.

I also tested the colourswitch on a HAM6 screen and the values BPLAM=0 & BPLAM=16. It is apparent that the content of the BPLCON4 register is totally ignored when you change it every scanline with the copper. The second (right) picture uses exactly the same palette (colours 0-15) as the first (left) one.

I know that HAM pixels behave different than normal pixels, but it's strange that it doesn't work. I thought selecting a colour value from a colour registers by the value 00 in the modify planes works the same way as on standard screens. Messing up the palette of the second picture on a HAM8 screen seems to be a side effect using plane 0-1 for modify and not plane 6-7.

Funnily enough, the same routine works fine on a normal lo-res screen with 128 colours and 7 bitplanes. The first picture uses colours 0-127, the second one colours 128-255.

The question is, if the use of colourswitching with the BPLCON4 register really works on HAM6/HAM8 screens? Maybe, you, Toni, could enlighten me.
dissident is offline  
Old 16 January 2017, 14:13   #2
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 22,460
First question is: does it work in winuae? It sounds it does not! If answer is not, I need a test case as usual

I'd have assumed BPLCON4 only "scrambles" palette selection but it seems to be something more complex (or more likely, some ugly hack)
Toni Wilen is online now  
Old 16 January 2017, 15:24   #3
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,404
Isn't it just some number that gets XOR'ed to the pixel value once it has been converted from planar data ?
meynaf is offline  
Old 16 January 2017, 21:57   #4
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 212
Quote:
Originally Posted by Toni Wilen View Post
First question is: does it work in winuae? It sounds it does not! If answer is not, I need a test case as usual
It does not work in winua, so I sent you three test exe-files (128 colours, HAM6 & HAM8 for each picture).
dissident is offline  
Old 17 January 2017, 21:59   #5
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 22,460
Quote:
Originally Posted by meynaf View Post
Isn't it just some number that gets XOR'ed to the pixel value once it has been converted from planar data ?
Apparently it isn't that simple in HAM mode. (HAM mode most likely does some tricks with palette selection)

Quote:
Originally Posted by dissident View Post
It does not work in winua, so I sent you three test exe-files (128 colours, HAM6 & HAM8 for each picture).
Thanks. I'll check them later this week.

Can you do some more tests to see how the colors change? BPLCON4 most likely still does the XOR operation but some bits may be simply swapped in HAM mode. For example set all colors to black except one, then check which BPLCON4 bits (set only single bit to one) change the color and which ones don't.
Toni Wilen is online now  
Old 17 January 2017, 22:25   #6
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 212
Quote:
Originally Posted by Toni Wilen View Post
Can you do some more tests to see how the colors change? BPLCON4 most likely still does the XOR operation but some bits may be simply swapped in HAM mode. For example set all colors to black except one, then check which BPLCON4 bits (set only single bit to one) change the color and which ones don't.
Good idea, I can check this. I guess this means that I only check the BPLAM-values 1,2,4,8,16 for HAM6 and 1,2,4,8,16,32,64 for HAM8 in conjunction with a certain colour. Right?

By the end of this week I should have some results for you.
dissident is offline  
Old 17 January 2017, 22:48   #7
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 22,460
Test all bits, I suspect that BPLCON4 bits to color index mapping may be shifted or multiple bits have identical behavior in HAM modes.

EDIT: Better divide this to 2 steps: first find out which "XOR" bits affect HAM8 mode color selection and which don't. Same for HAM6. Then try to find out how it actully works (which bit maps to which color selection, or if there is something more complex going on)

Last edited by Toni Wilen; 18 January 2017 at 09:46.
Toni Wilen is online now  
Old 18 January 2017, 22:17   #8
chaos
Registered User

chaos's Avatar
 
Join Date: Mar 2013
Location: Slovenia
Posts: 135
Hi Toni,

could you please forward those three test files, so I can see if this works on minimig?

Thanks!
chaos is offline  
Old 21 January 2017, 21:29   #9
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 22,460
I couldn't wait so did some quick tests. Mystery is also solved.

HAM has 3 different "parameters" (everyone reading this should already know it):
- selection bits (5 and 6 if HAM6, 0 and 1 if HAM8)
- palette index (0-15 if HAM6, 0-63 if HAM8), if selection bits are 0.
- R/G/B replacement value if selection bits are non-zero. (0-15 if HAM6, 0-63 if HAM8)

Selection bits are XOR'd with BPLCON4 XOR value. If HAM6: bits 5 and 6 are XOR'd with bits 5 and 6 of XOR value. HAM8: bits 0 and 1 with bits 0 and 1 of XOR value. Nothing interesting.

Palette index is also XOR'd. if HAM6: bits 0 to 3 are XOR'd with bits 0 to 3 of XOR value. Bits 4 to 7 are zeroed before palette selection. If HAM8: bits 2 to 7 are first XOR'd with XOR value bits 2 to 7, then shifted to bit positions 0 to 5, bits 6 and 7 gets zeroed.

XOR value does not affect RGB replacement value. Both HAM6 and HAM8 have same behavior.
Toni Wilen is online now  
Old 21 January 2017, 22:10   #10
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 22,460
AGA EHB also seems to have at least one unexpected feature:

It seems half-brite selection bit value (plane 6) is taken before XOR operation. XOR $20 won't make the whole display darker (if plane 6 is cleared) but instead it works like normal mode, color 0 becomes color 32, color 1 becomes color 33 (with normal brightness) and so on.

Quote:
Originally Posted by chaos View Post
could you please forward those three test files, so I can see if this works on minimig?
Don't ask me, they aren't my files.
Toni Wilen is online now  
Old 22 January 2017, 21:23   #11
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 212
Quote:
Originally Posted by Toni Wilen View Post
I couldn't wait so did some quick tests. Mystery is also solved.

HAM has 3 different "parameters" (everyone reading this should already know it):
- selection bits (5 and 6 if HAM6, 0 and 1 if HAM8)
- palette index (0-15 if HAM6, 0-63 if HAM8), if selection bits are 0.
- R/G/B replacement value if selection bits are non-zero. (0-15 if HAM6, 0-63 if HAM8)

Selection bits are XOR'd with BPLCON4 XOR value. If HAM6: bits 5 and 6 are XOR'd with bits 5 and 6 of XOR value. HAM8: bits 0 and 1 with bits 0 and 1 of XOR value. Nothing interesting.

Palette index is also XOR'd. if HAM6: bits 0 to 3 are XOR'd with bits 0 to 3 of XOR value. Bits 4 to 7 are zeroed before palette selection. If HAM8: bits 2 to 7 are first XOR'd with XOR value bits 2 to 7, then shifted to bit positions 0 to 5, bits 6 and 7 gets zeroed.

XOR value does not affect RGB replacement value. Both HAM6 and HAM8 have same behavior.
Well, I have some different results. I used HAM6/HAM8 horizontal colourruns for red, green and blue.

It was all tested on real hardware, an A1200/020, and also with WinUAE 3.3.0. There are many differences between real hardware and WinUAE. See more details in the excel-tables. I have faced there the behaviour of the real hardware against WinUAE 3.3.0.

HAM6: On real hardware BPLAM>=64 is ignored, if HAM-Mode is set. BPLAM <64 affects the selection of colour registers and the fetch of the RGB values.

HAM8: On real hardware BPLAM <= 4 affects the fetch of the RGB values. The selection of colour registers is not changed setting BPLAM>4, if HAM-mode is set.

If you need any testfiles for the cases, then I can send them to you, Tony.
Attached Files
File Type: zip BPLCON4-HAM.zip (109.7 KB, 41 views)
dissident is offline  
Old 22 January 2017, 21:51   #12
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 22,460
You results do not match your previous test files. HAM8 color palette index selection is clearly affected by BPLAM>=4. -> Test files needed.

(winuae.7z has updated logic and shows correct colors when using your previous test files)

EDIT: I did all testing in "reverse direction", set some garbage HAM mode screen, then tried to find out how to make it appear identically in emulation. I may have missed some side-effects.

Last edited by Toni Wilen; 22 January 2017 at 22:33.
Toni Wilen is online now  
Old 22 January 2017, 23:07   #13
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 212
Quote:
Originally Posted by Toni Wilen View Post
You results do not match your previous test files. HAM8 color palette index selection is clearly affected by BPLAM>=4. -> Test files needed.

(winuae.7z has updated logic and shows correct colors when using your previous test files)

EDIT: I did all testing in "reverse direction", set some garbage HAM mode screen, then tried to find out how to make it appear identically in emulation. I may have missed some side-effects.
Just wait. I guess you may be right. I've spent too many hours with that theme. I will check my routine with different pictures and the tables again tomorrow.
dissident is offline  
Old 23 January 2017, 22:33   #14
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 212
Quote:
Originally Posted by Toni Wilen View Post
You results do not match your previous test files. HAM8 color palette index selection is clearly affected by BPLAM>=4. -> Test files needed.

(winuae.7z has updated logic and shows correct colors when using your previous test files)

EDIT: I did all testing in "reverse direction", set some garbage HAM mode screen, then tried to find out how to make it appear identically in emulation. I may have missed some side-effects.

I did the test again with different pictures and updated my excel:

Main differences:
HAM6/BPLAM=64
Hardware: colouroffset=0
WinUAE: colouroffset=64

HAM6/BPLAM=65
Hardware: colouroffse= 1
WinUAE: colouroffset=65

It seems hardware cuts in HAM6-mode BPLAM and uses only BPLAM0-BPLAM5.

Yes, HAM8 color palette index selection is clearly affected by BPLAM>=4. There I was wrong. It seems that BPLAM>=4 is shifted 2 bits to the right. So the colour palette index BPLAM=64 starts with colour register 16 and not 64.

Toni, I've sent you my testfiles relating to my excel-table.
Attached Files
File Type: zip BPLCON4-with-HAM.zip (153.0 KB, 45 views)
dissident is offline  
Old 23 January 2017, 23:21   #15
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 22,460
Thanks. I compared all your test programs and there was no differences between real A1200 and updated emulation.
Toni Wilen is online now  
Old 15 February 2019, 20:01   #16
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,522
Sorry for resurrecting this, but i've to understand.

I'm in the making of an HAM8 effect that require base color starting from an upper bank position (>=32).
After setting BPLAM=64 i've noticed that colors are scrambled, tried to figure out if it was my fault , then searched for an explanation and found this thread.

From dissident:
Quote:
Originally Posted by dissident View Post
It seems that BPLAM>=4 is shifted 2 bits to the right. So the colour palette index BPLAM=64 starts with colour register 16 and not 64.
And Toni:
Quote:
Originally Posted by Toni Wilen View Post
If HAM8: bits 2 to 7 are first XOR'd with XOR value bits 2 to 7, then shifted to bit positions 0 to 5, bits 6 and 7 gets zeroed.
This practically mean that we can change the base for the colors selection, but anyway the selected color 'wraps itself' in the first 64 positions.
Making it impossible to use a full base HAM8 palette in the upper banks (pos. 64~255)..

Did I get it right?
ross is offline  
Old 15 February 2019, 21:20   #17
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,522
Ok, found a possible bug in WinUAE emulation.
It arise when HAM8 AND BPLAM>0 AND 64bit sprites used. All works as expected with BPLAM=0.
A strange big shift and gradient effect on bitplanes.
It's also interesting but it seems impossible for a real machine

Toni, I PM you a link (file cannot yet be made public).
ross is offline  
Old 16 February 2019, 10:46   #18
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 22,460
Quote:
Originally Posted by ross View Post
This practically mean that we can change the base for the colors selection, but anyway the selected color 'wraps itself' in the first 64 positions.
Making it impossible to use a full base HAM8 palette in the upper banks (pos. 64~255)..

Did I get it right?
Yeah. Unfortunately HAM8 "hidden" palette bits 6 and 7 are always ignored, even if XOR operation would have set them.

Quote:
Originally Posted by ross View Post
Ok, found a possible bug in WinUAE emulation.
Your test has one of the most complex display emulation situation:
- HAM
- BPLCON4 non-zero
- Border sprites

This requires multiple passes per scanline (one for HAM calculation, one for sprites, until final output is created) and there seems to be problem with left border position calculation in different passes, most likely due to border sprites that makes left border move towards left if bitplanes start later than sprite. (It would be waste of CPU time to assume left border is always as left as possible if there is nothing visible)

Fixing..
Toni Wilen is online now  
Old 16 February 2019, 11:51   #19
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 22,460
Fixed. Real A1200 confirmed too.
Toni Wilen is online now  
Old 16 February 2019, 12:10   #20
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,522
Great! Thanks for all.
ross is offline  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
Help needed with HAM mode and Photon Paint trydowave support.Apps 10 12 March 2013 21:49
Quite bad graphics corruption in DPAINT HAM MODE ral-clan support.WinUAE 11 24 May 2012 03:30
AGA color depth - HAM style NovaCoder Coders. General 6 18 July 2009 16:22
indivision aga and ham mode pbareges support.Hardware 3 03 February 2009 13:25
Game that used 'HAM' mode Big-Byte Looking for a game name ? 24 28 August 2002 11:37

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 15:03.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.10774 seconds with 16 queries