Thread: Bitplane Calculations View Single Post
01 February 2020, 12:31   #4
ross

Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 2,545
Quote:
 Originally Posted by mcgeezer So I'm fairly sure in that I'm right about the \$CA minterm function being the cause of the problem here. What is happening is the mask is controlling whether a 1 or 0 is set in the destination bitplane. From the HRM..."When blitting the car to the background we would want to use a function that, whenever the car mask (fetched with DMA channel A) had a bit set, we would pass through the car data from B, and whenever A did not have a bit set, we would pass through the original background from C. The corresponding function, commonly referred to as the cookie-cut function, is AB+AC, which works out to an LF code value of \$CA." What needs to happen is the car data needs to be OR'd into the original background C. Not sure if the blitter is capable of this with one go.
Hi Graeme, just a quick answer, maybe I'll look at it better later (I didn't follow the Rolling Thunder thread from which I think it all started),
but there are some inaccuracies in your reasoning.

\$CA minterm is D=A'C+AB (not AC+AB) and is already an OR (masked) to destination.
A (the mask) is not a selector for 0 or 1 but B or C (from the equation, if A=1 select B, if A=0 select C).
Of course you can exclude the mask from the equation, but B thus loses meaning in the selection of source colors.
EDIT: 0 or 1 in source B can have a significance for other planes too, you must be sure that B bit is in the destination when (mask)A=1

Anyway if you want D=B+C the minterm is \$EE (and you can disable A source so BLTCON0=\$07EE).
If you want to avoid too many blitter idle cycles you can use A as image source so D=A+C, minterm \$FA, BLTCON0=\$0BFA (a pretty standard blitter OR usage).

Last edited by ross; 01 February 2020 at 13:06. Reason: I struggle with English to make me understandable :)

Page generated in 0.04235 seconds with 11 queries