A VGA or FBAS video interface for your Lego-NXT, Parallax Propeller based.


  • DeLuxe (all inclusive) and stripped-down versions available (latter will follow soon...)
  • Simultaneous VGA or FBAS (PAL/NTSC) color output
  • Supports graphics and text display
  • Accepts input from USB (PC), RS232, RS485, I2C and SPI)
  • 64kB serial RAM (data collection)
  • some more...

Another consecutive side project of 93 others...
For debugging purposes of the laser scanner and the Sharp turret, I was in need to view the sensor outputs in real-time. Bluetooth is to slow and requires a lot of PC coding and standard LCD displays are non-readable from farther distances. I therefore decided to mount a little VGA/FBAS monitor on top of some robots.
Here's the hardware part...

I had some gift coupons left from a PCB manufacturer, hence the DeLuxe variant is full featured. The stripped down version should be reproducible by everybody. It could even be breadboarded...

If you are already familiar with Parallax Propeller, this little piece of hardware will be no big deal for you. Legisplays VGA and video port, as well as the FTDI interface are compatible to the Propeller Demo Board, hence you can choose from a wide variety of ready to use software in the OBEX (Propeller Object Echange).

The OBEX, as well as the activities in the Parallax Forum offer an incredible amount of software, ideas and nice people.

Legisplays extensions include a multi serial interface which can be attached to

  • I2C
  • RS-232 (CMOS/TTL level)
  • RS-485
  • SPI
  • (USB, PC)
an optical encoder with switch (although a stupid engineer forgot to attach it to the port pins...), and two serial 32kB RAM memory chips (23K256).

Depending on the software, Legisplay can not only act as a display. It could:

  • monitor sensors autarkic
  • interface additional sensors
  • simulate sensors
  • provide more memory
  • and a whole lot more; you decide...

The Propeller CPU (or should one say CPUs? ;-) offers wide, but also very specific (aka.: limited) resolutions or graphic capabilities. In fact all limitations are caused by the limited amount of on chip RAM (32kB HUB RAM). While it supports high horizontal and vertical deflections (up to 1600x1200 have been sighted), the chip does not have enough memory to control every single pixel (even monochrome, 1600x1200 would require at least 240kB).

If you expect full featured, true-color, fast-paced display action I have to disappoint you.
This is not possible with a Propeller chip and our NXT style of communication, and most notably, I did not intend to do something like this. It's just a little helper (but can provide hours and hours of Asteroids fun ;)
Use Google or YouTube to obtain an overview of the Propeller's graphics features... (or look below...)

A detailed description of the Propellers video capabilities is beyond the scope of this page.
Just to name a few:

  • 512 x 384 graphics pixel display with monochrome foreground but tiled (32x32), colored background
  • 128 x 64 chars (1024x768) 4 color foreground/background text display and cursor/mouse
  • diverse tiled (sprites) other resolutions
  • diverse PAL/NTSC text terminals or graphic displays


What is the preferred interface?
Simple, there isn't one... Each application may require a different one.

At a glance, the half-duplex RS-485 interface of the NXT seems to offer the best throughput, if one only takes its speed, up to ~1Mbit/s, into account. Well, that's not the complete story...
It's perfect for unidirectional text or single sensor (1 byte) outputs. But if you want to mix graphics and text or read back some data, it will get much more complicated.
Imagine what happens if you send multiple byte-packets, representing different sensor values, but one byte gets lost...
Your measurements (or whatever) will end up in a complete mixup...
A bidirectional transmission requires a sophisticated time and packet handling. Timeouts, tokens or packets that never got send (or were missing some bits) need extra treatment.
I already programmed a packet mode driver for the Propeller and pbLua (the good, old and well known DLE/STX/ETX type ;), feel free to download it as one of the examples I provide for Legisplays usage.

What about I2C?
While the master/host I2C algorithm is pretty straightforward, and already implemented in every operating system for the NXT, the handling of the slave/device can be really challenging. At least, if you want to handle every single, possible error:
Missing or repetitive start or stop conditions, timeouts due to missing clocks, short circuit conditions due to lost direction switching, and, and, and...
While this is not quite rocket science, it is time consuming.
If you once managed to get it done, you will be requited with an addressable, safe and medium to slow (still not full duplex) speed interface.
Your hardware can make use of multiple bus addresses: One for text, one for graphics, system messages or answers...

And the rest?
It indeed would be possible to program a polling-type full duplex UART state machine on the NXT. Unfortunately none of the available "operating systems" for the NXT support this (for some good reasons ;-)
As a feasibility study, I wrote a few routines for pbLua and Robug-C but all of these ate up far too much memory.

The last resort: SPI (see pbRAM)
Because none of the ready to use NXT systems provide one, you can invent whatever you like ;)
I usually use 9 bit transmissions (b8 for commands) but any arbitrary number of bits could be used.
You may download a variant of these below too...

So I can only use it with pbLua?
No. Of course, Legisplay obviously benefits from using it in conjunction with the best OS for NXTs (did I hear "ad"? 8-), but at least I2C and RS-485 should be usable on (almost) every other system too...
Just for the sake of it, I already created a NXT-G Labview block. But, this still needs some testing. Additionally, I am not a fan of Labview and I do not have access to it all the time...

Hardware, DeLuxe Edition

On to the hardware...

DeLuxe version; Click to enlarge...

  • IC1, EEPROM should be a 24LC256
  • IC1 is a SO8 wide type (bend pins under case if SO8)
  • A %&!$&$! script replaced all 1206 resistor reflow pads by wave types.
    Take care of short circuits (ground plane) or stick to 0204 (MiniMelf).
  • Do not use the RS-485 termination in conjunction with your NXT!
    This is for a different hardware.

At a glance, the schematic might look somehow complicated. It isn't, and not every component needs to be fitted.
A standard USB to RS-232 "converter" (FTDI) on the upper left, including a reset mechanism for the Propeller chip, which is attached to the DTR line. This is exactly the same circuit as provided on the Propeller demo board.

The same applies to the VGA and video output circuitry. No surprises here...
JP2 provides attachment of other components to the the "main-EEPROM-I2C-bus", including power supply. Some free pins on JP5 and JP4.

Power supply is taken from USB or NXT. Of course you can attach both at the same time, it will not harm your hardware.
The encoder on P4 and P5 is decoupled with <20k resistors. Using the pins as outputs for other stuff is no problem. If you want to hook up external inputs there, make sure your output impedance can handle the 1k/4n7/18k combination. This is not the right place to attach high impedance stuff...
For whatever reason I forgot to connect the switch of the encoder with P6. I guess you know how to catch up on this...

The two 23k256 share P11 for their SO outputs and P7 as a clock input. This saves two pins and you still have the ability of storing memory very fast (synchronously).
Both chip select lines CS1 and CS2, can be jumpered to P8 and P10 on demand.
If you don't want to use the encoder or the serial RAM, JP4 provides 8 port pins and a 3V3 power supply.

JP1 has 2x82k pullups for I2C (due to the NXT internal circuit, the resistance can not be chosen much lower) if it is jumpered to position 1-2.
Setting JP1 to 2-3 will enable the TX (NXT -> Legisplay) line of the ADM485, a RS-485 driver. The 2x82k remain between the "A" and "B" line to pull the RS-485 lines to one another. Additionally an AC termination, whose values depend on your cable and other attached stuff, can be enabled by JP3 (NOT WITH NXT!).

Using the original NXT cables is not recommended for farther distances. Use a twisted pair cable instead.

The main inputs to the Propeller chip are:

  • P0 -> SCL for I2C (free choice for SPI or UART)
  • P1 -> SDA for I2C (free choice for SPI or UART)
  • P2 -> RS-485 IN (NXT -> Legisplay)
  • P3 -> RS-485 OUT (NXT -> Legisplay)
  • P15 -> direction select for RS-485 (Note *1*)
*1* Note:
If you want to use video code from the Propeller OBEX/community, keep an eye on P15! This pin will interfere with RS-485 operation. Remove its activation!

Hardware, Breadboard Edition

I you're a pure Legoist, an electronics beginner or all thumbs you would probably prefer a reduced Mini-Breadboard edition, where you decide what, where and how you build it:

Legisplay Mini Breadboard Edition; Click to enlarge...

You will need at least:

  • the Propeller chip P8X32A in a 40pin DIP case
  • a 5MHz quartz (avoid ceramic resonators for video applications)
  • a 24LC256 EEPROM; optional but strongly recommended for saving programs
  • a 3V3 power supply for the Propeller and peripherals (ideally 5V available too, e.g. ADM485)
  • a handful of passive components (see schematic)

For programming the chip you will need a serial connection to your PC. Choose one here.

The TV output requires only 4-5 components and a chinch plug. VGA operation requires a 15 pin HD DSUB plug and 8 resistors. Choose by your own...

I2C needs a maximum of 4 resistors while the RS-485 variant with the ADM485 driver requires a little more.

If you have absolutely no clue about bringing this together without a PCB, here are some hints:

use a breadboard the classic method
for cowards the keep-your-hands-off-my-stuff! way

or orderly...

Don't be afraid, just build it. As long as you keep off your 230V (or 110V for backwoodsman countries ;-) mains, nobody will get hurt 8)

RS-485 Test

Usually, I don't use RS-485 for NXT<->Legisplay connection but this time, I wanted to test how far it can be pushed.

After I finished writing a, fairly usable, packet algorithm for the Propeller, including stuff like "drawPixel", "lines", "NXTdisplayCopy", ..., I started out for the hard part:
Finding an optimum combination of baudrate, delay time and packet handling.

One of the biggest problems with RS-485 on the NXT is that you have no possibility to check whether anything was sent or not and there is no chance of determining if a transmission is already over.
The screenshots below contain the following:

  • a "clear screen" packet (left)
  • a fixed delay
  • 7 times an 8-byte packet (draw 7 "A" on screen)

Although this is not completely true, you can estimate the time for sending a byte with (1/baudrate)*11. At 57600 bits/s, sending 8 bytes takes ~1.5ms.

The digital channel, labeled "RS485/TRIG" shows the calls to (one of the) send functions. While "TRIG" is high, the pbLua application is busy with sending.

57600bits/s; 7x8 bytes burst; "zero" delay
57600bits/s; 7x8 bytes burst; 500us delay
57600bits/s; 7x8 bytes burst; 1500us delay
230000bits/s; 7x8 bytes burst; 200us delay

In the upper row, left, only 5 "A"s were sent over to Legisplay. A little delay of 500us between the calls increased the number by 1, still one missing "A". Only increasing the time >1ms threw out all the packets (lower left).

After hours of fiddling around, I finally found the best settings for a packet communication (though, this is still all unidirectional! I did not yet try to read packets back from the display...):

The maximum baudrate that can be handled by the propeller chip is 230000 bits/s, on the NXT the delay can be set to a variable minimum:

-- uWait()
-- Waits (blocks) for ~<c> us.
-- Minimum value is ~80us
-- Use this while in a nxt.DisableNXT(1) <-> nxt.DisableNXT(0) loop!
function uWait(c)
  local i
  for i=1,c do

-- RS485PacSerSendPacket()
-- Creates a packet from a string and sends it via RS485
function RS485PacSerSend(data)
  data=string.gsub (data,string.char(0x10), string.char(0x10,0x10))

This gives us a fairly stable and "fast" (...) connection. Note: For whatever reason, putting the NXT send routine "nxt.RS485SendData()" between "nxt.DisableNXT(1)" and "nxt.DisableNXT(0)", does not work. It needs some further testing...


to do...


waiting, waiting...


nice weather...

Software, Demos

Demo-02, mixed text and graphics

Screenshot of Demo-02...

Sourcecode for this (Propeller) as well as a pbLua sample application, the one from the screenshot above, can be downloaded in the (guess where) download-section...
Although Demo-02 does nothing useful, it is interactive and shows some of the features and methods of using Legisplay.

Still some explanations missing, here. Will be done on another day...
Until then, you can take a look at the source code. The documentation in the Spin files is not perfect but better than nothing...

Some Useless Pics

DeLuxe Edition; Click to enlarge...


More to come:
- sample code SPI
- sample code I2C
- Robug-C example
- NXT-G example

DOWNLOAD: Source Code Propeller
DOWNLOAD: Source Code pbLua

Legisplay DeLuxe
- schematic (PDF)
- placement (PDF)
- layout, eagle (BRD)
DOWNLOAD: legisplay_v1.zip

Legisplay Mini Breadboard Edition
- schematic (PDF)
DOWNLOAD: legisplay_mini_v1.zip

ASkr 9/2009
ASkr 10/2009