Thinking out loud:

Most VFD's that I've dealt with were largely text displays - normally you'd
see an 8051 or similar driving a mess of shift registers. Essentially, one
would jam an ascii byte over GPIO and toggle a latch to update the display.
I'm assuming it will be somewhat similar for this display, even though it
supports bitmaps.

With that in mind, I'd be tempted to write this completely in userspace,
likely as an fs that overlays /dev/draw. It might be more hassle than it's
worth, but it would be rather fun to run the fs and fire up games/catclock
as a PoC.

Cheers,

Steve

On Wed, May 6, 2015 at 4:52 AM, Steve Simon <steve@quintile.net> wrote:

> Hi,
>
> I want to drive a small (180x32 pixel) VFD display from plan9.
> It talks i2c and can be driven as a text or graphics device.
> One irritation is it aligns bitmap bytes verticaly. i.e. the display's
> memory map appears to be a tradational 32x180 pixel display.
>
> I am going to talk to this from a raspberry pi.
>
> I see several options:
>
>         resurect a small graphics library I wrote in the last milenimum,
> this
>         knows about the weird layout but only supports rather nasty fonts
> and
>         very simple windowing.
>
>         talk text only to the display - again rather nasty fonts.
>
>         draw the images in a plan9 window under rio. A seperate process
>         which reads /dev/wsys/n/window, transforms it and sends it to the
> VFD.
>         I would also need a backing buffer in VFD layout so only the
> changed
>         bytes are sent.
>
> Is there another way?
>
> Could I run the plan9 graphics subsystem in a stand alone app rather
> than involving the kernel?
> I think I can but are there any examples of this?
> Though this sounds nice, is it worth the hassle of doing this?
>
> Any opinions?
>
> -Steve
>
>