home *** CD-ROM | disk | FTP | other *** search
/ Gold Fish 2 / goldfish_vol2_cd1.bin / files / misc / emu / z80 / notes.txt < prev    next >
Encoding:
Text File  |  1993-12-21  |  4.5 KB  |  101 lines
  1.  
  2.         Things not working exactly as in a real Z80:
  3.  
  4. * Interrupts
  5.  
  6.   Requests for interrupts and other services are only recognized and
  7.   served after flow control instructions. This is often enough without
  8.   spending too much time testing, and guarantees that emulation can never
  9.   be stuck in an endless (or simply long) loop without being able to
  10.   detect an interrupt.
  11.  
  12. * BCD arithmetic
  13.  
  14.   The H and N flags of the F register are completely ignored, and are
  15.   treated as the two unused flags.
  16.  
  17.   These instructions set flags so that a subsequent Daa will work :
  18.     Adc A,s , Add A,s , Neg , Sbc A,s , Sub s .
  19.   For them, data is stored for Daa to use.
  20.  
  21.   After these instructions, the flags are set so H (or Xh/Yh) could be
  22.   adjusted by doing  "Ld A,H , Daa , Ld H,A" :
  23.     Adc HL,ss , Add HL,ss , Add IX,ss , Sbc HL,ss .
  24.   For them, BCD is currently ignored. Nobody seems to use it.
  25.  
  26.   After the 8-bit Inc and Dec instructions, Daa could be successfully
  27.   done (if m <> A, through "Ld A,m , Daa , Ld m,A", otherwise simply
  28.   through Daa) provided it is regarded that Inc/Dec do not affect the
  29.   carry flag.
  30.   Currently not even the Inc A / Dec A instructions store Daa data, since
  31.   no occurrence of a subsequent Daa has been spotted in any program.
  32.  
  33.   Other tricks possible to perform with Daa, using various instructions
  34.   to set the flags, are simply ignored since that kind of total flag
  35.   emulation would slow everything down beyond reason.
  36.  
  37.   The data stored for Daa :
  38.     BCD_OP = operation, one of:
  39.       OP_ADD
  40.       OP_SUB
  41.       OP_ADC
  42.       OP_SBC
  43.  
  44.    BCD_A = destination (ackumulator before operation, or zero for Neg)
  45.    BCD_B = source (ackumulator for Neg)
  46.    BCD_C = flags before operation (word-sized, only stored for Adc/Sbc)
  47.  
  48. * Push/Pop AF
  49.  
  50.   When the flag register is pushed or popped, it could either be stored
  51.   and retreived in the 680x0 CCR form (the quickest way), or in Z80 form.
  52.   The compile flag AFPUSHPOP_CCR controls this. If the CCR form is used,
  53.   programs that inspect a stored flag byte will get wrong results.
  54.   The difference lies in how the flags are ordered within the byte. For
  55.   instance, in the 680x0, bit 3 is the sign flag; in the Z80, it is bit 7.
  56.   Only programs that inspect the pushed flags (like a debugger) will ever
  57.   notice this.
  58.     In neither case are bits in the unused positions (including H and N)
  59.   guaranteed to survive an operation that affects any of the flags.
  60.   Is IS guaranteed, that a Pop AF with a following Push AF (or vice versa)
  61.   and no flag-affecting instructions there inbetween, will preserve all
  62.   the transferred bits.
  63.     Since the H and N flags are not emulated, the BCD information could
  64.   be lost if the flags are pushed to call a subroutine and then popped.
  65.   There seems to be no problem, however, since nobody would want to delay
  66.   the decimal adjust until after he has first pushed and popped the flags
  67.   (unless he is bit-fiddling the flags, which wouldn't work anyway).
  68.   An interrupt could possibly occur between the arithmetic operation and
  69.   the decimal adjust (presently only if a change of flow control is made
  70.   to the point where the Daa will be done). The possibility is slight, but
  71.   I provide the option AFPUSHPOP_BCD to fix this; mostly for completeness.
  72.   If the option is used, the BCD data will be stored in a separate,
  73.   circular stack which keeps the last 7 pushed data units.
  74.  
  75. * Refresh register
  76.  
  77.   The real behaviour of the R register seems impossible to emulate at a
  78.   reasonable speed, since it increments at certain intervals providing
  79.   certain parts of the CPU are free. Usually once per instruction, but
  80.   sometimes twice. (If anybody finds a complete description of this,
  81.   please send me a copy).
  82.   I consider the Ld A,R and Ld R,A instructions to be implementation-
  83.   dependent:
  84.  
  85.    The R register is not incremented after each instruction; instead when
  86.    Ld A,R is executed the bits 0-6 have to be made up from some counter
  87.    like the Pseudo-PC or the system clock. Bit 7 is taken from the last
  88.    stored R in the Z80_R field.
  89.  
  90.    When Ld R,A is executed, only bit 7 must be safely stored in the
  91.    Z80_R field of the control structure. Bits 0-6 may be treated in any
  92.    way by the implementer.
  93.  
  94.    The file generic_macs.i provides a version of Ld A,R which uses the
  95.    Pseudo-PC to 'approximate R' as a non-machine specific way to do it.
  96.  
  97.   (Maybe it could be plausible to do proper ticking of the R register in
  98.   a single-step mode. Then one could single-step/trace through certain
  99.   routines that use the R register for coding. I'll need some more details
  100.   on its behaviour first.)
  101.