The test program, in short:
  Execute the same instruction (or short instruction sequence) number of
  times and use the E6 timer to measure how long it took.

The E6 timer has a resolution of 255682Hz (3579545Hz / 14). R800 runs at
7159090Hz (2 * 3579545Hz). So the timer ticks once every 28 R800 ticks.


-----------------------------------------------

	org	#c000

start	equ	#0100

	ld	de,start
	ld	hl,begin
	ld	bc,begin1-begin
	ldir
	push	de
	ld	hl,loop
	ld	bc,loop1-loop
	ldir
	pop	hl
	ld	bc,(20000-1)*(loop1-loop) ; number varies depending on
	ldir                              ; length of the test-sequence
	ld	hl,end
	ld	bc,end1-end
	ldir
	jp	start

begin	di
	out	(#e6),a
begin1

loop	muluw   hl,bc                     ; test sequence
loop1

end	in	a,(#e6)
	ld	l,a
	in	a,(#e7)
	ld	h,a
	ei
	ret
end1

-----------------------------------------------


Below are the results, it's formatted like this

  ----------------------------------------------
  [ prologue ]
  instruction-sequence  [ repeat-count ]
    result: <raw-result>
    cycles: <cycles>  [ instruction break-down ]
    notes:
  ----------------------------------------------

Prologue are extra setup instructions, they are only executed once, only a few
test have them

Instruction-sequence is the actual instruction that's been tested. Mostly this
is a single instruction, but sometimes there is a pair of instructions.

repeat-count indicates how many times the instruction-sequence is repeated.
I tried to repeat the instruction as much as possible. But to fit longer
instruction sequences (longer in number of opcode bytes) in memory, the
repeat count is sometimes reduced.

raw-result: this is the value of the E6 timer at the end of the test. Note
that you cannot directly compare this number to other test because other
test might have a different repeat-count.

cycles: here I calculated the number of cycles required per
'instruction-sequence'-iteration. I calculated this by comparing the result
to the 'nop' instruction (a nop takes 1 cycle). Note that the duration
of most instructions in almost never exactly an integer multiple of the
duration of the nop instruction. A possible explanation might be the
refresh (only happens at the end of an instruction, so for longer instructions
the chance of a refresh is relatively less). But we need additional test to
fully explain the refresh behaviour.

Instruction break-down: Here I tried to split the instruction into micro-ops.
I used the following notation:
  f  opcode fetch, no page-break, takes 1 cycle
  r  data read,    no page-break, takes 1 cycle
  w  data write,   no page-break, takes 1 cycle
  F  opcode fetch,    page-break, takes 2 cycles
  R  data read,       page-break, takes 2 cycles
  W  data write,      page-break, takes 2 cycles
  x  extra cycle (for various stuff)
  i  IO


---------------------------------------------------------------



* Instructions that don't do additional bus transactions (read, write, IO).

nop  [x 40000]
  result:           1629-1645
  openmsx-rev11643: 1637-1638
  cycles: 1  [f]

add hl,bc  [x 40000]
  result:           1633-1645
  openmsx-rev11643: 1637-1638
  cycles: 1  [f]

cpl  [x 40000]
  result:  varies between 1628-1647, most often around 1638
  openmsx-rev11643: 1637-1638
  cycles: 1  [f]
  note: same result for cpl, daa, ccf, scf, exx, ex af,af', ld sp,hl, rrca, ...

neg  [x 20000]
  result:           1637  (most often 1637, sometimes 1638)
  openmsx-rev11643: 1643-1645
  cycles: 2  [ff]
  note: - measurement on real HW is MUCH more stable for this test compared to
          previous tests
        - same result for ld {a,i,r},{a,i,r}
        - all results below for the real HW probably vary as well, though in
          my initial tests on the real HW I only noted the most often
          occuring value. I should re-test, but that's a lot of work.

im 0/1/2  [x 20000]
  result:           2453-2360, most often 2456
  openmsx-rev11643: 2459-2460
  cycles: 2  [ffx]

di  [x 40000]
  result:           3267
  openmsx-old:      3267
  openmsx-rev11643: 3273-3274
  cycles: 2  [fx]
  note: I added 'openmsx-old' tags where older openmsx revisions were better
        (possibly by accident) than the current revision.

ei  [x 40000]   (VDP irq disabled)
  result:           1435 (!)
  openmsx-rev11643: 1434-1436
  cycles: 1  [f]
  note: This is faster than nop!!
        Both instructions are one cycle, but it seems there's no refresh delay
        after a 'ei' instructions. At least with this assumption the theory
        matches very closely the measurment.... Implemented like this in openMSX
        and it matches the measurement very well.
        I verified that 'VDP irq disabled' has no influence on speed: I mean
        even with VDP irq disabled, the speed of 'nop' is the same as before.

ld a,ixh  [x 20000]
  result:           1637
  openmsx-old:      1636
  openmsx-rev11643: 1643-1545
  cycles: 2  [ff]

muluw hl,bc  [x 20000]
  result:           29354
  openmsx-rev11643: 29360-29361
  cycles: 36  [ffx34]

mulub a,b  [x 20000]
  result:           11419
  openmsx-rev11643: 11425-11427
  cycles: 14  [ffx12]



* Instructions that do a single read/write operation

ld (#d000),a  [x 10000]
  result:           2449
  openmsx-rev11643: 2446-2447
  cycles: 6  [FffW]
  note: page-break when switching from opcode fetching to data writes
        and again when switching from data write to opcode fetching

ld a,(#d000)  [x 10000]
  result:           2449
  openmsx-rev11643: 2445-2447
  cycles: 6  [FffR]
  note: same as above but for read

ld a,(#0100) [x 80(!)]
  result:           20
  openmsx-rev11643: 20
  cycles: 6  [FffR]
  note: opcode fetch and read are in the same 256-byte page,
        but still there is a page-break when switching from
        opcode reading to data reading

[ ld hl,#d000 ]
ld a,(hl)  [x 40000]
  result:           6522
  openmsx-rev11643: 6522-6523
  cycles: 4  [FR]

[ ld hl,#d000 ; ld bc,0 ]
ld a,(hl) ; add hl,bc  [x 20000]
  result:           4054
  openmsx-rev11643: 4054-4055
  cycles: 3 + 2  [fR F]

[ ld hl,start+XX ; ld bc,2 ]
ld a,(hl) ; add hl,bc  [x 20000]
  result:           4055
  openmsx-rev11643: 4054-4055
  cycles: 3 + 2  [fR F]
  note: same test as above, but now the data is in the same page as
        the instructions. There is still a page-break.

[ ld hl,start+XX ; ld bc,2 ]
ld (hl),a ; add hl,bc  [x 20000]
  result:           4054
  openmsx-rev11643: 4054-4055
  cycles: 3 + 2  [fW F]
  note: same as above but for writes

ld r,(ix+o)  [x 10000]
  result:           2854
  openmsx-rev11643: 2848-2849
  cycles: 7  [FffxR]
  note: between opcode fetching (3 bytes) and read there is one additional
        cycle to calculate the result of IX+o

ld (ix+o),r  [x 10000]
  result:           2854
  openmsx-rev11643: 2848-2849
  cycles: 7  [FffxW]
  note: same as above, but for write

ld (ix+o),n  [x 10000]
  result:           2861
  openmsx-rev11643: 2848-2849
  cycles: 7  [FfffW]
  note: Has the same number of cycles as 'ld (ix+o),r' even though this
        instruction is one byte longer. The IX+o calculation is done
        in parallel with fetching the last opcode byte.
        Z80 shows the same parallelism.
  note: Even though it has the same number of cycles as 'ld (ix+o),r', it
        is consistently slightly slower. A possible explanation is that there
        are page-breaks on opcode fetches in this test, since this instruction
        has length 4 instead of 3.

bit 0,a  [x 20000]
  result:           1637
  openmsx-old:      1636
  openmsx-rev11643: 1643-1645
  cycles: 2  [ff]

bit 0,(hl)  [x 20000]
  result:           4055
  openmsx-rev11643: 4065-4066
  cycles: 5  [FfR]

bit 0,(ix+o)  [x 10000]
  result:           2861
  openmsx-rev11643: 2848-2849
  cycles: 7  [FfffR]
  note: I always found it strange that the format of these instructions is
           <0xDD> <0xCB> <offset> <function>     (offset before function)
        But this allows to hide the latency of calculating IX+o. The same
        happens on a Z80.



* Instructions that read/write 2 bytes

ld (#d000),hl  [x 10000]
  result:           2854
  openmsx-rev11643: 2848-2849
  cycles: 7  [FffWw]
  note: no page-break for the second data write

ld (#d0ff),hl  [x 10000]
  result:           3264
  openmsx-rev11643: 3260-3262
  cycles: 8  [FffWW]
  note: of course here there must be a page-break

ld hl,(#d000)  [x 10000]
  result:           2854
  openmsx-rev11643: 2848-2849
  cycles: 7  [FffRr]
  note: similar for read

ld hl,(#d0ff)  [x 10000]
  result:           3264
  openmsx-rev11643: 3260-3262
  cycles: 8  [FffRR]

push hl ; pop hl  [x 20000]
  result:           8956
  openmsx-old:      8950
  openmsx-rev11643: 8928-8930
  cycles: 6 + 5  [FxWw FRr]
  note: push is once cycle slower than pop, probably because push first has
        to decrease SP, while pop can directly put the value of SP on the bus



* Read-modify-write instructions (single byte)

inc a  [x 40000]
  result:           1628-1642
  openmsx-rev11643: 1637-1638
  cycles: 1  [f]

inc (hl)  [x 40000]
  result:           11393
  openmsx-rev11643: 11392-11393
  cycles: 7  [FRxW]
  note: This instructions is slower than I expected, but it can be explained
        like this:
         - there is one cycle between data read and data write to get the
           time to actually increase the value
         - when switching from data-read to data-write there is a page-break
           (even though the address is identical)
        But see also the 'ex (sp),hl' instruction below

inc (ix+o)  [x 10000]
  result:           4080
  openmsx-rev11643: 4076-4077
  cycles: 10  [FffxRxW]
  note: similar as above, but 3 cycles longer:
          - need to fetch 2 more opcode bytes
          - need to calculate IX+o before data read can be executed

res 0,a  [x 20000]
  result:           1637
  openmsx-old:      1637
  openmsx-rev11643: 1643-1645
  cycles: 2  [ff]

res 0,(hl)  [x 20000]
  result:           6523
  openmsx-rev11643: 6522-6523
  cycles: 8  [FfRxW]
  note: similar to 'inc (hl)' but opcode is one byte longer

res 0,(ix+o)  [x 10000]
  result:           4083
  openmsx-rev11643: 4076-4077
  cycles: 10  [FfffRxW]
  note: similar to 'inc (ix+o)'. Opcode is one byte longer, but cost
        of IX+o can be hidden

rld  [x 20000]
  result:           6529
  openmsx-old:      6528
  openmsx-rev11643: 6521-6523
  cycles: 8 cycles  [FfRxW]
  note: similar to 'res 0,(hl)'

ld hl,#0000 ; ld de,#0100 ; ld bc,40000 ; ldir  [no repeat]   (src != dst)
  result:           11393
  openmsx-rev11643: 11393-11394
  cycles: 7  [FfRW]
  note: - as expected, 3 page-breaks are needed
        - there's no extra cycle needed to repeat the instruction
          TODO make a specific test for this   ldi <-> ldir

ld hl,#0100 ; ld de,#0100 ; ld bc,40000 ; ldir  [no repeat]   (src == dst)
  result:           11393
  openmsx-rev11643: 11393-11394
  cycles: 7  [FfRW]
  note: same timing as above, even though the read and write addresses are
        the same, there is a page-break in between


* Read-modify-write 2 bytes

ex (sp),hl  [x 40000]
  result:           11393
  openmsx-rev11643: 11392-11393
  cycles: 7  [FRrww]
  note: - This result was unexpected to me: based on the results in the previous
          section, I expected a page-break between the read and writes.
        - 7 cycles is really the minimum. There are 5 bus transactions (1 opcode
          fetch, 2 data reads and 2 data writes). Stack and instructions are in
          different pages so there must be at least 2 page-breaks.
        - I've confirmed the [frrww] order, see exsphl.txt for details.

[ ld sp,#xxFF ]
ex (sp),hl  [x 40000]
  result:           14660
  openmsx-rev11643: 14634-14635
  cycles: 9  [FRRwW]
  note: - Now we forced a page-break between reading/writing of the word. So two
          additional cycles.
        - This confirms that first two bytes are read and only then two byte are
          written: the order [FRwRw] would only require 8 cycles

[ ld sp,#01F0 ]
ex (sp),hl  [x 200(!)]
  result:           58
  openmsx-rev11643: 56-58
  cycles: 7  [FRrww]
  note: Stack pointer in same page as instructions. But there still seems to be
        a pagebreak between instructions and data.

ex (sp),ix  [x 20000]
  result:           6529
  openmsx-rev11643: 6521-6523
  cycles: 8  [FfRrww]

[ ld sp,#xxFF ]
ex (sp),ix  [x 20000]
  result:           8153
  openmsx-rev11643: 8152-8153
  cycles: 10  [FfRRwW]



* Jump instructions

jr $+2   [x 20000]
  result:           2455
  openmsx-rev11643: 2459-2460
  cycles: 3  [ffx]
  note: one additional cycle to calculate PC+offset

jr $+3 ; nop  [x 10000]    <- nop is skipped
  result:           1229
  openmsx-rev11643: 1229-1230
  cycles: 3  [ffx]
  note: - even if opcode fetching is not contiguous there is no extra
          page-break
        - slightly slower than test above, because code is less dense
          and thus overall there are more opcode-fetch page-breaks

jr $+2 ; nop  [x 10000]
  result:           1636
  openmsx-rev11643: 1637-1638
  cycles: 3 + 1  [ffx f]

[ ld a,0 ; or a ]
jr z,$+2  [x 20000]
  result:           2454
  openmsx-rev11643: 2459-2460
  cycles: 3  [ffx]
  note: condition is true, jump is taken

[ ld a,1 ; or a ]
jr z,$+2  [x 20000]
  result:           1637
  openmsx-old:      1636
  openmsx-rev11643: 1641-1642
  cycles: 2  [ff]
  note: condition is false, jump not taken
        PC+offset does not need to be calculated, so no extra cycle

djnz $+2  [x 20000]
  result:           2454
  openmsx-rev11643: 2457-2459
  cycles: 3  [ffx]
  note: - whether the jump is taken or not does not matter for the program flow
        - 1/256 of the times the jump is not taken, this can explain why this
          test is slightly faster than 'jr $+2' (but it's well within measure
          error margin)

[ ld b,0 ]
djnz $+0  [x 2000(!)]
  result:  i        63014
  openmsx-rev11643: 62707-62708  (1)
  openmsx-rev11643: 63013-63014  (2)
  cycles: 3  [ffx]
  note: - Only repeated instruction 2000 times (iso 20000) because otherwise
          timer would overflow.
        - The difference between (1) and (2) is that in (1) the djnz instruction
          is 2-bytes aligned, while in (2) it's mis-aligned. This matters
          because it will cause a lot more page-breaks. Maybe some of the
          regression in the other tests could also be explained like this?
          Till now I didn't pay much attention to instruction alignment.

[ ld b,1 ]
djnz $ ; inc b  [x 10000]
  result:           1228
  openmsx-rev11643: 1229-1230
  cycles: 3  [ff f]
  note: djnz only takes 2 cycles when it doesn't jump, same result as for jr

jp $+3  [x 10000]
  result:           2028
  openmsx-old:      2040
  openmsx-rev11643: not yet retested
  cycles: 5  [Fffx]
  note: Two additional cycles are unexpected. It can either be explained as
        two 'x' cycles or as one 'x' cycles plus a forced page-break.
        See also tests below.

[ ld a,0 ; or a ]
jp z,$+3  [x 10000]
  result:           2029
  openmsx:          2041
  openmsx-rev11643: not yet retested
  cycles: 5  [Fffx]
  note: condition is true, jump is taken

[ ld a,1 ; or a ]
jp z,$+3  [x 10000]
  result:           1229
  openmsx:          1227
  openmsx-rev11643: not yet retested
  cycles: 3  [fff]
  note: condition is false, jump not taken
        extra 2 cycles are gone

[ ld hl,start+XX ; ld bc,2 ]
add hl,bc ; jp (hl)  [x 20000]
  result:           3260
  openmsx-rev11643: 3266-3268
  cycles: 4  [F fx]
  note: Similar as above, 2 extra cycles

[ ld hl,start+XX ; ld bc,#0102 ; ld de,#FF02 ]
add hl,bc ; jp (hl) ; add hl,de ; jp (hl)  [x 10000]
  result:           3241
  openmsx-old:      3240
  openmsx-rev11643: 3201   TODO retest on real machine, I have the feeling
                                I'm not doing the exact same test now and before
  cycles: 8 cycles [F fx F fx]
  note: In this test every jump has a destination in a different 256-byte page.
        A single 'jp (hl)' instruction is still responsible for 3 cycles
        (though the cost of the forced page-break is pushed to the next
        instruction). This confirms that the two extra cycles in a jump are
        one 'x' cycle plus one forced page-break (in case of two 'x' cycles,
        this test would show yet an additional cost for the page-break).
  note: The 64 backward jumps in the first 256-byte page and the 64 forward
        jumps in the last page in this test are not executed.

call $+3 ; pop hl  [x 10000]
  result:           4880
  openmsx-old:      4891
  openmsx-rev11643: not yet retested
  cycles: 7 + 5  [FffWw FRr]
  note: This is again as expected, though the two extra cycles can be hidden
        by the data-writes.

[ ld a,0 ; or a ]
call z,$+3 ; pop hl  [x 10000]
  result:           4880
  openmsx-old:      4891
  openmsx-rev11643: not yet retested
  cycles: 7 + 5  [FffWw FRr]
  note: condition is true, call is executed
        as expected, same result as unconditional call

[ ld a,1 ; or a ]
call z,$+3  [x 10000]
  result:           1229
  openmsx-old:      1228
  openmsx-rev11643: not yet retested
  cycles: 3  [fff]
  note: condition is false, call not executed

[ ld hl,start+XX ; ld bc,3 ]
add hl,bc ; push hl ; ret  [x 10000]
  result:           4884-4887
  openmsx-rev11643: 4885-4886
  cycles: 12 [F fxWw FRr]
  note: 'RET' probably behaves as a 'JP (HL)' (two extra cycles), but these
        cycles can be hidden by the two data reads

[ ld hl,start+XX ; ld bc,3 ; ld a,0 ; or a ]
add hl,bc ; push hl ; ret z  [x 10000]
  result:           4884-4887
  openmsx-rev11643: 4885-4886
  cycles: 12 [F fxWw FRr]
  note: Same test as above, but with a conditional ret that is always executed.
        As expected same result as above.

[ ld a,1 ; or a ]
ret z  [x 40000]
  result:           1644
  openmsx-rev11643: 1637-1638
  cycles: 1  [f]


* IO instructions

in a,(0)  [x 20000]
  result:           8066
  openmsx-old:      8126
  openmsx-rev11643: 8152-8153
  cycles: 10  [ffI8]
  note: - 8 cycles for IO seems a lot, but this makes it the same speed as Z80
             Z80:  4 cycles @ 3.5MHz
             R800: 8 cycles @ 7MHz
          This is needed to keep the timing on the external cartridge slots
          the same.
        - Besides IO port 0, i checked a lot of other ports, but not all.
          I did check some random unused port numbers and at least one input
          port from each IO-device in the turbor. Only the VDP ports are
          different (see below)

in a,(#98)  [x 20000]
  result:           44286
  openmsx-rev11643: 40713
  cycles: +/- 54
  note: - Can be explained by the 'intelligent' VDP-delay added by the S1990
          Need additional tests to accurately measure this.
        - Only IO ports 0x98-0x9B show this behaviour
        - TODO this still differs a lot between emulation and real HW

[ ld b,0 ]
in a,(0) ; djnz $-2  [x 1]   [no page-break between in/djnz]
  result:           126
  openmsx-old:      132 136
  openmsx-rev11643: not yet retested
  cycles: 13  [ffI8 ffx]

[ ld b,0 ]
in a,(0) ; djnz $-2  [x 1]   [page-break between in/djnz]
  result:           145
  openmsx-old:      156
  openmsx-rev11643: not yet retested
  cycles: 15  [FfI8 Ffx]
  note: - we forced a page-break between the in and the djnz instruction by
          properly aligning the start address
        - 2 extra cycles compared to test above, this confirms the decomposition
          of the in instruction is [ffI8] (as opposed to [ffI7 + page-break])

out (0),a  [x 20000]
  result:           8065
  openmsx-old:      8125
  openmsx-rev11643: 8152-8153
  cycles: 10  [ffI8]
  note: similar to 'in a,(0)'

out (#98),a  [x 20000]
  result:           44285
  openmsx-rev11643: 40713
  cycles: +/- 54
  note: similar to 'in a,(#98)'


Theory: R800 is connected to a 7MHz bus, but IO is done over a 3.5MHz bus. If
        the start of IO is at an odd clock cycle (so not at a clock edge at the
        slower bus) there is an extra wait cycle required.

in a,(0) ; [nop] x A [x 8000]
  result:  A=0 -> 3226
           A=1 -> 3274
           A=2 -> 3872
           A=3 -> 3932
           A=4 -> 4525
  openmsx-old: A=0 -> 3248
               A=1 -> 3255
               A=2 -> 3893
               A=3 -> 3913
               A=4 -> 4557
  openmsx-rev11643: A=0 -> 3261
                    A=1 -> 3269
                    A=2 -> 3914
                    A=3 -> 3926
                    A=4 -> 4565
  cycles: A=0 -> 10  [ffxoI6]
          A=1 -> 10  [f ffxI6]
          A=2 -> 12  [f f ffxoI6]
          A=3 -> 12  [f f f ffxI6]
          A=4 -> 14  [f f f f ffxoI6]
  note: When there are an odd number of NOP instructions between two OUT
        instructions, one of the NOPs can be executed seemingly 'for free'.
        Or in other words when there's an even number of NOP instructions, the
        OUT instruction has an extra penality cycle.
        These results could be explained by assuming the following structure for
        the out command:  3 cycles [ffx..] followed by possibly one extra
        cycle to align to the slow 3.5MHz bus, followed by 6 cycles (= 3 cycles
        on the slow bus) for the actual IO.


* Internal-ROM

ld hl,(#xxyy)  [x 10000]
  with yy=#00 -> no page break
    with xx in normal RAM
      result: 2855
      cycles: 7  [FffRr]
    with xx in ROM, DRAM mode
      result: 2855
      cycles: 7  [FffRr]
    with xx in ROM
      result: 4080
      cycles: 10  [FffRmRm]     (m -> memory wait cycle)
  with yy=#ff -> page break during read
    with xx in normal RAM
      result: 3265
      cycles: 8  [FffRR]
    with xx in ROM, DRAM mode
      result: 3264
      cycles: 8  [FffRR]
    with xx in ROM
      result: 4080
      cycles: 10  [FffRmRm]
  note: - RAM or ROM in DRAM mode seems to have the same speed, including
          page break optimization
        - reads from ROM take 3 cycles, they don't become slower in case
          of a page break. So it seem there are always 2 cycles to set the
          address plus one wait cycle.
        - I did the same test with the 'ld (#xxyy),hl' instruction (even
          though writing to ROM doesn't make sense). I got the same results.

[ ld a,128 ; or a ]
[ BIOS ROM contains    nop (x 11) ; ret m    at address #1EB2 ]
call #1EB2  [x 10000]
  result: [(D)RAM]  9763-9770
          [ROM]    18757
  cycles: [(D)RAM] 24  [FffWw F  f  f  f  f  f  f  f  f  f  f  fRr ]   (<- 23 !!)
          [ROM]    46  [FffWw Fm Fm Fm Fm Fm Fm Fm Fm Fm Fm Fm FmRr ]
  note: - this confirm 3 cycles per memory read from ROM
        - we measured 24 cycles for (D)RAM while there should only be 23,
          this might be a measurement error though: to calculate the number
          of cycles (in long code sequences) I compare it with the duration
          of a NOP instruction, for long durations differences this may be
          inaccurate


* External-slot

ld hl,(#4000)  [x 5000]
  result: 2857
  cycles: 14  [FffRmmmRmmm] ??
  note: 5 cycles per memory access, close to 3 cycles (@ 3.5MHz) on Z80
        but I'd expected it to match exactly. It's strange to have halve
        cycles on the external 3.5MHz cartridge slots.

ld (#4000),hl  [x 5000]
  result: 2857
  cycles: 14  [FffRmmmRmmm] ??

ld a,(#4000)  [x 5000]
  result: 1634
  cycles: 8  [FffRmm] ??

ld (#4000),a  [x 5000]
  result: 1634
  cycles: 8  [FffWmm] ??

[ ld hl,#4000 ]
ld a,(hl)  [x 15000]
  result: 3669
  cycles: 6  [FRmm] ??

[ ld hl,#4000 ]
ld (hl),a  [x 15000]
  result: 3669
  cycles: 6  [FWmm] ??

[ ld hl,#4000 ]
inc (hl)  [x 15000]
  result: 7337
  cycles: 12  [FRmmxWmmm] ??





TODO: RETN, RST
      CPI(R), LDI(R), INI(R), OUTI(R)
      HALT (how to test?)











* refresh


	org #c000

	di
	ld	b,0
	ld	c,0
	out	(#e6),a
loop	nop		; variable number of nops
	djnz	loop
	dec	c
	jr	nz,loop
	in	a,(#e6)
	ld	l,a
	in	a,(#e7)
	ld	h,a
	ret


nops | real  | openmsx-old
-----+-------+---------
   0 |  8088 |  8036
   1 | 10717 | 10716
   2 | 13336 | 13382
   3 | 16079 | 16042
   4 | 18740 | 18726
  10 | 34778 | 34753

cycles (without refresh) = 65536 * nops + 197375