Jump to content
SiLic0ne t0aD

New Coleco RGB board?

Recommended Posts

33 minutes ago, ChildOfCv said:

Was this one of the common mods, or simply a direct connection to component outputs?

The 5-11under mod that he sold for a limited time at the end of 2009 and into 2010.

 

 

Share this post


Link to post
Share on other sites
15 hours ago, ChildOfCv said:

Without completely reverse engineering the original board, I can guess.

I feel like some variation of "if only we had a schematic..." has come up in this thread a dozen times now.

 

My wife took my four year old to a birthday party today, so I had a quiet afternoon to myself.  After following traces in a paint program for a few hours, then tinkering around in Eagle for a while, here is the reversed schematic for the ColecoRGB 1.2 board to the best of my (rather limited) ability.  Now we've at least got something to look at.

 

Things I learned:

 

1. Unless I'm missing something (I usually do when looking at these things), this is just the "R-G-B Converter" block.  It looks a lot closer to the German forum post that citrus3000psi mentioned in post #3 than it does the TMS document.

 

2. Norton op-amps are strange.  I'd never seen those I_set lines before.

 

3. Going board-to-schematic uses all different parts of your brain than schematic-to-board.  It's not unlike putting together a jigsaw puzzle. hehe.

 

It's (well) beyond my skill level to make any sort of meaningful comparison between what's going on (or missing) here vs. the TMS document.  So, the best I'll hope is that by doing the tedious part, someone else might be able to make heads or tails of it a little more easily!

annotatedBoard.png

ColecoRGB 1.2 schematic.pdf

  • Thanks 1

Share this post


Link to post
Share on other sites

Norton amplifiers are op-amps that operate on the difference of input current, instead of voltage.  So for example, U2B which outputs sync, has 5V through a 5.6K resistor which feeds in about 0.9mA.  That means that while the + side is above 1.3V through its 1.5K resistor, the amp will output a positive current.  Since it has no feedback network, it outputs max gain, or +5V during the visible part of the frame and drops to 0 on sync.  This seems kinda iffy though since the TMS9928's sync voltage ranges from a minimum of 1.2V to up to 2V depending on its mood.

Share this post


Link to post
Share on other sites
Quote

Yeah, the main reason for the 1881 is to reduce component count.  It may also do a better job than the discrete circuit, but keeping the size of the board down has a higher priority.

For a refreshed circuit, don't forget about the hugely improved LMH1981, more pins but worth it in all other aspects.

Edited by emmanuelf

Share this post


Link to post
Share on other sites

I'd read through the Wikipedia entry on Norton amps, but didn't feel like I got much out of it.  Following along with your example just now, that was very instructive!  Thanks!

 

I was poking around the "Sync Separator" block in the TMS document (unsuccessfully) trying to work out the analogous example to see if it would do any better, when I discovered a curiosity: for whatever reason, it looks like they're outputting C-sync twice.  Worse, R30 and R31 appear to have the only unspecified values in the entire design and aren't mentioned anywhere in the text.  (Is that some convention with resistor divider networks?  Is that shorthand for "use whatever you like, as long as they're equal" or something along those lines?)

 

Calling both of those "composite sync" is the part of circuit analysis that drives me a little crazy.  With one coming after an additional transistor stage, they couldn't possibly be the exact same signal (and if they were, why bother with the second transistor)... so which one is the "right" one?  If I wanted to build this thing verbatim, would it be safe to just leave out the R30/R31 leg and treat the circuit as only having a single C-sync output (coming off the R29/R32 divider)?  Or is the right answer to let the LM1881 / LMH1981 worry about that part in a modified design?

 

(There is a certain peace of mind knowing that TI graybeards effectively blessed the old schematic for our exact purpose.  I'm half-tempted to build the old design exactly as specified, old part numbers and all...)

dualSync.png

Share this post


Link to post
Share on other sites

J3-7 is 0v referenced, J3-6 is -5v referenced.

The later could be omitted and considered as a test point.

The -5v referencing is need because of the ac coupling at the input needed for the -5v/12v used for the AOP and the command of the 4066.

Edited by emmanuelf

Share this post


Link to post
Share on other sites

@FalonnSo, near the beginning of this thread, someone linked to that Hackaday project for suppressing the color burst to clean up the signal.  It occurs to me that perhaps your efforts to integrate something should be based on that anyway.  It has options for both component and RGB output, but you can simply remove what you don't want.

Share this post


Link to post
Share on other sites

That is for the 9929A, which is the PAL version of the 9928A. I don't know how it applies to the NTSC version.

Share this post


Link to post
Share on other sites
5 hours ago, MrPix said:

That is for the 9929A, which is the PAL version of the 9928A. I don't know how it applies to the NTSC version.

It does.  They both have the same output specs and they both have a color burst voltage bump.  The only difference is frame timing and that the 9929 bursts on both red and blue while the 9928 only does blue.

Share this post


Link to post
Share on other sites

I'll work on a schematic that combines the RGB conversion and 1881 sync separator. From there I could use an AD725 to obtain clean color composite that is more immune to dot crawl, plus S-Video. I have an existing reference for the AD725 that I've applied before.

Clean RGB, clean composite and S-Video should cover almost everyone's needs who doesn't have or want HDMI.

Share this post


Link to post
Share on other sites

@MrPix Yeah, digging through the LM1881 datasheet just now, they even mention (in section 8.1) that you can use the burst gate/back porch pulse from the IC for some "DC Restoration" step for some potential RGB output, which makes it sound like that single chip fills in virtually all the missing pieces.  I only glanced at the LMH1980 datasheet for a couple minutes, but at $10 and with so many mentions of HD format detection and tri-level sync detection, I wonder if it isn't overkill.  The LM1881 seems like it's exactly what we need.  I was thinking of grabbing a couple of them in the DIP package and tinkering around with some of this on a breadboard.  After poking around with my scope for a couple hours last night, these video signals don't seem as scary anymore.  If you needed any help, MrPix, with testing or just getting a confirmation that something works on someone else's board, I am happy to help!

 

For my part, I only need/care about RGB output.  I'm curious why you had mentioned buffering the RGB output a few posts back?  Are there any benefits?  All I can imagine is that you'd be introducing an extra source of latency.

 

@ChildOfCv Only tangentially related: I've been repairing an old Coleco board that "stopped working" that we've had since I was a child.  Upon opening it, the ground straps were already disconnected, all four power lines had been desoldered and were loose in the case, the heat sink on the 9928A was missing, the leg on one of the 0.1uF caps next to a VRAM was cut and partially desoldered, the resistor by the expansion port was missing... it was quite a crime scene.  I eventually deduced that sometime between it "stopped working" and today, a (presumably teenager-at-the-time) older brother of mine decided to use it for (de-)soldering practice.  I didn't know the values of the missing components, so I went searching for schematics.  As a happy coincidence, I found your excellent schematics from your very first post here.  That made repairing the interim damage much easier.  The original problem turned out to be the usual corrupt graphics due to a corroded power switch---also an easy fix---so the board is back up to 100%.  So, you've now inadvertently helped me one more time than you knew!  Thanks again! hehe.

  • Like 1

Share this post


Link to post
Share on other sites
On 2/11/2020 at 5:26 PM, ChildOfCv said:

@FalonnSo, near the beginning of this thread, someone linked to that Hackaday project for suppressing the color burst to clean up the signal.  It occurs to me that perhaps your efforts to integrate something should be based on that anyway.  It has options for both component and RGB output, but you can simply remove what you don't want.

Oh, hey, that schematic is lovely.  It neatly matches the TMS document but with the 1881 supplanting the DC Restoration and Sync Separator blocks (while still using the same 4066's to drop the color burst).  The only thing that creeps me out a little is the lack of trim pots to do any sort of fine tuning.  I don't see any extra magic tucked in there that wasn't in the TMS doc (except that extra Vref output from the TL081 that is fed back into all the other amps?) and TI seemed to still believe they needed the ability to do manual adjustment.  Hmm.

 

Now I'm even more interested in doing a sort of head-to-head battle where I build all of the above and compare their outputs on the scope (and screen).  Then some hybrid (probably this Hackaday version + pots), opensource board could be the ultimate solution that works for everybody in every region.  It looks like I need to place a Digikey order and build one of those all-white output test ROM cartridges...

Share this post


Link to post
Share on other sites

I assume you mean to adjust the strength of the color component outputs?  My guess is that any compliant TV or monitor will show a correct image as is.  But I guess for maximum compatibility, you may still want to be able to adjust them.

Share this post


Link to post
Share on other sites

I meant the oscilloscope-required, 1.0V peak-to-peak on each R, G, B line tuning described in the TMS document and used on the citrus board.  Since page 4, MobiusStripTech has been cautioning DIY'ers without a scope that it's "basically impossible to get perfect [by eye]".

 

It'd be cool if the Vref out from the TL081 in the Hackaday circuit was doing some sort of auto-scaling.  Even if that still meant something like a single pot that you can adjust by eye ("raise it until you see clipping, then lower it a little"), that'd make it a lot more accessible to hobbyists.

 

Hmm, re-reading the line on page 2 of the TMS doc, it sounds a little less vital: "Variable resistors R52, R53, and R54 have been included in the circuit in order to accommodate monitors requiring more (or less) than one volt peak-to-peak of drive, or to allow colors to be adjusted to suit a particular application".  I vaguely recall someone (earlier in this thread?) describing that they'd bottomed out one of the pots on the citrus board and still couldn't get the colors right.  Maybe that was more due to the missing DC restoration step than a finicky, ~40 year old graphics chip?

  • Thanks 1

Share this post


Link to post
Share on other sites

I’m going through the same process. 
 

What I’d really like is to relate the pixels to the pixel clock so I can digitize them and convert them to integer scaled HDMI. The problem is the delay of the conversion through the various versions of several mask revisions of 99x8/9 means the output has a lot of mixed relationships with the pixel clock from system to system.
 

Any thoughts?

Share this post


Link to post
Share on other sites

@MrPix That's starting to sound like you might be heading toward FPGA territory (along the lines of the F18A mod or even the CollectorVision Phoenix).

 

With things like the OSSC (and Framemeister, etc.) making RGB input more accessible to everyone, my own interest would be to keep the mod as unobtrusive/simple to install with the smallest reasonable BOM.  Those upscalers can already do a lot of the fancy cleanup work afterward, so it seems like a duplication of effort to add that sort of thing to the console.

 

In other news: last night I placed the DigiKey order to build all three (TMS doc, Citrus, and Hackaday) RGB boards using their (99%) originally specified parts.  The two 2N2907's from the TMS doc are even in the little metal can package.  Hopefully in a week or so, I'll have some Epic Colecovision RGB Board Showdown screenshots from my scope.  Then we'll be able to quantitatively compare the performance of these things (against an NTSC board).

  • Like 1

Share this post


Link to post
Share on other sites

If I can access an in-time pixel clock (3.58MHz) then I would switch up to using a PSoC 5LP. It's soft of an FPGA, but not in the traditional sense. I have used one before to make a replacement video generator for the Sinclair QL, giving legal line doubled, pixel tripled output (to convert 256x256 to 768x512), and asking it to do something with 9928 video would be quite light work. However, I wouldn't go full on FPGA, as I simply don't have the skills or the attention span to completely re-implement the 99x8 family - especially because this work has already been done.

Mostly, I just want to do something at a price point that it is accessible to a lot more people than traditional F18A prices. That rules out F18A-level development costs and time.

I'll sit back and wait for your comparison. If you can screencap your scope, I'd be very interested in seeing the results.

Share this post


Link to post
Share on other sites
On 2/15/2020 at 10:57 PM, MrPix said:

I’m going through the same process. 
 

What I’d really like is to relate the pixels to the pixel clock so I can digitize them and convert them to integer scaled HDMI. The problem is the delay of the conversion through the various versions of several mask revisions of 99x8/9 means the output has a lot of mixed relationships with the pixel clock from system to system.
 

Any thoughts?

Maybe you could synchronize with the sync pulse on the Y output.  That should give you a pretty strong indication of which clock cycle gives you the best chance at a clean conversion.

Share this post


Link to post
Share on other sites

I figure the 3.58MHz clock is on a pin right there so I just need to figure out the relationship between it and the output. That would give me a per pixel clock, rather than a per line clock.

Share this post


Link to post
Share on other sites
2 hours ago, MrPix said:

I figure the 3.58MHz clock is on a pin right there so I just need to figure out the relationship between it and the output. That would give me a per pixel clock, rather than a per line clock.

The internal pixel clock is actually a division by 2 of the input 10.7MHz clock.  So a pixel is 5.3MHz wide, not 3.58MHz.  At least according to the VDP datasheet which is known to have many typos and factual errors.  So you should key off of the 10.7MHz clock with your own divide-by-2, and also sync with... something.  I'd attempt the Hsync signal just to make sure you're on the right step.

Share this post


Link to post
Share on other sites

While waiting for my DigiKey stuff, I wanted to get all my ducks in a row.  Back on page 8, ChildOfCv mentioned a missing capacitor between the Hackaday schematic and Citrus' PAL board.  After spotting two other parts missing from the BOM (vs. Hackaday), I wanted to go through with a fine-toothed comb to see what else was different.  So I also reverse-engineered it and then compared each net between the two (rather painstakingly, hehe).

 

Citrus3000psi's board implementation of the Hackaday schematic is almost identical with the following differences (highlighted in red in the attached schematic):

  1. Citrus is missing the ferrite bead on the 5V input line.  This seems reasonable given the board's mounting style and resulting short/non-existent trace length from the graphics chip.
  2. Citrus is missing the 270R on the 5V output.  I'm not sure why it was there in the first place.  Maybe something MSX-specific?  SCART specific?  This is still an open question.
  3. Citrus is missing the 0.1uF coupling capacitor between the Y input and the LM1881's Video-In pin.  This is what ChildOfCv noticed before.  Right in the LM1881 datasheet, it says "The only required external components [...] are the composite input coupling capacitor at pin 2 [...]," so this definitely seems like a mistake.
  4. The Citrus board has a typo: the resistors near U5 are labeled "R27 R26 R27".  One of the two 27s should be a 28.  Luckily, the resistor values are also on the silkscreen and they are correct.  So, if someone is building one, they should confirm both the part name and values there.
  5. The component designators are all different.  I can't imagine how this would be useful to anyone, but I've attached a CSV with the mapping between the two.

Given the missing cap is a mistake according to the datasheet and that it's the only substantial difference between the two, I don't think I'll track them as separate variants when recording data for the upcoming RGB mod shoot-out.  So the plan is still to test the three circuits that I know about: from the 40 year old TMS doc, from the Hackaday post (equivalent/identical to ColecoRGB PAL), and Citrus' ColecoRGB 1.2 ("NTSC") board.

ColecoRGB PAL Annotated.png

schematic comparison.png

ColecoRGB PAL BOM comparison.csv

  • Thanks 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...