Graphics on the cybiko
The cybiko has a monochrome non-backlit LCD display. It has 160 pixels across and 100 pixels down. Each pixel has 2 bits associated with it so that it can have 1 of 4 shades. Typically these shades range: off - light grey - dark grey - black. The LCD driver can map different values to these 4 shades, but for most programming the typical values will be used:
00 - off - the lcd is off and the background shows through as 'white' or light
01 - light grey
10 - dark grey
11 - on - black

These bits are packed into bytes so that one byte contains 4 pixels. This saves on memory space - the LCD driver contains the entire memory for the LCD: 40 bytes across by 100 bytes down = 4000 bytes. If each pixel was stored in a byte then 160 x 100 bytes would be needed. The downside to this is that addressing pixels takes more operations to address pixels, thus taking more time. 

The 'Surface'
To address the speed/memory issues, the concept of 'surface' (loosely based on the SDL surface) is presented. A surface is always byte aligned and moved/put as whole bytes. A surface can be operated on then sent to the LCD. When a surface is sent to the LCD it is done very efficiently because all bytes are sent. The Surface and the LCD are byte aligned.

Not all operations are byte aligned. Fonts, sprites, pixelmaps are not byte aligned. These operations have been optimized to be fast.

Some experimentation has been done using one byte per pixel. This makes some operations very fast, but when compressing back to the LCD, most of the speed gains are lost. If it has to be done on every screen update, most gains become losses.

Using surfaces in games, etc: Divide the LCD display in to byte aligned sizes. One surface could be the scoring, another status and the other the gameboard. Each surface can now be operated on independantly and only has to be sent to the LCD when something in that surface changes. So the gameboard is updated often for sprites, etc, but the score surface only is sent to the LCD when the score changes. This usage is much more efficient than the previous 'change and write' where maybe the score changes and the whole screen bitmap is sent to the LCD.

gfx_XXXX - usually primitives for circles, boxes
surface_XXXX - surface operations
lcd_XXXX - LCD specific - these do not need surfaces, etc can be used on there own for small programs - see clock prog for example of lcd__ only calls.