I can observe the exaf bug on my machine. Using a test code based on hperaza's 2nd example, my hardware will get identical F, F' if the first ex af,af' instruction is located on an even address. I wrote a program that relocates the test code by one byte every iteration; and the error occurs every other iteration. What's interesting is that to observe the problem, the test code must not be in the cache. If the test code is in the cache, the error will occur every time regardless of the location. To flush the test code out of the cache, I'd call a routine that has more than 256 NOP before returning to the test code again.

One difference between my hardware and Tilmann Reh's CPU280 is that I've not implemented the burst mode memory transaction.

...
CPU280 have DRAM as well, so it must have a different way of refreshing the memory and not relying on the internal refresh counter.

CPU280 doesn't use the refresh counter as far as I know, but uses CAS-before-RAS refresh. This isn't well documented in the English manual; the German Hardware Handbuch shows the timing diagrams on page 22 (PDF page number).

Yeah, it does sound a bit confusing. The Z280 manual does say that if an external bus transaction doesn't occur within the number of cycles defined in the refresh control register, that a refresh transaction will be inserted anyway, even if refresh is disabled. This means that an idle loop, running entirely in cache, would trigger refresh cycles even with refresh disabled.

CPU280 doesn't use the refresh counter as far as I know, but uses CAS-before-RAS refresh. This isn't well documented in the English manual; the German Hardware Handbuch shows the timing diagrams on page 22 (PDF page number).

1.)
Collection of information by Tilmann Reh send to us including hardwarebook, short 
info for the operating system and historie informations. (german text as below) 

http://oldcomputers.dyndns.org/public/pub/rechner/zilog/z280/CPU280_Handbuch_und_Historie_(ger_bw_ocr).pdf

2.)
Zusammenstellung der Schreiben von Tilmann Reh - Hardware-Handbuch (210690), Kurz-Information zum 
Betriebssystem (231090) und aeltere Texte. 

http://oldcomputers.dyndns.org/public/pub/rechner/zilog/z280/CPU280_Handbuch_und_Historie_(ger_gray_ocr).pdf

I wonder whether this is part of the UZI280 problems?

Thinking about it more, even if SNC had set the rate field to non-zero value it can create insidious bugs because if program is idling in cache, the refresh mechanism would work properly, but if program starts running some tasks then the refresh cycles won't start and parts of the memory will become corrupted gradually. This is insidious because the tasks that run regularly will get refreshed, but the tasks that seldom get called will become corrupted and then crashed in random ways. DRAM can actually retain its data for many seconds without refresh but it is highly variable and strongly temperature dependent--a nightmarish problem to debug.

I think I am still finding more Z280 bugs

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)
cp (hl)

Alan

On RAM it works fine. I suspect it is keeping (hl) internally as an optimization and not flushing it. There is other stuff going on too, when I try and do ordinary bank switching weirdness happens (again cache on or off) in Z80 bus mode if I execute code, flip banks, do some I/O into memory in the new bank, flip back and then do stuff. Again caches on or off, prefetch hazards accounted for as far as I can see. Unfortunately I don't see any way to debug it without a fairly fancy logic analyzer.