Skip to content
Tags

, ,

A bit disappointed in the Z80 SPI speed

May 17, 2016

Clearing the TFT LCD just takes a lot of data transfer.  For each of the 240*320 pixels you have to send TWO 8 bit bytes. so that’s 1.2MB.  At 4mhz then, the best you could hope for is 1/3 second or so.  I can’t get anywhere near that though.  The naive fill routine written in Z80 assembler looks like uses a two instruction inner loop(OUT (0x81),a; djnz…).  This adds about 4us between each 2us burst of clock so it takes almost a second to clear the whole screen.  You can improve that a bit by doubling up the OUT’s and halving the count.

I remembered something Matt Millman had said about running the TP3465V in 16 bit mode but I still seem to need a nop between writes or it mungs the bits somehow and, in the end, it’s not much faster.

//16 bit fill routine
void zfillb(unsigned int n, unsigned char c){ //send n copies of c
	__asm
	;prolog will have prepped ix=sp
	ld	e,(ix+4)
	ld	d,(ix+5)
; here length is in de, value is at (ix+6)
	srl d
	rr	e
	ld	a,0xFF	;set channel 0 to 16 bits
	out (0x8c),a ;by writing to the MWM bit

	ld b,e          ; Number of loops is in DE
	dec de          ; Calculate DB value (destroys B, D and E)
	inc d
	ld a,(ix+6)
l_zfillb_00101:
		out (0x81),a	;first byte
		nop
		out (0x80),a	;second the same
	djnz l_zfillb_00101
	dec d
	jp nz,l_zfillb_00101
	;epilog will restore ix and return
	ld	a,0x00	;set channel 0 to 8 bits
	out (0x8c),a
	__endasm;
}
//8 bit follows
void zfilla(unsigned int n, unsigned char c){ //send n copies of c
	__asm
	;prolog will have prepped ix
	ld	e,(ix+4)
	ld	d,(ix+5)
	srl d
; here length is in de, value is at (ix+6)
; now we want lsb of count, msb+1(*) in d (* unless already 0)
	ld b,e          ; Number of loops is in DE
	dec de          ; Calculate DB value (destroys B, D and E)
	inc d
	ld a,(ix+6)
l_zfilla_00101:
		out (0x81),a
		nop
		out (0x81),a
	djnz l_zfilla_00101
	dec d
	jp nz,l_zfilla_00101
	;epilog will restore ix and return
	__endasm;
}

I always want the last word so that wordpress doesn’t eat my code!

Advertisements
3 Comments
  1. John Payson permalink

    When I’ve looked at interfacing those LCDs, one thing I’ve thought of doing would be to use a little extra hardware so that each byte output from the CPU could feed one or more pixels to the display. While having 65536 colors might be nice, being able to output 256-color graphics twice as fast, 16-color graphics four times as fast, or two-color graphics 16 times as fast, would be even nicer. If your display panel has exposed parallel-data wires, acceleration to accommodate the 256-color and two-color cases might be possible with less than a dozen standard chips–fewer if you include a small PLD, and would give the Z80 performance comparable to what would have been achieved with monochrome screens back in the Z80’s day).

  2. yes, i’m sure if you went to a parallel interface you could speed it up. It would be better if the d*mned thing had a built-in monochrome or 256 colour mode.

    I guess it’s possible you could do something like a clock doubler on the spa sick line when you were sending the actual pixel content but the time required to switch it off and on would probably kill the advantage.

Trackbacks & Pingbacks

  1. TP3465V 16 Bit Mode Works Just Fine | olduino

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: