osresearch / vst

Software for the v.st vector boards
GNU General Public License v2.0
79 stars 15 forks source link

Output on DACs seems to be stuck? #25

Open drumguy560 opened 4 years ago

drumguy560 commented 4 years ago

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!

ethanjamesauto commented 4 years ago

I would try the circuit out on a breadboard like this: https://www.flickr.com/photos/osr/22676279872/in/photostream/lightbox/. It shouldn't be too difficult to get this working, and it's all you need to use the vst with an oscilloscope. If you've already soldered down the DACs, try making sure that all of the traces lead the same way as the breadboard layout. I haven't actually build the full vst with the PCB, but I hope this helps.

drumguy560 commented 4 years ago

Thanks for the reply!

I ended up getting the DACs to work by shorting pin 9 to pin 1 on both DACs

I now get an image on the display when connected directly to the DAC outputs. As expected it is limited in size due to only swinging from 0-5v, instead of -10v-10v.

The monitor I am using is an electrohome g05 out of an old atari asteroids cabinet. Supposedly when fed with -10 and 10v on the x, and -7.5 and 7.5 on the Y, it will work. However, when i got through the outputs from the op amps, the display does not act as expected. I even checked that the signals were in range via oscilloscope, and they are.

I have tried adding different values of resistors onto the board (these are the unmarked ones on the .brd file), and different values give me different results, but none result in a correct picture. 1k gives me the best so far, but the image is still not centered and using the full range.

One other interesting thing that I noted is that when testing the DAC output, 4095 makes the output from the op amp go to the MINIMUM, and 0 makes it go to the MAXIMUM. I'm not sure if this is the intended operation. It seems counter logical.

Anyway, I have made a lot of progress. I am hoping to use the v.st plus raspberry pi to replace the entire pcb in my asteroids cab, and open it up to playing some other games on it.

thanks

drumguy560 commented 4 years ago

This is the output of my X channel from the v.st board. It seems like the negative side goes low enough, but the positive side doesn't go full range high? If i jump the resistor the values are in sync, but the signal degrades into nonsense...

Screen Shot 2020-07-26 at 3 10 18 PM

Swap-File commented 3 years ago

I've got my g05 showing a partial display. I had to cut the 5V trace that goes from the teensy to the DAC's VCC and hook it up to the regulated 5V (vref). The USB 5V sags lower than vref, which can cause all kinds of problems and jitter.

I don't yet have the op-amps set up for full screen coverage and I haven't tried Mame yet, I'm just testing with the Processing samples.

I've noticed that spot killer will be triggered on certain scenes if complexity drops too low, this might get better once I'm using the full screen or using a real game with Mame.

define BRIGHT_SHIFT 2 // larger numbers == dimmer lines

define NORMAL_SHIFT 2 // but we can control with Z axis

undef OFF_JUMP // too slow, so we can't jump the beam

define OFF_SHIFT 7 // smaller numbers == slower transits

define OFF_DWELL0 0 // time to sit beam on before starting a transit

define OFF_DWELL1 0 // time to sit before starting a transit

define OFF_DWELL2 2 // time to sit after finishing a transit

define REST_X 2048 // wait in the middle of the screen

define REST_Y 2048

define CONFIG_BRIGHTNESS // use the brightness DAC

define BRIGHT_OFF 810 // "0 volts", relative to reference

define BRIGHT_NORMAL 2800 // fairly bright

define BRIGHT_BRIGHT 3200 // super bright

define FLIP_X

define FLIP_Y

undef SWAP_XY

define FULL_SCALE

drumguy560 commented 3 years ago

@Swap-File - It sounds like we have a similar goal in mind - would you be willing to collaborate with me as I work that problem? I'd hate to clutter up this thread with us figuring all this out

-d

Swap-File commented 3 years ago

I got full screen working with approximately these values:

image

I'll be modifying it a little bit to give more adjustment for centering and width.

We can chat wherever you want.

Swap-File commented 3 years ago

image

A Pi0 running the last version of Jessie seems to work OK. Newer distros don't seem to work.

drumguy560 commented 3 years ago

@Swap-File This is fantastic!

So you cut the 5v trace, used the 5v reg to provide the VREF to the DACs, used a teensy 3.2, and the pi zero? Would you mind sharing an SD image of the pi zero? I have been banging my head against a wall trying to get this thing to work on my g08 so you are akin to my savior at the moment

Swap-File commented 3 years ago

Here is a basic picture of what I did (The centering circuit is super lazy, but does work). I think I'll fork the whole repo this weekend (it looks kind of abandoned) and work on an update of Mame for newer Pi OSes and a more formal update of the schematics and Teensy software.

image image

Swap-File commented 3 years ago

Here is a link to the base Jessie image I used, I think this is the last one they released: http://downloads.raspberrypi.org/raspbian/images/raspbian-2017-07-05/

drumguy560 commented 3 years ago

@Swap-File - I am really looking forward to this!

I have been tinkering with some testing and changing resistor values and the like. For some reason I wasn’t able to get full screen on my g05 with the values you specified (it’s quite possible I missed something). I got probably 75% coverage. The x centered well, but the y was offset of center for some reason.

I also get strange visual artifacts (wavy lines etc) for some reason.

I wonder if when you make the new schematics you could update it for teensy 3.6, which has a faster processor than 3.2. But I believe 3.2 and 3.6 code is compatible. A real treat would be moving up to the 4.0 or 4.1. Having a 600 MHz v.st board would be incredible