[Simh] DAA Emulation

[Richard Cini]

Al --

    Thanks a lot for the email. I¹m sure you looked at this, but I pulled
the Intel 8080 Users Manual and under DAA, it says the following (snipping a
bit):

    The 8-bit number in the accumulator is adjusted to form two 4-bit [BCD]
digits by the following process:

        (1) If the value of the least significant 4 bits is greater than 9
or if the AC flag is set, 6 is added to the accumulator.
        (2) if the value of the most significant 4 bits is now greater than
9 or if the CY flag is set, 6 is added to the most significant 4 bits of the
accumulator.

    Based on this, I would say that the second part of the test in the
Altair32 code is wrong. Further, it looks like the SIMH code may be wrong as
well because it doesn¹t test the CY flag in the second test.

    As far as the register display, I¹ll make that change ‹ oddly no one has
ever reported it.

    Thanks again for locating this bug.

Rich

--
Rich Cini
Collector of Classic Computers
Build Master and lead engineer, Altair32 Emulator
http://www.altair32.com
http://www.classiccmp.org/cini



On 12/11/10 1:32 AM, "Al Williams" <al.williams at awce.com> wrote:

> Hi Rich and Bob,
> 
> I've been doing some work on Vince Briel's excellent AVR emulation of the 8080
> and while rewriting DAA I came across what I think to be a harmless bug but
> thought you might want to comment on it.
> 
> From what I can glean DAA effects all flags including half carry. And I
> _think_ that half carry occurs from the +6 (if it happens at all). So if you
> don't adjust the LSD you get AC=0. If you add 6 then if adding the 6 gives you
> a carry out of Bit 3 you get AC set. Note that the carry might ripple so
> that's NOT to say Bit 4 is necessarily 1.
> 
> Here's part of Altair32's code:
> 
> static void daa ( OP_ARG_U ) 
> {
> // Decimal Adjust Accumulator
> // DAA:: A=BCD format
> // Flags: SZAPC
> // *****
> 
> register /* FJS */ word tmp = ACCUM;
> 
> if ( (( tmp & 0x0f ) > 0x09 ) || ( FLAGS & AC_FLAG ))
> tmp += 0x06;
> 
> if (tmp > 0x0f)
> FLAGS |= AC_FLAG; // if adjusted LSB > 0xf, set AC
> else
> FLAGS &= ~AC_FLAG; // else clear SC
> 
> 
> So since tmp is not masked off, any value >0xF gets AC set even if no carry or
> add occurred! In other words, pretend the value of ACCUM is 90 (and thus temp
> is 90) with AC=0. The first if does not fire. The second if does and AC gets
> set. That's got to be wrong. Granted, who checks AC after DAA? But still.... 
> 
> 
> So why copy Bob? Well... I think SIMH has a similar but different problem.
> Here's a snip from the DAA code:
> 
> /*opcode=0x27*/
> static void i86op_daa(PC_ENV *m)
> {
>    uint16 dbyte;
>    dbyte = m->R_AL;
>    if (ACCESS_FLAG(m,F_AF)|| (dbyte&0xf) > 9)
>      {
>     dbyte += 6;
>     if (dbyte&0x100)
>       SET_FLAG(m, F_CF);
>     SET_FLAG(m, F_AF);
>      }
>    else
> 
> 
> Here we add 6 to dbyte and then AC is always set. If no +6 then AC is cleared.
> This COULD be correct behavior, but I can't find any reference material that
> says it is. In any event, SIMH and Altair32 are doing something different
> here, so they both can't be right. Meanwhile I have my own version of DAA in
> AVR assembler that I will spare you unless you ask. The only real silicon I
> have even close to operational at the moment is a Z80 and not only is it not
> operational, the DAA is one place where it is a lot different so I don't trust
> the result there.
> 
> Oh. One other note about Altair32. In the debugger, the A and FLAGS display is
> swapped in the debug console window. The Register display up top left is ok
> though. I bet you've heard that one before.
> 
> If either of you can show documentation on the AC flag after DAA or point to a
> real piece of silicon's behavior I'd like to know so I can fix the DAA code in
> the Briel emulator to match. Otherwise, I thought you'd like to know about
> this bug even though it is pretty innocuous as far as I can tell.
> 
> 
> Al Williams
> http://www.ddj.com/embedded (among others)
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20101211/9c31adb2/attachment-0002.html>