[stella] BCD again (nearly there!)

[seagtgruff at aol.com]

Forgive my previous two mis-sends; I had a little problem replying. :)

Gabriel wrote:

> 2009/4/19? <seagtgruff at aol.com>:
> > result = (AH << 4) + (AL & 15) ; ... This wasn't explicitly given in the
> > code. I tried to use notation that looks like the rest of the code.
> >
>
> You need the mask & 255
>
> result = (AH << 4) + (AL & 15) & 255;
>
> because when you`ve done "if (AH & 16) AH -= 6" you can have AH[15..4]
> = 1, and you need to cut them off

Okay, that makes sense, except shouldn't there be another pair of parenthese there... or does the + take precedence over the &?

result = ((AH << 4) + (AL & 15)) & 255;

I was forgetting that just because *I'm* working with bytes (i.e., inside an Atari 2600 program), so *I* don't have to worry about values greater than 255, the C code is being run on processors that will definitely be using more than 8 bits for their numeric variables-- well, unless you specifically declare AL and AH to be bytes, I suppose.

> > (1) If AL has already been adjusted in line 2, then its value in line 3 will
> > be different, won't it?
>
> Yes!
>
> >
> > (2) The example Bob gave shows - 1 for - (AL & 16). Wouldn't (AL & 16) be 16
> > if bit 4 is set, rather than 1? In other words, is it supposed to be a bit
> > masking operation, or a logical true/false condition? If (A & 15) indicates
> > a bit masking operation to retrieve the lo nybble of A, then isn't (AL & 16)
> > a bit masking operation, too?
> >
>
> you are right... if it is a bit masking then the sum should have
> something like ((AL & 16) >> 3)... if it is logical... then it is
> right... I`ll test it for C.

Would the logical operation use && instead of &, as follows?

AH = (A >> 4) - (S >> 4) - (AL && 16);

If that's the case, then another version of the code could be as follows:

AL = (A & 15) - (S & 15) - !C;
AH = (A >> 4) - (S >> 4) - (AL && 16);
if (AL & 16) AL -= 6;
if (AH & 16) AH -= 6;

> > (expected) result anywhere. Now I still need to code and test the logic for
> > the flags.
> >
>
> "Bonne chance"

The flags were simple to do in my program, but that's because the flags for decimal SBC are determined the same they are for binary SBC, and the emulation for binary SBC doesn't seem to be buggy, so I was able to cheat:

??? CLD
??? SEC
??? LDA number1
??? SBC number2
??? PHP
??? PLA
??? STA expected_flags

Since the emulation for binary SBC is giving the correct flags, there shouldn't be any problem for Stephen to just copy that logic from the emulation of binary SBC. But if the timing of when you figure the flags makes a difference in what their results will be (i.e., before or after the various "nybble fixes"), then from the way I understand it, the best time to determine the flags would be right after the first two lines of the rearranged code:

AL = (A & 15) - (S & 15) - !C;
AH = (A >> 4) - (S >> 4) - (AL && 16);
; now figure the N, V, Z, and C flags, exactly as done for binary SBC
if (AL & 16) AL -= 6;
if (AH & 16) AH -= 6;
R?= ((AH << 4) + (AL & 15)) & 255;

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://atari2600.org/pipermail/stella/attachments/20090420/f522e2bf/attachment-0001.html>