I’ve been continuing the design development on a Mac-to-VGA video adapter with an integrated composite sync splitter, whose concept was first discussed in October, with a first-generation prototype following shortly after. To recap: some Macintosh models like the Mac IIci and IIsi and some Apple video cards like the Toby card output a composite sync signal, instead of the more common configuration with separate horizontal and vertical sync signals. VGA monitors don’t have a composite sync input, but some monitors will accept csync if it’s connected to their hsync input. For VGA monitors that lack this feature, the IIci/IIsi/Toby/etc simply won’t work, no matter how the DIP switches are configured on a passive VGA adapter.

My goal is to design an active Mac-to-VGA video adapter with the ability to process an incoming csync signal and generate new signals for hsync and vsync, thereby enabling the IIci/IIsi/Toby/etc to work on standard VGA monitors and LCDs. This sync translation should be optional, so the adapter can also be used similarly to a standard passive Mac-to-VGA adapter, and it can support the widest possible variety of computers, video cards, and video modes. I’m happy to report that I’m very close to this goal.

An active adapter needs a power source, and the first challenge of this development effort was that the Macintosh video port doesn’t provide any power. The port only has ground connections and data signals, but no handy +5V supply pin. I’ve settled on a design that uses phantom powering, drawing current from the sync input signals themselves in order to power the adapter’s circuitry. While this is generally considered a bad design practice, I’ve been able to keep the adapter’s total current consumption low enough that phantom powering doesn’t interfere with the normal functions of the sync signals. I prefer this solution over requiring an external power source, since it enables the active adapter to be used identically to passive adapters. Just plug it in to the video port, and it works.

The first-generation prototype used an LM1881, a specialized sync-splitting chip that can generate a new vsync signal from a csync input. The LM1881 can’t generate an hsync signal, however. This prototype worked with some monitors that I tested, but not others. I considered replacing the LM1881 with other more advanced sync-splitting chips, but they’re more expensive and more rare. After some experimentation I decided to use a small microcontroller instead of a dedicated sync-splitting chip, since it would be more flexible, cost less, and consume less power than a dedicated sync splitter. That decision was the foundation for this second-generation prototype, which I’m tentatively calling the Mac Sync-inator.

 
Generation Two: VGA Mac Sync-inator

Here’s a 3D rendering of the prototype. There’s not much to the hardware: just a DB-15 for the Macintosh side, an HD-15 for the VGA side, an ATTINY404 microcontroller, and a set of DIP switches. There’s also a USB jack for an optional source of external power, although so far my tests have found it isn’t needed. A pair of LEDs light up to indicate whether the Mac is outputting composite sync, separate horizontal and vertical sync, or both. This is a valuable debugging aid when you’re staring at a black screen and aren’t sure which piece of equipment to begin troubleshooting.

The first six DIP switches configure the monitor ID sense code that the Macintosh will see, and they function very similarly to the DIP switches on passive adapters. Many older Mac models check the sense code at startup, and use the code to determine what resolution of video output to generate, or whether to generate any video output at all. The last two DIP switches control the microcontroller’s sync conversion behavior. There are four choices:

1. Pass through hsync and vsync without any conversion – For newer Mac models that already output separate hsync and vsync signals.
2. Pass the Mac’s csync signal to the monitor’s hsync input – For older Mac models attached to VGA monitors that can accept a csync signal.
3. Don’t pass any sync signals – For Mac models and video cards that have sync information included in the green video channel, called sync-on-green.
4. Convert the csync signal into new hsync and vsync signals – For older Mac models attached to any VGA monitor, with the widest compatibility.

It’s that last option for csync conversion that’s the interesting one, and that makes this adapter unique. Passive adapters can do the first three behaviors, but not composite sync conversion.

And it works! Using the Mac-Syncinator in csync conversion mode, I’m now able to run my Macintosh IIci on any of my monitors, including the ViewSonic VG900b that has consistently been the pickiest monitor through all my development efforts. Hallelujah!

If you’ve ever used another Mac-to-VGA adapter with a set of DIP switches, then you’ve surely had the experience of not remembering what all the DIP switches do, and not being able to find the manual when you need it. It’s frustrating. To help with this problem, I’ve included a list of the switch settings for the most common video modes directly on the back of the Sync-inator:

 
Remaining Work

So what’s next? Is it all finished? Not quite. As of right now the Sync-inator works with the composite sync signals from the Macintosh IIci and IIsi, and from the Apple Macintosh II Monochrome Video Card 661-0518. But it doesn’t work with the Toby card (Macintosh II Video Card 820-1098) nor with a SuperMac ColorCard SE/30 that I tested. The reason is that not every composite sync signal is constructed the same way.

Here’s the csync signal from the Mac IIci, along with the new hsync and vsync signals that are created by the Sync-inator:

The csync signal is normally high, but there’s a short low pulse after every horizontal scan line of video. Once per frame, the polarity of the whole signal is reversed for a few lines – this inversion is the vsync. The important detail is that falling edges of csync are always regularly spaced, even during the inverted vsync period. The Sync-inator’s microcontroller uses these edges to derive timing information and create a synthetic hsync signal to feed to the monitor.

Now contrast this with the csync signal from the Apple Toby card:

During the vsync period, the csync signal polarity isn’t reversed – it’s simply flatlined at zero so there’s no timing information the microcontroller can use to generate synthetic hsync pulses. The falling edges of csync 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 and processed by generic program code.

I’ll probably focus on the flatlined zero problem first, since it’s common to both video cards. 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 in place of the missing pulse. 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. Those peripherals can’t necessarily be configured for that type of complex behavior. Maybe I can rig up some clever scheme of enabling and disabling interrupts at certain times, where the interrupt handlers change the hardware peripheral states, to create a behavior for a missed csync pulse. There will necessarily be timing jitter in these newly-created 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 the sync signal timing, so this whole approach may not even be viable. I guess I’ll find out.

It may be impossible to support these oddball csync formats, and I may have to footnote the Toby and ColorCard SE/30 as *not compatible with csync conversion. That wouldn’t be too bad, since the main goal was Macintosh IIci and IIsi support, which has already been achieved. But I’ll give it my best effort!

Read 15 comments and join the conversation 

Vintage Macintosh fans, here’s a firmware update for the BMOW Floppy Emu disk emulator with some exciting new features that I’ve been working on for the past few weeks. Please give this version femu-231209M a try, and let me know how it works for you. Even a basic report of “it works fine, I have nothing more to say” is helpful.

StuffIt File Support via Boxing

Archive files like StuffIt .sit, BinHex .hqx, MacBinary .bin, Compact Pro .cpt, and text .txt can now be directly used as if they were floppy disk images, with a new feature I’m calling “boxing”. Select a .sit file (or other archive) on your SD card, and Floppy Emu will automatically create a temporary disk image “box” that contains the file. From the user’s point of view, this basically makes StuffIt files and other archive files behave as if they were disk images, and it’s a major time-saver and quality of life improvement when you’re downloading software from The Garden and using your Floppy Emu to transfer it to your Mac.

Floppy Emu generates a read-only box disk that’s the smallest possible size to contain the StuffIt archive file: 400K, 800K, or 1440K. Your Mac will need to have support for the larger floppy disk sizes in order to transfer larger StuffIt files. 400K box disks are HFS, not MFS, so you’ll need to be running System 2 or later.

Macintosh Hard Disk support for Zulu SCSI, Blue SCSI, and CD-ROM images

For Mac models with support for HD20-type hard disks, Floppy Emu can now use disk images in SCSI device or CD-ROM formats, with an embedded Apple Partition Map, such as the disk images used with Zulu SCSI or Blue SCSI. Supported formats are HDA, IMG, ISO, CDR, DSK, and TOAST. When browsing for disk images in the Floppy Emu directory menus, these images will appear with an APM suffix, while traditional disk images will appear with an HFS suffix. For APM images, Floppy Emu will search the partition map and mount the first HFS partition in the image, ignoring driver partitions and other boring stuff.

Yes, this means Floppy Emu is now a CD-ROM emulator (sort of) – see above with a CodeWarrior CD mounted. CD-ROM images are mounted as read-only hard disks, not as removable media, and the speed is comparable to a 1x CD-ROM drive. It won’t replace a dedicated CD drive, but it’s great for installing software. If you’re running System 6, you may see an error message when using CD-ROM images complaining that the desktop file couldn’t be created because the disk is locked, just like you would with many real CD-ROMs and System 6. The INIT Desktop Manager 2.01 will fix this. With System 7 or later, it’s not needed.

Other Stuff

The Floppy Emu Model C also received some UI improvements and polishing. A “Settings Menu…” item has been added to the top level of the menus, providing an alternate way to return to the settings menu without needing to reset the device. The “..” directory menu item for returning to the parent directory was something that only a UNIX nerd could love, and has been replaced with “Go Back” and a curly arrow icon. Most error messages or dead-ends in the UI flow now have a way to exit or return, so it shouldn’t ever be necessary to use the RESET button to perform a hard reset of the device.

A new version of the Apple II firmware with these same UI improvements is also available. Have fun, and don’t forget to leave feedback on how it works for you!

Read 12 comments and join the conversation