Falonn

Alright, this is nearly there. Lots of little refinements: I didn't need one of the THS7374 channels, so I swapped it for a '7314. Using the LM1881 datasheet default of 680k for the Rset resistor makes the burst signal last into the CV's border color. Dropping it anywhere between 560k and 600k splits the difference nicely between the end of the color burst and the start of the color border. That will be safer. With the extra 2x from the output amp, we're in a new position of needing to attenuate the signals instead of amplify them: CV outputs 1.0 black-to-white Y, but LMH1251 is spec'd for 0.7V. So I added a set of voltage followers for each channel so we could sneak a divider network in there. Without the buffers, the output resistance from the mux was making things challenging/unpredictable. And putting any kind of load through the mux was causing big spikes on the transitions. (Using higher-value resistors to reduce the load also caused smearing in the image like Hackaday! So I get to take advantage of the voltage follower's output current and use nice, low resistor values to solve both problems. We're talkin' 1V signals here, so it's still only like 1mA.) Using a four channel amp means we can just collapse the sample-and-hold amp into the same IC, so we don't need to add anything to the board; just increase the pin count by a couple. Still to-do: 1. With those resistor values, all the output colors are officially in-spec (0.7V white after the 75ohms) now. This is through the Framemeister: But curiously, the RGB value coming through the capture device for white is around 230 (out of 255) on each channel. That's only 90%, which makes it feel like the Framemeister is expecting something closer to 0.8V before it will show things fully saturated. I'll probably leave them alone (it looks just fine on the TV), but include a bonus/alternate recommendation in the BOM for brighter colors. 2. The 74LVC2G17 is a tiny, 6-pin dual-Schmitt trigger that can solve two problems at once: alleviate the output current of pin 1 on the LM1881 and give the pin 5 burst output a much sharper corner. It's got plenty of output capacity for the former and is designed for the latter. That saves a resistor (and its board space) vs. the discrete transistor solution for LM1881 pin 1. I'm fairly confident this will work on the first try, but I don't have any of these on-hand yet. 3. You have to look hard, but you can see the slightest front edge on the transitions from black to other colors. Checking it out on the scope, Y predictably leads B-Y and R-Y by about 15ns because it doesn't go through the mux. I'm thinking of "needlessly" passing Y through the third channel (instead of the sample-and-hold) to level out the propagation delay. All we'd need is a little replacement SPST analog switch (say, the 74LVC1G66) for the sample-and-hold and the picture should essentially be perfect.

That was eventually corrected on the OSHPark page, so I don't count that mistake anymore. The "ColecoRGB PAL" board was already pretty full. With another IC, it might get tricky fitting it all under the VDP's footprint. In large quantities, I agree that the price wouldn't make as much sense to include an LMH1251, but for the kinds of short/medium runs this board will see, I bet it will at least end up in the same ballpark. I'm not sure the ~$5 difference would mean much to someone that wants to add RGB out to their beloved, forty year old system. So... I don't know very much about the Adam. I just poked around the user manual and the schematic. Are they just calling the RF port "Aux" to make a distinction between the composite out? They both output the same signal, right? In that case, the RGB out would supersede them both. (Sorry for my lack of experience! If those ports do something different, the answer will also be different.) You mentioned that the composite out looked good, so the workaround in the meantime is probably "use the composite output instead of RF".

"Breadboard effects" was my theory, too, because each of these circuits has slowly been moving up to faster op-amps. But then I went back and tried one of the first breadboards (that used to be perfectly clear a couple weeks ago) and the vertical lines were still there. Something has definitely changed in the interim... I'm just not sure what. I spotted in the service manual "Vertical Lines: Vertical lines on background rather than solid blue background with no lines? Replace C106." C106 is just the (tantalum) power supply bypass cap on the TMS9928A, but I was going to give it a shot to see if it helps. If it's not doing its job anymore for whatever reason, I could see the VDP getting starved for current which might cause something like that. That said, you are absolutely correct that a PCB should go a long way toward solving more of the problem, especially with that LPF!

Citrus3000psi's ColecoRGB PAL is just a verbatim copy of 256byteram's circuit from Hackaday (with a required component missing and a typo) and no attribution given that I've ever seen. So I'd rather give the credit to 256byteram. I suppose to be fair, Citrus' board would be easier to install... assuming you are able to correct for that missing capacitor and aren't tricked by the double R27 labels.

Well that was a quick turn-around! The LMH1251+THS7374 (with an LM1881 + TL081 sample-and-hold + mux to remove the color burst) works beautifully. At first it had seemed to amplify the noise from my failing console and give the worst picture I'd seen yet. Then I decided to try enabling the low-pass-filter built into the THS7374. As a rule I try to avoid that sort of post-processing, but in this case... magic. <-- without LPF / with LPF --> Just absolutely crisp, like an emulator screenshot (even with all that noise under the hood): The colors are still over-driven (almost like the RF output ), but that's because the CV's voltages are out of spec for the LMH1251. CV outputs 1.0V white and -4.7V sync. LMH1251 expects 0.7V white and -0.3V sync. There's already a 390Ω to ground on each of the Y, B-Y, and R-Y pins on the CV board. I wonder if we couldn't just use a simple resistor divider to get the scaling factors for each line? It'd be cool to do it with three tiny passives instead of adding a set of op-amps just for normalization. I'll play with that (and a few other things) tomorrow. So this version means: no -5V rail, no MCU programmer required, and the entire board is practically just 5 small ICs and a smattering of power bypass caps. In the meantime, the most important task (now that board layout is nearly imminent): this project needs a name! ColecoRGB would have been great, but it's already taken. I've been thinking about "TMS-RGB". Pros: It's less of a mouthful than "TMS992xA-RGB". It avoids any sort of Colecovision trademark issues. It implies broader compatibility (say, with the MSX or Adam) than just Colecovision. Cons: "TMS" isn't particularly notable. You have to be a hardware person before you know what it refers to. Any other suggestions?

I posted a summary in your other topic. Otherwise, I'm probably overdue here for an update: I have good news (for all of you) and bad news (for me). Those vertical lines in the ELM screenshots were bothering me more each day, so I decided to track the source down. At first I said that they came and went, but in reviewing my various screenshots I noticed that they really just arrived and never went away. The first few ELM screenshots are perfectly clean. Then, around the evening I got the MCU up and running, they seem to have appeared and persisted since. They're always in the same place, absolutely rock solid (relative to the video clock), and unchanging in intensity. With the color bar test cart running, there are literally no components on the breadboard running at a per-pixel frequency, (only per-16-pixels)... so it left me scratching my head as to what might be going on. I eventually disconnected everything and just probed the VDP pins directly... and found the exact same ~100mV steady/synchronized noise pattern on all the outputs. So the good news is that the current version of the ELM circuit most-likely outputs perfectly clean video. The bad news is that I think my Colecovision is dying! Hopefully it's unrelated to all this testing. This is definitely the most use this console has seen in 35 years, so I'd like to believe it's just wear/age-related. Diagnostics steps taken since then: this system was overdue for a re-capping, so I removed the RF board and replaced the six or so electrolytics. With the RF board still removed (I worry I'm changing too many variables at once), the noise is down to maybe half the level it was before. I've got a 5V RAM kit from Console5, but I wanted to hold off on that as long as I could so all of this RGB testing was done on a "stock" console. Instead, I ordered a couple replacement 9928A's from eBay. I'll add a socket and try swapping the VDP out. On the RGB front: I was reading this RetroTINK blog post and saw "the LMH1251 even took care of removing the sync signals from the output lines. This is great, because I was about to implement a discrete one..." and then I couldn't help myself. If there is a way to remove the MCU-programming requirement for end users, get rid of the pulses, and something like 80% of the passives in one fell swoop (with no -5V rail required, etc.), it's too good to pass up! I had already soldered an LMH1251 to a little adapter board a couple weeks ago, so I got it on a breadboard last night and connected some things. It doesn't have enough drive to output a 75-ohm video signal and I haven't gotten the THS7374 video amp on the board yet to actually see the output, but from the scope I can see it's doing something that looks vaguely correct. Notes: It neatly holds all three output lines at black during blanking. It does NOT suppress the color burst. 😕 It does all of its work with a 1-2V'ish DC bias. The sync output is split up on this chip for separate H- and V-sync but the V-sync line never changes. I'm guessing that last one is the 480p-minimum support mentioned in the datasheet. That's fine--we need C-sync anyway--so tacking an LM1881 on the board "solves" what is already a non-issue. Besides, we'll need the burst pin to do something like Hackaday's sample-and-hold to eliminate the burst, so it's double-useful. Now I just need to get the video output amp running, confirm the output looks reasonable (presumably with too-much-blue), and then try for the sample-and-hold, applied to B-Y and R-Y during burst, with what I'm hoping can be accomplished with a single mux. Then we'll have a 5th data point. ... I just hope I can fix my console's video output in the meantime.

There are three known solutions, but none of them are perfect. The graphics chip used in the Colecovision and Adam outputs relatively standard component (YPbPr) video with one quirk: during line blanking, it includes a "color burst" signal on the blue line (and also red in the PAL version) that is normally only seen in composite video signals. Presumably this was to make it more convenient for the RF and composite outputs to do their job, but it makes things less convenient for clean RGB out. That color burst signal has a tendency to upset the automatic level detection in modern RGB receivers so that they think blue can go lower than zero, which means black is no longer black. Everything gets a blue cast and generally looks pretty bad. Solution 1: There is an old Texas Instruments application note ("TMS9928/29 and TMS9128/29 Interface to Color Monitors") that shows a circuit that can do RGB out. They admit in the text of the document that they're not focused on accurate color output, which is already one strike against it. Worst of all: it does nothing to solve the "too much blue" problem. Solution 2: Citrus3000psi created ColecoRGB (current at version 1.2), which is a tiny board that can conveniently be soldered right on the back of the graphics chip. It was presumably based on the RGB circuit in the Baby Pac-Man arcade unit, which also uses the same graphics chip. This one solves the "too much blue" problem by throwing the baby out with the bathwater and clipping the bottom of the signal off. Whenever there is a transition from black to another color, that pixel gets mostly cut off, leading to very thin vertical lines and text that is barely legible. The colors aren't great, either. Solution 3: 256byteram released the TMS9929A RGB and Component adapter at Hackaday. This one solves the "too much blue" problem in a more clever way and is generally pretty passable. The color isn't perfect, but the only real downside is that some of the specified components in the circuit have been discontinued and are no longer available. Sample screenshots and lots more information about all of that can be found in the other topic where you posted. We've been testing and building these things over there for a couple months now to try and see each of their strengths and weaknesses. I feel like we're getting close to a 4th solution that would keep all the pros and omit all the cons above. It's a hobby project I've been working on in my evenings, so I couldn't possibly give a proper release date, but I want to say it's less than a month or so out. (I'm going to regret that sentence. )

With most of those colors at 100% output level in at least one channel (which implies clipping, which means it's not a linear function anymore), it'll be a little trickier to reverse. I also wonder if that means we'd need some sort of 1.4V hard clipper/limiter tacked onto the outputs. The alternative would be to play it fast and loose and output out-of-spec signals and hope the TV or whatever can handle it. That's not a great alternative.

Ha! I get to claim victory... sort of. [Popeye through ELM with the new YPbPr color matrix, into the OSSC 1.6's SCART input, captured via the Elgato HD60] That's delightful (save for the hopefully-just-breadboard vertical line artifacts). It looks great on the TV and from the capture card. By playing with the ratios, I was able to find plain, E24 series resistor values for all the op-amps while losing less than 1% accuracy. Even better, the color bar test comes out nearly identical to three different emulators: The top two lines are closer than I could have asked for. I'm not sure why the Framemeister removes the orange from the orangey reds, but it looks like the CoolCV emulator based their palette on something similar. Now for the "sort of" part: Today was also coincidentally the day my long-overdue package finally arrived: the only device I could find that seemed willing to output RF in a different format. That at least got it to VGA and the OSSC took it the rest of the way to HDMI so I could grab a frame from my capture device. This is very different! (Don't mind the artifacts; we're here for the color. The ADC in the tuner didn't do a great job... although, who can blame them when the source is RF?!) [Popeye straight out of the Colecovision's RF jack (through an RF-to-VGA adapter, into the OSSC 1.6, captured via the Elgato HD60)] Super vivid. Super saturated. There's at least one emulator that tries for the same style, but even the "scaled up to full brightness" version doesn't make it very close: (On the TV it wasn't exactly the same as through the capture device, but nearly. At least those first two greens were a little more easily distinguished.) I suppose I understand that "real" RGB necessarily looks differently than the NTSC'ified image on the other end. When I was first learning about RGB and how much nicer it could look than composite, this particular comparison image stood out: Not because of how much sharper the pixels were, but because of how different the colors were. Maybe RF is "wrong" and YPbPr is "right"? Maybe the artists saw the "right" version while they were developing our games and we just had to suffer through the "wrong" output from our TVs? I'd feel a little weird about making that decision for people. So now I'm wondering: it should only take a few hours to try and math-out a different color matrix to try and hit the "RF palette". When all of this finally gets published the right way, it would (hopefully) just be the difference between ~16 alternative resistor values listed in the BOM using the exact same PCB. Maybe it would be worth it to let the user choose which colors they're happier with? What do you guys think? When I look at just how yellow that bright yellow is in the RF color bars, I kind of want to see that in my games.

That will work, thanks! I was trying to think of creative ways to keep the same part count and remembered that one of the muxes was being used equivalently to a 4066B with one channel left over. That last free channel would have done the trick, too, but while comparing the two datasheets just now to see just how similar their characteristics were, it looked like the on-state resistance was an order of magnitude higher on the 4066B and I didn't want to mess around with the (now lovely) video signals any more at this point. A single discrete transistor and an extra resistor will do just fine. (It sounds like that 3k has a lot of wiggle room. I'll pick the next closest existing resistor value to save a line item in the BOM.) That's problem #1 tackled. I spent the rest of my evening doing math. I've now got a new set of resistor values for all the op-amps that checks out perfectly for all 15 colors to output at 0.7V (well, 1.4V) levels in my Excel sheet, in my color simulator app, and in a Falstad simulation of the op-amps themselves. They all agree to four significant digits, but I ran out of time to actually swap them into the breadboard. Tomorrow! In the meantime, I made the most satisfying discovery! I've been bellyaching about YUV vs. YPbPr for pages now. It started from the equations on this page where they list them separately with different coefficients. But! They're also listed with different input ranges. And after a bunch of nonsense in Matlab while comparing the two, when the eventual matrices finally shook out after scaling the VDP's voltages to each input range... they're absolutely identical! So now I can stop worrying about which is "correct". They both are! And I've got one matrix to rule them all. Assuming the live resistors match the triple-checked theoretical numbers, that's problem #2 solved! With any luck, my next post will have beautiful images.

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?

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. 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! 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. 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?) 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?

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

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

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.)

I'm just a layman when it comes to cart authenticity and reproductions... but even to my untrained eye, that looks obviously fake.

It's not much different since last time. 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. 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.

"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.

Here is the first pass on the color simulator: 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

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.

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? The O is for "open", so the schematic is readily available. 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.

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: 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...

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. 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

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: 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?)

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.