I re-read Tilmann Reh's description of Z280 bugs (section 10 of CPU280 Software Manual):
* OUTJMP bug is associated with I/O-write with wait state. This applies to both CPU access as well as DMA access. I can confirm that without wait state in I/O-write, the CPU access is not subject to the OUTJMP bug. I have not tried I/O write with DMA so far.
* DIVUW gives wrong results.
* DMA may not release the bus after I/O write for up to 20uS. There is a software fix named "Stefan Nitschke Chaos" for that.
* CPU may have invalid carry flag when instruction is sandwiched between two EX AF,AF' instructions. That error is also influenced by whether cache is enabled or not.

1. Possible cache corruption in Z80 (8-bit) bus mode (rev G of silicon): a memory read of 16-bit even-aligned data (not instruction) causes the cache to be updated inadvertently. Workaround: use Z-bus (16-bit) mode (this bug was documented by Zilog.)
   
2. Burst mode memory cycle does not work as specified when in the X2 and X4 clock mode (rev G of silicon): IE signal behaves as if it were a normal memory access cycle. Workaround: use the X1 clock mode (also documented by Zilog.)
   
3. There may not be a jump instruction (including call/restart) directly following an I/O write transaction which uses wait states. This is both for the CPU (OUT instruction) and the DMA (in flow-through, single-byte and burst modes). Supposedly, the problem occur for lots of wait states and not for the four wait states of the CPU280. Workaround: add an IN instruction or 4x NOPs between the two critical instructions. For the DMA, by design there can be no workaround! (Bug mentioned by Tilmann Reh, and known as the "OUTJMP" bug; I haven't been able to reproduce it on the CPU280 or Z280RC.)
   
4. The DIVUW supposedly gives wrong results in certain cases, such as when bit 15 of the divisor is set; the signed DIVW is supposedly correct (mentioned also by Tilmann Reh, but no details and no examples are given, and I haven't been able to reproduce it either - testing DIVUW for all possible cases against a division routine is a very long, time-consuming test; I ran a partial test with the bit 15 of divisor set and unset using a pseudo-random number generator for dividend and divisor and found no discrepancies even after several hours of running the test.)
   
5. After an I/O write the DMA sometimes will not release the bus, but stay in a wait state for as much as 20us. Workaround: refer to UZI280 release 1.02snc (bug reported by Stefan Nitschke; apparently not really a bug, but a consequence of the refresh timing register not being initialized as the register was not documented in early Zilog docs. Stefan's workaround consisted of writing a value to an I/O address that was later documented by Zilog.)
   
6. One single arithmetic or logical instruction that uses the ALU sandwiched between two ex af,af' instructions causes the flags register to be copied instead of swapped, for example:
   

           scf
           ex      af,af'
           sub     c       ; arithmetic instruction sandwiched between 2 exaf's
           ex      af,af'  ; CY is gone!
   

   the bug depends on the code location (triggered if the starting address of the sequence is even, but not if odd) and can be influenced by enabling or disabling the cache. Workaround: add a nop after the arithmetic or logic instruction (I can reproduce this bug.)
   
7. DMA linking not working properly? (Tilmann Reh also mentions it, but gives no details. Haven't tried it.)
   
8. Data pushed on the stack big-endian by early chip revisions? (This was one of the earliest Z280 bug reports I came across, but it was either not true or was quickly fixed by Zilog.)
   
9. M1 pin active only on RETI instructions? Haven't tried this one.
   
10. The CPU pipeline is not flushed after a MMU register is changed (this is actually documented on page 7-6 of the Zilog manual.)
    
11. This fails even with all the caches off and a cache flush in the middle:
    

            ld      hl,0    ; a ROM address
            ld      a,(hl)
            inc     (hl)
            purge
            cp      (hl)
    

    On RAM it works fine. Apparently, the CPU is keeping (hl) internally as an optimization and not flushing it. The problem can also appear when using external memory bank switching (i.e. not using the Z280 MMU). Z80 bus mode only? (Bug reported by Alan Cox.)
    

Hector, many thanks for the detailed answer and for all of your work on Z280 software!

Thank you for reviving the interest in the Z280, and for making the CPU280 board available again! And to Plasmo, of course, whose clever ROM-less Z280RC board makes software development much easier!