paul's blog

Light Table

paul — Sat, 19 Jun 2010 14:09:10 -0500

In my slow but steady quest for better macro photography of electronic projects, I decided to build a light table to (hopefully) eliminate shadows.

With boards from Laen's PCB group order, materials from TAP Plastics, 15 white LEDs and misc parts I mostly had laying around, this is how it turned out:

Read on for electronic details....

This view is inside a cheap 2 foot sized light tent I purchased from some ebay vendor, and a couple bright lights outside the tent on both side.

The LEDs are Cree CLM3C-WKW-CWBYA453, which are supposedly the same 5500K color temperature as the CFL lights outside the tent. Maybe that matters, maybe not, but it seemed like a good idea.

The Cree LED is a surface mount part, but fortunately Lean's PCB group order made it
very easy to convert to something I can solder wires onto. All the PCBs mount with
double sticky mounting tape.

As you can see in this LED photo, there's a bit of shadow. It's a soft
shadow due to the light tent casting light from many directions, but it's
still very present. This is the type of shadow I'm hoping just a little bit
of under side lighting will eliminate.

This little board is a contant current regulator. It takes a 0 to 5 volt input
and regulates a 0 to 20 mA output current to a string of 5 LEDs. I wanted to make
sure the current was perfectly contant since the camera might choose a quick
shutter time.

Here's the schematic for that circuit. At the time, it seemed like a good
idea to sense the current using a resistor between the NPN transistor's
collector and the LEDs. The idea was any small change in ground potential
between the board 0-5V control signal wouldn't matter, if I ran separate
signal and power ground lines.

But I didn't consider the current draw though those resistors around the
upper opamp. As you can see in the schematic, I change the values to
about as high as I reasonably could. It still have a tiny bit of the
lowest part of the range where the LEDs won't completely turn off.

The 0 to 5 volt signal just comes from this potentiometer on the front
panel. Because it's driving only the inputs to opamps, it doesn't have
any substantial load. I still used a 1K pot anyways, though a higher
value would have consumed a little less current. I guess I didn't care
about an extra 5 mA.

The power for everything comes from this simple little power supply,
which is just (approx) 24 volts unregulated, and a 5 volt regulated
output from the pot, which is from a 7805 regulator. Simple.

Of course, the opamp circuit isn't perfect. After putting this together,
I decided to try a different approach, sensing on the emitter side, and
no current sensing path to add to the LED current! I
also included 4.7K resistors on the feedback looks, and the positive
inputs see about a 1K impedance. Any errors from the opamp's input
(PNP) bias currents should be small, and shoud be more on the negative
than positive, so hopefully any tiny error will tend to redude the LED
current, not increase.

Then again, the original boards might work out ok, but Laen's PCB
group order makes it so very easy to just quickly draw up a (small)
board. Because the cost is so low, it's easy to just send it off
without all the worry the goes into a normal board order.

I still haven't actually put this thing to use... the top plastic cover
turned out to be just a bit too small, so I need to go shave it down
to size on my table saw (which currently has a bunch of other project
stuff piled on top of it). But soon, with a little luck, I'll be able
to take pictures of electronic stuff and adjust the light table to
null out or at least soften away most of the little shadows that I still
get, even with the light tent.

Accel-only breakout board (working)

paul — Sun, 13 Jun 2010 12:10:39 -0500

Boards from Laen's PCB group order arrived today, and I'm happy to say the Accel-only breakout board works. This was inspired by Sott's design, but with support for 5 volts, and using I2C.

I'll have 4 more kits at the next Monday meetup. The kit has all parts except the MMA7455 chip, and the kit's FREE if you build it or wreck it trying. So far, I've only written a tiny test program. Here's the code:

#include <Wire.h>


void setup() {
  Serial.begin(38400);
  Wire.begin();
  delay(500);
  
  // enter measurement mode
  Wire.beginTransmission(29);
  Wire.send(22);
  Wire.send(5);
  Wire.endTransmission();
}

void loop() {
  signed char x, y, z;
  
  delay(100);
  Wire.beginTransmission(29);
  Wire.send(6);
  Wire.endTransmission();
  Wire.requestFrom(29, 3);
  while (!Wire.available()) /* wait */ ;
  x =  Wire.receive();
  while (!Wire.available()) /* wait */ ;
  y =  Wire.receive();
  while (!Wire.available()) /* wait */ ;
  z =  Wire.receive();
  
  Serial.print("x = ");
  Serial.print((int)x);
  Serial.print(", y = ");
  Serial.print((int)y);
  Serial.print(", z = ");
  Serial.print((int)z);
  Serial.println();
  delay(200);
  
}

Obviously there's quite a lot more that can be done with the code, but at least this prints raw numbers and they clearly do change if you move the board around, or tilt it on axis. Clearly quite a lot more software work is needed to turn the raw acceleration numbers into useful X, Y, Z displacement and/or tilt angles.

Accel-only breakout board

paul — Fri, 11 Jun 2010 17:52:11 -0500

At the last meetup, I handed out 4 kits for an accelerometer-only breakout board... sans the bare PCB since they're delayed. Anyway, here's the parts placement diagram:

On the next group order, I'm going to send in an Accel+Gyro breakout board. Thanks to Scott for finding these cool chips!

HUB ISP

paul — Sun, 06 Jun 2010 14:14:54 -0500

On Friday I ran across a page lamenting the "chicken or egg" problem with most AVR ISP programmers, and I got to thinking about a way to do it using only USB and no programmable chips or specialized USB parts.

Teensy as Benito, at 57600 baud

paul — Sun, 30 May 2010 13:10:13 -0500

At the last Monday meetup, Scott mentioned my Teensy-as-Benito code wasn't working with the '328-based Arduino and Dorkboards, which now run at 57600 baud. So this weekend I dusted off my Dorkboard to investigate.

Read on for details, and updated code with a workaround....

The UART (serial port) in these AVR chips generates its baud rate from the main clock, which is usually a very accurate crystal or pretty accurate ceramic resonator. However, it can only divide that clock by integer multiples of 8 or 16. With a 16 MHz clock, you can get close, but not exactly the correct baud rates. Some small error is ok. Usually about 2% to 2.5% is the maximum error before reliability problems occur.

The Arduino bootloader is actually using 58824 baud, which is 16e6 / (17 * 16). That's +2.124% error.

The UART code in Teensyduino, when 57600 baud is requested, uses 57143, which is 16e6 / (35 * 8). That's -0.794% error.

Either can communicate with a FTDI chip or PC, which generates a very accurate 57600 baud rate, but when used together, the total error is too much because Arduino's is 2.1% too fast and Teensy's is 0.8% too slow.

As a workaround, I just added a check for when the PC requests 57600 baud, and instead the baud rate is set to 58824, to exactly match the Arduino bootloader's actual baud rate.

You can download the updated code. I also added code to blink the LED, and I included pre-compiled copies for Teensy 2.0, Teensy 1.0, and Don's Benito, so you can just load the appropriate code onto your board using the Teensy Loader or DFU programmer. Of course, you can customize it as easily as tweaking any Arduino-based project, because it's built with Teensyduino!

Here is the source code:

unsigned long baud = 19200;
HardwareSerial Uart = HardwareSerial();
const int reset_pin = 4;
const int led_pin = 11;  // 11=Teensy 2.0, 6=Teensy 1.0, 16=Benito
const int led_on = HIGH;
const int led_off = LOW;

void setup()
{
	pinMode(led_pin, OUTPUT);
	digitalWrite(led_pin, led_off);
	digitalWrite(reset_pin, HIGH);
	pinMode(reset_pin, OUTPUT);
	Serial.begin(baud);	// USB, communication to PC or Mac
        Uart.begin(baud);	// UART, communication to Dorkboard
}

long led_on_time=0;

void loop()
{
	unsigned char c, dtr;
	static unsigned char prev_dtr = 0;

	if (Serial.available()) {
		c = Serial.read();
		Uart.write(c);
		digitalWrite(led_pin, led_on);
		led_on_time = millis();
		return;
	}
	if (Uart.available()) {
		c = Uart.read();
		Serial.write(c);
		digitalWrite(led_pin, led_on);
		led_on_time = millis();
		return;
	}
	dtr = Serial.dtr();
	if (dtr && !prev_dtr) {
		digitalWrite(reset_pin, LOW);
		delayMicroseconds(250);
		digitalWrite(reset_pin, HIGH);
	}
	prev_dtr = dtr;
	if (millis() - led_on_time > 3) {
		digitalWrite(led_pin, led_off);
	}
	if (Serial.baud() != baud) {
		baud = Serial.baud();
		if (baud == 57600) {
			// This ugly hack is necessary for talking
			// to the arduino bootloader, which actually
			// communicates at 58824 baud (+2.1% error).
			// Teensyduino will configure the UART for
			// the closest baud rate, which is 57143
			// baud (-0.8% error).  Serial communication
			// can tolerate about 2.5% error, so the
			// combined error is too large.  Simply
			// setting the baud rate to the same as
			// arduino's actual baud rate works.
			Uart.begin(58824);
		} else {
			Uart.begin(baud);
		}
	}
}

Micro SD

paul — Sun, 16 May 2010 22:35:52 -0500

What I've been working on lately....

SD / Micro SD

paul — Sat, 15 May 2010 15:17:46 -0500

loving the PCB group order....

paul — Mon, 26 Apr 2010 14:13:39 -0500

Breadboard Power from 1 AA Battery

paul — Tue, 01 Dec 2009 16:23:50 -0600

Inspired by Laen's group PCB order and Ladyada's breadboard power supply, I decided to try making one that runs from a single AA battery.

click Read more for schematic and rambling about the design.....

Larger schematic 1280 pixels wide

The TI TPS61020 chip does all the heavy lifting. It's a pretty amazing chip.... I just hope it works as well as the datasheet says. TI claims it's 96% efficient (indeed it does use sync rectification), but I suspect that doesn't include copper and core losses in the inductor.

I included a MOSFET to (hopefully) protect against reverse polarity insertion of the battery. The funny capacitor and diodes thing attached to the inductor is pretty much right out of an example in the TPS61020 datasheet to create an unregulated voltage approximately double the output voltage. When you first attach the battery, the mosfet only turns on because of the battery voltage, but once the chip starts switching, the mosfet gate should be driven with at least 6 volts, which gets it to it's lowest on resistance. In theory, it should only be 0.022 ohms. With only one AA battery, there's no extra voltage to waste!

I wanted to keep this thing as small as possible, so nearly the entire top side is taken up by the AA battery holder. There's just a little exposed strip on the right side, for two little slide switches to turn it on/off, and to select 3.3 or 5 volts. I suppose I could have made it also adjustable like Ladyada's, but there wasn't room to place a pot without making the board quite a bit larger.

"Getting Started" Workshop Materials Are Online

paul — Wed, 14 Oct 2009 01:13:55 -0500

All the material covered in the "Getting Stared With Microcontrollers" workshop, the printed handout and online version, are available if you missed it.

Workshop on Monday, Oct 5th, 7-9pm

paul — Thu, 01 Oct 2009 11:39:55 -0500

The "Getting Started With Microcontrollers" workshop is coming up, next Monday. It's at Techshop (10100 SW Allen Blvd, Beaverton OR 97005) from 7-9pm, in the upstairs area. Cost is $10 to $40 depending on which parts you need. Here is the sign up link:

http://www.pjrc.com/store/workshop.html

Read on for details about this workshop....

This workshop is really intended for people who've wanted to build electronic projects but haven't managed to get started. By using a microcontroller (which is a tiny computer in a single chip), you can connect simple circuits to the pins and then use code to actually make your project function. The Arduino IDE provides a very simple, beginner-oriented environment for writing that code.

If you've purchased an Arduino compatible board but is sat on the shelf, or attended Don's Arduino Cult Induction but never put the board to actual use, or you don't have any board but want to get started, this workshop is for you. On the other hand, if you have used Arduino for a project or two, you are probably already up to speed. This workshop is really for beginners to get started.

The workshop will be arranged in 3 sections.

In the first section, we will be wiring a RGB LED and writing very simple code to make it blink. Because the LED has 3 colors inside, you can turn more than one on at a time to simulate almost any color.

The second section will cover using the serial monitor and Serial.print, which allows you to see a record of what your program is doing.

The third section will involve reading voltages with the analog inputs. We will begin with a thumbwheel trim pot which you can easily control the voltage, and if time permits move on to a simple temperature sensor.

The $10 workshop fee includes components and wire we will be using.

All construction will be done on solderless breadboards. If you need a breadboard, they are available for $7.

You will need an Arduino compatible board and USB cable. If you have the Dorkboard and Benito from Don's Arduino Cult Induction, those will work. A genuine Arduino board will work too. If you don't already have a board, the Teensy ($21) and a USB cable ($5) are recommended.

A "full kit" including the workshop fee, is $40. If you have no parts at all, that is your best option!

You will also need to bring a laptop computer and wire strippers. Windows XP & Vista, Mac OS 10.5 and Ubuntu 9.04 are supported. We will be using 22 gauge wire.

If you've been intended to start building electronic projects but haven't known where to begin, or you've purchased an Arduino compatible board or finished Don's Arduino Cult Induction but then it sat and never got used, or you loaded up Arduino and stared at a blank window and asked "now what do I do?", I hope you'll come to the workshop on Monday and get started with microcontrollers!

-Paul

Fancy Oscilloscope

paul — Tue, 29 Sep 2009 12:22:07 -0500

Last night Monty brought a Tektronix MSO2024 oscilloscope to the meeting. I've been very seriously considering buying one of these, or something similar (this model is $5400 new, about double my budget, though some lesser models are around $3200). Read on for a lengthy writeup of how it went....

First of all, I want to emphasize this scope and instruments like it are not designed for novice users. It can do a lot of really amazing things, which might seem like the solutions to all electronics problems. Tek's marketing people would certainly like you to believe that.

In reality, just using the scope requires quite a lot of knowledge and experience. Often times it can be a mini problem solving exercise to go from "why isn't it showing what I want?" to answers like "oh yeah, it's still in that triggering mode". Using it requires methodology of knowing what your waveform should look like to adjust the scope's MANY options, and usually only then can you start to do meaningful things.

There are lots very helpful on-screen displays and menus. Most use brief terms and symbols that are very meaningful to anyone with some experience with oscilloscopes. Monty was pretty familiar with the menus and worked them often, but several times I did too and after about 10 minutes using the scope I was pretty comfortable with what most things did. There were a couple minor misunderstandings on my part within those first minutes, like trying to use the largest knob to change the time base (it's actually a pan and zoom), but in minutes I was able to use it pretty well. Then again, I've been using oscilloscopes (mostly analog ones) for about 20 years.

One important feature, which pretty much all good digital scopes have these days, is a USB port where you can plug in a USB flash drive and get data capture. For example, you can easily capture the screen to a PNG file. Here's the first one we tried.

This picture really shows the long record length (buffer), which to me is probably the most important feature. Two channels are in use, and each is shown twice. The small region on the top is the entire time that's been captured by the scope into its buffer, which is many milliseconds. The larger bottom panel is showing 20 us, where the tiny gray rectangle in the top panel represents the portion of the buffer displayed large bottom panel.

In this view, the yellow is an analog signal. I had a Teensy running code which would charge a 100 uF capacitor for 10 ms (by setting a pin to output mode and driving it high), then let it discharge with a 10k resistor which was in parallel with the cap (by turning the pin back to input mode). On the top panel, you can see the last bit of the charging and some of the slow decline in voltage. The scope was set to trigger at about 4 volts, near the top of the charged voltage.

Right after charging the cap, the code would send a message via the UART, which is the blue trace. The long record length lets you grab a pretty substantial period of time and then hunt around with the pan and zoom knob to find and investigate interesting things.

This scope had the optional (and $700 extra) computer analysis software installed. Monty spent a while fiddling with the menus to get it turned on. Like so many fancy features, it requires quite a bit of fiddling and manipulating menus. For quite a while it was showing wrong information... and I even looked up ascii codes and wrote out bit patterns on a scrap of paper to figure out how its interpretation of the bits might correspond to what they were should be (I'm pretty sure my code works and outputs correct data!) After some guesswork, it ultimately turned out the scope was interpreting in the opposite polarity, which would have been correct for a RS-232 voltage, but this was a TTL-level signal right on the processor's pin. Monty inverted that channel, as you can see if you compare the screen above to this one, and suddenly the correct bytes appeared!

Here it is zoomed out a little more, so you can see the whole message.

And here is the code that was doing all this. The last line sends that message. The code above it charges the capacitor (pin 8) and blinks the LED (pin 6).

(edited)

Originally I wrote a rant here about the slow, sluggish user interface on this scope. On reflecting a bit, I decided to edit this bit of negativity out... of course, if you really want to see the original (especially if you're a product manager at Tek with any influence over future scope specs), just email me at paul at pjrc dot com and I'll send you the original.

The short story is, while I really love everything this scope can do, the slowness in the user interface would result in my using it only when I absolutely had to. I'm just not ready to blow $5k or $3k (without the digitial channels and only 100 MHz BW) for something I wouldn't actually want to use unless I had no other choice.

Teensy as a Benito

paul — Tue, 09 Jun 2009 19:35:52 -0500

I released a new version of Teensyduino today, which adds USB-serial extensions to the Arduino Serial object. Now it's possible to use the Teensy via the Arduino IDE for in sorts of new ways.

For example, the Teensy can be programmed to work as a Benito.

Here is the simple sketch that makes it work.....

#define RESET_PIN 4
unsigned long baud = 19200;
HardwareSerial Uart = HardwareSerial();

void setup()
{
        digitalWrite(RESET_PIN, HIGH);
        pinMode(RESET_PIN, OUTPUT);
        Serial.begin(baud);   // USB, communication to PC or Mac
        Uart.begin(baud);  // UART, communication to Dorkboard
}

void loop()
{
        unsigned char c, dtr;
        static unsigned char prev_dtr = 0;

        if (Serial.baud() != baud) {
                baud = Serial.baud();
                Uart.begin(baud);
        }
        if (Serial.available()) {
                c = Serial.read();
                Uart.write(c);
        }
        if (Uart.available()) {
                c = Uart.read();
                Serial.write(c);
        }
        dtr = Serial.dtr();
        if (dtr && !prev_dtr) {
                digitalWrite(RESET_PIN, LOW);
                delay(1);
                digitalWrite(RESET_PIN, HIGH);
        }
        prev_dtr = dtr;
}

It's also possible to use this on a real Benito board. Here is a link to the HEX file, which can be loaded onto a Benito using the "DFU Loader".

http://www.pjrc.com/teensy/Teensy_Benito.hex

Teensy++ Released

paul — Thu, 12 Mar 2009 10:35:38 -0500

The new teensy board was released a couple days ago. Here's a picture. The actual size is the same as a DIP-40 chip.

Teensyduino 0.2 Released

paul — Tue, 13 Jan 2009 12:07:52 -0600

Today I released the 2nd beta version of Teensyduino, my add-on package for Arduino-0012 that allows sketches to be built and run on the Teensy USB board. Version 0.2 fixes many bugs and has more robust coordination between the Arduino IDE and the Teensy Loader.

The main different between the Teensy and a regular Arduino (or the main Arduino clones) is the Teensy has direct full speed USB (12 Mbit/sec) instead of a slow serial port converted to USB by another chip. Teensy can be programmed to act as almost any kind of USB device (including keyboard, mouse, joystick, generic HID, etc), whereas a serial-to-USB board can only ever act as a serial-type USB device.

So far, Teensyduino only adds a serial type device. The Arduino IDE is built with a lot of serial assumption throughout its code. In time I intend to add non-serial options to Teensyduino, though making them work in the same simple way with Arduino-0012 is a massive project. 0.2 is a step in that direction, with major improvements in stability of the code.

Teensyduino

paul — Thu, 01 Jan 2009 19:24:47 -0600

It turned out to be a lot more work than I expected, but finally I've released the first beta test of Teensyduino, an add-on package for Arduino-0012 that adds support for the Teensy! I even wrote a nice gui-based installer (works on Mac, Linux and Windows).

Teensy USB released

paul — Thu, 04 Dec 2008 19:23:39 -0600

The Teensy USB Development Board is finally released! I'm still writing more web pages and working on easier example code, but everything really necessary is available.

If you want to get it at the next meeting, just place an order with the website and in the comment box on step 3, just type something like "bring to dorkbot meeting", and of course you won't get charged any shipping.

Here are a couple pictures.

LCD - almost working

paul — Wed, 24 Sep 2008 14:32:04 -0500

I'm getting close to making the LCDs work from Ben's Micro 2700 POS terminals (several of them are still up for grabs). Here's a photo.

More photos and technical details below...

First, I cut out almost all the chips. Here's a photos taken before I chopped all the chips off.

Really only 3 chips in the upper left corner are needed, the MSM6255 controller chip, the 32k RAM chip, and a 74HCT245 tri-state buffer. (those other 2 chips I left in place are buffers and transistors which seem to do startup stuff like reset pules and switching the RAM chip from battery backup to main power).

The MSM6255 has two buses, both 8 bit data, 16 bit addresses. One bus is for the Z80 microcontroller, and the other is a dedicated bus for the frame buffer RAM chip. The LCD controller only has 9 configuration registers, and a single instruction register. It only listens on 1 of the 16 address lines, which select between the instruction register or the 9 config registers. To write to the chip, you write to instruction register with A0=1, with the number of the config register you want. Then you write again with A0=0 to configure. Repeat this process 9 times to configure everything. However, a few of the registers only matter in character mode, and this board is wired only for graphical mode.

Since there are no other chips on the Z80 bus, I just wired the LCD controller chip select low (fount at U20, pin 10), and then it only takes 1 write select signal (found at U13, pin 11) to strobe the data in. Of course, A0 and the 8 data lines have to correct before pulsing the write pin low.

To access the frame buffer, the is a 74HCT245 tri-state buffer which causes the Z80 data lines to drive the frame buffer data lines. The LCD controller also has an address mux controlled by the DIEN signal. Both of these fortunately are high for the controller to access the frame buffer and low when the Z80 bus drives the RAM. So I just shorted them together (found at U19, pin 2 and 11). The RAM has its read signal low all the time. All I had to do was short the RAM CS signal low (found at U20, pin 6) to allow it to work.

The RAM write signal takes priority over read, so when you want to write new data into the frame buffer, all that's necessary is to drive DIEN and the '245 enable low to connect the Z80 bus to the frame buffer RAM (of course, set up the desired address and data first), and then pulse the RAM write signal low.

The frame buffer can be written at any time this way, but if this also happens to be at a moment when the LCD controller is reading, the screen will momentarily display whatever was on the frame buffer RAM data lines being driven by the 74HCT245 buffer. It appears this is the way the Micros 2700 worked.

The datasheet gives two suggestions for detecting times when the LCD controller isn't reading the data lines, and one of them isn't practical for large displays like this one. The other basically involves watching the CH0 signal from the controller and doing the framebuffer access right after it changes. I could not find the CH0 signal routed anywhere on the board, so I'm pretty sure Micros just didn't use it (they certainly didn't build the complex flip-flop sync circuit suggested in the MSM6255 datasheet). Maybe when I've got everything figured out I'll wire CH0 to a port pin and write a bit of code that waits for it to change right before I do the framebuffer write. It looks like CH0 is about a 560 kHz square wave, so that's plenty of time for a tight loop in the 18.432 MHz AVR to detect and complete the access. But for now, I'm not worrying about CH0.

So, here's my little circuit.

On the top are three 74HC164 shift register chips. These are connected to the MOSI and SCLK signals, so whatever the last 3 bytes were on the SPI port, they end up driving the Z80 address and data bus. The board has two headers that plug into the socket for the RAM chip that was dedicated to the Z80, so power, ground and all the address and data lines are connected there. That just leave the 2 write strobes for the LCD controller and frame buffer RAM, and the enable signal to drive the frame buffer bus. Only 3 extra signals! Well, maybe a 4th when/if I connect CH0 to avoid flicker.

The 28 pin chip is a ATMEGA88 - the same chip as the Aurdino, but only 8k of program memory. The chip on the left is a MAX232, and the white 3 pin connector is for a serial port that is intended to (someday) allow images to be downloaded easily. The little 8 pin chip on the right right is a 128K flash rom with SPI interface (Atmel AT45D011), which can hold 8 full-screem images, when I get all the pixels under control!

But not everything is working perfectly... yet. Here's what I get so far, trying to fill the entire frame buffer with 0x0F.

Those vertical bars are the desired pixels. They do change to other patters if I fill the frame buffer with other bytes. So at least I'm controlling some pixels.

Clearly, I haven't got the correct configuration for the LCD controller yet. The controller is designed to drive 2 sets of shift registers on the LCD, with 1, 2 or 4 bits per. This LCD seems to have only 1 shifter register with 4 bits, so I'm not entirely sure if I should use 2 or 4 bit mode, and exactly what the duty cycle setting should be isn't clear either. I've tried many different settings (mostly randomly), and so far none have been perfect.

I'll probably do one more session with the ohm meter to figure out more about how the LCD interfaces to the controller, and details about the frame buffer bus (which so far I've assumed is wired like the datasheet describes, but really all my probing has been on the Z80 bus and the many control signals).

Here are my latest notes/scribbles about how to connect the various signals.

I should also mention the stuff I learned about the power supply.

First, the simple part, the backlight. It's a cold cathode florescent lamp, and there is a module inside the main power supply. It's attached to the high voltage board deep inside, and so far I've just left it alone. I did stick my meter probe in there (past all the live 120 volt stuff in the way), and it looks like that module takes 24 volts DC input. Not at nice as 5 volts, but still not too bad. It looks like it can be easily separated and liberated from the big hulking power supply. The one sad bit is there is only 1 in there, with a Y cable to drive both LCDs.... so if everyone wants one of these LCDs for a project, half of them will need to acquire or build a CCFL driver.

The not-as-simple part (but still a lot simpler than the LCD config and frame buffer bus) is the LCD drive voltage. The LCD runs on 5 volts for its logic, and a negative voltage, up to -19 volts. The parts on the far right side of the board are a little switching power supply that converts +5 into a variable negative voltage.

At first I thought the little blue trim pot was the answer, but I kept getting very random results, especially if I touched the board. It turns out the chip in the lower right corner is a X9C103 digitally controlled pot, which adjusts the LCD drive voltage (which is what controls the contrast). I thought about hooking it up to the microcontroller, but in the interest of getting this thing to work, I simply clipped it off the board and wiring in a connection 10K pot, which you can see in the photo. However, the digital control pot is there on the board, so when/if anyone else uses all this, it's possible to control it from software. The X9C103 contains EEPROM memory to store the pot setting. I must have changed mine hundreds of times while touching the floating inputs with my fingers and wondering what I was doing that changed the LCD so much!

I had hoped to get this thing working before the next Dorkbot meeting, but it looks like I might have to put this whole thing on the shelf for a couple weeks (to make room for a paying project - which funds all this fun stuff....) I'm pretty sure I'll get the LCD config and frame buffer issues worked out, and when I do it's my hope everyone in Portland Dorkbot who wants one of these displays can have one!