Falonn

May 29, 2020

18 hours ago, MrPix said:

I just received the latest design from Falonn, and it's good enough that I have decided to assemble his board instead of re-implementing it in 4 layers. He's done a spectacular job of managing signal quality in two layers, and brought his A game on the ground and power fills - so I feel confident his 2-layer design would perform as well as any 4-layer design. We're just in final clean up and optimisation now. Crossing the I's and dotting the T's

MrPix is a sorcerer! Even though I'm the only one that has technically drawn a trace on this thing, I'm not sure how many dozens of suggestions it takes before someone deserves co-author credit. Whatever the number, we're well past it on this board! I can't believe how much his help has improved the electrical characteristics of this thing without fundamentally changing the schematic.

13 hours ago, emmanuelf said:

To be sure, what I've had in mind was to put the dividers before the MAX4395, with same ratio but higher values, not adding a resistor.

Sorry, when you asked this a few weeks ago I thought I had answered it. Some of the questions are covered in the initial post, but here is the summary:

The reason for adding the MAX4395 in the first place was to solve all the bad things that happen when you put the dividers "before the AOP".

High value resistors (anywhere): color smear.

Low value resistors: higher current (but perfect output).

The VDP is already loaded pretty heavily, as per the datasheet:

I couldn't find any per-pin current ratings in the datasheet, but taxing the 40 year old chip any more feels like a bad idea. If you put things after the mux, any amount of current going through it makes the transitions really spiky. I bet it wouldn't be as bad on a PCB, but then the mux's own channel resistance also throws the divider math off. We already needed an op-amp for the sample-and-hold, so changing an 8-pin IC to 14-pin to gain another three channels solves everything outright. It is a good answer with almost no trade-offs.

I just need to find a minute to confirm slightly higher (2-3x, still around 1k) resistor values don't have an adverse effect (while maybe getting lucky and consolidating another BOM line at the same time) and we should be all set.

May 27, 2020

The good news: the v1 PCBs arrived today, I built one, tested it on my also-just-built 3D printed pogo-pin jig, and it worked beautifully. That confirms I at least copied my hand-drawn schematic into Eagle correctly, hehe.

TSSOP is not for the faint of heart or shaky of hand. Sheesh. (Also: check out that solder ball on C11!)

Everything looked great on the Framemeister and OSSC. The subtle overshoot was improved, making the L9 bypass even more optional (though still a readily visible improvement).

The bad news: Those through-holes are way too small to actually install on the back of the Colecovision board. In the best case (the VDP's pins aren't bent at all), it can fit over them, but the standard "Prototype"/"Super Swift" stackup from OSHPark is still 1.6mm thick, which completely covers the remaining pin stick-out, so it'd be extra tricky getting solder down there.

So, the next step---sending a few out to installers with way more Colecovision revisions to test against than I have access to---is going to have to wait on another run of boards, unfortunately.

The silver lining: this means the fifty or so small improvements that MrPix suggested will also make it into the wider testing. v2 will have bigger holes and I'll try the "2oz-0.8mm" OSHPark stackup this time which cuts the board thickness in half. That should let the VDP pins stick through a little farther, too. Waiting on those also gives me a little bit of time to get a few more parts here. It occurred to me that I don't have any zero-ohm SMD "jumper" resistors (in any size), so I wouldn't have been able to build any test boards in the Genesis 2 configuration without resorting to "little bits of loose wire wedged into solder paste"-style methods. And now I'll have the time to test 2x higher value resistors on those divider networks to drop the current a little bit more (while still avoiding color smearing).

So... same time, same place in two weeks, I guess. Sorry for the wait, everyone! 😕

(Coming from a software background, all this waiting for fabrication and shipping is maddening. I'm used to pressing a button and seeing my changes immediately.)

May 27, 2020

12 hours ago, Ikrananka said:

... the wheel turning the pipes at the top of the screen was actually supposed to be a circle and not the ellipse I had seen on my UK ColecoVision all those years ago.

Oh, wow, I had always assumed PAL TVs knew how to deal with the extra lines to maintain the aspect ratio. Thinking about it again, I suppose it would have taken effort on the Carnival game developer's part to check the region flag and draw things differently. Hmm. I know about the other lack-of-developer-effort differences (usually stemming from 50Hz vs. 60Hz) like different gameplay or music speed. While trying to reverse this composite mod install, I saw this Tarzan gameplay on a PAL system and the music sounded like the game was running in slow motion to me!

9 hours ago, MrPix said:

I suspected PAL would work outright due to the suppression of the color burst...

I did too, but there's nothing like seeing it with your own eyes! That was easily worth buying, shipping, and repairing the system.

9 hours ago, MrPix said:

The real variance comes in the conversion to UHF...

This caught me by surprise. I've got a little TV tuner box that is supposed to be able to do NTSC and PAL. I was hoping to use it to confirm the system was back to a working state before moving forward with my own experiments. I was disappointed at first because the channel auto-scan didn't seem to find anything in the 50 to 70MHz range where I was expecting PAL channels 3 or 4. (Even though the "Ch. 3/4" trace on the RF box had obviously never had solder in the through-hole and the channel switch at the back of the case wasn't populated.)

I gave up with the tuner remote and turned back to the bench to start double-checking all my connections. A few minutes later, the static snow sound stopped on its own. I looked over and saw (horribly disfigured) color bars from my test cart! It had searched all the way up to 510'ish MHz but eventually found it. I didn't realize the PAL version of the CV used UHF.

9 hours ago, MrPix said:

That said, there may be small differences between the B-Y and R-Y signals on the 9928 and 9929...

The datasheet says there are. Try the top-left drop-down box in my TMS992xA color simulator.

Copy this and then click "Load from Clipboard" first to get reasonable colors:

Transform:1.695 2.03 1.14 1 -0.1864 -0.5085 1
Output:Framemeister

It seems like a really big difference on the "Color Bars" test image. But when going back and forth while comparing the others, it's not so jarring. Everything is definitely more pink than red in PAL though.

In all my digging, I didn't see any PAL-specific YPbPr conversion matrices, so was this just a conscious choice TI made to handle the gamma difference (that I think I've read about?) in PAL TVs? In the datasheet it's a non-linear transformation between the two. Only some of the colors have been modified, so the best we could do with resistor changes is approximate things while making the unchanged colors "incorrect".

9 hours ago, MrPix said:

... have you measured the current being sunk by those resistor dividers?

Nope, but the Y line is the lowest resistance of the bunch and the math says that a solid white screen would draw 4.6mA in the worst case (minus the lower draw during blanking)... if the circuit were DC-restored at that point, but it's not anymore like it was in ELM. 😬 Hmm. With the 2'ish volt DC bias, that's less great.

9 hours ago, MrPix said:

You could multiply those resistances up to reduce current to ground, as 150 ohms is quite low and it will cause a little additional heating in U3. Every little bit helps.

Every little bit of picture quality helps! hehe. I had tried the resistors in the 15k range but was already seeing some pretty bad color smearing. So two orders of magnitude bigger is too much. 2x would probably be safe. Realizing those lines aren't 1V just now, I might try that. Although, the thermal image of the amp doesn't have me very worried. We're still way inside the device ratings... but ~25mA total across all three channels average feels more wasteful than the ~4mA I had initially estimated. That's explains the difference in overall current measurement a little better in the thermal image post. The amp would consume about 15% of the circuit's overall power instead of the 2% I thought it was. Hmm.

May 26, 2020

PAL compatibility confirmed! Notice it's squashed vertically a little through the Framemeister because of PAL's extra hundred or so lines.

Same breadboard, same connections, same everything. TMS-RGB works across NTSC and PAL with zero changes!

It took some work getting the PAL CV back up and running. There was a mostly-installed-but-incorrectly-working composite mod that I had to strip back out and restore to original condition. Then, it just took tapping the five pins right off the VDP and the picture you see above worked immediately. I fear there are more things wrong with this PAL unit---the controller was completely unresponsive and it seems like the '2' button is being held constantly---but that's not what we're here to test! 🤣

I'll take a closer look with the scope when I get a chance to make sure that things like the color burst lasts as long as the LM1881 is set to expect, etc.

But this was too exciting of a result not to share immediately!

May 21, 2020

25 minutes ago, MrPix said:

I do have a library logic for separating CSYNCH into HSYNCH and VSYNCH. If there is a lot of demand for this, I can incorporate it. It's a 50c part.

In theory, the LMH1251 provides H- and V-sync out of the box... but when I checked the V-sync line once a couple of weeks ago (out of curiosity when I first got it up and running), I saw nothing at all. The chip is spec'd for 480p minimum, so I wonder if we're technically using it out of spec as far as the sync lines are concerned. I vaguely recall the H-sync line was fine though. Combined with the LM1881's usable V-sync signal and we might have something that could work as-is. There'll probably be some slight timing differences between the two, but I can't imagine it would break anything. (I haven't tested it though.)

2 minutes ago, videofx said:

No problem. Just let me know what 8pin din to scart cable I need and that will work Thanks!

It's usually this one or the Retro Gaming Cables cable that H454 just mentioned.

This circuit also trivially works with "Genesis 2" 9-pin mini-DIN just by replacing the three 75-ohm output resistors with 0-ohm jumpers and using the TTL C-sync output pad instead of the 75-ohm C-sync output pad. I was just able to finally test this yesterday.

May 21, 2020

1 minute ago, videofx said:

I want to connect it VGA to my OSSC then HDMI out

You may have better luck with the 8-pin mini-DIN to SCART (and then to HDMI) option for output then. That's how I've been testing it with the OSSC and it works well.

VGA requires separate H-sync and V-sync signals (vs. C-sync which combines both and is used in this circuit), which I haven't done any testing against.

May 21, 2020

1 hour ago, MrPix said:

I'm looking forward to revision 0.2 (since this is still very beta... Isn't it? Or is it?

Yep. The first batch is just to make sure the circuit still turns over and that I didn't make any major mistakes in the schematic. Assuming it works as well as the breadboard version, I was planning to send a couple out to people that have more Colecovisions to test against than I do (like Ruggers Customs) so we can find out if it still works on fussy systems.

But since your PM'd design review, there'll definitely be a version 2 with, like, fifty small improvements. That was a whole lot of awesome information, thanks again!

May 21, 2020

4 hours ago, ChildOfCv said:

And just posted on the EEVBLOG channel...

I am happy to see a few things called out there that I just sort of did intuitively. There isn't much room for value consolidation when there are so few values, but getting two uses out of the 150ohm and 910ohm resistors was a conscious choice while designing the various dividers. ☺️

3 hours ago, MrPix said:

I also will change the board shape to reduce hole count...

I had considered a kind of hourglass shape with some of the unused holes removed, but for my target (one-off, artisanal, hand-made boards by adventurous hobbyists 😉 ), they'll always be using a prototyping PCB service, which I've only ever seen charge for axis-aligned bounding-box area (vs. drill count, etc.).

After seeing cracked-off through-holes on the ColecoRGB board more than once, just keeping the board whole (even if that means an extra 15 holes) seemed like a fair trade-off for strength. Remember that most of these installs will be done by inexperienced hobbyists that have too-large tips on their too-low wattage irons and few (if any) of the usual tools needed for small things.

3 hours ago, MrPix said:

... and minimize layer changes to reduce via count...

Planarity was a constant preoccupation of mine during layout (to the detriment of many other things 😅 ), so I would be very interested in seeing a board with fewer vias.

Outside of a bit of tangle between U1 through U3 along with routing hard-to-reach power in a couple cases, there are no layer changes. 🤣

May 20, 2020

1 hour ago, ChildOfCv said:

You should see the metric 0402's that I accidentally ordered once.

It scares me a little each time I see that the metric size designations start matching the Imperial list at those smallest sizes. I am sure I'm going to make the same mistake one day. (Looking at the comparison chart, metric 0402's are specks of dust!) 😬

May 19, 2020

18 minutes ago, MrPix said:

I never have crazy shipping rates.

I didn't mean you would intentionally choose crazy rates, hehe. I've just heard horror stories about, like, $60 to send a 1oz padded envelope to Australia. All I was trying to do was illustrate how tiny the "I should make it myself" slice on the Venn diagram is going to be. 🤣

22 minutes ago, MrPix said:

The components all fit into a half inch band. 13mm. The parts and board are *tiny*.

You're not kidding! I'm a little anxious about having to do my first test boards by hand. I have some cut tape with a few hundred 0603 caps here; I removed one to show my 4-year-old and now that it's back in the bag, my brain still registers it as a speck of dust before I recall it's actually a circuit component. 😅

May 19, 2020

2 hours ago, pokemontrainer said:

Really cool to see this progress! 👏 I will take 2 (1 PAL and 1 NTSC) as well!

With any luck, the same board should be PAL and NTSC compatible (simultaneously). I just took delivery of a PAL Colecovision this afternoon. It's in a slight state of disrepair (with a previously-failed RGB mod install), but assuming it's not too hard to get back up and running, we'll have a more definitive answer on compatibility than "should be". That's on my mini-project list (along with testing the Genesis 2 cable configuration) while waiting for the first batch of test boards to arrive next week.

2 hours ago, MrPix said:

It will only be available fully assembled - sorry kit makers...

For the adventurous: you'll still be able to order a blank PCB from places like OSHPark and get the pieces separately from any of the usual distributors (all that information will be neatly detailed on the upcoming project info page). That said, in the quantities that MrPix is talking about, it will probably end up cheaper to buy an assembled board than to try and make one yourself!

The rare case where it might make any sense at all is if you live someplace very different than MrPix that has crazy shipping rates. If the components are available locally and are less than the difference in shipping and you've already got the tools to do the assembly and you've got good eyesight and fine motor control... well, making one yourself might be the right answer. But that's a lot of "ands". 🤣

May 19, 2020

For anyone that might be interested in working with adam1977 in the future: this transaction was an absolute delight. Adam was super responsive, made every step of the process easy and clear, and was friendly above all else.

I just received a PAL Colecovision safely, in a well-packed box from a third of the way around the world in less than a week.

Thanks again!

May 17, 2020

I think this is everything (see attached PDF for a zoomable/printable/etc. copy):

At least, I hope it's everything... because here is a board layout that I've already ordered from OSHPark & OSH Stencils for testing. 😅

The density there is a little crazy for hand-assembly. The labels on the passives just to the right of U3 & U4 suffered a little, but otherwise it should be legible everywhere else.

Once they arrive, we'll see how impossible it is to drop all these things in place with SMD tweezers. Assuming everything goes smoothly and the board actually works, I'll open/share the OSHPark project as a public link. The GitHub repo has the Eagle files so far. Otherwise the information page just a stub until I get the boards in hand for installation photos and whatnot.

In other news, my broken PAL Colecovision should be delivered in the next few days, so (with any luck) we'll be able to get a PAL-compatibility data point pretty soon.

tms-rgb-v1.pdf

May 15, 2020

It's a lot of stuff! I think I can do it without going down to 0402. 😅

May 15, 2020

Alright, that's that. The little SPST switch arrived. After some bumbling, I was able to get Y routed through the same mux for propagation matching. The result is very slightly sharper now that all three channels are ~8ns closer to perfectly synchronized. Really, it's challenging to see the effect---even zoomed way in using an image editor. In a pinch, we could probably leave that IC out and just use the 3rd mux channel for the sample and hold. It's only $0.20 in reasonable quantities and not much more board space than an 0805, so I'll leave it in my version for completeness. But it's worth mentioning that there is a cost/size-reduced version of this circuit that could omit it without much quality loss.

Here's the final breadboard prototype screenshot (with L9 on the CV board bypassed):

Now it's time to draw up and release a proper schematic! I got a head-start on it (really, I'm almost finished) while waiting for the SPST switch to get here. That's next with the board layout following shortly afterward.

May 12, 2020

You mentioned that you'd paid in pounds, which makes me wonder if it's a PAL ColecoVision (with the TMS9929A graphics chip instead of the '28A). If it is, I've been interested in getting a hold of a PAL ColecoVision board for a while.

We're developing a new RGB mod over here with the intent of solving all the known issues in the other ones. The final mod should technically be PAL and NTSC compatible simultaneously, but I'd like to test it and see the results with my own eyes (and oscilloscope).

I'm sure international shipping costs will be an unmitigated disaster, but that's a price I'm willing to pay to have one of these on the workbench in person.

So... if you're sure it's got a '29A graphics chip, I'm your buyer!

May 11, 2020

2 hours ago, MrPix said:

... it seems the clock goes to pieces...

Sorry! Those slight line shifts are just an artifact from the capture device that are always present in random parts of the image. They don't show up on the TV and if you capture a frame ten times, they'll always be in ten different places. I should have spent more time trying to get the "stable" part to appear in the place I was zooming into. That shift is not representative of bypassing the inductor. If anything, it's more likely to be caused by building all this on breadboards, but those artifacts have been present for the whole two month process now across all five prototypes.

I'm going to try a different method (frame grabs from a video instead of the screenshot feature from the capture device's app, which is frustrating because it outputs relatively low-quality jpeg without any knobs to adjust it) and average several frames together. I'm planning a fairly comprehensive installation instructions page to go along with the open source files, and having a nice, animated GIF-style comparison of several games showing the results of this optional step will be a nice addition. I'll try to control for that unrelated effect a little better.

Something like this. Here's a two frame animated PNG (or APNG), which is supported in most browsers.

The slight shift in the pixels occurs because the inductor also caused a tiny phase shift on Y, which you can see if you alternate between that pair of scope shots in my previous post. Without it, the channels are better synchronized. (This will be improved again when Y also goes through the mux.)

Overall it's subtle, but it's a definite improvement!

3 hours ago, emmanuelf said:

Or replace it by a ferrite bead.

That would probably work, too. Although, if inductance was the cause of the problem, I'd be hesitant to add even trace amounts with something else. I read the schematic as "we need a filter but can only afford to add a single passive; let's go with 32mH". Now that it'll be replaced with the fancy, active, "6th order", etc. filter in the THS7374, a plain jumper is probably as good as anything.

I also suspect that "short piece of wire" will be better than "pair of tweezers in parallel with L9"!

May 11, 2020

L9 on the CV motherboard is responsible for the overshoot on Y!

Typical Y signal (showing color bars) on a Rev.H2 Colecovision

Y with L9 bypassed (using my tweezers)

There is a little more noise (which is presumably why L9 was there in the first place), but it's nothing the LPF on the THS7374 can't take care of.

The results are immediately visible when you zoom way in:

Bypassing L9 might be a new, optional step during the install of something like this. I know I'm going to do it on my system when the time comes, hehe.

May 10, 2020

If you meant the overshoot I mentioned in section 5, you can actually see it on the TV screen (just barely). And it only shows up on the Y line (and not B-Y or R-Y) on the scope, so I'm pretty sure it's really there. The real question is whether it's always present on all CVs and where it comes from (e.g., something on the CV board or is it inherent to the VDP)?

I'm not too worried about it because it's nearly invisible, but I figure if we're already going to this much effort, what's a little more?

May 10, 2020

Small update for the past three evenings:

1. The "absolute maximum rating" output current of LM1881's pin 1 is 5mA... but the most you can usefully get out of it is apparently much lower. I wanted the TTL-sync output (post Schmitt trigger) to be as clean as possible, so I tried tapping the little divider network (to get things down to SCART-level for the 75Ω sync) right off the LM1881. I was seeing some weird droop right on pin 1, even when the total divider impedance was around 7kΩ. It was only semi-passable once it was closer to 300kΩ, but at that point the distortion on the output of the divider makes it pretty useless.

Checking the "Electrical Characteristics" table in the datasheet revealed that pin 1 will already drop to 3.6V with 1.6mA on it, and will even reach as low as 4.5V with a paltry 40uA being sourced from it! They really intended that to be a logic-only output that is buffered elsewhere!

So... divider after the Schmitt trigger it is! Users will only realistically be using one kind of sync anyway, so if someone wants TTL, we could put a recommendation in the BOM to leave the divider out and simply ground Ch.4 of the THS7374 so it isn't left floating.

2. The edge speed on these Schmitt triggers is crazy fast. They easily push the limits of trying to do all of this on a breadboard farther than any other step in this process. With only a couple inches of wire, I'm seeing 2V of overshoot (on a 5V signal) on the scope! This is one of those things I'm just going to have to cross my fingers in the hopes that a properly laid out PCB will fix.

3. Speaking of edge speeds, I had thought squaring the output of the LM1881 burst pin was just sort of a "nice to have" because the tiny Schmitt trigger happened to have two circuits and I only needed one at the time. But, looking at the timing diagram in the mux datasheet, the burst pin's transition speed was just out of spec. Now it isn't.

4. The LM1251 uses more power than I would have expected. I happened to brush it with my finger during testing and noticed it was... warm. Just for fun (and because I have no legitimate reason to own one of these things, so I try to make an excuse to use it any chance I get) here is a thermal shot of the breadboard (from before I switched back to the THS7374):

Checking with my meter, measuring through the 5V pin coming from the CV to the breadboard, I saw 140mA with the color bars test cart and 131mA at the Popeye level select screen. The LMH1251 datasheet says it's responsible for 70mA of that and judging from the picture, I'd believe it! hehe.

In a back-of-the-VDP installation, I wonder if it'd be a good idea to add a tiny chunk of heatsink to the LMH1251, just tall enough to make it contact the rear RF shield? That would give it a ton of surface area to dissipate heat.

5. Of course I ordered an NO switch from Digikey instead of the NC needed for the sample-and-hold (during logic-low h-sync). New parts on the way... again.

That said, I measured the actual propagation delay through the mux and it was only 3-4ns, so this extra switch might be a little superfluous. I mean, every little bit helps, but is that 4ns worth the extra $0.25 and board space? I'm not sure. It does make me wonder where the other 10ns is coming from though.

I've had my doubts about L9 on the CV board. I might try bridging it to see if there is any effect on the Y-only overshoot I've been seeing this whole time or if it has any impact on this slight phase offset.

May 8, 2020

2 hours ago, SearsRoebuck said:

... is there a chance this could help with a (true) s-video out for the CV? With my setup, S-video is the best I can do, and even with a (very nice) composite modded cv, there is still some blurriness on some games with small text.

Yeah, going from composite (1 signal) to S-video (2 signals) will leave some of the image irretrievable. RGBS (4 signals) or RGBHV (5 signals) are the best case where everything is completely split out already, which makes them a nice "mother" format for converting back down to fewer wires.

I'll answer your question with a strong "in theory it's possible". You could add something like the AD725 near the end of the circuit, which would give nice, clean composite and S-video outputs in addition to RGB. Judging from the datasheet, it looks like it'd be a relatively straightforward integration. But the chip by itself (in single quantities) costs $11. The small constellation of components that it needs (in single quantities) would add a few more dollars on top of that. With a larger PCB and more output jacks, you'll be getting close to $20 more. All to go "backwards" to lower quality outputs.

There is still a pretty big disparity between that and the $95 for the 2X-SCART from RetroTINK---which is the lowest-cost, "real" RGB-to-HDMI converter that I know about---but it's definitely worth considering. HDMI isn't going anywhere for the next 10 years, but I haven't seen S-video on a new TV in about as long.

These sorts of "I know it makes sense in your situation but it doesn't for everyone else, so I'm not going to do it" answers are the worst! So, I'd like to apologize that this initial reference board won't be able to solve the problem for you. I suppose the good news is that the schematic and other files will be completely open so anyone else could come along and add their own new features. As a hobby project, this has begun to consume most of my time (at the expense of my work, even ), so I'm excited to see it barreling toward its conclusion. I would be happy to see others follow along afterwards to make different variations like one that had a proper S-video output.

May 7, 2020

Is there a way the game could instruct the TMS to output an off-violet? That isn't one of the colors in the palette and the artifact already looks different at the left side than it does the right side (hence the slight downhill angle on the R line in that scope trace).

You're right that a custom program is the right answer to fully characterize the problem. Then we could check the transition between black and each color instead of just that bright blue.

May 7, 2020

22 hours ago, emmanuelf said:

... immune to short circuit, to esd, specially designed to drive 75ohm inputs etc...

Those do sound like nice features. Maybe having both outputs on the board would be the lesser of two evils after all? I'll try to get the THS7374 swapped back in with an extra tap from somewhere earlier in the circuit for those people that want/need TTL CSYNC for whatever reason.

In the meantime, while doing more extensive testing (finally it's not the same screenshot!), I spotted some strange behavior in level 3 of Popeye:

Take a look at the right-hand side of the screen, just after each of the long black platforms. There is a long sort of color "smear" just after a transition from a line that is mostly solid black to a bright color. If you look very closely, it even continues recovering all the way on the next line (at the far left) after each one.

I wanted to see if this was just a VDP thing, but right now I've got the RF board removed from my test CV. I tried it via RF on a different CV, but it either doesn't happen there or it's so slight that the normal warbling in the RF picture is enough to hide it.

Zooming into the right side of the screen on line 89 (Olive's platform at the top), it looks like this:

It's tricky to capture just that on the scope (notably: it takes 5+ minutes to get to level three, you can't pause the game, and the game over screen only lasts about 30 seconds so you have to play simultaneously while adjusting the scope ), but here it is at the input (straight off the VDP pins) and the output (after the 75ohm resistors):

You can see a 70mV or so decline (especially on R) in the output. It's sort of there on the inputs if more subtle (and the noise certainly doesn't help). That was what made me wonder if it showed up over RF... but testing it against a completely different chip doesn't feel like a good comparison.

So, is this a known issue for (old/poor/failing) 9928A chips? Or do we have a problem in the RGB converter that can be addressed?

My instinct wants to say some capacitor somewhere either isn't getting charged enough or is getting too much time to charge. It's just a question of whether that capacitor is on the CV board or this board, hehe.

Any ideas? Thanks!

May 6, 2020

7 hours ago, MrPix said:

Do you think this is evolved enough for me to start IC shopping?

It feels very close, but I've been surprised during this process (like ten times now, hehe), so I will leave that gamble up to you. My DigiKey order with what should be the last of the prototyping parts is supposed to be here on the 9th. I should know more after that.

8 hours ago, MrPix said:

... the only other changes will be values?

And hopefully just the addition of those two small 74LVC' parts I mentioned above. But again, every time I think I'm finally getting the hang of this, the scope shows me that I missed half a dozen important details.

4 hours ago, emmanuelf said:

Without, in real condition you will go into trouble with CSYNC at one time or another.

Avoiding the buffer for CSYNC was intentional. Right now the eventual PCB will be able to target two different output connections. As-drawn, it works with the "plain" miniDIN-8 to SCART cable (with no internal components except the pull-up on the enable-RGB pin). But if you switch the three 75Ω and the 470Ω output resistors to 0Ω jumpers (or just solder bridge them), it will also work with all the Sega Genesis 2 miniDIN-9 to RGB SCART cables out there (which already have the 75's and 470 right in the cable).

So maintaining the ability to optionally output TTL-level CSYNC was on my requirements list. If I had dropped the sync voltage before running it through the 4th channel of the '7374, we would need to route a separate pad for TTL CSYNC, which would have added a trap (using the wrong sync output) to the installation instructions. As-is, the instructions are simple: "DIN-8: use these four resistors. DIN-9: use jumpers instead". I like that. Less room for error.

The range of valid sync voltages in the SCART spec is super wide: "0.3V (-3 dB, +10dB)", which ends up like 0.21V to 0.95V, right? It seems like they intentionally included a lot of wiggle room for situations like these. Using the LM1881's output through a Schmitt trigger---just for the extra output drive because it's already on the board---seems like the best case scenario for a clean signal. I've heard horror stories in the past about sync not working, but they seemed to usually involve an already-weak sync-on-Luma signal or something like that.

4 hours ago, emmanuelf said:

PS: why using followers and dividers instead of proper gain on each channel ?

The "gain" on all three channels is less than 1.0. It could be done on the inverting side, but then you'd need another set of amps to invert it again, right?

5 hours ago, emmanuelf said:

Ac coupling and "high"/not low impedance output on the coupling is not ideal.

Putting it anywhere else caused more trouble. Between the mux and the amps caused spikes on the mux's transitions. Before the mux or without the amps caused smearing. I agree it's not ideal but it feels like it'd be silly to add another stage of voltage followers to drop the impedance when the output is already looking/measuring perfect.

May 5, 2020

Apparently it's available on GitHub now. This was news to me. 🤣

Sign In

Profiles

Member Map

Forums

Blogs

Gallery

Calendar

Store

Posts posted by Falonn