Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

132 Excellent

About Falonn

  • Rank
    Chopper Commander

Recent Profile Visitors

483 profile views
  1. Here's a snapshot on the bottom level. The trick: you can walk right off of a ledge, which appears to dump you right into the death animation... but you can still control your "jump" and land right-side up. So on the middle platform: jump onto the highest point, walk off the right edge, and spin yourself upright. That way you don't hit your head on the ceiling. Now for the bad news: touching the person on the lowest level just restarts the car section again with zero fanfare of any kind. 😕 coolcv_snapshot.bin
  2. I have one too (from that exact listing) and have also had a great experience with it.
  3. 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.
  4. 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. 😕
  5. 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.
  6. 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.
  7. 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. 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. TMS-RGB only touches things that are already 5V. It should be completely independent of the 5V RAM mod.
  8. 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.
  9. 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.
  10. 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!)
  11. 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.
  12. 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.)
  13. 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.
  14. 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.
  15. 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.
  • Create New...