The rounding capability is useful when doing fixed point math with exactly eight fractional digits. For example, supposing that the number in A is a fixed-point number with 2 fractional digits, and the number in B is a fixed-point number with 6 fractional digits. This gives a result with 8 fractional digits:
lda #%00100010 A=%001000.10=8.5
ldb #%11110000 B=%11.110000=3.75
If we only want the integer result, we could take the most significant byte of the result, which throws away the fractional part:
sta result Stores truncated result, 31
However, since the C flag has been set to the most significant fractional digit:
C flag set to 1 to match this digit
We can round the integer result easily:
adca #0 A=32 (rounded result)
That gives us a more accurate result for this weird corner case where our fixed point multiplicands have exactly eight fractional digits between them.
Approximating division more accurately
If doing fixed point math with exactly eight fractional digits seems like a weird thing to build in support for, consider that it let lets you improve accuracy when approximating division of one eight-bit integer by an integer constant. The 6809 doesn't have hardware division, but if you can accept the result being sometimes off by one, then the approximation is quick and easy, multiplying by the reciprocal of the dividend, converted to a fixed-point binary fraction. You can do this without rounding and get results that are close, but often off by one. With rounding, you improve accuracy and get results that are more often correct.
Let's divide 2 by 3. This is done by multiplying 2 by 1/3. We can't represent 1/3 exactly in binary, but we can get close:
ldb #%01010101 B=%.01010101=0.33203125
The integer part of the result is 0, which is only one off from the actual integer result, but we can do better:
adca #0 A=%00000001=1
For this case, where we are approximating dividing by three, then trying all 256 possible divisors without rounding gives us a mean absolute error of 0.66. Not bad. But with rounding, the mean absolute error goes down to 0.28. Now the majority of the integer results are exactly correct.