Hello,
I would want to play with minterm in my graphics tests.
Reading the autodoc and .h file (I don't remember the name now), it is a bit complicated without help.
I mean those ABN, BAN or whatever are very cryptic to me.
Any info?
Sat, 2017-09-09 13:19
#1
Use of minterm
Rather than using those macros you can fill in a truth table and get the minterm value directly.
The A, B and C columns are the input channels and the D column is the output channel. For each bit combination you write what you want the result to be in the D column (either 0 or 1) and once you are done you read it from bottom to top to get your minterm as a binary number.
Do note that if you are using RTG then only a few common minterms are supported and the rest will be no-ops.
Also I must say that I don't really know which input channels the system blit calls use for what so you might have to experiment a bit.
To give an example, for a simple copy from input channel A the minterm would be:
%11110000 = 0xF0
This should really be documented. I find it extremely difficult to get this information from experiments. Your example of 0xf0 even contradicts the documentation.
These are the minterms documented in the autodocs:
So for me it seems that channel A is used as kind of mask, even if you don't blit trough a mask. If A is 0 the result is 0, too. Only where A is 1 the other channels are used. For BltBitMap it's obvious that B is the source and C is the destination bitplane.
However, I have no idea how BltMaskBitMapRastPort works. Again channel A seems to be used as a global condition, but then there are not enough channels left for source, dest and mask.
I said 0xF0 is the minterm for A->D copy, which it is, this contradicts nothing. 0xC0 which is listed above as "vanilla copy" is (A & B) -> D.
If you use the blitter directly then you can use the blitter input channels however you want and that is where most of my experience stems from, hence why I said: "Also I must say that I don't really know which input channels the system blit calls use for what so you might have to experiment a bit.".
BTW to do a straight copy with the blitter you should only use of one of the input channels. Using any more than this just makes the blit take longer for no added benefit. If an input channel is disabled then you can set it to a constant 16-bit value (can be useful for simple patterns and such).
All that is nice explained and well known from a hardware perspective. But I am not talking about hacking the hardware, I talk about graphics.library functions BltBitMapRastPort and BltMaskBitMapRastPort. They ask for MinTerms but do not give any explanation how they use the blitter channels and as far as I can see there is no way to influence the channel usage. So it's nice to know that using less channels speeds thing up and how MinTerms combine blitter channels. But when using these functions, the blitter channels are preselected and it's not documented which channel is used for which purpose or how MinTerms are constructed for these functions.
It would be much easier if the examples given in the autodocs would be better explained, but they aren't. They only state that for a "vanilly copy" you should use 0xc0. Of course I know that 0xc0 is not A->D but A&B->D. But why? Why is 0xc0 a vanilla copy when common sense would use 0xf0?
And why is 0xe0 to be used for blit through mask while common sense would say 0xca or 0xe2?
Looking at the blitter docs more closely (because it's been a while since I last wrote any blitter code) the channel A would have to be used as a mask because otherwise the functions wouldn't be able to handle unaligned blits (where either the destination x coordinate or width is not a multiple of 16) because the BLTAFWM and BLTLWM (first word mask and last word mask) only exist for this channel (for unmasked functions the channel A can still be disabled and BPLADAT set to 0xFFFF).
Also channel B has to be the source because barrel rolling is only supported for channels A and B, which leaves channel C as the destination (channel C is needed for both masked and unmasked because of unaligned blits).
All this in turn means that none of the minterms you quoted seem to make any sense...
Thanks to both of you.
I have a headache now! I didn't understand all.
I agree with Thomas, this would be more and better explained in the autodocs.
If anyone of the charming guys here is going to the AmiWest Devcon 2017, please chat with Solie may be with a beer... I am sure that he will agree with this...
I looked a bit more into this and what I've found so far is that BltBitMap() and friends mask the minterm first with 0xF0, which means that anything you set in the lower 4 bits is ignored, and after that it ors it with (NABC+NANBC) which goes to explain why the documented minterms don't directly correspond to what you would use when programming the blitter directly (like why vanilla copy is 0xC0 instead of 0xCA).
Taking this into account if you want to do any more advanced blitter operations than the basic ones documented in the table thomas mentioned you will want to use the blitter directly with OwnBlitter(), WaitBlit() and DisownBlitter().
If you are interested in doing more advanced graphics operations in RTG (i.e. for non-Classic Amigas) you should really look into Warp3D Nova and shaders.