I was investigating whether the 'R' register behaves the same on Z80 and R800.

I initially wrote this program:

	di

	ld	hl,#0100

	xor	a

	ld	b,a

	ld	r,a

loop:	ld	a,r        ; (2)

	ld	(hl),a     ; (4)

	inc	hl         ; (1)

	djnz	loop       ; (3)

	ei

	ret

On Z80, for every iteration of this loop, R is increased by 5 (+2 for 'ld a,r'

and +1 for the other 3 instructions). On R800 R is also increased by 5 each

iteration. Though sometimes it's increased by 6!

The increase by 6 instead of 5 happened every 18th or 19th (alternating)

Iteration. One iteration takes 10 cycles (taking R800-page-breaks into account),

so that's on average every 185th clock cycle.

This number 185 is very close to the number of useful cycles in a full R800

refresh cycle. Currently (2010-08-16) R800-refresh in openmsx stalls the R800

for 26 cycles every 210 cycles (so that leaves 210-26=184 useful cycles).

So all this lead me to the hypotheses that a R800-refresh cycle also increases

the R register by one.

This would be very useful because it would allow to measure in more detail how

refresh works exactly on R800 (the current model in openMSX (210/26) is not

100% correct). So that's what I'll do in the rest of this document.

New test program. This records sequences longer than 256, it's important that

each iteration takes the same amount of cycles. So I had to replace the djnz

instruction.

	di

	ld	hl,#0100

	xor	a

	ld	r,a

loop:	ld	a,r        ; (2)

	ld	(hl),a     ; (4)

	inc	hl         ; (1)

	ld	a,h        ; (1)

	cp	#c0        ; (2)

	jr	nz,loop    ; (3)

	[ some code to transform memory block #0100-#C000 into

	  the differential of this block, so it's easy to see by

	  how much R increased each iteration ]

Each iteration takes 13 cycles. Per iteration R is increased by either 7 or 8.

The difference table (a small portion) looked like this:

   07 07 07 07 07 07 07 07  07 07 07 07 07 08 07 07

   07 07 07 07 07 07 07 07  07 07 07 08 07 07 07 07

   07 07 07 07 07 07 07 07  07 08 07 07 07 07 07 07

   07 07 07 07 07 07 07 08  07 07 07 07 07 07 07 07

   07 07 07 07 07 07 08 07  07 07 07 07 07 07 07 07

   07 07 07 07 08 07 07 07  07 07 07 07 07 07 07 07

   07 07 08 07 07 07 07 07  07 07 07 07 07 07 07 07

   08 07 07 07 07 07 07 07  07 07 07 07 07 07 07 08

   07 07 07 07 07 07 07 07  07 07 07 07 07 07 08 07

   07 07 07 07 07 07 07 07  07 07 07 07 08 07 07 07

   ...

These tables always have only two different numbers, in this case a series of

7's followed by one 8, then again a series of 7's followed by one 8 and so one.

The actual number '7' or '8' is not important for timing, only the pattern of

these numbers in the table is important. So I'll create a more compact notation

for the table above:

  14 14 14 14 15 14 14 14 14 15 14 ...       (these are decimal numbers)

or even

  4*14 15 ...

This means there are 4 repetitions of '13*0x07 + 1* 0x08' (length 14) followed by

one time '14*0x07 + 1*0x08' (length 15).

So this notation indicates how many iterations there are before there is a

refresh.

For this test on average there are '(4 * 14 + 1 * 15) / 5 = 14.2' iterations

between two refresh cycles. Each iteration takes 13 cycles. So that's 184.6

useful clock cycles between refresh cycles.

Next I realized this test program could be speed up one cycle:

	ld	c,#c0

loop:	ld	a,r        ; (2)

	ld	(hl),a     ; (4)

	inc	hl         ; (1)

	ld	a,h        ; (1)

	cp	c          ; (1)

	jr	nz,loop    ; (3)

An iteration now takes 12 cycles (R is still increased by 7 or 8).

Difference table looks like this

  16 3*15 16 2*15 16 2*15    (this sequence repeats all the time)

That's (3*16+7*15)/10 = 15.3 iteration

or 15.3*12 = 183.6 clock cycles between refresh.

Then I started inserting extra instructions in this test program:

	ld	c,#c0

loop:	ld	a,r        ; (2)

	ld	(hl),a     ; (4)

	[***]

	inc	hl         ; (1)

	ld	a,h        ; (1)

	cp	c          ; (1)

	djnz	loop       ; (3)

* NOP

  13 cycles per iteration  (R increases 8 or 9)

  pattern: 8*14 15

  cycles between refresh: 183.44      (8*14+15)/9*13

* 2 x NOP

  14 cycles/iteration  (R incr 9 or 10)

  pattern: 5*13 14

  cycles/refresh = 184.33

  I noticed the start of the difference table was a bit different, it went like

  this:

     9*13 14 7*13 14 5*13 14 5*13 14 5*13 14

  So it took some time before it stabilized on the '5*13 14' pattern. For the

  rest of the tests I didn't look at the start of the table anymore. I only

  searched for the 'stable' pattern.

  I ran this same test again, but now the (stable) pattern was

     9*13 14

  that gives

     cycles/refresh = 183.4

  This is very interesting behaviour, depending on some (yet unknown) initial

  conditions, _the_whole_test_ runs slightly faster or slower. This is

  interesting because it may give a clue to why there is considerable variation

  to *some* speed measurements on a real R800 (see doc/r800-test.txt) while for

  other tests the results are much more stable. (Also in the current R800 openMSX

  emulation, the speed measurements are always stable).

  I didn't repeat the previous tests. Maybe they also show different patterns

  on different runs. I did repeat all future tests (there always seems to be

  either only 1 or 2 different stable patterns)

* NEG   (like 2xNOP also takes 2 cycles)

  14 cycles/iteration (R incr 9 or 10)

  pattern: 7*13 14

  cycles/refresh = 183.75

* 3 x NOP

  15 cycles/iteration (R incr 10 or 11)

  pattern: 2*12 13

           3*12 13

  cycles/refresh = 185

                   183.75

* IM 1   (3 cycles, like 3xNOP)

  15 cycles/iteration (R incr 9 or 10)

  pattern: same as 3 x NOP

* 4 x NOP

  16 cycles/iteration (R incr 11 or 12)

  pattern: 11 12

  cycles/refresh = 184

* LD (HL),A  (4 cycles (with page-breaks))

  16 cycles/iteration (R incr 8 or 9)

  pattern: same as 4 x NOP

* 5 x NOP

  17 cycles/iteration (R incr 12 or 13)

  pattern: 4*11 10

           7*11 10 6*11 10

  cycles/refresh = 183.6

                   184.73

* BIT 0,(HL)   (5 cycles)

  17 cycles/iteration (R incr 9 or 10)

  pattern: 5*11 10 4*11 10

           6*11 10

  cycles/refresh = 183.90

                   184.57

I still need to do more experiments, but some *guesses* so far: useful number

of cycles always seems to be within (183, 185]. That's a variation of more than

one clock cycle. Maybe refresh also waits for an even clock cycle (just like IO

does). This could explain why there are two stable patterns for some tests (in

one case you have to insert an extra cycle to align to an even number of

cycles, in the other case you're already aligned). This could explain why there

can be variation in speed between different runs of the same test. And finally

it explains why the documentation (e.g. atoc or even the turbor datapack) talks

about half clock cycles for the duration of the refresh (in 50% of the cases it

needs to add one cycle). Those docs talk about 21.5 cycles refresh every 222

cycles, those number seem wrong to me (don't match measurements on real HW),

but at least I now have an idea about that half clock cycle.

---------

I implemented the above guess (refresh waits for even clock cycle) in openMSX

revision 11643. I can now more or less reproduce the results above: The

number of useful clock cycles per refresh is also in range (183, 185], but the

number per test is not the same as above (the 'stable patterns' from the tests

above are different). Also in openMSX there's always only one stable pattern,

while on a real R800, for some test, there clearly were two different possible

patterns.

New test: above we measured the number of useful clock cycles per 'refresh

cycle'. Now we're going to measure how many cycles the refresh itself takes.

The idea goes like this: by observing the R register we can detect that there

was a refresh, so by doing a longer test we can count how many refresh cycles

there were. We can combine this with measuring the total time of the test

(using the E6-timer). We can also calculate how many 'useful' cycles there

were in the whole test. So the difference between actual and useful cycles

must be cycles spend on refresh. And finally if we divide that by the counted

number of refreshes, we should know how many cycles a single refresh takes.

Full test program:

        org     #c000

        di

        ld      hl,#0100

        ld      c,#bc

        ld      e,3

l1      ld      a,r        ; This loop waits till there was a refresh.

        ld      d,a        ; It's an attempt to get more stable measurements.

        ld      a,r        ; Note that this loop will not terminate in Z80

        sub     d          ; mode.

        sub     e

        jr      z,l1

        out     (#e6),a

loop    ld      a,r        ; (2)   Actual test loop, same as in tests above

        ld      (hl),a     ; (4)   One iteration takes 12 cycles

        inc     hl         ; (1)

        ;[***]             ;       extra instructions here (see below)

        ld      a,h        ; (1)

        cp      c          ; (1)

        jr      nz,loop    ; (3/2) 3 cycles when jump is taken, 2 otherwise

        in      a,(#e6)

        ld      l,a

        in      a,(#e7)

        ld      h,a

        ld      (#be00),hl ; store total duration of the test

        ld      hl,#0100   ; Next we do some post-processing on the data:

l2      inc     hl         ; First calculate the difference table, same

        ld      a,(hl)     ; routine as in tests above (though not shown

        dec     hl         ; there).

        sub     (hl)

        ld      (hl),a

        inc     hl

        ld      a,h

        cp      c

        jr      nz,l2

        ld      hl,#bc00

        ld      de,#bc00+1

        ld      bc,#200-1

        ld      (hl),0

        ldir

        ld      de,#100    ; Next we calculate a histogram.

        ld      hl,#bc00   ; We expect this histogram to be all zero, except for

l3      ld      a,(de)     ; two entries: the iterations with and without a

        ld      l,a        ; refresh cycle.

        inc     (hl)       ; There is a single other point in this histogram,

        jr      nz,nc      ; that's because we don't calculate the difference of

        inc     h          ; the very last iteration correctly (we'd have to

        inc     (hl)       ; sample the R register one more time outside the

        dec     h          ; loop). But for now we ignore this outlier.

nc      inc     de

        ld      a,d

        cp      h

        jr      nz, l3

        ei

        ret

Test results:

* no extra instructions:

   real machine:

     histogram: 0x07: 0xAECE

                0x08: 0x0C31

                0x66: 0x0001 -> belongs to 0x07, can be seen by the pattern

                                in the difference table, I won't show this

                                entry anymore in the next results

     E6-ticks:  0x5B75

     total cycles: E6-timer * 28 cycles/E6-tick = 655564 cycles

     useful cycles: 0xBB00 iterations * 12 cycles/iteration = 574464 cycles

     overhead cycles: 655564 - 574464 = 81100 cycles

     cycles per refresh = 81100 cycles / 0xc31 refreshes

                        = 25.985 cycles/refresh

   openMSX revision 11648:

     histogram: 0x07: 0xAECD+1

                0x08: 0x0C32

     E6-ticks:  0x5B78

      --> 26.004 cycles/refresh

* extra instruction: NOP (1 cycles, increases R by 1)

   real machine:

     histogram: 0x8: 0xADCA

                0x9: 0x0D36

     E6-ticks:  0x6318

      --> 26.011 cycles/refresh

   openMSX revision 11648:

     histogram: 0x8: 0xADC8

                0x9: 0x0D38

     E6-ticks:  0x632A

      --> 26.144 cycles/refresh

* extra instruction: IM 1 (3 cycles, incr R 2)

   real machine:

     histogram: 0x9: 0xABCA

                0xA: 0x0F36

     E6-ticks:  0x721B

      --> 25.636 cycles/refresh

   openMSX revision 11648:

     histogram: 0x9: 0xABBC

                0xA: 0x0F44

     E6-ticks:  0x727E

      --> 26.25 cycles/refresh

   !! Big difference between openmsx and real MSX !!

* extra instructions: EXX ; MULUW HL,BC ; EXX (1+36+1 cycles, incr R 1+2+1)

   real machine:

     histogram: 0xB: 0x882D

                0xC: 0x32D3

     E6-ticks:  0x17D33  (of course I couldn't measure how many times the

                          timer overflowed, but it must be one time)

      --> 26.042 cycles/refresh

   openMSX revision 11648:

     histogram: 0xB: 0x8801

                0xC: 0x32FF

     E6-ticks:  0x17E80

      --> 26.669 cycles/refresh

   !! Big difference between openmsx and real MSX !!

Preliminary conclusion:

  Refresh seems to take about 26 cycles, this is also the value we currently

  use in openMSX. Though especially for the 'IM 1' case there's still a

  relatively big difference between openMSX and the real hardware. Needs

  more experiments.

One other difference between Z80 and R800

	di

	xor	a

	ld      r,a

	ld	a,r

	ld	c,a	; Z80: c=2   R800: c=1

	ld	a,r

	ld	b,a     ; Z80: b=5   R800: b=4

	ld	a,r     ; Z80: a=8   R800: a=7

And of course once in a while the numbers for R800 are (partially) increased by

one.

This difference can possibly be explained by a difference in the order of

storing the result to the 'R' register and increasing the 'R' register on each

M1 cycle.