-
Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.
Designing a Mac-to-VGA monitor sync-splitter adapter
- Thread starter bigmessowires
- Start date
Phipli
Well-known member
It might just need recapping. My ViewSonic had a single failed cap on the power board that made it power cycle constantly.
bigmessowires
Well-known member
I had some more time today for finishing up the VGA Syncinator. All the other sync pass-through modes are working now, which wasn't necessarily a given. The "pass-through" isn't a physical switch, but a microcontroller function using built-in programmable logic cells to asynchronously copy signals between input and output pins. I also have the LEDs working to detect the presence of different kinds of sync input signals, which again wasn't necessarily a given, but I used another hardware feature of the MCU to detect changes on those pins without code polling and it worked out OK.
The only task that remains is seeing whether I can support the Apple Toby and SuperMac ColorCard composite sync signal formats somehow. Unlike the composite sync from the Mac IIci, IIsi, and other Apple video cards, the Toby and SuperMac csync signals are a bit weird in different ways and my MCU code isn't able to extract hsync and vsync from them.
Here's a normal csync, like the Mac IIci generates. The signal is normally high, but there's a short low pulse after every line. Once per frame, the polarity of the signal is reversed for a few lines - this inversion is the vsync signal.
The important detail is that falling edges of csync are always regularly spaced, even during the inverted vsync period. The microcontroller uses this to derive timing information for a synthetic hsync signal to feed to the monitor. Now contrast this with the csync signal from the Apple Toby:
During vsync, the signal polarity isn't reversed - it's simply flatlined at zero so there's no timing information I can use to generate synthetic hsync pulses. The falling edges of sync aren't always regularly spaced either. They're mostly consistent, but during the lines just before and just after vsync you can see the csync pulses are suddenly twice as frequent as normal.
The SuperMac card has the same flatlined zero behavior as the Toby, but not the double-speed csync pulse behavior.
The double-speed csync pulses seem like maybe they could be filtered out by ignoring any csync pulse that arrives too soon after that previous pulse. But what's "too soon"? If I could assume a specific video resolution then I could probably use a fixed time duration for the filter, but if the video resolution might change then I probably need to measure the normal duration between pulses and then create a dynamic filter threshold based on that. Even if I knew exactly how long to make the filter, I'm not yet sure how I would implement it, since csync is triggering a hardware peripheral in the microcontroller rather than being polled by generic program code.
I will probably focus on the flatlined zero problem first, since it's shared by both video cards, but I don't have any great ideas how to solve it. In theory the microcontroller needs to measure the average time between csync pulses, and detect cases where a csync pulse doesn't arrive within a small error window around the expected time, and then insert a synthetic pulse instead. That might be plausible if I were using a super-fast microcontroller and all of this behavior was implemented in program code, but I'm relying heavily on hardware peripherals in the chip. Maybe I can rig up some clever scheme of enabling and disabling interrupts at certain times to trigger a behavior for a missed csync pulse. There will necessarily be jitter in the synthetic pulses though, plus some delay between the end of the window where csync was expected and the start of the time where the synthetic pulse is generated. From my earlier experiments, many monitors don't react well to this kind of jitter and variance in sync signal timing, so the whole approach may not even be viable. I guess I'll find out.
The only task that remains is seeing whether I can support the Apple Toby and SuperMac ColorCard composite sync signal formats somehow. Unlike the composite sync from the Mac IIci, IIsi, and other Apple video cards, the Toby and SuperMac csync signals are a bit weird in different ways and my MCU code isn't able to extract hsync and vsync from them.
Here's a normal csync, like the Mac IIci generates. The signal is normally high, but there's a short low pulse after every line. Once per frame, the polarity of the signal is reversed for a few lines - this inversion is the vsync signal.
The important detail is that falling edges of csync are always regularly spaced, even during the inverted vsync period. The microcontroller uses this to derive timing information for a synthetic hsync signal to feed to the monitor. Now contrast this with the csync signal from the Apple Toby:
During vsync, the signal polarity isn't reversed - it's simply flatlined at zero so there's no timing information I can use to generate synthetic hsync pulses. The falling edges of sync aren't always regularly spaced either. They're mostly consistent, but during the lines just before and just after vsync you can see the csync pulses are suddenly twice as frequent as normal.
The SuperMac card has the same flatlined zero behavior as the Toby, but not the double-speed csync pulse behavior.
The double-speed csync pulses seem like maybe they could be filtered out by ignoring any csync pulse that arrives too soon after that previous pulse. But what's "too soon"? If I could assume a specific video resolution then I could probably use a fixed time duration for the filter, but if the video resolution might change then I probably need to measure the normal duration between pulses and then create a dynamic filter threshold based on that. Even if I knew exactly how long to make the filter, I'm not yet sure how I would implement it, since csync is triggering a hardware peripheral in the microcontroller rather than being polled by generic program code.
I will probably focus on the flatlined zero problem first, since it's shared by both video cards, but I don't have any great ideas how to solve it. In theory the microcontroller needs to measure the average time between csync pulses, and detect cases where a csync pulse doesn't arrive within a small error window around the expected time, and then insert a synthetic pulse instead. That might be plausible if I were using a super-fast microcontroller and all of this behavior was implemented in program code, but I'm relying heavily on hardware peripherals in the chip. Maybe I can rig up some clever scheme of enabling and disabling interrupts at certain times to trigger a behavior for a missed csync pulse. There will necessarily be jitter in the synthetic pulses though, plus some delay between the end of the window where csync was expected and the start of the time where the synthetic pulse is generated. From my earlier experiments, many monitors don't react well to this kind of jitter and variance in sync signal timing, so the whole approach may not even be viable. I guess I'll find out.
bigmessowires
Well-known member
The final pieces are coming together now, and I've got everything mostly working on the Toby card and the SuperMac ColorCard SE/30, as well as the other more normal cards and Mac models.
What do you do with a microcontroller-based VGA adapter when you have one free pin remaining? Turn it into a serial port, naturally. You wanted sync info? You wanted debugging info for that one crazy video card? Are sync indicator LEDs not good enough for you? Connect a serial monitor and now you can get the full report:
Toby card at 640x480:
SuperMac ColorCard SE/30 at 1024x768:
What do you do with a microcontroller-based VGA adapter when you have one free pin remaining? Turn it into a serial port, naturally. You wanted sync info? You wanted debugging info for that one crazy video card? Are sync indicator LEDs not good enough for you? Connect a serial monitor and now you can get the full report:
Toby card at 640x480:
SuperMac ColorCard SE/30 at 1024x768:
bigmessowires
Well-known member
Pin 8 has no connection on the standard Mac video port, but pin 7 is sense bit 1. Depending on how you set the DIP switches, that could connect -5 volts to sense bits 0 and 2 (pins 4 and 10) or to ground. Maybe it's possible to work on the IIgs, but at the risk of a miconfigured DIP swtich setting causing a short-circuit in the power supply?
EDIT: It looks like the Apple IIgs also puts sound on pin 11 and monochrome video on pin 12, which are respectively VSYNC/CSYNC ground and VSYNC on a Mac.
EDIT: It looks like the Apple IIgs also puts sound on pin 11 and monochrome video on pin 12, which are respectively VSYNC/CSYNC ground and VSYNC on a Mac.
Last edited:
FWIW, I have had no ill effects using a Belkin Mac-VGA adapter setup to "pass thru H+V sync" and sense code "VGA/Super VGA", which appears to connect Sense 2 (pin 10) to Sense 1 (pin 7). Maybe it was dumb luck on my part (since I never checked this), but that combo was safely sending -5v to a pin that had no connection!
bigmessowires
Well-known member
This has become a project where the closer it gets to finished, the slower the progress moves. I'm discovering that software-generated sync signals are easy to get mostly right. I have an ever-expanding test matrix of video sources, video resolutions, and monitors, and whenever I make a little change to address a problem somewhere then I have to go back and start over to verify I didn't introduce any new problems. It feels like playing wack-a-mole.
IIgs support should be working, and I'll receive a 15kHz-capable monitor soon where I can test it directly. I accidentally tried the "evil" DIP switch combination that results in shorting the IIgs -5V and GND supplies, and it caused a funny noise and failure to turn on, but no lasting damage that I could see. So yes @NJRoadfan I think you were OK because your adapter never connects the "bad" pins. From what I've seen, aside from the 15.7 kHz horizontal rate, the IIgs composite sync is also different from any of the Mac or Mac video cards that I've looked at.
I've repurposed one of the DIP switch settings to be "automatic sync detection". If it works correctly, which it mostly does, then you can leave it on that setting and it'll always do the right thing about passing through hsync and vsync if they're present, or else converting csync into new hsync and vsync signals.
Where I'm at right now, everything pretty much works, but there are lots of carefully-tuned parameters and code paths for different cases, and whenever I change anything it tends to have unintended consequences somewhere else. I need to take a step back and rethink, and see if a different approach might be more robust and require fewer special cases.
During my experiments I've collected an interesting variety of failure modes:
- no picture
- "out of range" error when it's not out of range
- picture sporadically blinks on and off
- every line is randomly offset horizontally by a few pixels
- picture bounces up and down like it's vibrating
- picture rolls vertically like an analog TV with the wrong vertical hold setting
- monitor becomes totally unresponsive and must be reset (happened several times on different monitors)
IIgs support should be working, and I'll receive a 15kHz-capable monitor soon where I can test it directly. I accidentally tried the "evil" DIP switch combination that results in shorting the IIgs -5V and GND supplies, and it caused a funny noise and failure to turn on, but no lasting damage that I could see. So yes @NJRoadfan I think you were OK because your adapter never connects the "bad" pins. From what I've seen, aside from the 15.7 kHz horizontal rate, the IIgs composite sync is also different from any of the Mac or Mac video cards that I've looked at.
I've repurposed one of the DIP switch settings to be "automatic sync detection". If it works correctly, which it mostly does, then you can leave it on that setting and it'll always do the right thing about passing through hsync and vsync if they're present, or else converting csync into new hsync and vsync signals.
Where I'm at right now, everything pretty much works, but there are lots of carefully-tuned parameters and code paths for different cases, and whenever I change anything it tends to have unintended consequences somewhere else. I need to take a step back and rethink, and see if a different approach might be more robust and require fewer special cases.
During my experiments I've collected an interesting variety of failure modes:
- no picture
- "out of range" error when it's not out of range
- picture sporadically blinks on and off
- every line is randomly offset horizontally by a few pixels
- picture bounces up and down like it's vibrating
- picture rolls vertically like an analog TV with the wrong vertical hold setting
- monitor becomes totally unresponsive and must be reset (happened several times on different monitors)
bigmessowires
Well-known member
Well, this composite-splitter VGA adapter effort is still ongoing. It was 95 percent working, but it was full of special case code for specific video resolutions, and I wasn't happy with it. So I went back to the drawing board with a different approach. I will spare you most of the boring details, but this approach is more generic (less special-case code), eliminates most jitter on falling and rising edges, and is generally more faithful to the original signal. It also allows for changing the video resolution on the fly, including with MaxAppleZoom. But the new method is slightly worse in some other respects, and struggles a bit more with the Toby video card's signal. So it still needs more testing and tuning.
I have a massive spreadsheet of 10 monitors times 12 video sources times 4 sync methods, and whenever I tweak something, I need to go back and try them all again. It's been unexpectedly hard to test if something "works", but it's not a simple yes or no. I've had some tests where everything appears fine initially, but extended testing shows that the picture glitches out briefly every 5, 10, or 20 minutes or so. Ooof!
I'm still waiting on a 15 kHz capable monitor for IIgs testing, but I believe it should work.
Some day this will be finished.
I have a massive spreadsheet of 10 monitors times 12 video sources times 4 sync methods, and whenever I tweak something, I need to go back and try them all again. It's been unexpectedly hard to test if something "works", but it's not a simple yes or no. I've had some tests where everything appears fine initially, but extended testing shows that the picture glitches out briefly every 5, 10, or 20 minutes or so. Ooof!
I'm still waiting on a 15 kHz capable monitor for IIgs testing, but I believe it should work.
Some day this will be finished.
olePigeon
Well-known member
@bigmessowires Late to the thread, but, what about Full Page Displays? The 3rd party cards tend to have really weird timings.
Skate323k137
Well-known member
I hope to see this come to completion, some day when it all feels right.
I was lucky to get a couple of these, some years ago, for very cheap:
https://www.extron.com/product/ss200
They can strip sync on green among other things, but you need at least one BNC breakout cable, so while the function is amazing the wiring ends up bulky. And sadly this device will NOT handle 15K rgb
I was lucky to get a couple of these, some years ago, for very cheap:
https://www.extron.com/product/ss200
They can strip sync on green among other things, but you need at least one BNC breakout cable, so while the function is amazing the wiring ends up bulky. And sadly this device will NOT handle 15K rgb
bigmessowires
Well-known member
@olePigeon Full page displays should be OK, I think, but I'd need some help with testing 3rd-party FPD video cards. Full page displays might not be the best example though, since even with proper sync signals and a VGA adapter, most modern monitors won't be able to display a 640x870 image correctly. And at least on the Mac IIci, the built-in 640x870 video mode already uses separate hsync and vsync signals, so a sync splitter isn't needed.
@Skate323k137 the Extron seems like a great device and I've heard many people singing its praises. The Sync-inator isn't intended to compete with that though. From what I've heard about it, the Extron can do upscaling and other fancy things. The Sync-inator is a small in-line dongle that aims to be a "Pro version" of the Mac to VGA adapters you likely already have, and that takes some of the frustration out of the Mac-to-monitor setup dance, and enables some new combinations of video sources and monitors to work together that were previously incompatible.
The Sync-inator works by rerouting, modifying, or splitting the sync signals from the video source before they're sent to the monitor. It'll do everything that adapters like these will do, plus more:
The timing and resolution of the actual video signal are not modified in any way, only the sync. So your monitor still needs to support the resolution and timing of your video source.
The "pro" features of the Sync-inator over standard VGA adapters are:
- It can split a composite sync signal into separate hsync and vsync signals. This is essential for some older video sources that only provide composite sync (the Mac IIci and IIsi built-in video, Toby Nubus video card, Mac II monochrome card, and some earlier third-party cards). Some monitors can handle composite sync or sync on green, but many can't, so for those monitors a sync splitter is required. This is what motivated this project initially, trying to get my IIci built-in video working on one such monitor.
- It can auto-detect and auto-configure the sync behavior, reducing the typical setup hassles experienced with other adapters. If it senses that hsync and vsync signals are already present, it'll simply pass them through. If those signals aren't present, then it'll kick over to composite sync splitter mode.
- It has two LEDs that will visually show you whether the video source is outputting composite sync, separate h and vsync, both, or neither. This should further reduce setup hassles, by making it easy to distinguish between cases where you get no picture due to sync/resolution compatibility problems versus cases where the video source isn't outputting anything at all.
- It has a serial port that will dump a bunch of diagnostic info about the video source and its characteristics and timing. That's fun for video nerds, maybe useful for something.
"Sync splitting" is a slightly misleading term, because it sounds like you already have two signals that you simply need to separate. In reality it's more like "sync generation", synthesizing two wholly new hsync and vsync signals using the csync signal as a reference. This is straightforward in theory, but in practice it's proven challenging to get every timing detail 100 percent right, so that's where all the development time has gone. Along the way I've discovered that some monitors care about certain aspects of hsync and vsync that others don't seem to: like whether they trigger from the hsync falling edge, rising edge, or both edges, their sensitivity to changes in hsync pulse width, and their behavior when the relative timing between hsync and vsync edges changes. So I've amassed a growing stable of new and old monitors for compatibility testing.
@Skate323k137 the Extron seems like a great device and I've heard many people singing its praises. The Sync-inator isn't intended to compete with that though. From what I've heard about it, the Extron can do upscaling and other fancy things. The Sync-inator is a small in-line dongle that aims to be a "Pro version" of the Mac to VGA adapters you likely already have, and that takes some of the frustration out of the Mac-to-monitor setup dance, and enables some new combinations of video sources and monitors to work together that were previously incompatible.
The Sync-inator works by rerouting, modifying, or splitting the sync signals from the video source before they're sent to the monitor. It'll do everything that adapters like these will do, plus more:
The timing and resolution of the actual video signal are not modified in any way, only the sync. So your monitor still needs to support the resolution and timing of your video source.
The "pro" features of the Sync-inator over standard VGA adapters are:
- It can split a composite sync signal into separate hsync and vsync signals. This is essential for some older video sources that only provide composite sync (the Mac IIci and IIsi built-in video, Toby Nubus video card, Mac II monochrome card, and some earlier third-party cards). Some monitors can handle composite sync or sync on green, but many can't, so for those monitors a sync splitter is required. This is what motivated this project initially, trying to get my IIci built-in video working on one such monitor.
- It can auto-detect and auto-configure the sync behavior, reducing the typical setup hassles experienced with other adapters. If it senses that hsync and vsync signals are already present, it'll simply pass them through. If those signals aren't present, then it'll kick over to composite sync splitter mode.
- It has two LEDs that will visually show you whether the video source is outputting composite sync, separate h and vsync, both, or neither. This should further reduce setup hassles, by making it easy to distinguish between cases where you get no picture due to sync/resolution compatibility problems versus cases where the video source isn't outputting anything at all.
- It has a serial port that will dump a bunch of diagnostic info about the video source and its characteristics and timing. That's fun for video nerds, maybe useful for something.
"Sync splitting" is a slightly misleading term, because it sounds like you already have two signals that you simply need to separate. In reality it's more like "sync generation", synthesizing two wholly new hsync and vsync signals using the csync signal as a reference. This is straightforward in theory, but in practice it's proven challenging to get every timing detail 100 percent right, so that's where all the development time has gone. Along the way I've discovered that some monitors care about certain aspects of hsync and vsync that others don't seem to: like whether they trigger from the hsync falling edge, rising edge, or both edges, their sensitivity to changes in hsync pulse width, and their behavior when the relative timing between hsync and vsync edges changes. So I've amassed a growing stable of new and old monitors for compatibility testing.
Skate323k137
Well-known member
Thanks for all that!
to be clear the SS 200 is not a scaler in any way. It's only a sync processor. Extron makes a whole line of scalers and transcoders but this is not one.
to be clear the SS 200 is not a scaler in any way. It's only a sync processor. Extron makes a whole line of scalers and transcoders but this is not one.
bigmessowires
Well-known member
All the normal Mac-to-VGA features are working well, but getting to 100% on composite sync splitting is proving to be very hard. It works for most combinations of video sources and monitors, but not all of them, and code changes that fix one combination may break another. When a monitor won't sync to the signal, it doesn't tell me why... it just blinks unhelpfully or shows a black screen. There's a lot of futzing around in 100 nanosecond increments trying to guess what the issue is.
I'll keep poking at it for a while more, but I'm beginning to think that a microcontroller-generated composite sync splitter just isn't going to work in every single case, and I'll just need to optimize for working in the largest number of cases possible. The idea is basically that this tool is still useful if it does everything that existing VGA adapters do, plus most of the extra stuff I'd hoped it would do, even if it doesn't cover EVERY case that I'd hoped it might.
There's one design question that I'd be interesting to hear people's opinions about. With the DIP switches you can choose one of four possible behaviors: hsync and vsync pass-through, csync pass-through, csync splitting into hsync and vsync, or automatic sync detection. The first two are needed in order to match the capabilities of standard VGA adapters, and the third one is this project's special sauce. But I could get rid of the "automatic" option and replace it a second csync splitting method instead. The idea is that if you needed csync splitting, and you were unlucky enough that the standard method didn't work on your video source or monitor, you could try an alternate csync splitting method. Two choices are better than one.
But I'm leaning towards keeping the "automatic" setting and not including a csync splitter method #2, because the automatic setting is useful to everyone all the time, but the csync splitter method #2 would only be useful to a small number of people in rare cases. And in those cases, I couldn't guarantee it would work anyway - maybe method #1 and #2 both wouldn't work.
Another possibility - this is a microcontroller and it has EEPROM memory where it could save configuration settings. There just isn't any UI where somebody could configure those settings. But maybe a "better than nothing" option would be a back-door way to enable csync splitter methods #2, #3, #4, etc that then gets saved in EEPROM. But if the method is too awkward or obscure then it's not much good anyway.
I'll keep poking at it for a while more, but I'm beginning to think that a microcontroller-generated composite sync splitter just isn't going to work in every single case, and I'll just need to optimize for working in the largest number of cases possible. The idea is basically that this tool is still useful if it does everything that existing VGA adapters do, plus most of the extra stuff I'd hoped it would do, even if it doesn't cover EVERY case that I'd hoped it might.
There's one design question that I'd be interesting to hear people's opinions about. With the DIP switches you can choose one of four possible behaviors: hsync and vsync pass-through, csync pass-through, csync splitting into hsync and vsync, or automatic sync detection. The first two are needed in order to match the capabilities of standard VGA adapters, and the third one is this project's special sauce. But I could get rid of the "automatic" option and replace it a second csync splitting method instead. The idea is that if you needed csync splitting, and you were unlucky enough that the standard method didn't work on your video source or monitor, you could try an alternate csync splitting method. Two choices are better than one.
But I'm leaning towards keeping the "automatic" setting and not including a csync splitter method #2, because the automatic setting is useful to everyone all the time, but the csync splitter method #2 would only be useful to a small number of people in rare cases. And in those cases, I couldn't guarantee it would work anyway - maybe method #1 and #2 both wouldn't work.
Another possibility - this is a microcontroller and it has EEPROM memory where it could save configuration settings. There just isn't any UI where somebody could configure those settings. But maybe a "better than nothing" option would be a back-door way to enable csync splitter methods #2, #3, #4, etc that then gets saved in EEPROM. But if the method is too awkward or obscure then it's not much good anyway.
bigmessowires
Well-known member
Good news, bad news for Apple IIgs fans: the Sync-inator does work on the GS when you have a monitor that can handle 15 kHz, but it doesn't work the way I'd expected. Composite sync splitting of the 15 kHz GS signal doesn't work very well, but proves to be mostly unnecessary anyway. Here's the GS/OS desktop in all its glory:
Chapter 1: I bought a Samsung SyncMaster 512N specifically because it was reported to work at 15 kHz with the IIgs, in this page at Manila Gear: https://manilagear.com/vga-monitors-for-the-apple-iigs/ Unfortunately it didn't work. The 512N's activity LED would turn green and the backlight would turn on, but no picture would appear. The monitor's front panel buttons were also unresponsive, as if the monitor firmware were frozen. I tried this in composite sync splitting mode, as well as sync-on-green and csync-to-hsync modes, with the same behavior every time. The failure in sync splitting mode could be a flaw with the Sync-inator, but the other modes should definitely work since this monitor supports 15 kHz as well as SOG and csync-to-hsync (I confirmed the sync support with some other video sources).
So I started doing some digging. In the manual for this monitor, it lists 30 kHz as the lowest supported refresh rate, not 15 kHz: https://www.manua.ls/samsung/syncmaster-512n/manual?p=67 Then I found a handy web page with a big list of older monitors and their 15 kHz support: http://15khz.wikidot.com/ This page lists the 510N's 15 kHz capabilities as "partial". It doesn't have an entry for the 512N, but I think they're the same thing with and without audio speakers. The other SyncMasters in the same product series were also listed as "partial" or "no".
After doing more reading, this leads me to believe that 15 kHz is an undocumented feature that may only work on some 512N samples. Either Samsung changed what parts are used during the product's lifetime without changing the model number, or it's a question of engineering tolerances and manufacturing variability whether 15 kHz works or not. In my case, the answer seems to be "not".
Chapter 2: But hang on, that handy web page also listed the Asus VE228H as having full 15 kHz support, and that just happens to be one of the eleven monitors in my growing fleet of test equipment. So I hooked up the VE228H in sync-on-green mode, and it worked! I also tried the mode where csync is sent to the monitor's hsync input, and that worked too, even when I physically cut the green video line to be certain it wasn't sneakily using SOG.
Sadly the Sync-inator's csync splitting didn't work on the VE228H - mostly it just showed a blank screen or "out of range". That's OK because csync splitting isn't needed in this case anyway, since you can use one of the other sync modes instead. But it meant that something wasn't quite right with my 15 kHz sync-split signal, which might eventually be a problem in other settings with other monitors. I spent a long time fiddling with parameters and attempting to hand-tune to resulting sync signals to be as good as possible, and while I did succeed in getting the IIgs video to appear for brief moments, I never found a combination that worked reliably.
Just for grins, I reverted all my Sync-inator code changes back to December 20, when I had completely changed the way the sync splitting is performed, and that old December 20 version actually worked!
Chapter 3: So now what? I can't change all the code back to how it was on December 20, because the recent changes were made for good reasons for compatibility with many other Mac video sources and monitors. And I can't include both versions as a user-selectable option with a switch, because there's not enough room in the microcontroller flash and also because there are no spare DIP switches unless I do another hardware update.
But maybe I don't need to. Looking at that 15 kHz web page again, most of the comments for monitors that worked say that they were tested with a simple pass-through adapter, and not any fancy csync splitting. How common would it be to find a monitor to supports 15 kHz on its separate hsync/vsync inputs but that can't support that same signal as SOG or csync-to-hsync? Those comments would suggest it's rare.
I think I'll probably remove explicit IIgs support from the csync-splitting code, since it doesn't work in its current incarnation, and since most of the time you should be able to use another sync mode with the IIgs (assuming your monitor is up to the task). Removing the IIgs code would slightly simplify the main loop for csync splitting, enabling it to run a bit faster, which might also help in other areas. So the answer to "Does Sync-inator support the Apple IIgs" will be "yes it's supported with two different passive sync translation modes, if your monitor can handle it.
Chapter 4: With that, I think I've nearly reached the end of compatibility testing. I've added a feature that dynamically changes the microcontroller's system clock speed depending on the supply voltage it detects, which allows for slightly more precise csync splitting behavior when power is available. This has no affect on the other sync translation modes.
Current status:
- "Normal" Mac-to-VGA adapter behaviors are 100% working, including setting the desired video resolution through DIP switches, and choosing a passive sync translation mode. This matches the capabilities of other adapters like Belkin, etc.
- For troubleshooting help,. the csync and hsync/vsync activity LEDs are working, and the serial port output is working. The default DIP switch setting for sync mode is also "automatic", which aims to reduce guesswork and reconfiguration.
- For the Mac IIci and IIsi, composite sync splitting is 100% working on every monitor that I've tested. That was my main goal, and it's met. This enables the IIci and IIsi to work on a wider selection of monitors than before.
- For the Macintosh Monochrome Card, composite sync splitting is working out-of-the-box with >90% of monitors tested, and the only holdout works if you attach an external 5V power supply.
- I could only find two other Mac video cards that don't output separate hsync/vsync signals and that would benefit from csync splitting. The Toby Nubus video card works with >90% of the monitors tested, although two monitors worked by ignoring the csync splitting and using sync-on-green. One stubborn monitor would not work with the Toby. I would rate csync splitting support for Toby as 4.5 out of 5 stars.
- The SuperMac ColorCard SE/30 fared similar to the Toby, with csync splitting working with > 90% of monitors tested but with a couple of instances where the monitor reverted to using sync-on-green. It worked best at 640x480 resolution, and still worked well at 1024x768 although two monitors showed a slight shimmer at this resolution when the adapter is self-powered. The 1024x768 image was stable on those monitors if you attach an external 5V power supply. I would rate csync splitting support for this SuperMac card as 4 out of 5 stars.
- Most of the time you won't need csync splitting mode, because you're not using a crusty old video source with composite sync or because your monitor supports SOG or csync-to-hsync. Those cases are completely working, 5 out of 5 stars.
I still need to clean up a few loose ends here, but it's good progress and I'm finally starting to see the light at the end of the tunnel.
Chapter 1: I bought a Samsung SyncMaster 512N specifically because it was reported to work at 15 kHz with the IIgs, in this page at Manila Gear: https://manilagear.com/vga-monitors-for-the-apple-iigs/ Unfortunately it didn't work. The 512N's activity LED would turn green and the backlight would turn on, but no picture would appear. The monitor's front panel buttons were also unresponsive, as if the monitor firmware were frozen. I tried this in composite sync splitting mode, as well as sync-on-green and csync-to-hsync modes, with the same behavior every time. The failure in sync splitting mode could be a flaw with the Sync-inator, but the other modes should definitely work since this monitor supports 15 kHz as well as SOG and csync-to-hsync (I confirmed the sync support with some other video sources).
So I started doing some digging. In the manual for this monitor, it lists 30 kHz as the lowest supported refresh rate, not 15 kHz: https://www.manua.ls/samsung/syncmaster-512n/manual?p=67 Then I found a handy web page with a big list of older monitors and their 15 kHz support: http://15khz.wikidot.com/ This page lists the 510N's 15 kHz capabilities as "partial". It doesn't have an entry for the 512N, but I think they're the same thing with and without audio speakers. The other SyncMasters in the same product series were also listed as "partial" or "no".
After doing more reading, this leads me to believe that 15 kHz is an undocumented feature that may only work on some 512N samples. Either Samsung changed what parts are used during the product's lifetime without changing the model number, or it's a question of engineering tolerances and manufacturing variability whether 15 kHz works or not. In my case, the answer seems to be "not".
Chapter 2: But hang on, that handy web page also listed the Asus VE228H as having full 15 kHz support, and that just happens to be one of the eleven monitors in my growing fleet of test equipment. So I hooked up the VE228H in sync-on-green mode, and it worked! I also tried the mode where csync is sent to the monitor's hsync input, and that worked too, even when I physically cut the green video line to be certain it wasn't sneakily using SOG.
Sadly the Sync-inator's csync splitting didn't work on the VE228H - mostly it just showed a blank screen or "out of range". That's OK because csync splitting isn't needed in this case anyway, since you can use one of the other sync modes instead. But it meant that something wasn't quite right with my 15 kHz sync-split signal, which might eventually be a problem in other settings with other monitors. I spent a long time fiddling with parameters and attempting to hand-tune to resulting sync signals to be as good as possible, and while I did succeed in getting the IIgs video to appear for brief moments, I never found a combination that worked reliably.
Just for grins, I reverted all my Sync-inator code changes back to December 20, when I had completely changed the way the sync splitting is performed, and that old December 20 version actually worked!
Chapter 3: So now what? I can't change all the code back to how it was on December 20, because the recent changes were made for good reasons for compatibility with many other Mac video sources and monitors. And I can't include both versions as a user-selectable option with a switch, because there's not enough room in the microcontroller flash and also because there are no spare DIP switches unless I do another hardware update.
But maybe I don't need to. Looking at that 15 kHz web page again, most of the comments for monitors that worked say that they were tested with a simple pass-through adapter, and not any fancy csync splitting. How common would it be to find a monitor to supports 15 kHz on its separate hsync/vsync inputs but that can't support that same signal as SOG or csync-to-hsync? Those comments would suggest it's rare.
I think I'll probably remove explicit IIgs support from the csync-splitting code, since it doesn't work in its current incarnation, and since most of the time you should be able to use another sync mode with the IIgs (assuming your monitor is up to the task). Removing the IIgs code would slightly simplify the main loop for csync splitting, enabling it to run a bit faster, which might also help in other areas. So the answer to "Does Sync-inator support the Apple IIgs" will be "yes it's supported with two different passive sync translation modes, if your monitor can handle it.
Chapter 4: With that, I think I've nearly reached the end of compatibility testing. I've added a feature that dynamically changes the microcontroller's system clock speed depending on the supply voltage it detects, which allows for slightly more precise csync splitting behavior when power is available. This has no affect on the other sync translation modes.
Current status:
- "Normal" Mac-to-VGA adapter behaviors are 100% working, including setting the desired video resolution through DIP switches, and choosing a passive sync translation mode. This matches the capabilities of other adapters like Belkin, etc.
- For troubleshooting help,. the csync and hsync/vsync activity LEDs are working, and the serial port output is working. The default DIP switch setting for sync mode is also "automatic", which aims to reduce guesswork and reconfiguration.
- For the Mac IIci and IIsi, composite sync splitting is 100% working on every monitor that I've tested. That was my main goal, and it's met. This enables the IIci and IIsi to work on a wider selection of monitors than before.
- For the Macintosh Monochrome Card, composite sync splitting is working out-of-the-box with >90% of monitors tested, and the only holdout works if you attach an external 5V power supply.
- I could only find two other Mac video cards that don't output separate hsync/vsync signals and that would benefit from csync splitting. The Toby Nubus video card works with >90% of the monitors tested, although two monitors worked by ignoring the csync splitting and using sync-on-green. One stubborn monitor would not work with the Toby. I would rate csync splitting support for Toby as 4.5 out of 5 stars.
- The SuperMac ColorCard SE/30 fared similar to the Toby, with csync splitting working with > 90% of monitors tested but with a couple of instances where the monitor reverted to using sync-on-green. It worked best at 640x480 resolution, and still worked well at 1024x768 although two monitors showed a slight shimmer at this resolution when the adapter is self-powered. The 1024x768 image was stable on those monitors if you attach an external 5V power supply. I would rate csync splitting support for this SuperMac card as 4 out of 5 stars.
- Most of the time you won't need csync splitting mode, because you're not using a crusty old video source with composite sync or because your monitor supports SOG or csync-to-hsync. Those cases are completely working, 5 out of 5 stars.
I still need to clean up a few loose ends here, but it's good progress and I'm finally starting to see the light at the end of the tunnel.
bigmessowires
Well-known member
I'm declaring the Sync-inator ready for public consumption. I've tested a million different combinations of monitors and video sources and it's finally good to go, four months after the adventure started with my Mac IIci and some Craigslist monitors that wouldn't cooperate.
The current situation at BMOW HQ is monitors, monitors, everywhere!
I made a last-minute change to one of the alternate sync-handling methods, to make it functionally identical to an LM1881-based VGA adapter like my original prototype or like the Manila Gear IIgs adapter. So the Sync-inator will offer four options:
I'll post a call for beta testers soon. Beta units will be functionally identical to the final hardware except for some layout differences and silkscreen text. Stay tuned for my fire sale in the Trading Post forum where I unload a bunch of random old monitors for beer and peanuts.
The current situation at BMOW HQ is monitors, monitors, everywhere!
I made a last-minute change to one of the alternate sync-handling methods, to make it functionally identical to an LM1881-based VGA adapter like my original prototype or like the Manila Gear IIgs adapter. So the Sync-inator will offer four options:
- Route the sync signals straight through. This is best if your video source provides separate hsync and vsync signals, and also works if the video source provides sync on green and the monitor can support that.
- Route csync to the monitor's hsync, and generate a new vsync signal in software based on the csync timing information. This is "LM1881 equivalent mode".
- Convert csync via software into new hsync and csync signals. This is "csync splitting" and is the best option for making that weird old composite sync source A work on that stubborn monitor B.
- Damn you, just choose for me! I don't have time for all these decisions!
I'll post a call for beta testers soon. Beta units will be functionally identical to the final hardware except for some layout differences and silkscreen text. Stay tuned for my fire sale in the Trading Post forum where I unload a bunch of random old monitors for beer and peanuts.
Nice work! It's exciting to see this all coming together after your original IIci VGA adapter thread. I'm super impressed that you were able to pull this off with a microcontroller instead of more complicated specific hardware. When you mention the built-in programmable logic cells for passthrough mode, are you referring to the CCL in the ATtiny204? I had never heard of that peripheral before, very neat.
Judging by those pictures, it's looking like we need to temporarily turn the W in your name upside down for a while. Big Mess o' Monitors!
Judging by those pictures, it's looking like we need to temporarily turn the W in your name upside down for a while. Big Mess o' Monitors!
bigmessowires
Well-known member
Thanks! Yes it's the CCL peripheral, and some variant of it has been appearing in many newer microcontrollers from Atmel / Microchip in recent years. Combined with the event system (also fairly new to this family) and some asynchronous timer capabilities, it's a pretty impressive toolkit for a lowly 8-bit micro.
Similar threads
