Potential hobby project- figuring out VGA output

KillaMaaki

Let me begin by saying forgive me if I say anything that sounds totally wrong - I'm a bit of a newb when it comes to electronics (I used to have a big battery-powered prototyping kit thing complete with breadboard, but that was when I was a child, haven't touched anything similar in probably a decade).
Being a newb, this project is probably a bad idea BUT I suddenly recently had the idea that I wanted to build some sort of very simple retro game console, not unlike the XGS series (I actually did have an XGS Micro but sadly I accidentally fried the thing...). Reading the specs for the Hydra brought the Propeller to my attention, and I must say it looks like a very cool microprocessor design.
Anyway, what I'm trying to do is break down each piece of the whole puzzle and try to figure out how everything will work before I order any parts so that I know what to order and have at least a semblance of an idea of what I'm doing. First on the list is VGA output.

Looking at pin diagrams for hooking up VGA to the Propeller, I see that two pins connected to resistors are then both fed into one VGA output for a color channel. I've read a few things which say that the RGB pins are terminated with 75Ω resistance, which can be used to form a voltage divider (which makes sense I suppose, since the pinouts I've seen have for interfacing with a Propeller have had no voltage divider of their own whatsoever).

That in mind, I'm putting together a little test in circuits.io to try and extend the existing two pin per channel design to three pins per channel (which should yield 9 bit color - on par with the Sega MegaDrive - and a total of 11 pins used for video). I want to verify that what I have is correct (all of this is simulated):

First, I hooked up a 9V battery, then created a voltage divider with R1=138Ω and R2=100Ω, which according to the simulated multimeter gives me very nearly 3.3V (this bit wouldn't be in the final design ofc, just using it to get a test 3.3V source in replacement of an IO pin)

That I then hooked up to three switches, each switch hooked up to its own resistor. Those resistors are then hooked up to another voltage divider with R2=75Ω, and finally wired to the multimeter. With a few calculators (a voltage divider calculator and a parallel resistance calculator) and a bit of brute force, I came up with three resistance values: 380Ω, 760Ω, and 1.52kΩ, one per digit in order from least significant to most significant bit to get close to 0.7V altogether. I then used the formula ( (number/7) * 0.7 ) to calculate a linear value between 0V and 0.7V based on a number between 0 and 7 (the range of a 3-bit unsigned integer), then checked against the simulation. The difference for any number seems to vary quite a bit - 0 and 7 are very close, but in between the difference varies between around 20mV above the calculated value, to nearly 100mV above the calculated value. This kind of worries me and makes me wonder if I made a mistake somewhere, but I think at worst this would just somewhat skew the color palette, which may not be a big issue.

Since I'm so new to this stuff, I wanted to make sure my calculations were correct and everything I've described sounds OK at least in theory.

Tubular

You're off to a great start, and the prop is great for learning and applying this kind of thing.

Some of the differences you're seeing are due to things not being ideal - for instance your 9v battery includes a 'source resistance' - because (100/(100+138))* 9.0v = 3.78v, so if you're seeing 3.3v that indicates the battery is a bit flat, or perhaps its a carbon type with a higher source resistance. Check it under load (with your divider connected) to see whats on the battery terminals.

The other thing that is happening is your 3v3 point will sag a bit as you turn your switches on, because you're changing the overall load current, and your source is far from ideal.

The important thing is to understand whats happening in your circuit, because when you transition across to the prop, there are some similar issues, for instance the pin driving fets inside the prop have resistances around 28 ohms, which should be factored in.

I'll post a link soon to where I worked out a greyscale resistor dac, for what its worth

KillaMaaki

I must have made a mistake. I wonder if I encountered a bug in the simulator or just dun goofed, since now it appears to match the output of a calculator pretty closely. So now I'm using R1=100, R2=172 for the first voltage divider. I *think* I understand what you mean about each switch changing the load (not entirely sure, it's 3:00 AM where I am and my brain is pretty thoroughly fried right now).

KillaMaaki

OK, for one thing now that I'm awake I can see that I did not have to brute force the resistance values for each of the three resistors. Simple goddamn algebra >.<
The formula I ended up deriving for a series of three resistors, R1, R2, and R3, to fit a given target total resistance Rt, was as follows:

R1 = 1.75 / ( 1/Rt )

Derived from the formula for calculating parallel resistance modified for my scenario of doubling resistance values: ( 1 / ( 1/r + 1/2r + 1/4r ) )

Then R2 is 2*R1, and R3 is 4*R1.

Rt itself can be calculated with a voltage divider calculation where Vin is voltage output from the three pins, R2 is 75, and Vout is 0.7V - solving for R1 and then plugging that in as Rt in the above formula.

circuits.io actually supports a fully simulated Arduino board, so I decided to see what would happen if I used digital pins on an Arduino instead of switches and a battery. I ended up still having to fudge the resistance values, but the output is almost perfect now (even with fudging and then picking closest values I could find sold on DigiKey). I threw together an Arduino program which would read a number between 0-7 from serial, then set pins 5, 6, and 7 to the binary representation of the number. Hooked the whole thing up to a multimeter, and this is what I get for each number:

0 - 0V (go figure)
1 - 99.8mV
2 - 200mV
3 - 300mV
4 - 400mV
5 - 500mV
6 - 600mV
7 - 700mV

The three resistors were 756, 1.56k, and 3.18k (I fudged each one individually by getting as close as possible for 1, 2, and 4 so I could test each digit separately, then proceeded to pick values from what DigiKey actually sells which resulted in 1 being a little bit off but not too bad). Not that it really matters for the Propeller since I'm going to have to calculate different values for the Propeller's output voltage, but at least now I know it's possible to get pretty darn close to exact values.

EDIT1: Made a mistake in the above table, meant to write mV instead of V.

EDIT2: Actually managed to find another circuit simulator which has support for logic inputs where I can set the high/low voltage and click each one to set high or low. So I set up three logic inputs at 3.3V, three resistors for the logic inputs, a voltage divider at R2=75, and an output. Here I've settled on R1=487, R2=973, and R3=1.94k (all chosen based on my calculated values and what I could find listed on DigiKey). Output is pretty close:

0 - 0V
1 - 100.47mV
2 - 200.33mV
3 - 300.8mV
4 - 400.25mV
5 - 500.72mV
6 - 600.58mV
7 - 701.05mV

Of course this is just in theory, but it should work fine right? (btw, plugging in the resistance values I've seen for the two-bit DAC - 240 and 470 - into a simulator yields a value between approximately 0 and 1V - even though the VGA standard is 0-0.7V AFAIK)

EDIT3: Here's a link to the circuits in the second simulator I found.

Tubular

Those resistor values seem about right for a 5v drive, but the prop will be driving with 3.3v, so you'll need lower valued resistors

One the classic propeller demo board schematic, there's a 3 bit DAC for driving composite video around 1.0 volt peak. It uses 270, 560 and 1100 ohm resistors.
https://www.parallax.com/sites/default/files/downloads/32100-Propeller-Demo-Board-Schematic-RevG_0.pdf

You can do a quick and easy check for the peak voltage because all three resistors are high, so you can parallel them (270 || 560 ||1100) equals 156 ohms, then for your monitor 75/(75+156)*3.3v = 1.07v peak

Tubular

Here's the link to working out the grayscale values. Hopefully its not too confusing. It'll all be worth it!...
forums.parallax.com/discussion/131622/resistor-values-for-64-greyscale-vga-output-from-the-propeller

KillaMaaki

Tubular wrote: »

(270 || 560 ||1100) equals 156 ohms, then for your monitor 75/(75+156)*3.3v = 1.07v

But I don't necessarily want a 1.07v peak, do I? Even thought that would probably work, I thought the standard was 0.7
Using your calculation with the resistor values I chose:
75/(75+278)*3.3 ~= 0.7V

I get the feeling I'm missing something simple here... XD
EDIT: I should probably work through that post you linked and see where that gets me...

Tubular

Yep 278 ohms is indeed what you want, but its created by a R, 2R and 4R resistor in parallel.

So Rtotal=278 = 1/(1/R + 1/2R + 1/4R) = 4R/7, hence R should be 486 ohms, 2R=972, 4R=1944 ohms will give you what you want

Or to be really fussy subtract 28 ohms (the prop pin driving resistance) off those values, giving 458, 944, 1916 ohms

From here it's worth breadboarding, remember you can just write a simple Prop program to step through the 0 to 7 values and check you get the millivolt readings you expect

KillaMaaki

Ah, OK, so I was actually pretty close then. I was off by 1 ohm for the first two, and 4 ohms for the last. I think this might be some of the fudging I did.

Based on what you've said about the Prop's pin resistance, I modified the circuit simulation - now each input has a separate 28 ohm resistor. Probably not at all necessary since I can just adjust the resistance values when I go to order resistors, but I do like seeing them separated.

So here's a new sim, with two separate circuits. One is with the values you just gave exactly (458, 944, and 1916). The other is with the closest values I could find from the DigiKey online inventory.

Thanks for the help so far

Tubular

That's looking good. I like the way the simulator shows the relative currents flowing

After you hook something up with the prop and check the DC levels output, I found Kye's 160x120 vga really useful as it is one byte per pixel

macca

FYI, here is a link to a similar discussion which includes a couple of Excel sheets to calculate the resistor values.
http://forums.parallax.com/discussion/135385/better-vga-dac-resistors

KillaMaaki

Ah, reading through that thread confirms a few things for me (for one that the existing pinouts I've seen, with the 240 ohm and 470 ohm resistors, produce a peak voltage that's higher than the VGA standard, and for another that doing so can produce a somewhat over-saturated image).

One thing I'd like to do with this in the end is, ideally, hook up external RAM in which to store a frame buffer and dedicate a cog to rendering from the framebuffer. I'd like to shoot for 256x240 8-bit paletted - the resolution and one byte per pixel would make it convenient to address pixel positions (low byte for X position, high byte for Y position)
Of course, my initial tests are going to just be outputting single color fill, then simple test patterns.

macca

KillaMaaki wrote: »

One thing I'd like to do with this in the end is, ideally, hook up external RAM in which to store a frame buffer and dedicate a cog to rendering from the framebuffer. I'd like to shoot for 256x240 8-bit paletted - the resolution and one byte per pixel would make it convenient to address pixel positions (low byte for X position, high byte for Y position)

This may give you some hints:
http://forums.parallax.com/discussion/140402/prop-c3-add-on-expansion-board-c3-synapse-is-coming-soon

There is also the schematic somewhere.

KillaMaaki

Ah, nice link. Got me thinking about some of the design, since I sort of wanted to tackle how I wanted to handle external RAM next. Looks like an SPI bus is the way to go for the task - think that will be fast enough for the purposes of dedicating some SRAM to hold a frame buffer? I see digimorf in that thread mention having two cogs, one responsible for generating the video signal and the other responsible for reading a scanline from the frame buffer and caching it for the first cog, which seems like a really neat idea that I may end up trying to implement (maybe have the cog responsible for caching the scanline perform the color palette lookups as well).