Falonn
-
Content Count
169 -
Joined
-
Last visited
Posts posted by Falonn
-
-
Because it's clean/standard RGB out, there shouldn't be anything preventing additional conversions. (This isn't internal to the console, but something like the RetroTINK RGB2COMP should work right out of the box.)
That said, the TMS-RGB is already doing a YUV-to-YPbPr-to-RGB conversion. So if you wanted component out, the Right Thing wouldn't be adding an additional conversion, but circumventing the LMH1251 chip in the middle of the board (which is responsible for the YPbPr-to-RGB half) instead.
Because that one is responsible for about half the cost of the whole board (and because YPbPr doesn't require separate sync lines, meaning you can remove a few more components), a stand-alone "TMS-YPbPr" board could be smaller, simpler, and cheaper. It probably wouldn't be as popular as the RGB board--more like the TMS-RGB's "little brother" or something like that--but I've had the thing half-routed and almost ready to test for something like six months now. It's one of those projects I keep trying to find the time for, but life keeps getting in the way. 😕
-
With any luck, the answer should be "just about anything you've got". The sticker right on the Colecovision power supply says all three power rails are rated for less than 1.0 amp (and my own testing showed that the 5V rail, which is the highest rated of the three, was only using 0.6A in practice).
So, using any of the usual AWG charts, even if you've got a stranded wire with a ton of cores, 24 AWG should still be plenty.
-
1 hour ago, -^CrossBow^- said:But you are saying that just running composite to pin 4 only on the 9-pin din is enough for all cables to work?
Nope, what you said is exactly correct. You just did a better job of saying it than I was able to!
Doing it that way (with pin 4 and pin 5 both connected to useful signals) means you reach maximum compatibility with just about everything.
-
23 hours ago, -^CrossBow^- said:Only HDRetrovision cables require the composite signal for them to get Sync from. Why they aren't using actual C-sync I have no idea...
Yeah, I think Ruggers ran into the same thing during his initial testing. For whatever reason they get their sync from the composite video pin instead of the dedicated C-sync pin.
4 hours ago, ChildOfCv said:Well, one idea for a V3 design might be to include jumpers for the SYNC input to the final amps, to come from either the 1881 or the Y signal.
It's just that the cable is looking at the "wrong" pin.
In a 9-pin, Genesis-style installation, you can go one step farther and have your cake and eat it too if you also install the typical composite mod. It ends up looking like the usual set of connections for a 9-pin TMS-RGB install except pin 4 goes to the composite mod instead of the TMS-RGB board. That configuration works with all cables: Genesis RGB, Genesis composite, HD Retrovision, or whatever else you might have.
1 hour ago, Ianr757 said:Another quick question. Will this mod still function if I install the 5v RAM mod?
TMS-RGB only touches things that are already 5V. It should be completely independent of the 5V RAM mod.
-
In a turn-key little box that anyone can just click onto the back of their expansion module, at around $10 in parts wholesale (leaving plenty of room for a healthy margin), I think you might be right!
Hopefully that will be a big enough carrot to have someone else pick it up. I know I'd be first in line to buy one if someone else finished it.
-
I gave building this a shot, but had some trouble. The video from expansion #1 through my ColecoVision is just fine, but through the mod, it shows up very dark. Only the brightest colors just barely register on the screen. Since the "external video" pin runs straight to the place people usually tap for the composite video mod in their CV, I'm guessing it's just a weak signal that needs a bit of amplification. I tried cobbling something together from parts I had on hand and was able to get something too-bright to show up, at which point I decided to stop fiddling with it for now.
Instead of drilling holes and adding stuff to the expansion module itself, I wanted to try making a little card-edge adapter that did all the same stuff (like I'd mentioned up in the #3 post). It turned out pretty cool and fit perfectly on the first try:
Don't mind the bodge wire on the ground pin; that was for debugging.
All the parts are through-hole, so it goes together in just a few minutes with a soldering iron.
I did change a couple things in the design. I can't imagine any of them are responsible for it not working, but here's the list:
- It uses HDTV1080P's Mean Well power supply, which already has all the exact voltage levels necessary. No voltage regulators needed.
- I included the same power filtering capacitor+inductor scheme from the ColecoVision board. This was more of a "better safe than sorry" measure. It's a long power cord, so having some local filtering made me feel better.
- I added some debouncing to the reset switch. I was going to use the same scheme from the CV board again, but they've got an elaborate pulse-generator thing. I decided to meet in the middle and add something but keep it simple.
Anyhoo, once I saw that there was still design work to be done, I decided it exceeded the amount of time I had for a simple board layout exercise (and eventual 3D printed case design) and am going to leave it unfinished. I just put all the files on GitHub with a public domain license if anyone else wants to pick the project up from here.
-
4
-
It's an easy mistake to make. Most Wikipedia-type listings for these old systems mention them as having the '9918 (probably?) because the whole family of chips was lumped under the "TMS9918" banner. You usually have to do more digging for schematics (or peek under the heat sink) to find out for sure.
That eBay listing looks good. Coincidentally I purchased a set of three of the same item from the same seller about six months ago. Mine even had the same little red paint dot added to the corners to show pin 1 for whatever reason. As far as I could tell, they were OEM parts and not any sort of sketchy replica.
Otherwise, I don't think there would be any way to tell which might be free of the graphical problem. Luck of the draw, I suspect. (More reason for adding the socket!)
-
They haven't made new '9928A chips in decades, but they seem to be pretty readily available on eBay. (Your link is for the 9918A which is the composite-output version of the chip instead of the YUV output, so don't buy that one.)
Otherwise: a 40-pin socket is a great idea. I don't think the extra height would make the clearance on the heatsink much worse, so it should be safe.
-
On 12/31/2020 at 4:29 AM, Ianr757 said:Do you think there is a way to fix or reduce the severity of the flickering by removing, swapping or adding components either to the mod board or the Coleco motherboard?
Having never seen this particular problem before, I wouldn't know where to begin, sorry.
If my hypothesis is true that it's more to do with a fussy, old chip than it is with the mod, you've always got the nuclear option of swapping the entire VDP out with something like the F18A. (The last news we heard about the MK2 wasn't exactly what everyone was hoping for, but it's been a month or so since then, so hope begins to return.)
-
18 hours ago, doubledown said:Out of curiosity, what do you use for a keypad with this Genesis controller?
The extended Genesis controllers (made by Hyperkin, I think) have more buttons than usual including an extra, flush shoulder button that you can't see in the pictures. The mapping that Rugger's uses can reach most of the things you need in most games. But, the real answer to your question is that I switch back to the standard controller when I need more buttons.
-
1
-
-
I was an Original Hand Controller guy for 35 years until I tried Rugger's re-wired Genesis controller a few months ago. The D-pad controls things a thousand times better than the original joystick.
-
1
-
-
I don't have a good answer, but I do have a few anecdotes that might be related to possible explanations:
1. "Strange behavior caused by large, solid-colored areas" is something I've seen from the VDP before. At the time I mentioned I wasn't able to reproduce it over RF. Eventually I was able to, though it was a little fainter because the poor quality from the RF output masked it pretty well. I wonder if the same isn't the case here: perhaps some additional filtering along the RF path (to help clean it up) isn't hiding the effect and it can only now be seen when the veil has been lifted on the image quality?
2. More evidence of large, solid-colored areas causing things you might not expect: during our (still forthcoming) investigation into the 9928A's palette, Ikrananka noticed that the colors generated by the VDP varied slightly depending on the contents of the rest of the line! A vectorscope measurement of an entire, solid-color screen showed a slightly different result than that same color when measured on a whole-palette-visible-at-once vertical bar test pattern screen. This also doesn't involve the kind of flickering you're seeing, but it does drive home the idea that it was a very early, completely-analog design, implemented in chips that are just about to reach their 40th birthdays. I would be willing to forgive some of their fussiness.
3. Continuing down the "it might be the VDP with the problem" path: it's kind of jarring how much strange stuff there is to uncover when you start reading the internal memos from the different TI development teams for the VDPs. They go back and forth about the bugs and math they got wrong (the 9929A uses NTSC gamma correction even though it's a PAL chip; this wasn't corrected until the 9129 successor). When you run the numbers to convert the YUV output voltages to RGB (with the assumption that the "White" entry in the palette should be at a full 100% R, G, and B), you end up with both blues clipping rather aggressively (>140%) in the blue channel and both reds clipping a little (105% and 119%) in the red channel.
Ikrananka uncovered an interesting piece of evidence that seems to suggest this may have been a bug. In this old schematic of the Tatung Einstein TC01 computer (which uses the PAL chip, but with the same results), take a look at R019 (the smallest yellow circle):
That computer used a direct, (rare?) YUV output cable and left the Y and V signals completely untouched before the output voltage buffers. But the 82 ohms on the U line forms a divider with R021's 470 ohms to ground, which would drop the voltage to about 85% of the input. That brings the maximum clipping in the blue channel right in line with that in the red channel. Presumably the Tatung engineers noticed that TI's VDP would output out-of-spec voltages if left uncorrected? They appear to have opted for a slightly modified palette (with all the blues less saturated) in order to avoid any output that was over the limit.
I'm beginning to wonder if the ColecoVision folks didn't combat the problem using a different strategy: reduce the strength of all three (R, G, and B) channels until none of the channels clip for any color in the palette. You'd be left with a white that was darker than it should be, but everything would be in-spec. Looking at the video on the front page of the TMS-RGB site (say, Antarctic Adventure at 0:12), the RF recording on the left side shows something a lot more gray than white.
While choosing the output levels for TMS-RGB, I noticed that the SCART spec allows "synthetic pictures" to use a wider voltage range than "natural pictures" (footnote 8 on page 10), presumably for situations like these where the hardware is going to be pushing the very highest values to get fully saturated colors. After running the numbers, it looked like the VDP's clipping on the blue channel would still be inside the expanded range, so I chose components that would deliver white-whites. So, one explanation might be that your TV isn't as tolerant to blues that are so strong? If the TV has some kind of "gain" or "picture" control, try reducing it to see if the flickering stops.
I've gone back and forth a few times now on my decision to make White fully bright at the expense of the blues being out of range. The SCART document initially gave me confidence, but hearing about faint jailbars in some cases and now this flickering problem makes me wonder if toning the whole thing down to white showing as a light gray wouldn't have avoided some trouble for people. Hmm.
-
-
I'm having trouble finding my notes on it--I've never seen any of the 91xx's in the wild--but from memory I thought the only difference was an extra video mode and a slightly different palette (with better gamma correction) in the PAL version. It was more of a revision to the 9928A/29A than a whole new chip.
My guess is that it should work just fine. Out of curiosity what do you have that uses the 9128?
-
Nice work! I'm surprised at how similar everything in the PAL version--except the A/V subsystem--is to the NTSC model. (Although, in retrospect, I suppose I shouldn't be. Reusing those other blocks is just good engineering on their part.)
There is a lot more to take in on the PAL A/V page though, sheesh! It's sort of a combination of the NTSC's A/V stuff, the RF board, and another clock circuit all rolled into one. I can't imagine how long it must have taken to trace all of that out. Thanks again for your generosity to the community! This is a great resource.
-
I've been hunting around to place an order for ~10 authentic-looking new cartridge shells for a while now. I have (vaguely defined) aspirations of making a game someday and am interested in completing the project by making something "real" looking that my kids could play on the original hardware.
I was surprised something like this wasn't already readily available after seeing the hundreds of varieties of cartridge shell available for something like the NES. To not have a single option for Colecovision seemed strange. My plan so far was to cast my own shell halves in urethane using a silicone mold from some donor cartridge with the label removed. I got as far as a $1.40 eBay purchase for a sacrificial Super Action Baseball but no farther. I would be much happier buying an off-the-shelf solution to the problem instead!
- Yes, the shell I'm interested in is the standard/official version that the majority of Colecovision games used.
- Original screw direction, all the way. Reverse might be convenient while wrapping up prototyping, but so is plugging in a bare PCB.
-
Obviously these are more niche, so if it's a matter of minimum quantity to make it worth the effort, I'm happy to do my part and buy 2-3x more than I need (or pay 2-3x more than is sensible) if it means they'll actually become available!
-
2
-
That's reasonable. I've never done the mod myself and I haven't traced the -5V path through the PCB to see how equivalent the two operations are. I just remembered seeing that warning in the instructions months ago, so I figured I would say something just in case. Good luck!
-
Isn't disconnecting the -5V rail one of the steps in the memory mod? Reconnecting it would join the 5V and -5V rails together, where presumably bad things would happen.
The note at the top of that page (beginning with "IMPORTANT!!!") says you should make sure -5V remains disconnected.
-
This is awesome. Nice work! It's surprising how few components it takes to remove the rest of the Colecovision from the equation.
It would be cool to see the whole thing put on a small PCB with a card-edge connector to slot right into the back of the expansion module. Then you would have a "no cut" version that could be assembled/sold as a single plug-and-play unit.
-
Send me a Phoenix for testing and I will.
-
5 hours ago, Bmack36 said:If it was just passing 5V along it might work, but it would be generating the 12 and -12 as well which would pull too much power from the system.
If the ColUSB is connected directly to the Roller Controller, wouldn't the +12V and -5V rails be completely unloaded? On that controller's plug, those two lines are just a straight passthrough (for the eventual connection to the Colecovision itself, which wouldn't be present in this case) and it only runs the +5V and GND lines to the controller. (If you look at the power wire, it's clear there are only two conductors. The schematic also confirms that only +5V is used.)
I have no idea what the quiescent current would be for the unused rails, but if they're small enough to fit in that adapter, they're going to be the buck/boost style, which are usually pretty efficient, right?
-
It looks like the output from the OSSC is a little hot. You might be able to adjust it via the OSSC's settings or simply by turning the brightness down on your TV. Once they're toned down a bit, there should be a clearer distinction between the two Pac-Man ghosts.
For what it's worth, the "Light Red" and "Dark Red" colors that the TMS9928A outputs are nearly the same hue, so the chip can't really produce an orange and a red simultaneously. Here is a shot from a vectorscope showing the full '9928A palette running on a Colecovision:
(Thanks and acknowledgements to Artemio Urbina for the vectorscope shot. This is a tiny snippet and sneak peek from a larger investigation we've been helping Ikrananka with.)
The angle around the circle is the hue. Since you can draw a line from the center mass out through both dots at the upper-left (near the "R"), that means (depending on your TV's settings) you're either getting two oranges or two reds, but not an orange and a red simultaneously.
The F18A gets to cheat and choose the colors arbitrarily. TMS-RGB is pure analog and linear transformations, so while you can tweak things like how each channel is mixed (linearly), there isn't going to be a way to change the hue of one of the reds without changing the other. This is one of those cases where the F18A's clear advantage in (35 year newer) capabilities easily outshines the original hardware.
-
3
-
-
That's good to hear the shielding fixed it!
-
Nice work!
The ringing in your DK picture is a little disconcerting though:
I never saw anything like that during development. I wonder if there are some signal reflections happening somehow with your cabling setup?
3 hours ago, Macross_VF1 said:Have you tried adjusting your OSSC's offset controls mentioned in step 10 of the install guide? I always saw the vertical lines through the OSSC (but not the Framemeister), but I was able to clean them up by tweaking the offsets for each channel.
Otherwise, that sync issue is interesting. I'd imagine newer TVs have started dropping support for ancient resolutions. It might be getting confused because 240p is very similar to 480i, where it probably doesn't support the former and is trying to force a square peg into a 480i-shaped hole. Hmm.
In any event, that looks like a great install and your DIN adapter still isn't as bad as the 3 or 5 separate holes you see sometimes with composite/component mods.
-
1
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
TMS-RGB: An RGB Mod for 2020 and Beyond
in ColecoVision / Adam
Posted
Yep, coordinating with you is also on that same to-do list.
(Testing the corrected palette is the very first step once I get the still-assembled TMS-RGB breadboard converted over to YPbPr. I'd love to take a look at what you've got written up.)
The board I was talking about routing would be the same kind of compact, "right on the back of the VDP" thing as the TMS-RGB, so your idea of a drop-in replacement for existing installs using the 5-11under form factor is still a useful idea with plenty of work you'll get to do.
Outside of the connectors, I expect both form factors will end up with a near-identical BOM. So, anyone that wanted to build a TMS-YPbPr themselves could just pick the PCB shape that works best for their situation and then buy a "universal" set of components for it.