Mac-to-VGA monitor adapter struggles

[bigmessowires]

No I don't think the color voltage levels are a problem. Ideally you'd need to measure those with an actual monitor connected to see the effect of the termination inside the monitor, or add a separate resistor like you did.

At this point I'm pretty certain the problem is that CSYNC can't be substituted for HSYNC with this monitor. Which leads me to speculate how these monitors are designed internally, and why it doesn't work. Is there a PLL inside with a range of 30 to 82 kHz that attempts to lock on to the HSYNC input signal? If so, I would expect that PLL to also work with CSYNC, since the CSYNC signal is identical to the HSYNC signal for 522 out of 525 lines. It wouldn't be a perfect match, but it would be like pushing a swing where 522 cycles out of every 525 you push at the right time to swing higher, and 3 cycles you push at the wrong time: it would still work.

And do CRTs likely use a different method of adjusting to the horizontal frequency than LCDs do? It was interesting to see that in my test of three monitors, the CRTs accepted CSYNC as an HSYNC substitute, but the LCD did not.

 

[dougg3]

Ahh, somehow I missed the significance of the last test you did with Mac CSYNC -> VGA HSYNC and Mac VSYNC -> VGA VSYNC. Agreed, that's proof right there of the problem.

Assuming the RTD2513 is indeed used in this monitor based on my previous research, its datasheet might provide some insight into why the monitor doesn't handle it properly.

Interesting register bits:

• SYNC_CTRL bit 0 (R/W): Sync Mode Select
  • 0: Separate H & V
  • 1: Composite Sync from HSYNC or Green
  • It's probably safe to assume this monitor's firmware has that bit written as a 0.
• SYNC_POR bit 0 (R/W): HSYNC & VSYNC Measured Mode
  • 0: HS period counted by crystal clock and VS period counted by HS
  • 1: H resolution counted by input clock and V resolution counted by ENA
• MEAS_VSYNC_HI bit 3 (R/W): VSYNC Synchronize Edge
  • 0: latch VS by the positive edge of input HSYNC
  • 1: latch VS by the negative edge of input HSYNC

Kind of jumping into crazy speculation here, but maybe csync (being treated as hsync)'s changing behavior during the vsync period interferes with some of the logic described by these bits above?

 

[bigmessowires]

That's interesting. You're a great datasheet sleuth. What do you suppose SYNC_POR = 1 means? What input clock? What's ENA?

Maybe I had it backwards regarding CRT vs LCD compatibility. Speculating wildly about things I'm mostly ignorant of, maybe they work something like this:

CRTs: Contain something like simple LC oscillators for H and V frequency, which drive the electron beam, and which are dynamically adjusted through some analog-ish means to match the frequencies of the input HSYNC and VSYNC signals. I would expect this approach to also work OK if CSYNC is substituted for HSYNC, but that's only a guess.

LCDs: Contain digital circuitry that counts HSYNC pulses and measures HSYNC's and VSYNC's period, using those numbers to configure internal control logic. If even one of those measurements is far off the expected value, or the counted number of HSYNC pulses appears +/- 1 from the expected value, I could imagine it might cause failure.

It's a big speculation, but if true it would mean my LM1881 adapter will probably work for other CRTs but probably not for other LCDs.

 

[dougg3]

Yeah, in my head it definitely seems more likely that at least older CRTs would be doing analog-type stuff to make use of the sync signals whereas LCDs would be doing more digital-type stuff. In the end, on the LCD side anyway, it's probably going to vary based on what chipset is being used too. I tried to take apart my LCD and find out what display controller IC it uses, because it always seems to work with everything I throw at it. But unfortunately, I couldn't get the enclosure apart and I don't want to risk destroying it.

I wonder of the well-behaved monitors just use better display controller ICs that are better at detecting sync through multiple methods, or if their firmware is smarter about configuring the controller for different sync schemes to automatically detect if a signal is present?

What do you suppose SYNC_POR = 1 means? What input clock? What's ENA?

Yeah, that's where I got totally lost. The datasheet also says this about SYNC_POR = 1:

(Get the correct resolution which is triggered by enable signal, ENA)

Which doesn't really help much because I don't know what enable signal it's talking about. There is a DENA pin but I think it's dealing more with the LCD output rather than the inputs. This register in general seems to be involved with automatically detecting the polarity of vsync and hsync. It has two read-only bits indicating the polarity of vsync and hsync. I suppose the "hsync that is really csync" signal switching polarity during vsync could confuse it...

 

[Phipli]

I wonder of the well-behaved monitors just use better display controller ICs that are better at detecting sync through multiple methods, or if their firmware is smarter about configuring the controller for different sync schemes to automatically detect if a signal is present?

My most compatible LCD suspiciously acted like it was reprogramming an FPGA when exposed to new timings. It worked with absolutely anything and did 1:1, proportional scaling, stretched, PiP and PoP. I miss that screen.

But anyway, when it saw a previously unseen frequency, it would say something like "new resolution detected" and pause for a couple more seconds than usual before showing it.

 

[dougg3]

But anyway, when it saw a previously unseen frequency, it would say something like "new resolution detected" and pause for a couple more seconds than usual before showing it.

That's really cool! I have some experience working with Xilinx's video processing IP cores in an FPGA and...yeah...I could definitely imagine the monitor's firmware taking some time to collect info about the signal and setting up various registers for a scaler, video mixer, etc. to match the signal.

I just remembered I have another VGA LCD monitor: a Xenarc 1020TSV touchscreen. I can throw this into the contender list. The specs for this monitor don't specify supported refresh rates. Just a range of resolutions: 640x480 to 1920x1080. Here are my test results with it:

• Does not work with any 640x480 at 67 Hz modes on my IIci or 475 (switches 14xxx), regardless of what sync schemes I throw at it. It just says NOT_SUPPORT on the screen. This one probably does care about the refresh rate, oddly enough.
• Unfortunately I have no way of generating sync on green at 60 Hz, so I can't say whether this monitor supports it or not.
• Portrait mode on my IIci and 475 with separate syncs (23467) also results in NOT_SUPPORT.
• If I set it for 640x480, 60 Hz VGA mode with separate syncs (2367) it works on my 475. The monitor briefly prints "640x480_60Hz" in the upper left of the screen.
  • 235 does not work (NOT_SUPPORT), so it doesn't support composite sync by itself on hsync.
  • 2357 works, so whatever scheme it uses for detecting hsync alongside vsync is tolerant of hsync actually being composite sync.

I don't want to take this monitor apart too much, but it appears to have an Analog Devices AD9883A for VGA conversion to digital and a huge AYUTTHA AU300 chip that I can find no documentation about. According to the AD9883A datasheet, it uses HSYNC to feed a PLL to generate a pixel clock. There's an interesting section in this datasheet that I think is relevant to the work that @bigmessowires has been doing:



So yeah...it's clear from this description that (at least some) chip makers put thought into HSYNC being weird during VSYNC. Although in this case it seems that it depends on the manufacturer to hook up the COAST input properly to account for it.

I guess the only real conclusion I can draw from all of this is: LCDs are weird and you never know what's going to work. It all depends on the chips they used and how they wired them up. There's nothing in the datasheet for the AD9883A that says it's limited to 60 Hz, I feel like it may be an artificial limit in the firmware of this display...

 

[dougg3]

One last data point (I promise, this is the last): a random LCD controller board I bought on eBay a while back to reuse a 20" LCD from an old iMac. Uses an NT68676 controller -- no idea who the manufacturer is.

• Supports 640x480 at 67 Hz with sync on green from my IIci (switches 14)
• Supports portrait mode with separate syncs from my IIci (234)
• Supports 640x480 at 67 Hz with only composite sync on HSYNC from my 475 (145)
  • Also supports 1467 and 1457

 

[bigmessowires]

That's an interesting result from your Xenarc LCD. It does support CSYNC substituting for HSYNC, but doesn't support 640 x 480 @ 67 Hz. So there's no way it could ever work with a Mac IIci, no matter how you might process or split the sync signals.

We're diving into some very detailed weeds here, but my big question is this: would a Mac-to-VGA adapter with integrated sync-splitter be a useful thing for many people? If yes, I would continue to test and polish the concept, and eventually offer it in the BMOW store. I don't care if it made much money in sales, but I do care if it's actually filling a real need.

• Maybe there's no real need for this, because monitors with SOG and composite sync support are cheap and common enough, and anything newer than an LC can output separate H/V sync anyway?
  
  
• Or maybe there's no real value in this, because the LM1881 doesn't completely solve the problem anyway? It worked for my Viewsonic and E-Machines CRTs, but not for the VG900b and it wouldn't work for your Xenarc either.
  
  
• Maybe it would only be useful if the adapter had a more complex chip that could generate true HSYNC as well as VSYNC, instead of the LM1881? I'm not sure I'm actually interested in designing such a thing, but at least in theory.

In short, is this problem a big enough problem to even be worth addressing, and does the solution solve the problem well enough to be worthwhile?

 

[Phipli]

would a Mac-to-VGA adapter with integrated sync-splitter be a useful thing for many people? If yes, I would continue to test and polish the concept, and eventually offer it in the BMOW store. I don't care if it made much money in sales, but I do care if it's actually filling a real need.

Having a reliable source of adapters that give a good chance of working with most machines would be a huge benefit. Most Mac IIs, especially the IIci and older, possibly also the IIsi, are quite hard to get running and we spend a lot of time telling people they need an adapter, but not being able to point them at a reliable source.

I wouldn't expect a huge number of sales, but we have a couple of people struggling per month at least, combined with people who aren't here, I suspect there would be a fair few.

What is the cost impact of the sync chip on the final cost? My thought is that an approved monitor list might be an alternative solution, combined with simpler adapter, if the cost difference is large.

 

[dougg3]

I guess one question is: are the IIci and the IIsi the only Macs that have this problem? Or do some of the older NuBus video cards have the same problem with only generating csync? I've seen some mention that maybe the Quadra 700 is the same way, but I don't have one to test with. If the IIci and IIsi are the only two Macs that truly need your sync separator solution, there might not be much of a market for it...but it still seems like a converter with a sync separator would be a nice thing to have available for people who do need it. It's definitely a big improvement over the generic 10-switch adapters out there.

The big concern in my head is that you've already found a monitor that won't work with the current approach, and I've found one, albeit a weird one, that will never work with any approach. It will be difficult for people to know if the adapter will fix their particular problem unless there's a monitor compatibility list like Phipli mentioned. Will people be willing to pay for a "maybe" solution? Will it be a support nightmare every time someone buys one and can't get it to work with their random monitor?

To be brutally honest, I feel like since you've already found a monitor that doesn't like having composite sync instead of real hsync in a pretty small sample size of monitors, it would make for a better final product if your final sync splitter was able to provide a real hsync. I realize that complicates things though, both from a "more complex sync separator chip" and "needs another switch" standpoint Not to mention pricing, possibly...

But who knows. Maybe you hit the jackpot and that's like the only monitor in existence that has the weird problem with not accepting csync for hsync!

This last thing I'm going to mention may very well be a dumb idea, and I'm already thinking of deleting it as I write it, but I'll say it anyway. Feel free to ridicule me Is this a problem that people deal with in other vintage computing sects? Would there be any value in making your sync splitter a VGA-VGA thing instead, that assumes the input side has csync on the hsync pin and splits it out? I'm asking purely from the perspective of "ways to increase your market size". On the other hand, a Mac-specific adapter turns it into a great swiss army knife product for Mac aficionados to have around. Also, tech support for issues with random other vintage computers' video signals doesn't sound like a fun time...

 

[Phipli]

I guess one question is: are the IIci and the IIsi the only Macs that have this problem?

It will impact Toby cards too, which came with the II, IIx and IIcx. Obviously these can be replaced, or even fitted to newer Nubus Macs, but these Toby cards represent the biggest support problem for the forum. They sell "cheap" so lots of new users needing a card buy one then... Struggle to get video working.

I've seen some mention that maybe the Quadra 700 is the same way

I don't anticipate the Q700 has the same issue, it has way more advanced video and even supports MultiSync.

 

[bigmessowires]

I don't know what computers or video cards have this inability to output separate HSYNC and VSYNC at 640 x 480. There's a very relevant TinkerDifferent thread here: https://tinkerdifferent.com/threads/which-macintoshes-nubus-video-cards-only-do-sync-on-green.1048/

IIci and IIsi - definitely
IIvi, IIvx, Q700, early Apple NuBus video cards (Toby) - likely
Q900, LC, LCII - maybe?
Anything newer - probably not

we spend a lot of time telling people they need an adapter, but not being able to point them at a reliable source.

Right, that's what I'm thinking too. This adapter doesn't have to be only useful for sync splitting. It's a regular Mac to VGA adapter like all the others you'll find on eBay, and can work on any Mac model, but it also has an added feature of sync splitting. That seems like a valuable tool in anybody's toolkit, even if they won't need it very often, as long as it doesn't add a huge amount to the cost.

It will be difficult for people to know if the adapter will fix their particular problem unless there's a monitor compatibility list like Phipli mentioned. Will people be willing to pay for a "maybe" solution? Will it be a support nightmare every time someone buys one and can't get it to work with their random monitor?

Yes that's a very real concern. Unfortunately I don't think an approved monitor list is realistic, there are simply too many and I'm not interested in maintaining such a list. It would be important to make sure claims about the adapter are clear - it will split the sync signal. It will not guarantee your monitor will work with your computer. In the worst case, that could result in a lot of product returns or customer support headaches.

I suppose I could send some prototype units to beta testers and collect data on what did and didn't work, to get a sense of whether it mostly works with common monitor brands, or mostly doesn't.

What is the cost impact of the sync chip on the final cost?

The cost of the chip is only one factor; and the time cost of evaluating a new chip and prototyping and testing with it is another. If I'm starting over with a new chip... as of right this moment, I probably wouldn't choose to do that. I'm about to lose my stable of test monitors, and anyway I'm getting a bit tired of this whole saga. Maybe later I could look more into something like the LMH1980. But to answer your question, the LMH1980 would be about $1.30 to $3.00 more than the LM1881 depending on where parts are sourced and who does the assembly, which translates into something like a $4 to $8 difference in retail price for an item targeting a price around $25.

But all this may be moot, because I think I've found a way to get true HSYNC out of the LM1881, borrowing an idea from the Cadet I Sync Generator: https://www.siammodular.com/sites/default/files/Cadet I Sync Generator Schematics-min.pdf

This uses a one-shot (monostable multivibrator) which is triggered by negative edges on CSYNC, in order to generate a proper HSYNC. I had to stare at the schematic for a while, but I think it should work. They key part is the 74HC4538.

Good thing #1: I could test this right now if I had a 74HC4538. I think I can test it tomorrow (time permitting). I live nearby Jameco and they have this in stock, more or less. It's actually the 74123, which is a different monostable multivibrator and which doesn't mention any logic family like LS or HC. Maybe there are other stores I can try. Even though I'm in Silicon Valley, the days where you could walk into a retail store and buy an assortment of 74xxx chips over the counter are mostly gone.

Good thing #2: I think the "Sync Magician" adapters I've already designed and ordered could be hacked to do this! By sheer coincidence, I already included a 74HC123 for the "activity detection" LEDs on the board. If I remove the LED from the CSYNC detector, and replace the resistor and capacitor with different value ones, and solder a patch wire from the '123 /Q output to VGA HSYNC, I think it would do it.

 

[NJRoadfan]

Add the Apple IIgs to the list of machines that only outputs composite sync and sync-on-green. That and its 15.75khz RGB output. I think it might have been the first Apple machine with an analog RGB DB-15 port.

https://carnationsoftware.com/images/Apple_IIgs_RGB_pin_outs.jpeg

Note some difference in the pinout. I haven't had any issues using a Mac2VGA adapter with the machine however.

 

[bigmessowires]

I would imagine it's hard to find monitors that support a 15 kHz horizontal rate for the IIgs. That would be a bigger hurdle than the sync.

I'm sooo close on creating a real HSYNC signal. I don't have a one-shot chip, but I cobbled together a circuit using two NAND gates and a resistor and capacitor:



That's Mac CSYNC at the top, my extracted HSYNC in the middle, and LM1881 VSYNC at the bottom. All the timing looks correct and it's a real HSYNC, except there's some glitching on the HSYNC signal. The NAND gate input that's connected to the capacitor is seeing an invalid intermediate voltage level for a long time. If I had a Schmitt trigger input, or a real one-shot like the '4538, I think it would be clean.

I tried this on the VG900b, but still no success. Hopefully that's due to the glitching, and if I can clean that up, it will work. I'm afraid there might be more issues though, like the relative timing of HSYNC and VSYNC edges that I mentioned earlier. With a real HSYNC and VSYNC, the VSYNC falling edge comes slightly after the HSYNC falling edge. But with my setup, the VSYNC falling edge comes first.

A radical idea: After thinking it over, I don't actually need an LM1881 or any sync splitter chip for this. Those are all designed to do something much more complicated than I need: extract sync from composite video 0.7V signals. But I already have a composite sync signal separated from the video data and with standard TTL voltage levels, so this should be a much easier job. A simple 8-bit microcontroller and a 10-line assembly language program could probably do all the work. The relevant signals are dirt slow by MCU standards, in the tens of KHz range at most. The program could look for falling edges on CSYNC and generate a fixed width low pulse on HSYNC. It could also look for CSYNC remaining low more than about 3 us, and output a fixed width low pulse on VSYNC.

 

[Phipli]

I don't have a one-shot chip

Can you use a 555? You must have a 555, they grow in drawers.

 

[bigmessowires]

Good thought, yes I do. But the more I think about it, this is a job for a microcontroller. Then the pulse widths could be adjustable in software instead of fixed by RC component values, and I can set the length of VSYNC to whatever I want, and advance or retard the relative timing of VSYNC versus HSYNC, and blink LEDs, and whatever else I want to do, all with a single chip that costs the same or less than the LM1881. I could even do crazy stuff like write the current h and v refresh rates to the serial port for debugging. The only slight downside is it would need to be programmed, so I'd either need to build a programming header into the adapter or get the chips pre-programmed from the parts distributor.

 

[NJRoadfan]

The only situation I can think of that would require a LM1881 and friends is Sync-on-Green. I don't know how many Macintosh video cards solely output that style of sync.

 

[bigmessowires]

Yes that's just what I was thinking. For the IIci and IIsi we've seen that you get both CSYNC and sync on green. Are there any Mac models or video cards that output only sync on green? Anybody have an old NuBus card like a Toby, or Ivi, IIvx, Q700, Q900, LC, LCII and able to test it?

 

[Phipli]

Yes that's just what I was thinking. For the IIci and IIsi we've seen that you get both CSYNC and sync on green. Are there any Mac models or video cards that output only sync on green? Anybody have an old NuBus card like a Toby, or Ivi, IIvx, Q700, Q900, LC, LCII and able to test it?

This implies that the IIci style video out was what was used by the first few macs / cards.

Apple Vintage Mac Monitor Connections

But note that there were some sense pin weirdness in the original Toby

 

[bigmessowires]

Now I'm realizing some reasons why using a microcontroller maybe isn't a great idea: jitter and delay.

• The built-in synchronizer on the inputs adds 1-2 clock cycles of delay, limiting how quickly outputs can respond to inputs
• The edges of the output sync signals will all get quantized to the mcu system clock, which introduces some jitter relative to the CSYNC input and the pixel data
• The tightest loop for "wait until CSYNC goes low" still takes several clock cycles to execute, and depending on when the edge hits relative to that polling loop, there can be a few more clock cycles of jitter.

A faster clock speed helps, but that makes the mcu consume more current and makes it harder to achieve self-powering from the Mac's video port. And the jitter would need to be reduced to less than 1 pixel's worth of time (about 33 ns here) before it might become small enough to be tolerable. That implies a mcu clock of at least 33 MHz and probably more like 100+ MHz.