!!! THIS INFORMATION IS OBSOLETE !!!

This document describes an initial improvement to the openMSX VDP LINE command
timing. Later it has been improved further to be nearly identical to the real
VDP. Those improvements are described in the 'vdp-vram-timing' document.

So this document is only useful if you're interested in the historic
development of openMSX.

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

Speed-test for V99x8 LINE commands
----------------------------------

This test is inspired by this forum topic:
   http://www.msx.org/forum/msx-talk/software-and-gaming/line
and more in particular the post by NYYRIKKI on 09-08-2012, and the pictures he
posted the next day.

Very briefly his test draws in a loop lines (using the LINE command) from the
center of the screen to each point along the edge of the screen. _While_ the
command is executing the command engine COLOR register is changed rapidly. This
results in color patterns that give an indication for how fast the LINE command
is executing for different line directions (see the pictures in the forum).

I took this test as a starting point and changed it in the following ways:
 a) Run in screen 8 instead of screen 5
 b) Start drawing from pixel (0,0) instead of from the center
 c) Change the colors faster

a) The color value of a pixel is an indication for how many times the color
register has been changed (in my test it starts at 0 and increments by 1 each
time). In screen 8 we see the lower 8 bits of this count, while in screen 5 we
only have 4 bits. Even in screen 8 this counter will overflow (we actually need
9 bits) but getting the actual count value is easier in screen 8. (As a
verification we also did a few tests in screen 5 and those gave the exact same
timing results as compared to screen 8.)

b) When drawing from the top-left we can draw lines of length 256 pixels
(longest axis) instead of only 128 pixels. This gives more accurate
measurements. From NYYRIKKI's original pictures we can see the pattern has 8
axis of symmetry, so it's OK to only test one octet (only 1 direction in X/Y
and also only X-major).

c) NYYRIKKI's original test used OTIR to rapidly change the COLOR register,
this takes 23 Z80 cycles per iteration. I use a long sequence of
  INC A ; OUT (#9B),A
instructions, this only takes 17 cycles per change. Multiply this by 6 to get
VDP ticks.

At the bottom of this text you find the source code of my test program.


We run this test program in 3 modes:
 1) display enabled, sprites enabled
 2) display enabled, sprites disabled
 3) display disabled, (sprite status doesn't matter)
See 'line-speed.xcf.bz2' for the graphical output of these tests
(enable/disable the different layers to see the different pictures).


Next we fit this data on some timing model. This is the model we used:

 time-of-line-cmd = A * pixels-of-major-axis + B * pixels-of-minor-axis.

With A and B (yet unknown) constants. (BTW the old timing model in openMSX
had B==0).

In the last column of the 3 pictures we can read an indication for the total
time it took to draw this line. After taking overflow into account we can
multiply this number by '17 * 6' to get (approximately) the time in VDP cycles
it took to draw the LINE to that point. Note that we can only (easily) do this
for the pixels in the last column because the pixels in the other columns are
possibly overwritten by multiple LINE commands.

So now we have 256 measurements to fit two parameters. When doing a
least-squares-fit (actually a least-squares-fit with the additional constraint
that the result must be integer) we get these results:

  display=on, sprites=on   A = 135    B = 36
  display=on, sprites=off  A = 120    B = 30
  display=off              A = 109    B = 29


Next we change the implementation in openMSX for this timing model, and then we
run the same tests we first ran on a real machine in openMSX (you can see those
results also in 'line-speed.xcf.bz2).


Compared to openMSX the real measurements show more irregularities. This means
that the timing model is not yet complete. My current best guess is that these
irregularities can be explained by fixed VRAM-access-slots for the different
VDP subsystems. But very little information is known about such access-slots.


Wouter



;-----------------------------------------------------------------------------

		org	#C000-7

		db	#fe
		dw	start
		dw	stop
		dw	start

start		di

		ld	a,2
		out	(#99),a
		ld	a,15+128
		out	(#99),a		; Select S#2
WaitCE		in	a,(#99)
		rra
		jp	c,WaitCE

loop
wait1		in	a,(#99)
		and	#40
		jr	z,wait1		; wait if not inside vertical border
wait2		in	a,(#99)
		and	#40
		jr	nz,wait2	; wait if inside vertical border
		; at this point we're at the top of the display area

		ld	a,36
		out	(#99),a
		ld	a,17+128
		out	(#99),a		; Indirect access to R#32 and up
		ld      hl,LineCmd
		ld	bc,10*256+#9B
		otir

		ld	a,44+128
		out	(#99),a
		ld	a,17+128
		out	(#99),a		; Indirect access to CMD-CLR

		ld	a,#70
		out	(#99),a
		ld	a,46+128
		out	(#99),a		; start LINE cmd

		; Change command color register as fast as possible
		;   17 Z80 cycles per change
		xor	a
		out	(#9B),a ; 0x000
		inc	a
		out	(#9B),a ; 0x001
		[ repeated so that we have a sequence of 512 OUT instructions ]
		inc	a
		out	(#9B),a ; 0x1ff


		in	a,(#99)
		rra
		jr	nc,ok
		halt			; ERROR line cmd was not yet finished!
ok
		ld	hl,(LineCmd+6)	; ny
		ld	a,h
		or	a
		jr	nz,break
		inc	hl
		ld	(LineCmd+6),hl
		jp	loop

break		xor	a
		out	(#99),a
		ld	a,15+128
		out	(#99),a		; Select S#0

		ei
		ret

LineCmd		dw	  0, 0		; dx, dy
		dw	256, 0		; nx, ny
		db	  0
		db	  0

stop		equ	$