Jump to content
SiLic0ne t0aD

New Coleco RGB board?

Recommended Posts

It may be a testament to just how fast these op-amps are, but I'm measuring 9ns propagation delay between the input and output (across both stages combined)!  The sync pulse out of the LM1881 lags the Y input by 80ns.

 

Share this post


Link to post
Share on other sites
4 hours ago, Falonn said:

While I'm here: this is just a small detail, but the LM6172 datasheet says that 14ohm is the typical output resistance.  Does that mean 60ohm would be a better value for the output resistors than 75?

No, because the output after the resistance is what feeds back to its input(s).  Any internal resistance on its output is offset by increasing output voltage until it can maintain equilibrium.  So in effect, setting it up for normal operation cancels out its output impedance.  Just my own conjecture here, but the output resistance may figure into its bandwidth limits.  And depending on cutoff frequency, if you were to design it as an active filter you could need to include the output resistance in your calculations.  But for this application, I don't think it matters.

  • Thanks 1

Share this post


Link to post
Share on other sites

That's a great explanation, thanks!  (I'm still not completely used to the op-amp magic that lets them break all the rules to make things simpler.)

 

After a full night of absolutely wrestling with microcontroller timers (and losing), I just hacked something together using hard-coded timing so I would have something to show.

 

So, without further ado:

ELM.thumb.png.d9331035bdfe28a29edcccb5c8bb0ae5.png

 

Completely unmodified, straight from the capture device.

 

The output levels are a little lower than Hackaday, but everything else is basically perfect.  (For what it's worth, it seems brighter on the TV itself.)  Otherwise: no bloom and no smearing.

 

There was the faintest bit of noise in the solid black areas.  Adding a set of 470uF coupling caps to each output didn't solve it (the way it did with Hackaday).  This is cheating, but adjusting the Framemeister's brightness level a single notch (on a scale of 50) made it completely disappear.  Cranking it in the other direction, the noise pattern looks like a vertical stripe for each pixel across the screen.  I am certain this has to do with stray capacitance and inductive coupling from all the flying wires.

 

Speaking of breadboard effects, just putting my hand near some of this stuff will visibly alter the colors on the screen.  It'll be tricky to control for that during the upcoming color matrix comparison, but with any luck it'll still be a useful exercise.

 

Looking at the TMS9900 series datasheet... are the frame timings exactly the same between the 9928A and 9929A?  The master clock is listed as 10.738 MHz for both and the horizontal timing diagrams and tables don't seem to make any distinction between the two.  The only place I could find a mention of something being different in the whole document was right in section 1.1 where it says the 9928A generates 525 lines and the 9929A generates 625.  Besides the presence of the positive color burst on red in the '29A, is that the only difference?  That would simplify the final code considerably.  (That hundred extra lines is just the difference between 50 and 60 Hz video, right?)

Share this post


Link to post
Share on other sites

I made a test ROM that shows all the colors on every line, to make the next steps a little easier.  (Addressing pixels in multi-color mode is weird!)  You can really see that per-clock inductance here that I'm attributing to all of this being built on a breadboard.  It comes and goes.

 

colorBars.thumb.jpg.f6fc88027c6e914007d4463fe1065f38.jpg

 

Now it's even more plain that the levels aren't correct.

 

So, before going any farther, I wanted to sanity-test the values straight out of the console.  TI has a table of the expected voltages.

 

Using a nice, multi-second average over the width of each color bar, I was happy to see my own values (post DC-restore) matched within 30mV on all Y values and within 50mV on all color difference values.  Even better, the average error across everything was under 10mV.  So, it feels safe to consider my console a typical specimen. (For anyone interested in the raw data, see the attached CSV.)

 

So, it's immediately obvious that ELM's preconditions (either of 0.7 Vp-p or 1.4 Vp-p) aren't correct.  Here we're showing 0.93 Vp-p on Y and 0.85 Vp-p on the other two.

 

Next up: making a little simulator to try lots of values easily without fiddling with a dozen resistors each time! :)

 

color voltages.csv

  • Like 1

Share this post


Link to post
Share on other sites

An interesting wrinkle: I wanted a second opinion on the colors, so I grabbed an OSSC 1.6 to compare/contrast against the Framemeister's output.  I expected something a little different (say, within a constant factor on all the channels), but got something very different instead:

 

1251660155_ELMOSSC.thumb.png.b2944934bd5a1bb1c07d69128916063d.png

 

Flipping back and forth, a few of those (most notably the orange'ish red in the middle) aren't even close between the two.  With default settings on both upscalers, I'm surprised at the difference.

 

Searching around, the only mention of color quality/accuracy I could find was on RetroRGB's upscalercompare page.  See the side-by-side Super Metroid comparison shot about halfway down the page.  For my money, the OSSC's output on the right-hand side feels a little exaggerated.

 

Even in this color bar test, what is supposed to be white ends up a lot lighter gray than the Framemeister's output, which makes me suspect the OSSC of engaging in the age-old tactic used by stereo salespeople across the country: "louder sounds better!" (or "brighter looks better!" in this case).

 

At any rate, I'm going to measure the output voltage levels from the ELM board, then compare it to the pixel values in both screen grabs to try and reverse engineer their own transformations (and confirm the real op-amp operations at the same time).  My color simulator is coming along, so maybe in addition to being able to vary the input voltages (between 9928A ideal, my Rev.H2 board 9928A as-measured, and 9929A ideal), I might be able to add a way to simulate which device you're viewing the output through, too.

 

Beyond that, I've got a little "RF to VGA" adapter on the way.  I'm going to double-check that it (hopefully) outputs the same colors as RF straight into the TV (to establish a baseline) so that I can grab some screenshots, which will give us a third data point: "output through an LM1889".  At that point the goal will be to find a way to make the first two look as close to the third as possible.  That'll be the "R&D" stage completed and we'll be able to move onto actually making a little board.

 

In the meantime, I see some matrix multiplication in my immediate future... :D

  • Like 2

Share this post


Link to post
Share on other sites

The OSSC uses a monolithic chip that processes and repackages the analog component inputs and (IIRC) it outputs digital RGB for either DVI or HDMI purposes.  It definitely would depend on the input being within spec though, for proper output.  If the TMS is too sloppy, your only real recourse would be to attempt some automatic gain control.  But I'm not confident that it would work correctly either since it needs to know what a full-strength signal is before it can properly scale the not-quite-full-scale signal.  And unfortunately, the TMS has pretty wide tolerances which are also affected by temperature.

  • Like 1

Share this post


Link to post
Share on other sites
9 hours ago, ChildOfCv said:

And unfortunately, the TMS has pretty wide tolerances which are also affected by temperature.

Do we have any idea how much of those tolerances are "spent" on a variable DC offset?

 

In the TMS Doc there is a line under the "DC Restoration" heading that says "[Restoration] cannot be done with a DC biasing scheme because the output level of the VDP can vary from device to device as a function of process, or as a function of temperature."

 

After reading that a few times, it seems reasonable (or at least plausible) that most of the (scary-)wide tolerances listed in the datasheet might be due to the unknown/varying DC offset, which would be corrected outright by any DC Restoration step.  This is my hypothesis why the ColecoRGB board (which lacks restoration) is inconsistent across systems.

 

At least, that's what I've been telling myself.  If not, showing the VDP on any screen would basically become an intractable problem, right?

 

10 hours ago, ChildOfCv said:

The OSSC uses a monolithic chip...

The O is for "open", so the schematic is readily available. :D   The RGB inputs run through a THS7353 buffer (presumably for DC restoration) followed by the TVP7002PZP video DAC.

 

While measuring the output voltages last night, it was curious that just being plugged into either the Framemeister or OSSC changed the output levels by as much as 10mV.  My guess is just the tolerance differences in the 75ohm input resistors between the two.

 

Just poking at the numbers (I haven't done any proper linear regressions yet), it looks like the OSSC shaves the bottom 70mV off the signal to establish its black level.  Framemeister is more conservative and only loses the bottom 35mV or so of dynamic range.

 

This process of trying to characterize these output devices is just to make sure we're not doing color correction to a particular device, but still sticking to some middle-of-the-road ideal that will (or should) work for everyone.  This could probably be done just by looking at the output voltages, but I like to understand the system from end-to-end before drawing conclusions.

Share this post


Link to post
Share on other sites
26 minutes ago, Falonn said:

Do we have any idea how much of those tolerances are "spent" on a variable DC offset?

Well, the data sheet shows Vnocolor on the timing diagram, but neglects to offer a listing in the voltages section.  Sigh.

 

But you can still see the horror of its capabilities in the other params:  Vwhite is anywhere between 2.5 and 3.6V.  Vblack is anywhere between 1.6 and 2.5V.  The difference in voltage between white and black on any channel is between 0.7V and 1V.  So, pretty sloppy tolerances.

 

26 minutes ago, Falonn said:

 

In the TMS Doc there is a line under the "DC Restoration" heading that says "[Restoration] cannot be done with a DC biasing scheme because the output level of the VDP can vary from device to device as a function of process, or as a function of temperature."

 

After reading that a few times, it seems reasonable (or at least plausible) that most of the (scary-)wide tolerances listed in the datasheet might be due to the unknown/varying DC offset, which would be corrected outright by any DC Restoration step.  This is my hypothesis why the ColecoRGB board (which lacks restoration) is inconsistent across systems.

You'll notice that the ColecoVision also has a DC restoration circuit too.  Not quite as sophisticated, but definitely there.

 

26 minutes ago, Falonn said:

 

At least, that's what I've been telling myself.  If not, showing the VDP on any screen would basically become an intractable problem, right?

Not really.  Most people weren't picky about the accuracy of the colors.  They just wanted to play a game :)

 

  • Thanks 1

Share this post


Link to post
Share on other sites
41 minutes ago, Falonn said:

While measuring the output voltages last night, it was curious that just being plugged into either the Framemeister or OSSC changed the output levels by as much as 10mV.  My guess is just the tolerance differences in the 75ohm input resistors between the two.

Could be.  Since the output is the middle of a voltage divider between your circuit and theirs, the true resistance of the resistors used on both sides will matter.  And a .01V difference for a 0.7V swing is within 2% tolerance.  The REALLY cheap resistors can be as tolerant as 10%.

Share this post


Link to post
Share on other sites
8 minutes ago, ChildOfCv said:

The difference in voltage between white and black on any channel is between 0.7V and 1V.  So, pretty sloppy tolerances.

I hadn't seen that particular point.  That's... not great.

 

The goal is still a board that doesn't require tuning.  I wonder how close the other channels would be relative to the 0.7 to 1.0V swing?  If it's relatively linear across all three, that would just mean some Colecovisions with this eventual adapter would be a little darker than others.  The incorrect color bars above only have 450mV between white and black, so even a 700mV difference between them should be passable (and mostly correctable with TV or upscaler controls).

 

I'm starting to make a lot of assumptions though.  I keep hearing these horror stories about how bad the outputs are.  Hmm.

Share this post


Link to post
Share on other sites

300 mv on a standard that swings +- 1v ... don't chase the dragon so much in analog realm, this crap was made up in the 1960's

 

and built to the absolute lowest cost, "that will do" standards 

Edited by Osgeld

Share this post


Link to post
Share on other sites

Here is the first pass on the color simulator:

 

SimulatorYUV.thumb.png.4c3e8a62346d9fa98f2d242896d05303.png

 

 

If you've got a Windows machine, it's way too much fun not to play with!  (Windows .exe attached below.)

 

To get started, try copying one of these four blocks to your clipboard, then click "Load from Clipboard".

# Pretty close to the real OSSC output
Voltage:9928A Measured (Rev H2)
Screen:Color Bars
Transform:1.0 1.77 1.4 1.0 -0.186 -0.51 1.0
Output:OSSC 1.6

# A familiar image
Voltage:9928A Too Much Blue
Screen:Popeye
Transform:1.0 1.77 1.4 1.0 -0.186 -0.51 1.0
Output:Framemeister

# Ideal YUV --> RGB with 2x Y
Voltage:9928A Datasheet
Transform:2.0 0.83 1.3 1.140 -0.395 -0.581 2.032
Output:Ideal divider, assume 1.0Vpk

# Ideal YPbPr --> RGB with 2x Y
Voltage:9928A Datasheet
Transform:2.0 1.05 1.07 1.402 -0.344 -0.714 1.772
Output:Ideal divider, assume 1.0Vpk

I'm not sure where the extra factor of 2.0 comes in, but both of those last two "by the book" entries have their Y pre-scaling set to 2.0 (instead of the prescribed 1.0) which makes everything, like, perfect.  The output matches the tiny openMSX emulator thumbnails almost exactly and only Light Red barely clips.  With only 1x for Y, everything is wrong.

 

In any event, while trying to get the simulator to match the real screenshots, I noticed the first aberration: the simulator-predicted voltages for R and B are all within about 20mV of the real measurements.  But the predicted voltages for G differ by 150mV or more(!) on almost every color in the palette.

 

The first step is going to be reconfirming every resistor value.  Assuming they're good, what do you suppose the chances are of the resistor network between the two op-amp stages letting colors bleed into the other amps where they shouldn't?  I can see many paths (say, through R12, R13, then R16) where these channels look like they could mix in ways we don't want them to.  Is this another one of those "op-amp magic!" things we shouldn't have to worry about?  Or would this discrepancy be cleaned up if there were, say, seven voltage followers just in front of each of those middle seven resistors?

 

TMS-RGB 1.1.exe

Edited by Falonn
A silly mistake in the app. Fixed in v1.1

Share this post


Link to post
Share on other sites
8 hours ago, Falonn said:

The first step is going to be reconfirming every resistor value.  Assuming they're good, what do you suppose the chances are of the resistor network between the two op-amp stages letting colors bleed into the other amps where they shouldn't?  I can see many paths (say, through R12, R13, then R16) where these channels look like they could mix in ways we don't want them to.  Is this another one of those "op-amp magic!" things we shouldn't have to worry about?  Or would this discrepancy be cleaned up if there were, say, seven voltage followers just in front of each of those middle seven resistors?

It's not that they're "magic".  It's that they literally ARE voltage regulators.  It's just that the regulated output voltage is related to its input voltage.  So anywhere there is a direct line of sight to the op-amp output, you can expect the voltage at that point to remain rock solid.

 

Now, there is always a delay in responding to voltage spikes.  You can attempt to minimize it by making the electronics even more complex (which typically just moves the problem elsewhere), but you'll never get rid of it.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

"Remain rock solid" is what I needed to hear to convince myself, thanks!  So those other paths shouldn't matter--not "much" but "at all", because the output (say, between R13 and R16) will be maintained correctly via U5A's feedback.  That is, it will fight the "back flow" I was worried about there, right?

 

So it sounds like I simply made a mistake someplace in the vicinity of the green channel.

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, Falonn said:

"Remain rock solid" is what I needed to hear to convince myself, thanks!  So those other paths shouldn't matter--not "much" but "at all", because the output (say, between R13 and R16) will be maintained correctly via U5A's feedback.  That is, it will fight the "back flow" I was worried about there, right?

Right.  The "operation" of the op-amp is that when you place a varying load on the output, as would happen when two op-amps sum into the same network, it will change the feedback voltage.  That change will be sensed by the op-amp's feedback inputs.  If the "-" input falls below the "+" input, it will output more voltage, until they are equal again, and output less voltage when the "-" rises above the "+".

 

One potential gotcha though, is when two op-amps start arguing with each other and create oscillations (since both will be actively attempting to regulate their own voltages).  But the large resistor values should minimize that.

1 hour ago, Falonn said:

So it sounds like I simply made a mistake someplace in the vicinity of the green channel.

Possibly.  Do you have an updated schematic?  It looks like the last one still has the voltage doublers for the component stage, so I assume it's not the one you built.

  • Like 1

Share this post


Link to post
Share on other sites

It's not much different since last time.

 

ELM2.thumb.png.5a720a06811b383ecc1aae180b611089.png

 

The post with the previous schematic mentioned the important changes (that weren't reflected in the image yet).  Maintaining the MS Paint aesthetic in this one is a little slower. :D

 

Here's the exhaustive list of changes since last time:

  • Removed R6 (Y feedback).
  • Changed R8 (R-Y feedback) to 188ohm.
  • Changed R10 (B-Y feedback) to 364ohm.
  • Added R30 and C10 to the LM1881's Rset pin.  (The CPLD version of the ELM schematic omitted it and we also/still don't need the burst pin... but the datasheet says these are required.  I didn't want to risk having the chip misbehave elsewhere.)
  • Updated the math at the top.
  • Removed the 1k resistors between U7 (which used to be the CPLD) and the mux control lines.

I haven't assigned pins to the MCU because I've been using an ATTiny85 as a stand-in until the 9's arrive (which has been inconvenient because the '85 doesn't have a 16-bit timer; The '9 does).

 

Speaking of microcontrollers, I think I've narrowed down why I've had trouble with the LM1881's burst pin in the past.  The pulse length is determined by those two passives: R30 and C10, which have inherent tolerances.  So just between three boards and three LM1881's, I've already seen enough variability that the end of the pulse is either before the end of the color burst or after pixels are already appearing on the screen (at which point video should already be switched back from ground / sample-and-hold).

 

It's a very small timing window between the end of the color burst and the start of the line, which the microcontroller can hit consistently.  It would have been nice to clock it from the VDP's own clock, but they're crystal pins instead of a proper square wave.  It's not too much more trouble to make-do with counting the time between the various pulses using the Tiny's internal 8MHz "calibrated" oscillator.  The way I'm doing it now is re-learning the best timing every line, so there shouldn't be any problem with drift over time/temperature.  The jitter between the two clocks creeps me out a little, but so far it's been working 100%.  The real test will be seeing it work in all the board/chip revisions out there.

 

Regarding color: now that I've seen how little difference there is between YUV and YPbPr (especially relative to the tolerances in the VDP) and that even though the VDP's resolution is quoted as 192 lines, it still generates a proper 240p signal (after borders and the off-screen lines), I'm growing curious whether the LMH1251 might really be able to replace U4, U5, U6, and something like 18 resistors.  That would be pretty cool.  I worry that we'll still need a little pre-scaling before the monolithic converter for whatever reason, which would more than halve the savings.  We'll see.  In either case, we should be on our way toward accurate color, soon.

Share this post


Link to post
Share on other sites

I was about 30 minutes into ramping up for an LMH1251 experiment when I decided I needed to just focus on the task at hand.  Outside of fewer components in the BOM (although not necessarily cheaper), there wouldn't be any huge wins over what we have now.  So let's press on!

 

The last deficiency (besides color) that I know about is the sync output.  It's essentially "TTL C-sync" right now, which doesn't conform to the 150ohm, 0.7V SCART standard.

 

The LM1881 is only spec'd to source/sink 5mA, so we need at least one more component.  Sending it through a voltage divider to 0.7V, then a voltage follower, and finally the 75ohm resistor would work just fine, right?

 

That said, if we're already adding another IC to the board, would it make more sense to run all four lines through the ubiquitous THS7374?  We'd need the color matrix to output at 0.7V because it would add 2x to everything that passes through it, but it can source plenty (85mA) of output current... not that we need all of that.

 

Or am I overthinking it?  The LM6172's can already source enough (25mA) for the RGB lines.  Should we just address sync separately, call it a day, and start making these boards sooner?  (I think I'm beginning to experience R&D fatigue.) :D

Share this post


Link to post
Share on other sites
22 hours ago, Falonn said:

Here's the exhaustive list of changes since last time:

  • Removed R6 (Y feedback).
  • Changed R8 (R-Y feedback) to 188ohm.
  • Changed R10 (B-Y feedback) to 364ohm.
  • Added R30 and C10 to the LM1881's Rset pin.  (The CPLD version of the ELM schematic omitted it and we also/still don't need the burst pin... but the datasheet says these are required.  I didn't want to risk having the chip misbehave elsewhere.)
  • Updated the math at the top.
  • Removed the 1k resistors between U7 (which used to be the CPLD) and the mux control lines.

You could also remove R7.  All it is now is a leaky bucket.

 

I do wonder why the first stage needs to do any multiplication though.  You could simply use the first stage as voltage following buffers and do all of the factorization in the second stage and multiply your terms through.  Or is this intended for normalization?  If so, did you test the R-Y and B-Y voltage ranges throughout the color outputs to find their total voltage ranges, and compare that to Y with white vs black?

 

Also, note that your R and B second stages are set to double the output voltage.  Maybe that's what you're going for, but I just thought I'd point that out.  The G stage, though, has a lower gain because 922||2530 is 675, but you matched it with another 470.

  • Thanks 1

Share this post


Link to post
Share on other sites
23 hours ago, Falonn said:

Speaking of microcontrollers, I think I've narrowed down why I've had trouble with the LM1881's burst pin in the past.  The pulse length is determined by those two passives: R30 and C10, which have inherent tolerances.  So just between three boards and three LM1881's, I've already seen enough variability that the end of the pulse is either before the end of the color burst or after pixels are already appearing on the screen (at which point video should already be switched back from ground / sample-and-hold).

Yikes.  You definitely need tighter tolerances on the components used for Rset then.

Share this post


Link to post
Share on other sites
23 hours ago, Falonn said:

It's a very small timing window between the end of the color burst and the start of the line, which the microcontroller can hit consistently.  It would have been nice to clock it from the VDP's own clock, but they're crystal pins instead of a proper square wave.  It's not too much more trouble to make-do with counting the time between the various pulses using the Tiny's internal 8MHz "calibrated" oscillator.  The way I'm doing it now is re-learning the best timing every line, so there shouldn't be any problem with drift over time/temperature.  The jitter between the two clocks creeps me out a little, but so far it's been working 100%.  The real test will be seeing it work in all the board/chip revisions out there.

I guess that's the difference between the tinys that you're using vs the ones you've ordered?  I'm pretty sure the 9's are 12MHz.  If so, you'll have to recalculate your clock periods too.

Share this post


Link to post
Share on other sites
1 hour ago, ChildOfCv said:

I do wonder why the first stage needs to do any multiplication though.

There does seem to be plenty of gain-bandwidth-product to go around (and the gain in each stage is tiny anyway), so maybe the ELM circuit author just did it out of convenience?  It does make calculating resistor values for the second stage easier.

 

1 hour ago, ChildOfCv said:

Or is this intended for normalization?  If so, did you test the R-Y and B-Y voltage ranges throughout the color outputs to find their total voltage ranges, and compare that to Y with white vs black?

The "Ideal YUV" and "Ideal YPbPr" profiles above in the color testing app post use them for normalization.  (Although, really, the coefficients are like 1.05x and 1.07x on one of them.  It's probably not that critical.)  I still don't know why the 2.0x on Y is required there (contrary to all color matrices posted everywhere) to get the output looking perfect and the voltages all in-spec.  Otherwise the first stage could be all voltage-followers.

 

1 hour ago, ChildOfCv said:

The G stage, though, has a lower gain because 922||2530 is 675, but you matched it with another 470.

I think that was the bug, thanks!  I recalculated the ratio between the two correctly but forgot to match the gain afterward.  470:675 is right around the difference I measured, too.

 

1 hour ago, ChildOfCv said:

Yikes.  You definitely need tighter tolerances on the components used for Rset then.

I've been having a lot of trouble characterizing the problem (even to myself).  It's still fuzzy.  It's not that the burst pin isn't doing its job... Hm.

 

So, the Hackaday circuit has a problem I hadn't seen until after I'd made my color bar test cart.  This was the first time I'd noticed that the border color begins immediately after the back porch (I suppose, by definition, hehe).  

 

Here is Hackaday back under the scope:

 

HackadayBurst.thumb.png.925ae35ea2bf0ee15707b946bd6f54cd.png

1: Sync, 2: Burst pin, 3: Y in, 4: Blue out.

 

Because Hackaday uses the burst output for the sample-and-hold, you can see where the white border sort of fades in.  (Check the difference between the pink and dark blue lines just after the burst ends.  One has a sharp corner.  The other doesn't.)

 

So the burst pin isn't perfect for performing what I've started calling "video enable".  This is especially true just as V-sync is beginning:

 

HackadayVsync.thumb.png.d272607f0e0796f267955578ec3eed30.png HackadayVsyncZoomed.thumb.png.619b376fe7f43aae3d5b70f3363c70b7.png

Left: the last line and start of V-sync.  Right: Zoomed into the little V-sync spike.

 

The LM1881 still signals that the final (non-existent) burst is active even after Y has gone back to blanking level, so it's sampling-and-holding the blanking level instead of black.

 

So as a "video enabler", it cuts a little real data out and leaves a little junk data in.

 

Next, the burst pin isn't perfect for DC restoration:

 

482337545_1.3uswindow.thumb.png.7571d9b43306e8d60403aa131ede36d9.png

1: Sync, 2: LM1881 burst pin, 3: B-Y (showing negative color burst), 4: Y in (showing incoming white border).

 

In a circuit that uses DC restoration (not Hackaday, but ELM or TMS Doc), if you trigger your restore on the burst pin, you'll restore against the color burst, followed by the real black level, and finally the front edge of the background color.  (Restoring during a white background makes everything look crazy!)  Laid out like this, I can finally see that this was the reason you've heard me repeat a few times over the last couple pages that "I can't quite seem to be able to get rid of the rest of the blue" when trying Hackaday's approach on the others.  It doesn't work.

 

That horizontal slice I marked off with the cursors is the critical 1.3 microseconds.  If you DC restore during that timing window instead, you can restore all three channels perfectly.  And if you switch to "video enable" anywhere in the middle, you don't cut any visible portion of the screen off.

 

(I think I'm getting close to what I meant to say the first time around!)  When I mentioned tolerances, I meant you could try to fiddle with the RC values on the LM1881's Rset pin to get the burst signal to cut off somewhere in the middle of the critical 1.3us (instead of lasting for the entire back porch and cutting off the leading pixels), but that with such a tight timing window, the tolerances of the components would come into play.

 

Barring that, the burst pin can only be a jack of all trades, master of none.  Replacing it with a microcontroller fixes both problems simultaneously (and then some).

 

For what it's worth, all of my components are, like, 1% tolerance.  I just need to say what I actually mean. :D

 

2 hours ago, ChildOfCv said:

I'm pretty sure the 9's are 12MHz.

That 12MHz is a "rated up to" when using an external clock or crystal.  (You can get ATTiny85's rated up to 20MHz for the same purpose.)

 

Both of them (and the entire ATTiny line as far as I know) have an internal 8MHz oscillator that you can use without any external components.  I put "calibrated" in scare-quotes because it's something like a 10% tolerance, which isn't great.

 

2 hours ago, ChildOfCv said:

If so, you'll have to recalculate your clock periods too.

For now I've just had it hard-coded to the particular chip.

 

Now that I've got some '9s in hand (with their nice 16-bit timer), the plan is to switch to adaptive timing: measure the rise/fall time between each sync pulse to establish a baseline and work in those units instead.  That should take F_clock out of the equation, modulo any remaining jitter.

 

From my testing, I've been able to hit the critical 1.3us window (with plenty of accuracy and precision to spare), so we shouldn't need any extra hardware (crystals, clocks, PLLs, etc.).  That said, aesthetically, I would have liked to use the same, known clock as the VDP.  Oh well.  I think the only difference would be a slightly less shaky line on the scope.

 

(As a bonus: I'll also get to use the extra timer resolution to detect V-sync a little more conveniently, so it can count how many lines there are in a frame--making it PAL/NTSC agnostic--and turn off the video-enable mux during any/all blanking.  Then my inner perfectionist will know that R-, G-, and B-out will be perfectly clean.)

 

 

So at this point, I think the only tasks remaining in the prototyping stage are:

  1. Figure out the simplest way to get sync-out into spec for SCART.
  2. Swap out all the resistors (whose values may depend on the answer to #1) to make the colors correct.
  3. Update the ATTiny code for the '9 and get it working for the general case instead of my specific case.

 

HackadayVsyncZoomed.png

Share this post


Link to post
Share on other sites

(Hrm, don't mind that final image.  That was an earlier version of the "Zoomed into the little v-sync spike" shot that I forgot to remove.  Sorry.)

 

And of course, moments after clicking Submit, I noticed I had misinterpreted some of my own evidence. 😕  All of the output edges in that first Hackaday image are rounded (hence the smear) and looking more closely, no matter how conservative you are about the logic levels on that slow burst pin, it does appear to end inside the critical 1.3us, before the white border begins.

 

Alright, I will concede that there is a path to doing this without a microcontroller.  Things we'd need:

  1. Use a smaller Rset resistor to get the burst pin to end its pulse closer to the end of the real color burst.
  2. Turn that (slow, awful) edge into a ~1us pulse. (Maybe with a 555?)
  3. I'd have to give up my (totally self-imposed) desire for no sync pulses in the output. :D

DC restore on the new pulse.  Video enable on some combination of sync+burst+new pulse using discrete logic.

 

That would do it.  Would it remove the "you need a way to program one of the chips" end-user requirement?  Yes.  Would it be fewer components?  No.   Would those extra components still be able to fit on a tiny one-sided board?  I'm not sure; it feels like we're probably already pushing the limits as-is.

 

Alternatively:

  1. Focus more of my energy on fixing Hackaday's shortcomings instead of pressing forward with ELM.

 

It's certainly food for thought.  For now I think I'll continue down the microcontroller route.  You can get a USBasp programmer for $5 these days, so that's less of a barrier to entry.  The hardest part for hobbyists will be making an electrical connection to those tiny SOT-23 pins!  Although, ideas like this one are a pretty clever way to do it cheaply/easily. hehe.  (I never heard back from Digi-Key about single-unit custom programming pricing.  If it wasn't worth replying to my email, I'm guessing the price would have been too high.)

 

So we're back to the same three tasks remaining as my last post.

Share this post


Link to post
Share on other sites
5 hours ago, Falonn said:

So, the Hackaday circuit has a problem I hadn't seen until after I'd made my color bar test cart.  This was the first time I'd noticed that the border color begins immediately after the back porch (I suppose, by definition, hehe).  

I can believe that.  TMS's "border color" is just like CGA's border color:  It begins as soon as the signal does.  This gives you a colored edge of the screen which would normally be trimmed by the overscan.  (Older TVs used overscan as a means of making the image look more pristine by making it about 20% too big so that the CRT can chop it into a nice rectangle).  Unfortunately, many modern LCDs will show the entire image now and the overscan artifacts become apparent.  If you can at least make the color consistent when it does begin to show again, then I'd consider that to be good enough.

 

6 hours ago, Falonn said:

Because Hackaday uses the burst output for the sample-and-hold, you can see where the white border sort of fades in.  (Check the difference between the pink and dark blue lines just after the burst ends.  One has a sharp corner.  The other doesn't.)

Whoa there!  No, the Hackaday is supposed to use the sync pulse for sample and hold.  It uses the burst period for suppression, because that's when the TV starts sampling for neutral, but the 992x is sending burst voltages instead.

6 hours ago, Falonn said:

Both of them (and the entire ATTiny line as far as I know) have an internal 8MHz oscillator that you can use without any external components.  I put "calibrated" in scare-quotes because it's something like a 10% tolerance, which isn't great.

Wow.  Even a 6-pin microcontroller can take an external crystal?  That leaves you with only 2 pins for GPIO, so quite limited in applications.

6 hours ago, Falonn said:

Figure out the simplest way to get sync-out into spec for SCART.

Remove the 100 ohm resistor to ground.  From my calcs, 5V through a 470-ohm resistor into a 75-ohm load should put close to .7V on the load.

4 hours ago, Falonn said:

Turn that (slow, awful) edge into a ~1us pulse. (Maybe with a 555?)

Schmitt trigger would be best for squaring a wave.  But I wonder what could be causing such a crappy buildup in the first place?  Maybe it has to do with the Rset circuit.

 

Share this post


Link to post
Share on other sites
1 hour ago, ChildOfCv said:

Whoa there!  No, the Hackaday is supposed to use the sync pulse for sample and hold.

Er, sorry for the confusion.  This is another one of those times where I spoke faster than I was precise.  "Because Hackaday uses the burst output [as the time window to output] the sample-and-hold..."  So it sounds like we were both saying the same thing, except you actually said it while I said something else, hehe.

 

1 hour ago, ChildOfCv said:

Even a 6-pin microcontroller can take an external crystal?

Luckily you get the option of using a plain square wave input as a clock source, too.  In that case you'd have 3 GPIO pins left over... which still isn't very many! :D

 

1 hour ago, ChildOfCv said:

But I wonder what could be causing such a crappy buildup in the first place?  Maybe it has to do with the Rset circuit.

Yeah, I think I saw it detailed in the datasheet.  It builds up an internal charge during sync and then dumps it just afterward through the Rset components.  That's how you get to choose how long the pulse lasts.  The 680k is mentioned in the datasheet as being a safe value for both NTSC and PAL timings.  This is also why that tiny sync pulse just before v-sync creates such an anemic burst pulse: the chip doesn't have a good chance to finish its internal charging.

 

1 hour ago, ChildOfCv said:

From my calcs, 5V through a 470-ohm resistor into a 75-ohm load should put close to .7V on the load.

Over night I'd spotted that in a few places, like RetroRGB's c-sync page.  I may have been too focused on the impedance half of the equation. Since 16'ish kHz doesn't start to experience transmission line effects until it's (hundreds?) of miles long, we probably don't have to be as careful about reflections due to mismatched impedances.

 

With every power supply I've thrown at this Colecovision (including ColUSB), I've only seen about 4.6V by the time it reaches the VDP's Vcc pin.  Is that typical?  If so, would it make sense to scale that 470-ohms down a little to be safe?  (Or do I just have a broken system?) :D

 

Coincidentally, I've been talking to Ruggers Customs via PM and he pitched a really interesting idea: instead of targeting this made-up 8-pin mini DIN "standard", if we used the same outputs from the 9-pin mini DIN used by Sega in the Genesis 2 (and later), there'd be an even richer ecosystem of cables with a good chance that many people already have one.  One of the details is that they output TTL c-sync and let the cables do the work of adding that 470-ohms along with all four 75-ohm resistors.

 

Once you've got the extra pin for composite, instead of making a tiny board that gets soldered to the back of the VDP, you could make a slightly larger board that simply replaces the RF board: no cutting required on the case (mini DIN replaces the RF jack), still completely reversible, audio is available from the 8-pin RF header (one less wire to run manually), and external video from expansion #1 could be passed straight through (upgrading it from RF to composite in the process) so no features are lost.  Kind of a neat idea to kick around.

 

It looks like the only new requirement in that case (judging from your RF schematic) is that you'd either need to run a separate 5V line to the board or include a little buck converter to drop the (usually?) 12V down to 5V.  Do you know what the jumpers to select between 12V and 5V are for?  Was that just for possible future revisions of the RF board?

 

I was trying to think of any cons at all in replacing the RF board and all I could come up with is that it technically requires a little desoldering (which a back-of-the-VDP solution doesn't) to remove and then re-add the RF board's metal shroud.  That's about it.  You could argue that during this kind of installation a lot of people would be interested in the other more routine maintenance tasks, and you already have to remove the RF board during a full re-capping, so this might not be any extra work at all. :)

 

EDIT: Alright, I thought of another one: back-of-the-VDP is more general and works on non-Colecovision things, too!  Maybe there is room for two board layouts?

Edited by Falonn
  • Like 1

Share this post


Link to post
Share on other sites
14 hours ago, ChildOfCv said:

From my calcs, 5V through a 470-ohm resistor into a 75-ohm load should put close to .7V on the load.

Isn't 5V/(470Ω+75Ω) still about 9.2mA?  That's close to twice what the LM1881 is rated to supply out of pin 1.

 

Would running it into some tiny CMOS switch (connected to 5V) solve the problem?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...