5.3.1. Hardware cursor extension

Before the hardware cursor was introduced, moving the cursor required software to:

With a cursor size of 64x64 and 24-bit color, each cursor move involved reading and writing approximately 75KB of data. The hardware cursor, however, provides a completely separate image buffer for the cursor, and superimposes the cursor image on the LCD output stream at the current cursor (X,Y) coordinate. To move the hardware cursor, the software driver supplies a new cursor coordinate. Because the frame buffer requires no modification, this significantly reduces the software overhead.

The cursor image is held in the CLCDC in a 256x32-bit dual-port RAM. The contents are programmed through the CLCDC AMBA AHB slave interface.

Figure 5.3 shows a block diagram of the hardware cursor.

Figure 5.3. Hardware cursor block diagram

Operation

All cursor programming registers are accessed through the CLCDC slave interface. The cursor image is held in the CLCDC in a 256x32-bit dual-port RAM.

When enabled, the hardware cursor uses the horizontal and vertical synchronization signals, along with a pixel clock enable and various display parameters to calculate the current scan coordinate such as:

  • Horizontal Back Porch (HBP)

  • Vertical Back Porch (VBP)

  • Horizontal ACtive line (HAC)

  • Vertical Active Column (VAC)

  • Pixels-Per-Line (PPL)

  • Lines-Per-Panel (LPP).

When the display point is inside the bounds of the cursor image, the cursor replaces frame buffer pixels with cursor pixels.

The image RAM offers single cycle performance to enable the read to take place in the clock cycle preceding its use, and maintains the data output until the next access. This removes the requirement for a holding register.

When the last cursor pixel is displayed, an interrupt is generated that can be used by software as an indication that it is safe to modify the cursor image. This enables software controlled animations to be performed without flickering for frame synchronized cursors.

Supported cursor sizes

Table 5.2 shows the two cursor sizes that are supported.

Table 5.2. Supported cursor images

X PixelsY PixelsBits per pixelWords per lineWords in cursor image
32322264
646424256

Movement

The following descriptions assume that both the screen and cursor origins are at the top left of the visible screen (the first visible pixel scanned each frame). Each pixel coordinate is assumed to be the top left corner of the pixel as shown in Figure 5.4.

Figure 5.4. Hardware cursor movement

The ClcdCrsrXY Register controls the cursor position on the cursor overlay. This provides separate fields for X and Y ordinates.

The ClcdCrsrConfig Register (see Cursor Configuration Register) provides a FrameSync bit controlling the visible behavior of the cursor.

With FrameSync inactive, the cursor responds immediately to any change in the programmed ClcdCrsrXY value. Some transient smearing effects are likely to be visible if the cursor is moved across the LCD scan line.

With FrameSync active, the cursor only updates its position after a vertical synchronization has occurred. This provides clean cursor movement, but the cursor position only updates once a frame

The ClcdCrsrXY Register (see Cursor XY Position Register) is programmed with positive binary values that enable the cursor image to be located anywhere on the visible screen image. The cursor image is clipped automatically at the screen limits when it extends beyond the screen image to the right or bottom (see X1,Y1 in Figure 5.5). The checked pattern shows the visible portion of the cursor.

Because the ClcdCrsrXY Register values are positive integers, to emulate cursor clipping on the left and top of screen, a Clip Index Register, ClcdCrsrClipXY, is provided. This determines which point of the cursor image is positioned at the ClcdCrsrXY coordinate. For clipping functions on the Y axis, ClcdCrsrXY(X) is zero, and Clip(X) is programmed to provide the offset into the cursor image (X2 and X3). The equivalent function is provided to clip on the X axis at the top of the display (Y2).

For cursors that are not clipped at the X=0 or Y=0 lines, program the Clip Index Register X and Y fields with zero to display the cursor correctly. See Clip(X4,Y4) for the effect of incorrect programming.

Figure 5.5. Hardware cursor clipping

Image format

The LCD frame buffer supports three packing formats, but the hardware cursor image requirement has been simplified to support only LBBP. This is little-endian byte, big-endian pixel for Windows CE mode.

The Image RAM start address (IBase) is 0x10120800.The displayed cursor coordinate system is expressed in terms of (X,Y). 64x64 is an extension of the 32x32 format shown in Figure 5.6.

Figure 5.6. Hardware cursor image format

For 32x32 bit pixels, four cursors are held in memory, each with the same pixel format. Table 5.3 lists the base addresses for the four cursors.

Table 5.3. 32x32 cursor base addresses

AddressDescription
0x10120800Cursor0 start address
0x10120900Cursor1 start address
0x10120A00Cursor2 start address
0x10120B00Cursor3 start address

Table 5.4 and Table 5.5 list the LBBP buffer to pixel mapping for Cursor0.

Table 5.4. LBBP buffer to pixel mapping 32x32 Cursor0 for datawords [31:16]

Offset from CLCDC base at 0x10120800Dataword
[31:30][29:28][27:26][25:24][23:22][21:20][19:18][17:16]
+0(12,0)(13,0)(14,0)(15,0)(8,0)(9,0)(10,0)(11,0)
+4(28,0)(29,0)(30,0)(31,0)(24,0)(25,0)(26,0)(27,0)
+(8*y)(12,y)(13,y)(14,y)(15,y)(8,y)(9,y)(10,y)(11,y)
+(8*y)+4(28,y)(29,y)(30,y)(31,y)(24,y)(25,y)(26,y)(27,y)
+0xF8(12,31)(13,31)(14,31)(15,31)(8,31)(9,31)(10,31)(11,31)
+0xFC(28,31)(29,31)(30,31)(31,31)(24,31)(25,31)(26,31)(27,31)

Table 5.5. LBBP buffer to pixel mapping 32x32 Cursor0 for datawords [15:0]

Offset from CLCDC base at 0x10120800Dataword
[15:14][13:12][]11:10][9:8][7:6][5:4][3:2][1:0]
+0(4,0)(5,0)(6,0)(7,0)(0,0)(1,0)(2,0)(3,0)
+4(20,0)(21,0)(22,0)(23,0)(16,0)(17,0)(18,0)(19,0)
+(8*y)(4,y)(5,y)(6,y)(7,y)(0,y)(1,y)(2,y)(3,y)
+(8*y)+4(20,y)(21,y)(22,y)(23,y)(16,y)(17,y)(18,y)(19,y)
+0xF8(4,31)(5,31)(6,31)(7,31)(0,31)(1,31)(2,31)(3,31)
+0xFC(20,31)(21,31)(22,31)(23,31)(16,31)(17,31)(18,31)(19,31)

Table 5.6 and Table 5.7 list the format in which a single 64-bit cursor can be held.

Table 5.6. LBBP buffer to pixel mapping 64x64 for datawords [31:16]

Offset from CLCDC base at 0x10120800Dataword
[31:30][29:28][27:26][25:24][23:22][21:20][19:18][17:16]
+0(12,0)(13,0)(14,0)(15,0)(8,0)(9,0)(10,0)(11,0)
+0x4(28,0)(29,0)(30,0)(31,0)(24,0)(25,0)(26,0)(27,0)
+0x8(44,0)(45,0)(46,0)(47,0)(40,0)(41,0)(42,0)(43,0)
+0xC(60,0)(61,0)(62,0)(63,0)(56,0)(57,0)(58,0)(59,0)
+16*y+0(12,y)(13,y)(14,y)(15,y)(8,y)(9,y)(10,y)(11,y)
+16*y+4(28,y)(29,y)(30,y)(31,y)(24,y)(25,y)(26,y)(27,y)
+16*y+8(44,y)(45,y)(46,y)(47,y)(40,y)(41,y)(42,y)(43,y)
+16*y+12(60,y)(61,y)(62,y)(63,y)(56,y)(57,y)(58,y)(59,y)
+0x3FC(60,63)(61,63)(62,63)(63,63)(56,63)(57,63)(58,63)(59,63)

Table 5.7. LBBP buffer to pixel mapping 64x64 for datawords [15:0]

Offset from CLCDC base at 0x10120800Dataword
[15:14][13:12][11:10][9:8][7:6][5:4][3:2][1:0]
+0(4,0)(5,0)(6,0)(7,0)(0,0)(1,0)(2,0)(3,0)
+0x4(20,0)(21,0)(22,0)(23,0)(16,0)(17,0)(18,0)(19,0)
+0x8(36,0)(37,0)(38,0)(39,0)(32,0)(33,0)(34,0)(35,0)
+0xC(52,0)(53,0)(54,0)(55,0)(48,0)(49,0)(50,0)(51,0)
+16*y+0(4,y)(5,y)(6,y)(7,y)(0,y)(1,y)(2,y)(3,y)
+16*y+4(20,y)(21,y)(22,y)(23,y)(16,y)(17,y)(18,y)(19,y)
+16*y+8(36,y)(37,y)(38,y)(39,y)(32,y)(33,y)(34,y)(35,y)
+16*y+12(52,y)(53,y)(54,y)(55,y)(48,y)(49,y)(50,y)(51,y)
+0x3FC(52,63)(53,63)(54,63)(55,63)(48,63)(49,63)(50,63)(51,63)

Software format for Windows CE

The software low-level cursor mask is split into two memory areas providing separate AND and XOR buffers. These buffers are held as single bit memory images, and must be combined by software to form a unified cursor image that is then copied to the cursor image buffer when required.

The hardware cursor does not support full color cursor images because of practical limitations on the size of the image dual-port RAM.

The software AND and XOR masks both follow the same format. Table 5.8 lists the format for 32x32 pixels and Table 5.9 the format for 64x64 pixels.

Table 5.8. 32x32 software mask storage

External memory offsetData bit to pixel correspondence
[7][6][5][4][3][2][1][0]
+0(0,0)(1,0)(2,0)(3,0)(4,0)(5,0)(6,0)(7,0)
+1(8,0)(9,0)(10,0)(11,0)(12,0)(13,0)(14,0)(15,0)
+2(16,0)(17,0)(18,0)(19,0)(20,0)(21,0)(22,0)(23,0)
+3(24,0)(25,0)(26,0)(27,0)(28,0)(29,0)(30,0)(31,0)
. . .--------
+127(24,31)(25,31)(26,31)(27,31)(28,31)(29,31)(30,31)(31,31)

Table 5.9. 64x64 software mask storage

External memory offsetData bit to pixel correspondence
[7][6][5][4][3][2][1][0]
+0(0,0)(1,0)(2,0)(3,0)(4,0)(5,0)(6,0)(7,0)
+1(8,0)(9,0)(10,0)(11,0)(12,0)(13,0)(14,0)(15,0)
+2(16,0)(17,0)(18,0)(19,0)(20,0)(21,0)(22,0)(23,0)
+3(24,0)(25,0)(26,0)(27,0)(28,0)(29,0)(30,0)(31,0)
+4(32,0)(33,0)(34,0)(35,0)(36,0)(37,0)(38,0)(39,0)
+5(40,0)(41,0)(42,0)(43,0)(44,0)(45,0)(46,0)(47,0)
+6(48,0)(49,0)(50,0)(51,0)(52,0)(53,0)(54,0)(55,0)
+7(56,0)(57,0)(58,0)(59,0)(60,0)(61,0)(62,0)(63,0)
. . .--------
+511(56,63)(57,63)(58,63)(59,63)(60,63)(61,63)(62,63)(63,63)

Pixel encoding

Each pixel of the cursor requires two bits of information that are interpreted as Color0, Color1, Transparent, and Transparent inverted.

In the coding scheme, bit 1 selects between color and transparent (AND mask) and bit 0 selects variant (XOR mask).

Table 5.10 lists the pixel encoding bit assignments.

Table 5.10. Pixel encoding

BitsDescription
[00]Color0. The cursor color is displayed according to the Red-Green-Blue (RGB) value programmed into the CrsrPalette0 Register.
[01]Color1. The cursor color is displayed according to the RGB value programmed into the CrsrPalette1 Register.
[10]Transparent. The cursor pixel is transparent, so is displayed unchanged. This enables the visible cursor to assume shapes that are not square.
[11]Transparent inverted. The cursor pixel assumes the complementary color of the frame pixel that is displayed. This can be used to ensure that the cursor is visible regardless of the color of the frame buffer image.
Copyright © 2004, 2006 ARM Limited. All rights reserved.ARM DDI 0287B
Non-Confidential