Image Map Image Map
Results 1 to 10 of 10

Thread: Blurred video RGB on LCD monitor

  1. #1

    Default Blurred video RGB on LCD monitor

    I have two identical old video cards for macintosh nubus both showing the same problem when connected to LCD monitor: the RGB color components are shifted with respect to each other so that white area gets green fringe on one border and red on the opposite. When the same monitor is connected with the same cable to builtin video port on motherboard there is no such trouble, the pixels are sharp: see attached photos for comparison.

    I was wondering maybe this is by design some sort of artificial shift of color component to match timing of some specific CRT monitors. It seems unlikely that two boards developed the same subtle problem. Before anyone suggests - I did check electrolytic capacitors and did try replacing some of them, which did not have any effect.

    Any insights on the topic are appreciated
    IMG_0582.jpg
    IMG_0583.jpg

  2. #2

    Default

    it has to do with the sync signal, and the way your cable is wired.

    I could give you a more technically complete answer if you told us which LCD monitor and which NuBus video card you're using.

  3. #3

    Default

    Quote Originally Posted by bear View Post
    it has to do with the sync signal, and the way your cable is wired.

    I could give you a more technically complete answer if you told us which LCD monitor and which NuBus video card you're using.
    The cards are Supermac spectrum/8 series 3. The monitor is some standard Dell with max resolution 1600x1000, I can lookup model this night when I get home. This monitor is capable of syncing on green with all kinds of vintage computers without any conversion - commodore 128, amiga, vaxstation 3100, decmate.

    I would also doubt it is sync being the reason, because I was watching with a scope the color component signals on the card itself while outputting gray field of startup screen on mac iici - it appears to be an alternating pattern of black and white pixels. So although pixel waveform is not very sharp on my scope the edges of color signals are shifted with respect to each other consistently with the displayed image.
    Last edited by vldmrrr; October 23rd, 2019 at 06:12 AM.

  4. #4
    Join Date
    Mar 2017
    Location
    New Jersey, USA
    Posts
    503

    Default

    Quote Originally Posted by vldmrrr View Post
    I was wondering maybe this is by design some sort of artificial shift of color component to match timing of some specific CRT monitors.
    It seems crazy but I suppose it might be possible. But if this was deliberate I'd guess it was to match the dot/stripe pitch of a specific CRT, not the timing. If the red waveform is early and the green waveform is late, that would imply that this was intended for use with a tube with a Red, Blue, Green dot/stripe order, so not a Trinitron CRT which has Red Green Blue stripe order. Is the amount of lag from red-to-blue and from blue-to-green about the same amount of time as it takes for the electron beam on the CRT to pass a single red blue or green phosphor dot or stripe?

    Here's a pen-and-paper simulation when red leads by 1/3 dot triad width and green lags by 1/3 dot triad width, for RGB and RBG phosphor orders. You can see that with an RBG stripe order all the waveforms lead to smooth transitions, but when displayed on an RGB tube you get occasional red or green fringes (these are the places where 101 appears).

    Code:
    Waveform from video card:
    R 01111111111111100000000
    G 00011111111111111000000
    B 00111111111111110000000
    
    CRT with RGB stripe order:
      RGBRGBRGBRGBRGBRGBRGBRG
      00111111111111101000000
    
      BRGBRGBRGBRGBRGBRGBRGBR
      01011111111111110000000
    
      GBRGBRGBRGBRGBRGBRGBRGB
      00111111111111110000000
    
    CRT with RBG stripe order:
      RBGRBGRBGRBGRBGRBGRBGRB
      00011111111111100000000
    
      GRBGRBGRBGRBGRBGRBGRBGR
      01111111111111110000000
    
      BGRBGRBGRBGRBGRBGRBGRBG
      00111111111111111000000
    -ken

  5. #5

    Default

    Quote Originally Posted by kgober View Post
    Is the amount of lag from red-to-blue and from blue-to-green about the same amount of time as it takes for the electron beam on the CRT to pass a single red blue or green phosphor dot or stripe?
    -ken
    It appears to be roughly the same judging from screen shot. I did not measure that on the scope, but as I recall they are roughly the same.

    So if those cards are tuned specifically for RBG stripe I assume there should be something either in hardware or software to modify such tuning. I did a quick search for the IC in the output stage and this datasheet seem to match. I will study it this evening to see if there is any configuration for output.

  6. #6
    Join Date
    Mar 2017
    Location
    New Jersey, USA
    Posts
    503

    Default

    I wouldn't expect this to be something a stock chip would do. My guess would have been some kind of resistor/capacitor setup. I did some quick reading and op-amps might need to be involved. Analog circuits aren't my thing so I'm not able to speculate much more on this.

  7. #7
    Join Date
    Mar 2017
    Location
    New Jersey, USA
    Posts
    503

    Default

    Also while doing some more research I found that the proper term for the not-RGB ordering is "BGR". I'm getting lots more hits using "BGR" than "RBG" and as a bonus "BGR" and "RGB" are much more easily distinguished. The easiest path forward might be to just get yourself a BGR display panel for use with these cards.

  8. #8

    Default

    Well, to my embarrassment I found that the time shift I observed with the scope was due to differences in probes I used - when today I connected both to the same signal, I found the same difference. After I switched to better matched probes the observed time shift between color component signals practically disappeared.

    Also, after taking a closer look at screenshot it seems that what actually happens is green component is late by almost exactly one pixels. So it looks like the uniform test pattern that I used is not very suitable for this situation - I would need a screen with a single pixel white vertical line.

  9. #9

    Default

    I'm going to make a vague assertion here, that I haven't had time to go turn into an actual technical explanation. You've got some non-sync, non-rgb signal coming through to the monitor on one of the hsync or vsync pins, because of the way your cable is wired, and it's confusing the autosync/agc circuit.

    But I've encountered this (and other effects) with enough NuBus display adapters to be confident of the solution. The simplest thing to do is make sure only the R, G, and B are connected by using a DA15-3BNC cable, but there are other options. You might try to find a Supermac-specific DA15-DE15 adapter, or one of the generic Mac DA15-DE15 adapters with switchable monitor sense.

  10. #10

    Default

    Quote Originally Posted by bear View Post
    I'm going to make a vague assertion here, that I haven't had time to go turn into an actual technical explanation. You've got some non-sync, non-rgb signal coming through to the monitor on one of the hsync or vsync pins, because of the way your cable is wired, and it's confusing the autosync/agc circuit.
    You turned out absolutely right. After your message I've dig into my box with various mac adapters and found one that had separate dip switches for Sync. Mode - others have just various resolution settings. On this one there are 4 possible settings:
    • Separate
    • Composite
    • Separate+Composite
    • Sync on Green

    The last one - sync on green - resulted in clean B/W image on LCD monitor. Who would have thought!

    Thank you for the tip! The issue resolved

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •