osresearch / vst

Software for the v.st vector boards

v.st vector board

This is the firmware and example code for the opensource harwdare quad-DAC vector board. It can be used with MAME to display the vectors from 1970s and 80s games like Starwars or Asteroids on vectorscopes and XY monitors like the Vectrex, as well as with new art projects.

More details at https://trmm.net/V.st and https://trmm.net/MAME

Flashing the Firmware

To flash the firmware, make sure you have Teensyduino installed.

Clone this repository and load teensyv/teensyv.ino in the Arduino IDE. Next select Teensy 3.1 / 3.2 from the Tools -> Board menu in the Arduino IDE. Hit verify and follow the on screen instructions to flash your Teensy with the firmware.

Running the Demos

Make sure you have Processing installed and your Teensy is flashed with the firmware.

Open processingDemo/processingDemo.pde in Processing. As soon as you hit run and your v.st board is attached to the computer, the demo starts playing on your screen and should be visible on the device attached to your v.st.

vst's Issues

Shape and path processing library

Add a Shape and Path class to the vector library for manipulating more complex paths with a matrix-transform option prior to display.

Use Processing video backend

It looks like it might be possible to extend the Processing 2d graphics class to get the lines, etc directly from the internals, rather than requiring the user to call our line, circle, elipse, etc functions. For example, the PDF backend does: https://github.com/processing/processing/blob/master/java/libraries/pdf/src/processing/pdf/PGraphicsPDF.java#L49

public class PGraphicsPDF extends PGraphicsJava2D {
...
}

SVG Demo

Would be cool if the SVG Demo could be added like all the other demos to the Demo list. Since the SVG functionality is called svgtest I was not sure if it is ready yet, otherwise I would have made a PR.
Let me know what you think and I will provide a PR.

VstBuffer should track segments

The VstBuffer class should track segments, rather than individual points. This might make the sort algorithm simpler and maps well to the line() override.

Output on DACs seems to be stuck?

Hello!

Hopefully this finds you well.

I have wired up the current version of the v.st board from the OSHpark link with all of the prescribed components.

I am using a teensy 3.2, which I got to successfully compile by using the TimeLib.h instead of Time.h.

No matter what I do, I cannot seem to get any sane output from the DACs. Input voltages (12v, -12v, 5v) are all within range. I am getting data out of the teensy as verified on a oscilloscope.

Anywhere I should start?

Thank you!

Kits

Hey,
I saw the talk on 32C3 and was wondering if there are kits available? I just need this to put my oscilloscope to some good use :-)

On OSH the minimum quantity for the board is 3 pieces - which is too much for my personal use.

On the other hand I would be willing to order a medium run (30 pieces) on OSH, including the rest of the BOM and bundle them into kits - if I am allowed to and you are not planning on doing kits.

Price for the board would be: ~ 7€ / 7.5$
Price for the components, excluding Teensy: ~ 25€ / 27$
Totaling in at ~ 32€ / 34.5$ excluding the teensy.

Let me know what you think, also let me know if there is general interest in such a kit / group order.

Clipping includes one too many pixels

Clipping goes from 0 to width and 0 to height, not 0 to width-1 and height-1. This caused some lines to not be drawn on the vector display.

Processing library should sort vectors

The processing library doesn't sort the vectors, so it becomes slow on a vectrex.

use Processing transformation matrix

Let the user call translate() and rotate() in Processing to adjust the position and orientation of the vectors.

Character generator

Add a command to the serial protocol to draw characters from the built in font.

Curves or circles

The command set could be extended to add curves or circles.

Teensy 3.2 SS chip select problem

Hi,
I tried to get it running on a Teensy3.2 wich has as I understand a slightly different port setup on the SPI Ports? (according to https://www.pjrc.com/teensy/teensy31.html)

The sketch compiles and uploads, I have a correct CS/SS signal on Pin 6, on PIN 10 however is NOTHING. My DACs working just fine, If I connect the second to PIN6 I have the same analog out on both.

I tried changing this part but no joy.
// configure the output on pin 10 for !SS0 from the SPI hardware
// and pin 6 for !SS1.
CORE_PIN6_CONFIG = PORT_PCR_DSE | PORT_PCR_MUX(2);
CORE_PIN10_CONFIG = PORT_PCR_DSE | PORT_PCR_MUX(2);

Help!

teensyv doesn't compile with arduino 1.6.7

Time.h and dwell errors

Arbitrary brightness command

For systems that have analog brightness (Vectrex), there should be a command to request that the next path be drawn with a custom brightness.

Processing library output can be delayed

The processing library doesn't check the serial port status, so it is possible for it to become very behind on rendering complex scenes. I've seen the spiral demo play through as much as a few seconds of buffered vectors as the OS's serial queues are drained.

Clipping is created after serial port

clip is created after serial port early return, so it will cause null pointer exception if a valid serial port is found.

Options Setting Brightness

I think we should consider how brightness is handled in the Vst methods. The current approach is handles brightness by passing a boolean as the first parameter, as demonstrated in the following signatures:

// class Vst
void line(boolean bright, float x0, float y0, float x1, float y1)
void line(boolean bright, PVector p0, PVector p1)
void rect(boolean bright, float x, float y, float w, float h)
void point(int bright, PVector v)

Here is a list of potential options (more suggestions welcome):

• 1. Keep the methods as they are.
• 2. Re-arrange the order of parameters, placing brightness as the end, and then when no 5th parameter, it defaults to normal brightness. For example:

// class Vst
void line(PVector p0, PVector p1)  // Normal brightness
void line(PVector p0, PVector p1, true)  // Bright
void line(PVector p0, PVector p1, false)  // Bright

• 3. Map the stroke() value.
  • While this works, the mapping of 256 points to 3 (off, normal, bright), seems off.
  • Need to account for overall brightness, since stroke is a combination of RGBA.
  • Need to account for colorMode() as well. It's possible to change the range from 0-255 to some other arbitrary range.
  • If there are plans to up the resolution of the z-index, then stroke() makes much more sense.
  • Here's how it would look:

stroke(128);
vst.line(p0, p1);  // Normal
pushStyle();
stroke(255);
vst.line(p2, p3);  // Bright
popStyle();
vst.line(p4, p5);  // Normal

• 4. Create a new function that works like stroke(), but specifically for brightness.
  • Could respond to pushStyle() and popStyle().
  • This
  • Possibilities:

// class Vst
void bright(float b)  // 0 - 255
void bright(int b)  // 0 - 3

• 5. A combination of the above. Though the trick here is trying not to over complicate it by trying to account for possible use.

Personally, I think I'm in favor of 2 and 4. Thoughts?

Can't tell whether I'm outputting with the correct protocol

My intention is to run a simple Node server, and use it to send serial output coming from another application to the v.st board:
https://github.com/duncanmalashock/vsttest (refer to test.js)

My issue is that I can't get test output on the screen of my scope. My steps:

1. Connect USB to the v.st board, see the v.st test pattern on the scope
2. Run the server with node test.js /dev/tty.usbmodem2752111
3. I expect to see a diagonal line from the bottom-left to top-right corner of the screen, but my scope screen goes blank, and my terminal shows:

-1090519040
-1073741825
Port open

It appears data is being sent, but it's not in the correct format.

My immediate problem would be solved if I could fix the error in my code. This is mainly what I'm asking for help with.

But an additional concern is that there's no response back through the serial port from the v.st to tell me what I did wrong. A nice long-term solution could be a debug mode of some kind, with helpful error messages.

3D shapes in processing

Add support for generating 3D wireframes in processing. This can't use the p3d calls since we need vectors before they go to the OpenGL renderer.

No resistor values for R16, R17, R20

The pcb/teensyv.brd file doesn't have resistor values for R16, R17, R20 that I can see. If someone can give me a hint on what they should be (10k?), I can try a PR for an updated board file, and probably add digikey part numbers for easier ordering.

Vector sorting in processing can have wrong brightness

Segments with mixed brightness can be sorted wrong.