View Single Post
Old 01 February 2020, 12:31   #4
Per aspera ad astra

ross's Avatar
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 2,545
Originally Posted by mcgeezer View Post
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 :)
ross is offline  
Page generated in 0.04235 seconds with 11 queries