Jump to content


New Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

11 Good

About Falonn

  • Rank
    Space Invader

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Well, that's anti-climactic. Last night I had swapped back to the first XR8054 SMT-to-DIP adapter board I'd made for no other reason than because I'd already added the little "U1 & U2" label to the first one. Tonight, in preparation for my anticipated long debugging search (possibly rebuilding the whole board if necessary), I did a quick power-on to make sure things were in their last known state... and this was the result: So, I suppose, lets chalk it up to a flaky breadboard and hopefully it won't crop up again. *sigh* Alright, first off: lots and lots of ringing! Red takes too long to discharge. Green areas begin with too much overshoot. Some of this is probably the breadboard's fault, but I'm going to try the same capacitor trick from the TMS board to see if it can at least mitigate the green problem. As for the good: the colors are (a lot) better than ColecoRGB 1.2 and it doesn't suffer from the awful cut-off pixel problem. Comparing it against the CoolCV emulator screenshot (which I haven't actually validated as having accurate colors), blue is a little dark and green is super bright, almost neon. The difference between the two colors of grass is hard to distinguish because they're both super saturated. Question 1: Does anyone know if there is a nice, reference standard emulator out there that has gone out of their way for good color accuracy? That would help with verification and tuning. I've seen this AA topic, which seems to take the subject pretty seriously, but I'm not sure if that work ever ended up in something I can download. Also last night, while trying to dig into op-amp theory (for the third or fourth time) and trying to figure out the operations for each amp, I got a different answer for U2A's output than your result above, ChildOfCV. It was tough to track down anyone talking about negative feedback going to anything besides ground, but this answer looked promising. With Vi=2.5V (Vref), Ri=2k, Rf=1k, Vp=R-Y, and using their formula, I got: 1.5*R-Y - 1.25V. Although, with an unknown impedance on the R-Y line, I wasn't quite sure how to calculate (using superposition? or the op-amp summing network formula?) what to do with that 10k to Vref. Still, I'm curious how you found that the 1.5x also applies to the negative feedback Vref term? In many topics here (and several times in this one), I've seen people describe the TMS992xA as outputting something like "almost component but with weird scaling and biasing". While digging around some more (last night was research-heavy), after re-reading "in conformance to standard industry practice [we divide by 1.14 and 2.03]" in the TMS doc, I was curious how that was standard. In the Hackaday schematic, he even named the B-Y input line "U". Looking up the YUV color space, it's apparently exactly the same as component (YPbPr, which uses B-Y and R-Y lines) except with those scaling terms. Question 2: Does that mean a more accurate description would be "YUV with a DC bias" and that we should be calling these the U and V lines instead of B-Y and R-Y? (Was that just nomenclature that wasn't in use when the chip was designed? Do they avoid it because YUV seems to also imply half-bandwidth for the U and V channels?) Once we're free to search for "YUV to RGB converter" instead of something much more TMS-specific, there are hundreds of these things all over the place. One of the first results is this delightful project with a wonderful schematic. The op-amp analysis is already done in the margins and it looks like much(!) more care was taken in picking the resistor values than any of these three other known boards. (The schematic continues to go to the trouble of listing the parallel resistor combinations needed to get the exact values required. It's really very nice.) That reminded me of the wording in the TMS doc: "[Our] purpose is to produce a bright, sharp image [...] rather than to produce a very accurate color difference..." And now I'm wondering how much better things could get if our purpose was actually color accuracy! 😉 I haven't studied it in detail yet, but the idea in the (what I'm calling) ELM circuit above appears to be a combination of all the good parts we've seen so far: the same DC restoration idea from the TMS doc (and possibly color burst cleanup at the same time by using an LM1881?!) using a mux the same way as TMS Doc uses the 4066. And then two amp stages like the Hackaday board, which should allow for much better color accuracy (when you actually take the time to pick good resistor values). It does still need a -5V rail which is kind of a bummer, but in doing so, it saves all the complexity of the sample-and-hold for the bias voltage (and makes the analysis almost trivial). I'm tempted to build the ELM circuit as-specified, like the others... but I wonder if just grafting those nice resistor values along with our other lessons learned as we near the final solution wouldn't be more expedient? Now that it's been, what, two months that we've been dissecting these things, I'm starting to feel a tiny bit more confident about what to expect from this repeating pattern of "a little up-front cleanup followed by voltage math".
  2. The meter is showing 740 ohms across the IC pins while in-circuit. The feedback resistor (R11) tested in isolation afterward is exactly 1000 ohm, down to as much precision as my meter has. (I intentionally grabbed a set of 1% tolerance resistors for this project and then hand-picked the closest one from the 20pcs of each value as I went along.)
  3. No way, hehe, it's just the quintessential, entry-level Rigol DS1054Z (with the software stuff unlocked) that you see recommended everywhere as "what's the cheapest scope I should buy?" With nothing at all connected to the Colecovision board (except the scope probes), the R-Y and B-Y pins of my 9928A are showing the exact same range: Popeye game selection screen: Y: 1.8V to 3.16V (black at 2.2V) R-Y: 2.2V to 3.16V (blank at 2.63V) B-Y: 2.2V to 3.16V (blank at 2.63V) Solid white screen (test cart): Y: 1.8V to 3.16V (black at 2.2V) R-Y: 2.6V, always B-Y: 2.3V to 2.63V (blank at 2.63V, burst at 2.3V) It is worth mentioning: the XR8052 amps in the schematic were discontinued the year after the schematic was made. I wasn't able to find any of those in the usual places, but there were still a handful (literally, less than a dozen) of the four-channel XR8054 sister chips left at Digikey. So instead of 3x two-channel amps, I had to build this with U1 and U2 combined into a four-channel chip and U3 on its own with the C and D channels wired as plain unity-gain with a voltage divider feeding around 2.5V into the input (as recommended for unused op-amp channels). As far as I can tell, this has had zero impact, but it's good to clarify. (When you say U2A, it really means something like U1C when I go to find the pin, hehe.) Should we find a way to get this board working, a suitable replacement part for these discontinued ICs will be yet another challenge... As for U2A, here are the traces for about three lines (directly from the IC's pins): - Ch1 (yellow): Burst, pin 5 from LM1881 - Ch2 (cyan😞 U2A output - Ch3 (pink): U2A negative input - Ch4 (dk.blue): U2A positive input Test conditions (in order): - solid "white" (actually fuscia) screen - solid "black" (actually red) screen - Popeye mode select In the meantime, I've also conducted a couple of my own experiments: Experiment #1: Graft the R-Y/B-Y DC Restoration scheme from TMS over to Hackaday It took four or five readings before it finally clicked yesterday, but the scheme in the old TI document is really graceful for making sure the blanking level comes in at 0V. They couple the inputs with a fairly large'ish capacitor, but then during blanking, they open a pair of 4066 switches to ground them. I thought I'd give it a shot to try and get things back in range, so I tacked this onto the beginning of the Hackaday circuit (temporarily; since removed): It actually got pretty close. Instead of going crazy and over-saturating the red almost immediately, it mostly just looked like a red version of the usual "too much blue" we've seen elsewhere, and then around 10 seconds later, it would eventually creep back up to being a mess. Still, an interesting experiment to be sure. Experiment #2: Use the wonderful burst signal from the LM1881 to try and do something in the TMS circuit I had a couple of 4066 channels free on that board already and connecting an LM1881 is trivial, so I wondered what would happen if I just used the 4066 to "shut off" the B-Y and R-Y inputs during the burst interval? That should look like this: Alright, yeah, they're technically floating inputs during the burst, so who knows what you'll get... The answer (at least on my Colecovision) is that the too-much-blue problem is solved(!)... replaced by a tiny-bit-too-much-green problem instead. 😆 I was hoping for a perfectly flat B-Y signal when the 4066 was off during burst. Instead, I got a smoothed-out, slight positive bump for the entire duration. That's fine for blue. Positive doesn't impact the auto-scaling done by the receiver. But when green is calculated by subtracting the B-Y line, you get a slight negative bump. And that does impact the auto-scaling. In any event, this is very close to correct now: (The green is strongest at the top of the screen and fades to black by the bottom. It's much easier to see on the TV. In this capture from my Elgato HD60, you almost need to raise the brightness before you can see the solid green in the background.) I haven't tried it yet, but the next experiment will hopefully be a refinement that should fix this outright: Instead of a 4066 channel that's either on or off, you could use a little SPDT switch (like this one) to switch from B-Y/R-Y (or even the R, G, B outputs themselves) over to, say, a voltage divider between 5V and GND that was set right at the black level. No more floating data. Perfectly flat line (hopefully/in-theory). Thinking about it more, it might even help with the trimmer pot tuning! Since the black level during burst would be forced to 0.3V by the divider network regardless of the pots, there would be a perfect sweet spot (when adjusting the blue pot on an NTSC system) where the (now artificially induced) too-much-blue would fade to black just before switching to too-much-green. You could most-likely tune it by eye instead of needing a scope. Speaking of auto-tuning, the more I think about a circuit without trimmer pots, the more I have my doubts. While re-reading the TMS doc, I ran across their reasoning for DC restoration: "In the case of an RGB encoder, a black screen with dark red letters might appear as a gray screen with pink letters" followed later by "unfortunately, the R-Y and B-Y signals are not guaranteed to have a most negative or positive excursion within any particular period of time" and "the output level of the video display processor can vary from device to device as a function of process, or as a function of temperature". It makes me wonder if the Hackaday circuit wasn't designed for his particular chip and mine is just a "fussier" one? At any rate, those three statements taken together make me wonder if any sort of auto- or preset-scaling might be a lost cause? What works for one board probably won't on another, right? (That may even be what we're seeing here already.) As-is, I already had to remove the 82-ohm pull-down/divider from the sync output (R25) on the Hackaday board before it would even sync on my Framemeister. And the output is AC-coupled, which is contentious at best. (The TL;DR; for that page is "they probably shouldn't be; TVs are pretty forgiving; and in some extreme cases you may even have to!") So I'm leaning even more heavily toward "TMS Doc with half the discrete parts replaced by an LM1881 plus something to filter out the color bursts" as being the most promising path. I ordered some of those little SPDT switches to try next. (We'll see when/if they arrive...)
  4. My first sanity check (before spotting your post) was to swap out all the ICs with spares, just in case I'd destroyed one with ESD or when soldering the small ones to the adapter boards. No effect / identical results. Now, following along with your description: 1) Yes, this is very clear coming off pin 1 of LM1881. About 150mV when active, 3.3V otherwise. 2 & 3) Yes, testing the net between U4A and U4D (pin 2 of the 4066), it's essentially the inverse of sync: 4.8V when active, 650mV otherwise. 4 & 5) As B-Y hasn't been DC-restored at this point, (on an all-white screen,) it's always 2.65V, except during the burst period when it's 2.3V. The sample/hold seems to be working correctly as the positive input to U6 shows a flat 2.65V at all times. U6's positive input might as well be a perfectly flat line. The output (Vref, in pink) is similar, but not quite as clean: Yellow is pin 1 of the LM1881. 1) Yep, the burst output (LM1881 pin 5, in pink) neatly covers the full duration of the color burst on the B-Y line (in blue). 2) The negative input of U2A is exactly Vref. Zoomed way in, the traces overlay exactly. Comparing this to the other circuits where the B-Y color burst was at or dipping just below 0V, it's a little strange that it's hanging out around 2.3V, here. Is there a missing DC restoration step? Would DC restoration fix this?
  5. Yeah, as soon as I saw the initial red cast on the TV, I shut everything off and switched back to one of the other boards to make sure I hadn't somehow damaged the Colecovision. (I hadn't.) Next is a meticulous confirmation that each op-amp channel is still working correctly. Here's the family portrait, now that they're all complete: Looking at the Hackaday schematic a little more, is it really the sample-and-hold (with the TL081) that's cleaning up the color burst? From the looks of it, that's just doing the auto-scaling (so it doesn't need any trim pots). Isn't it the pair of 4066 channels being controlled by "burst" (pin 5) of the LM1881 that actually does the cleaning up? If that's all it takes, it should be easy to port just that piece of it over to the TMS circuit. (There are even two unused 4066 channels left on that board, so it wouldn't take any additional chips. And adding an LM1881 means dropping like half the part count from the TMS circuit. hehe.) Still, I would have liked fully automatic scaling. Hopefully I'll be able to suss out what's going wrong here...
  6. Good news and bad news for the Hackaday circuit. The good: it does appear to suppress the blue color burst correctly. The bad: something is very wrong in the red channel. The output level is way up in the 4V range. I've done an initial pass at double-checking all the components are where they need to be (and doing a few sanity checks with the scope), but didn't spot any obvious mistakes. I confirm each resistor value with a meter before it even makes it to the breadboard, so that shouldn't be the problem. Just tinkering around---knowing this circuit doesn't use split rail op-amps, so this probably wouldn't work---I added the same 10uF coupling caps used in the TMS circuit to the B-Y and R-Y inputs. The result was interesting to look at, but not much better. Here (at 4 seconds), I press the reset button and we get to watch the caps charging in real-time: It's curious that the same isn't true of the blue output. They're nearly symmetrical in the schematic. I'll poke around tonight to check for mistakes again. If anyone has suggestions on what to check, I'd love to hear them! (Unless there are more electrical differences between the 28A and 29A than I know about, we've already seen this circuit work on a PAL Colecovision a few pages back, so this is most-likely my fault.) I am heartened by the blue color burst being removed, at least. We're nearly at the point of grabbing the best pieces from each circuit and creating some Frankenstein's monster that actually works.
  7. "d.c. component" makes it sound like just the bias with the 0.7V on top of that. And yes, having an official source is awesome. I'd also been looking for something like this. Thanks!
  8. FWIW, I spotted this TI blog post while learning about the overshoot/ringing problem on the TMS board. They suggested adjusting the cap in the negative feedback network. As it turns out, one of the very few, small substitutions I had to make while constructing these was using 4.7pF instead of 5pF in those places. I didn't have any 5pF caps. The next size up in my parts bin was 15pF. Swapping each 4.7 out for 15 on the R and B amps eliminated the overshoot in those channels. The green channel still has a little, and 15pF was either too much or too little, but this gives me hope that the problem is just coming down to parasitic capacitance from the breadboard and the wires flying all over the place. Now the (still too-blue) picture from the TMS Doc board looks even more lovely!
  9. I'm afraid it might be your fate to remind me that it can't generate negative voltages, forever. 😅 A find-and-replace for "0V" to "black level" is almost certainly what I keep intending despite continually mistaking "sync level = -0.3V" when I (probably) mean "sync level = black level - 0.3V... with black=0.3V". Sorry for the continued source of misinformation. Are the voltages that you mentioned ("+B is about 3V", "Yellow is ~2V", etc.) referring to what's coming from the graphics chip on the B-Y line (maybe after correcting with the scaling and +Y)? Or did you mean the B in the final RGB output? For the latter, wouldn't there need to be some voltage on the R and G lines to make yellow? All of my discussion above was for the B output at the end of the RGB conversion, so we may have been talking about two different things. Sorry again for the confusion!
  10. Hmm, I hadn't noticed it before, but in doing these back-and-forth comparisons between those images, it looks like the TMS Doc version actually has a little bit of overshoot on all of those first pixels. (You can see it best on the left edge of each staircase where it's a little brighter than the rest.) Initially I had chalked up these sorts of artifacts to having all of this built on a solderless breadboard with long wires running all over the place. I wonder how much some final, tiny, actually-soldered board will clean any of this up?
  11. As an aside: isn't that extra 100Ω in series with the B & R outputs technically causing an impedance mismatch for video signals? If it's really necessary for the LM359's operation in this case, wouldn't the outputs need to run through something like a unity-gain buffer and then 75Ω to be properly matched and avoid reflections, etc.?
  12. Aren't the negative voltages only ever used for non-color communication? The color values themselves are always positive, right? The impression I've gotten (at least for the Framemeister; I can't speak to how the OSSC or RGB monitors do things) is that the R, G, and B lines are assumed to have no negative voltages. Then, 0V (or black) is taken to be the smallest value ever seen across all three color channels (within some reasonable time window, maybe once per-frame?) and the peak saturation level for any/all color channels is the largest value ever seen across all three. (This why you want them to use the same 1V'ish pk-pk scale. Raising one to a new max changes the scaling on the other two.) It's this "color burst is below 0V" that causes the blue cast in the TMS Doc circuit. By chopping it out here (and apparently clamping the output to 0V), the auto-scaling procedure done by the Framemeister seems to be handling everything normally. The yellows are yellow. Something else is being sacrificed in the process though. I dredged out my Elgato HD60 capture box this morning so now we don't have to rely on awful phone pictures. To really see the difference between these, view them full screen and switch back and forth using an image previewer that doesn't flicker or animate between images. TMS: Raw 1080p capture from the "TMS Doc" board that includes the blue cast. TMS-adjusted: I used an image editing app to artificially remove the blue cast (to make comparisons a little easier). CRGB: Raw 1080p capture from the "ColecoRGB 1.2" board that shows the really stark, thin single-pixel columns. CoolCV-scaled: My best attempt in an image editor to get the emulator screenshot to align with the others. CoolCV: The source, unscaled screenshot from the emulator. Just for completeness. Switching back and forth between "TMS-adjusted" and "CRGB" shows just how bad that missing leading-edge of pixels looks in the ColecoRGB 1.2 circuit! Sure it's crisp, bright, and whites are actually white... but the picture quality is awful. Again, the "1UP" at the top-left is probably the most striking difference.
  13. Almost certain to find the same (or worse) results as last time, I decided to get the ColecoRGB ("NTSC") 1.2 build out of the way quickly (since it was the smallest one) before moving onto the most promising Hackaday circuit. So, I was surprised when I got everything built and was greeted with a perfectly clean blue signal! Some tinkering with the pots and I think I can see why this one has caused some trouble for people. At least for the resistor values specified, adjusting the green pot through it's full range, I was only able to get the pk-pk voltage to go from 1.0V to 1.3V. So there's room for improvement there. (I haven't tried swapping it around yet, but looking at the schematic, the green output isn't symmetrical with B & R in terms of going through that extra 100Ω (R19), which I recall seeing in the LM359's datasheet. Instead it's in series with 3.9kΩ (R20), which is almost certainly a mistake... why bother; just use 4kΩ instead or omit it entirely.) All of that said, the most interesting bit of behavior I've spotted in the first 30 minutes of playing with it is what happens when you sweep through the full range of the blue pot: The bad stuff is apparently still there hiding in the cracks, but the LM359 is performing some magic to clean it up until you get past a certain threshold. Comparing this to the TMS Doc images above, it also appears to be doing the same to the (yellow) sync line. Those two transient spikes on either side of the H-sync pulse are where the black levels were before. How interesting! I suspect this "tune it to just before the saturation point but no farther" is rather brittle and dependent on temperature, age, and how the graphics chip is feeling that day. I feel like the verdict is "this can mostly work, but takes a lot of care and feeding." This is subtle, but while testing with Popeye, I noticed that single-pixel columns seem to be too narrow (presumably by not swinging back to 1V fast enough?): Left is a terrible cellphone image of my LCD TV's screen. Right is from an emulator. The too-narrow problem is even more pronounced when it's not white. Depending on the pot tuning, the pink "1UP" at the top left of the screen just looked like a handful of scattered pixels because all the 1px wide parts were essentially invisible. I don't remember this happening with the TMS Doc circuit, so I'll have to make a note to go back and check. There is a chance that this is an artifact being produced by the Framemeister's up-scaling, but something about the output from this board just feels "clipped" compared to last time. Maybe I've just forgotten over the past two weeks or maybe the implacable blue cast was able to hide this particular artifact? I'll collect more data when it's not 2 AM. In the meantime, same as before: please let me know if anyone is curious about a certain net and would like me to poke around with the scope and post images. I don't know if I'll bother trying to swap that 100Ω resistor around on the green output before jumping right into the third and final build: 256byteram's Hackaday circuit!
  14. Hmm, I wonder if the Hackaday circuit is doing this correctly? It goes through two op amp stages for each channel, so it definitely has more breathing room as far as number of available operations is concerned. I tinkered with the op amp-based limiting/clipping recipe I'd mentioned back in post #284, but it looked like it was around two orders of magnitude too slow to work at these kinds of frequencies. Rather than go down that rabbit hole any farther, I think I'll press on and start the next build. I did want to be exhaustive, but I wonder how valuable it is to spend time on the "NTSC" ColecoRGB 1.2, since the method is the same as this one minus half of the useful bits? It's simple enough that it would be a quick build, but maybe jumping right to the Hackaday circuit is a better idea...
  15. Here are the inputs (Y, B-Y, R-Y, and the output Sync to compare it to) for a solid white screen, during H-blank: Using the scope to add Y and B-Y together (without any of the "correction factor" mentioned in the document), that looks like a proper black level: Comparing that to the actual Blue output at the bottom, the scope's math channel looks more correct. I wonder if the circuit's order of operations isn't backwards? Maybe they're doing the 2x first and the addition second? That would magnify the little bump and cause what we're seeing on the Blue output line. If you reverse the order, doing the addition first (like the purple Y + B-Y trace) and then do the 2x afterward, you'd get something closer to the correct answer without the below-0V pulse. Hmm. You guys are probably right. I was focused on fixing this circuit's problems. It might be a more effective use of time to jump right to the more promising circuit instead. I don't know about heavy lifting, hehe. You guys (and the 11 pages of posts before this one) have done a lot more than I have! That said, if any of this does turn into a finished "product", I don't have any plans to produce physical things. I've always wanted to do something like that, but I've got two kids under five years old and I already run my own other thing so it would be doing a disservice to the community to make them wait around until I could find the time to manufacture the next batch or whatever. I like OSH-style projects: schematics/project files/BOMs/gerbers/etc. publicly available for the enterprising DIY'er but still plenty of room left for modder-types to provide a service on top of that (whether it be assembling/distributing kits or doing full installs). Seeing page after page of requests for a DIY kit get shot down by Yurkie made me a little sad. If we can put something together that solves all the known problems, then, if I have any say over it, I'd like to make sure everyone in the community has ready, permanent access to it. That seems the most fair to me since whatever final version is going to be 95% based off already-public schematics. Outside of a little elbow grease, I'm not sure I'm actually contributing much, hehe. Besides, all of this is counting our chickens before they hatch! 😀
  • Create New...