Things not working exactly as in a real Z80:

* Interrupts

  Requests for interrupts and other services are only recognized and
  served after flow control instructions. This is often enough without
  spending too much time testing, and guarantees that emulation can never
  be stuck in an endless (or simply long) loop without being able to
  detect an interrupt.

* BCD arithmetic

  The H and N flags of the F register are completely ignored, and are
  treated as the two unused flags.

  These instructions set flags so that a subsequent Daa will work :
    Adc A,s , Add A,s , Neg , Sbc A,s , Sub s .
  For them, data is stored for Daa to use.

  After these instructions, the flags are set so H (or Xh/Yh) could be
  adjusted by doing  "Ld A,H , Daa , Ld H,A" :
    Adc HL,ss , Add HL,ss , Add IX,ss , Sbc HL,ss .
  For them, BCD is currently ignored. Nobody seems to use it.

  After the 8-bit Inc and Dec instructions, Daa could be successfully
  done (if m <> A, through "Ld A,m , Daa , Ld m,A", otherwise simply
  through Daa) provided it is regarded that Inc/Dec do not affect the
  carry flag.
  Currently not even the Inc A / Dec A instructions store Daa data, since
  no occurrence of a subsequent Daa has been spotted in any program.

  Other tricks possible to perform with Daa, using various instructions
  to set the flags, are simply ignored since that kind of total flag
  emulation would slow everything down beyond reason.

  The data stored for Daa :
    BCD_OP = operation, one of:
      OP_ADD
      OP_SUB
      OP_ADC
      OP_SBC

   BCD_A = destination (ackumulator before operation, or zero for Neg)
   BCD_B = source (ackumulator for Neg)
   BCD_C = flags before operation (word-sized, only stored for Adc/Sbc)

* Push/Pop AF

  When the flag register is pushed or popped, it could either be stored
  and retreived in the 680x0 CCR form (the quickest way), or in Z80 form.
  The compile flag AFPUSHPOP_CCR controls this. If the CCR form is used,
  programs that inspect a stored flag byte will get wrong results.
  The difference lies in how the flags are ordered within the byte. For
  instance, in the 680x0, bit 3 is the sign flag; in the Z80, it is bit 7.
  Only programs that inspect the pushed flags (like a debugger) will ever
  notice this.
    In neither case are bits in the unused positions (including H and N)
  guaranteed to survive an operation that affects any of the flags.
  Is IS guaranteed, that a Pop AF with a following Push AF (or vice versa)
  and no flag-affecting instructions there inbetween, will preserve all
  the transferred bits.
    Since the H and N flags are not emulated, the BCD information could
  be lost if the flags are pushed to call a subroutine and then popped.
  There seems to be no problem, however, since nobody would want to delay
  the decimal adjust until after he has first pushed and popped the flags
  (unless he is bit-fiddling the flags, which wouldn't work anyway).
  An interrupt could possibly occur between the arithmetic operation and
  the decimal adjust (presently only if a change of flow control is made
  to the point where the Daa will be done). The possibility is slight, but
  I provide the option AFPUSHPOP_BCD to fix this; mostly for completeness.
  If the option is used, the BCD data will be stored in a separate,
  circular stack which keeps the last 7 pushed data units.

* Refresh register

  The real behaviour of the R register seems impossible to emulate at a
  reasonable speed, since it increments at certain intervals providing
  certain parts of the CPU are free. Usually once per instruction, but
  sometimes twice. (If anybody finds a complete description of this,
  please send me a copy).
  I consider the Ld A,R and Ld R,A instructions to be implementation-
  dependent:

   The R register is not incremented after each instruction; instead when
   Ld A,R is executed the bits 0-6 have to be made up from some counter
   like the Pseudo-PC or the system clock. Bit 7 is taken from the last
   stored R in the Z80_R field.

   When Ld R,A is executed, only bit 7 must be safely stored in the
   Z80_R field of the control structure. Bits 0-6 may be treated in any
   way by the implementer.

   The file generic_macs.i provides a version of Ld A,R which uses the
   Pseudo-PC to 'approximate R' as a non-machine specific way to do it.

  (Maybe it could be plausible to do proper ticking of the R register in
  a single-step mode. Then one could single-step/trace through certain
  routines that use the R register for coding. I'll need some more details
  on its behaviour first.)