9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Steven Stallion <sstallion@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] small VFD display
Date: Wed,  6 May 2015 09:13:05 -0500	[thread overview]
Message-ID: <CAGGHmKGmxLR14EUy29sxjRW=Jw2pmu4+=hHNmN1-2S9tfT7v+A@mail.gmail.com> (raw)
In-Reply-To: <304bae18668f389aae7eccd289462cda@quintile.net>

[-- Attachment #1: Type: text/plain, Size: 1884 bytes --]

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
>
>

[-- Attachment #2: Type: text/html, Size: 2433 bytes --]

  parent reply	other threads:[~2015-05-06 14:13 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-06  9:52 Steve Simon
2015-05-06 13:30 ` yy
2015-05-06 14:31   ` Steve Simon
2015-05-06 14:13 ` Steven Stallion [this message]
2015-06-09  4:56 ` Ethan Grammatikidis
2015-06-09 10:10   ` lucio
2015-06-09 18:03     ` Robert Raschke
2015-06-09 18:34     ` Ethan Grammatikidis
2015-06-10  4:43       ` lucio
2015-06-10  4:43       ` lucio
2015-06-10 15:58       ` Giacomo Tesio

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGGHmKGmxLR14EUy29sxjRW=Jw2pmu4+=hHNmN1-2S9tfT7v+A@mail.gmail.com' \
    --to=sstallion@gmail.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).