[Simh] DAA Emulation

[Al Williams]

Yeah I've read the docs, but even what you pasted in doesn't directly answer
the question: What is the state of the AC flag after a DAA? So I think the
code correctly implements the additions you mentioned. But I think we all 3
disagree on the AC flag code. Notice I didn't copy the whole function in
either case, so the handling of the MSD is "not shown".




On Sat, Dec 11, 2010 at 8:16 AM, Richard Cini <rich.cini at verizon.net> wrote:

>  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/ccd8581a/attachment-0002.html>