ZipIt Peeks & Pokes

Unofficial Zipit "Peeks & Pokes"
Version 1.2 -  June 10, 2005

Contributors: "Ken McGuire"  ("cynfab") "matt_westervelt"  ("mattw") "Adam Tilghman"  ("atilghma")

Updates/Corrections/Additions: Please send them to Adam Tilghman .

Message board, files, links to chipset data sheets: http://groups.yahoo.com/group/zipitwireless

Cirrus ep7312 (Main CPU) General-purpose I/O (GPIO) pins:

Port A: All   = input      [ keyboard row inputs ]

Port B: Bit 0 = unused        [ unaccessable ] 1 = output    [ green LED ] 2 = input     [ battery charging ] 3 = input     [ lid-closed switch status & tied to R115; also tied to Port A interrupt ] 4 = input       [ hpdet from audio jack & WM8751L 23 ] 5 = unused    [ goes to a via on the back of the board ] 6 = i/o       [ i2c SDA ] 7 = i/o       [ i2c SCK ]

Port D:     0 = output     [ yellow/orange LED ] 1 = output    [ drives gate of "CR5" a 2N7002 fet part of contrast control ] 2 = output    [ drives gate of "CR6" a 2N7002 fet part of contrast control ] 3 = output    [ drives gate of "CR8" a 2N7002 fet part of contrast control ] 4 = output? [ cynfab: Set & cleared by the Zipit audiodrv.o code; not sure what it does, unaccessable.] 5 = output    [ enable/disable LCD ] 6 = reserved  [ used for SDRAM interface ] 7 = reserved  [ used for SDRAM interface ]

Port E:     0 = tied low   [ ==> boot ROM is 16-bits wide ] 1 = tied high [ ==> boot ROM is 16-bits wide ]

DSR:        [ unused and unaccessable ] DCD:        [ unused and accessable on bottom of board ] CTS:        [ unused and unaccessable ]

--- Zipit I2C bus:

Device 0x1b =  wm8751l DAC (handles audio output) [ cynfab has written a working driver for this chip ]

Device 0x55 =  LPC915 microcontroller (?? handles battery charging, power mgmt, more? ??)

Register 0x01 = ??? (writing to 0x02 loads a value into this reg.)

Register 0x02 = READ: battery charge state? (per cynfab) [ atilghma: by averaging the last 20 values I get a consistent reading which seems to approximate battery charge level. Reading this register may directly sample the voltage across the battery via the LPC915's ADC comparator.]

WRITE: writing to this location seems to load a related value into Register 0x01,

Register 0x04 = ??? (value seems to fluctuate)

Register 0x81 = READs or WRITEs: Power down the system immediately

Register 0x84 = READs or WRITEs: Reboot the system after ~1 sec. delay

The LPC915 has the following connections:

Pin 2  P0.0  input   from R102 & CR12  P/O Reset ckt Pin 1  P0.1  ? from R116 & R114 P/O Audio Jack extra pins Pin 14 P0.2  input   from voltage divider across battery Pin 13 P0.3  input   from R112 & CR12  P/O Reset ckt Pin 12 P0.4  ? from C52 & U3 (k6) wireless chip Pin 11 P0.5  NC

Pin 9  P1.0  ? from CPU nEint Pin 8  P1.1  ? from CPU Wakeup Pin 7  P1.2  i/o     i2c SCL Pin 6  P1.3  i/o     i2c SDA Pin 5  P1.4  ? from CPU nPOR Pin 3  P1.5  NC

Pin 4  VSS   GND Pin 10 VDD   +V

-- end --

LCD framebuffer
> Straight to the point: > When accessing the framebuffer memory, how many bits is the IO?

Each pixel is 4 bits. The 320x240 pixel screen is 38400 bytes (320x240/2) - 160 bytes per row. For speed, I recommend accessing them 4 pixels at a time (32 bits written to framebuffer memory). The CPU can address memory in 8, 16 or 32 bit sizes. The framebuffer is regular memory (either SRAM or the SDRAM). Writing a 4 bit value" == reading the old byte from framebuffer memory, masking out the nibble you want to replace, "OR" in the new nibble, and writing the updated byte back to the frame buffer

The 4 bits for each pixel is an index into the hardware color palette. The standard Linux palette is non-linear (used to make the Tux penguin look good)

If you run "lcdpal 0" it will set the hardware color palette to a linear palette

That way a 4 bit value of 0 will be dark (~= black), and a 4 bit value of 15 will be brightest (~=white).

If you don't want to use 'lcdpal' you can set the register yourself:

PALLSW = 0x89ABCDEF;

PALMSW = 0x01234567;