I spotted this Noritake page selling VFD kits. The K612A4 variants run directly off 12v, uses std RS232 signals, and does keypad scanning.

Am I wrong in thinkng this, with the addition of a few buttons, could be hooked directly to an empeg for a remote display?

would probably need a little bit of programming, but nothing hard. Might have to look at getting 1 of these as where my empeg is in my car I can't see it that easily. Would need some buttons as well.

Could you clarify "a little programming"? Is this something that would happen in Hijack? Like we all pick one as a standard? If programming is required would it be just as easy to pick a larger display and modify the output? I await details on the edge of my seat...

There's several model lines; Most of them have different command sets, shapes, sizes, speeds, etc. I have software to drive my 9300-series, Mike (foxtrot_xray) sent me a k610a to port it to but the board fried due to a polarity misunderstanding and he hasn't sent a replacement, at the same time I was going to port the 7000-series, which is almost the same command set as the 9300. So I haven't worked on the 7000 even though I guess I could, I wanted to cover all the displays (at the time, this one is new) at the same time.

Basic drawing is pretty easy, it's optimizing it to fit down the speed of serial that's an issue for several models. 38400 won't even do 10fps just blasting out raw frames. I've done a fair bit of work optimizing for the 9300 that could be mostly reused.

Then there's other issues I haven't really looked into like getting the player app to not hog the CPU and stop drawing onto your screen or listening for key input. There might not be much we can do about drawing because it takes actual CPU time, but the key input should be able to run with high priority because all it has to do is check for a byte on the serial line every few dozen ms.

My input is a Grayhill joystick that covers the 7 standard Empeg face functions (the stick also twists and pushes in), and 6 other buttons that can be assigned to whatever keycodes.. A BasicStamp takes the output of all them and sends serial commands, 'D' for down button down, 'd' for down button up, etc, then an app on the Empeg receives them and injects keys into hijack.

Clue me in here.

Your software provides the full display emulation? If there is enough bandwidth?
Sweet.

I didn't see any Noritake modules that provide key scanning and Baudrates above 38k .

Where full means 1-bit instead of 2 (pixels are either on or off, no 2 grays in between), and lower framerate, yes. The 3900 (I meant 3900 before, not 9300...)s have something like 10 I/O pins you can use for whatever, but I run my own input with the BasicStamp, the VFD isn't involved at all in it.

Here's a video from early in development, just doing raw bitmap drawing at this point I think (and laggy, and pixel-doubling doesn't help, my VFD is 256x64 @ 38.4k to allow 4 empeg-sized screens of stuff). And some images of the construction and final setup. The thing that looks like the cigarette lighter is the joystick you see in the vid with the head of the cigarette lighter mounted on.

your version takes the png that hijack creates and replicates the display right?

Using the version that was originally posted here has its own serial interface already so putting your own code on the vfd side of things would probably prove difficult.

You'd have to run something on the empeg to send the data in the format the vd requires. This would involve sending more data than just sending the png.

Um yeah, I think he knows that... He's way ahead of ya...

"Raw bitmap" means sending the little header that the VFD requires and then sending all vfd_width by vfd_height bits of data to the display, rewriting the entire screen every frame. The source of the data could be hijack's png (which would require decoding PNG, and be a waste of time), or the raw version, or reading /dev/display. No matter how you do it you still need to process the data, it's 2-bit (or 4, really) and needs to be converted to 1-bit. Then it's row-wise, and most of the VFDs expect pixels column-wise, just to be annoying, so you have to write it out 'sideways'.

But the amount of data that can be sent down the serial is limited, and much of the screen stays the same most of the time (except for some visual modes), so drawing the entire frame every frame is a big waste of bandwidth when you could just say "change this pixel to off, and this one to on, draw a line here, draw a bitmap there" etc. The clever bit is trying to do it quickly (which usually, but not always, means with the fewest bytes sent to the VFD), but you film it, and then play it back.. backwards.

To perhaps clarify, the VFD I'm using, and all the other ones (k610a, 7000-series, 3900-series), are essentially the same as this one (k612a). They have different resolutions, physical sizes, brightness, command sets, serial speeds, etc, but they're all serial-driven graphic displays and all support drawing pixels, lines bitmaps, etc. The display is sent commands by software on the empeg and does what they say, it's not asking Hijack for an image, decoding it, and showing it autonomously (although you could probably sort of do that with the 3900s in theory, lots of macro support).

Basically I have a general API of drawing functions, and an implementation of it for my 3900 (and almost the 7000, since the command set is nearly the same). A quick-n-dirty port to another display is just implementing the drawing functions for that display and linking them in instead of the 3900's. Then you go back and figure out why it doesn't work, and then you go back again and find different ways to speed things up with the different features each display supports (for example.. some can draw in XOR mode so you can just send the changed pixels and say "toggle 'em all", others can't so you have to specifically set each changed pixel on or off).

And to clarify slightly further, don't panic, the circuit board full of stuff in the pictures is just a switching power supply (that powers the controller and VFD) and a bunch of junk required to take the joystick/button input and send out character codes down the serial line to the Empeg. The VFD itself just takes power from it and passes the receive line through to the Empeg's transmit. You could possibly get away with no real power supply since this model is 12V instead of 5, but it has to tolerate the noisy and variable 14V output of a car. Or you could use a simpler/less efficient regulator that just burns the voltage off as heat.