openMSX/doc/internal/r800-djnz.txt

It seems in some cases on R800 a djnz or jr instruction take one cycle longer
than expected. I discovered this purely by accident: I was doing another timing
test in which I varied the number of instructions inside a loop. For a specific
amount of instructions I got an expected result. This happened when a djnz
instruction was the very last instruction in a 256-byte memory page. In the
following test I'll investigate this in some more detail.



Test-program:

	org	#c000

	di
	ld	b,0

	ds      248         ; vary between 248-251

	out     (#e6),a
loop	djnz    loop
	in      a,(#e6)
	ld      l,a
	in      a,(#e7)
	ld      h,a
	ret

By varying the value of the 'ds' directive between 248 and 251, the start
address of the djnz instruction varies from 0xc0fd to 0xc100. For each position
we measure how long the test takes using the E6-timer (this timer ticks once
every 28 R800 clock cycles, there's also approx 18% overhead for refresh)

djnz-start-address  | real turborGT | openmsx-rev11821 | openmsx-fixed
--------------------+---------------+------------------+--------------
             0xC0FD | 31 - 33       | 31 - 32          | 31 - 32
             0xC0FE | 41 - 42       | 31 - 32 (!!!)    | 41 - 42
             0xC0FF | 52 - 53       | 52 - 53          | 52 - 53
             0xC100 | 31 - 32       | 31 - 32          | 31 - 32
 (there's some variation in the measured E6-ticks, we list the range of all
  measured values in this table)

Translated to clock ticks per iteration:

address | real | rev11821 | fixed
--------+------+----------+------
 0xC0FD |  3   |    3     |   3
 0xC0FE |  4   |    3     |   4
 0xC0FF |  5   |    5     |   5
 0xC100 |  3   |    3     |   3

There are 3 different cases in this test:
 0xC0FD and 0xC100:
   djnz instruction takes 3 cycles, this is the normal case for a djnz
   instruction which does execute a jump. There are no page-breaks: all
   opcode bytes are fetched from the same 256-byte memory page.
 0xC0FE:
   This is the unexpected case, for some yet unknown reason the instruction
   takes 1 cycle extra. Note that all opcode bytes are fetched from the
   same 256-byte memory page. See below for a possible explanation.
 0xC0FF:
   Here both opcode bytes of the djnz instruction are located in a different
   memory page, so per iteration there are two extra cycles for two page break,
   thus 5 cycles in total.



I did a similar test for the jr instruction:

	org	#c000

	di
	ld	b,0

	ds	242	; vary between 239-242

	out	(#e6),a
test2a	djnz	test2b
	in	a,(#e6)
	ld	l,a
	in	a,(#e7)
	ld	h,a
	ret
test2b	jr	test2a

jr-start-address  | real turborGT | openmsx-rev11821 | openmsx-fixed
------------------+---------------+------------------+--------------
           0xC0FD | 63 - 64       | 62 - 63          | 62 - 63
           0xC0FE | 73 - 74       | 62 - 64 (!!!)    | 73 - 74
           0xC0FF | 83 - 84       | 83 - 84          | 83 - 84
           0xC100 | 83 - 84       | 83 - 85          | 83 - 84

address | real | rev11821 | fixed
--------+------+----------+------
 0xC0FD |  6   |    6     |   6
 0xC0FE |  7   |    6     |   7
 0xC0FF |  8   |    8     |   8
 0xC100 |  8   |    8     |   8

Again 3 different cases in this test:
 0xC0FD:
   Both jr and djnz instruction take 3 cycles (when they do jump) there are no
   page break or no extra penalty cycles.
 0xC0FE:
   Now the jr instruction is the last in a memory page, this shows the same
   penalty cycle as a djnz instruction. Again there is no 'real' page break in
   this test.
 0xC0FF and 0xC100:
   In both these cases there are two page breaks per iteration (but at different
   locations for the two cases). So 8 cycles per iteration in total.





Possible explanation (this is just a guess but it does explain the
measurements):

This behaviour could be explained by some (very limited) pipeline behaviour in
the R800: it seems that the decision to cause a page-break on the next
instruction is already made during the execution of the current instruction,
after the last opcode byte is fetched, but before the destination address of
the jump is calculated. (Though when the jump does actually go to another page,
this is also a reason for a page-break).

It's possible all R800 instructions have this pipeline behaviour, but it's only
visible in the djnz and the jr instructions. All other instructions either don't
jump (the PC simply increments) and then it's not possible to externally detect
when exactly the 'must-fetch-opcode-using-page-break-decision' is made. Or the
instruction does jump but it already causes a page-break for another reason, so
the possible extra page-break is always masked. The list of instructions that
cause a 'jump' is:

   djnz, jr, jr-conditional
     These show the extra page-break behaviour

   jp, jp-conditional, jp (hl/ix/iy)
     There's _always_ a forced page-break after this instruction. (The exact
     reason why is not clear to me.)

   call, call-conditional, ret, ret-conditional, rst, accept-an-IRQ
     All these instructions (or events) push/pop on/from the stack. When
     switching between data read/write and opcode fetch there's always a
     page-break;

   otir, otdr, inir, indr, ldir, lddr, cpir, cpdr
     (When these are repeated PC is decremented by 2.) All these instructions
     do a data read or write and thus there already is a page-break when
     switching back to opcode fetching (even if opcode and data are in the
     same memory page).

   halt
     I'm not sure about this instruction: it's possible this instruction
     constantly decrements PC by one (after it's been increased). At least
     this is how Z80 does it. So it might be the case that a halt instruction
     as the last instruction in a memory page 'loops' a bit slower. Though
     this effect will be hard to notice. At the moment I don't know how to
     write a test to detect this. Suggestions are welcome.




As you've already seen in the measurements above: I implemented a forced
page-break in the djnz and jr instructions when they are located at address
0x..FE. After this fix the measurements in openMSX match the real hardware.



Wouter