TashSync: Macintosh Video Sync Signal Converter/Generator

[Tashtari]

I have a "syncing" feeling it's time for another TashProject...

Introducing... TashSync!


Elevator Pitch

It's a video sync signal conversion/generation firmware for Macs, targeting the PIC12F1501 (8 pins, 77¢ in quantity) microcontroller. Primarily, it takes a "composite" video sync signal and processes it into separate horizontal and vertical sync signals, broadening the range of VGA monitors that can be used with certain Macs (such as the IIsi and IIci) and Mac video adapters (such as the Toby card).


Project Status

90% complete, all that's left is the other 90%. The firmware is most of the way complete but there's a great deal of testing still to be done.


Caveats

It does not modify video signals at all, only sync signals. For something that re-scales video to make it palatable to a VGA monitor, you will need an FPGA or Pi Pico or something with a lot more oomph than a PIC.


Why Do This?

I did this because I am always attracted by projects that squeeze a high degree of functionality out of a little PIC, and with eight pins, 64 bytes of SRAM, and 1024 words of program memory, the 8-pin PIC12F1501 definitely qualifies as a little PIC. I wanted to see if this was possible, I wanted to find out what manner of tricks I had to employ to make it work, I wanted a fun project. By those measures, I've already been highly successful!

I know the BMOW Sync-inator exists and it's a great product, I have one myself. If this project's premise interests you but you want something you can buy right now, give the Sync-inator a look. This project shouldn't be all that interesting to you unless (1) you're an open-source fan or (2) you're someone who always has to do things the hard way - sometimes known as a DIYer. =)


Technical Details

The PIC12F1501 has two CLCs (configurable logic cells), without which this project would certainly have been impossible. They are employed in various contortions, primarily as D flip-flops and transparent latches, to take edges on a composite sync signal and translate them into corresponding edges on vertical and horizontal sync signals. Where an edge on composite sync does not directly correspond to an edge on the output vertical or horizontal sync signal, other means (timers, sometimes just code loops) are used to produce the desired signal. These can only be so accurate given that the PIC is running off of an internal RC oscillator rather than a crystal, but they are as precise as they can be in the circumstances.

One free pin remains after the sync inputs and outputs are accounted for, and I've used this to make a simple bitbanged UART which spits out details of how it's processing the signal. Most notably, it emits a simple, low-resolution signal trace of the vertical sync area of the video signal - besides using this internally to determine how to generate the separate horizontal and vertical sync signals, this can shed a lot of light on the particulars of a given video adapter's output signal.


Code

GitHub - lampmerchant/tashsync: Macintosh video sync signal converter/generator for PIC12F1501.

Macintosh video sync signal converter/generator for PIC12F1501. - lampmerchant/tashsync

github.com

 

[davidg5678]

Count me as interested! I just logged in to ask about a solution to this exact problem, and I'm happy about this coincidence. If you need anyone to help test this out, let me know! (I have a Mac II with its original video card.)

 

[daanvdl]

It sounds like a better replacement for the LM1881, since it only splits off V-SYNC and keeps the H-SYNC composite. I'm willing to test!

 

[NJRoadfan]

As this is right up their alley, you may want to post about this over on the SHMUPS hardware forum: https://shmups.system11.org/viewforum.php?f=6

 

[Tashtari]

If you need anyone to help test this out, let me know! (I have a Mac II with its original video card.)

I'm willing to test!

Thanks! I will definitely take you guys up on that once I get something a bit closer to shippable (though if you've got a PICkit3 or similar and feel like breadboarding, I'd be more than happy to work with you before that!)

you may want to post about this over on the SHMUPS hardware forum

Interesting, thanks for the tip. I may do that - again, once I'm a bit closer to a finished product...


Also, new development, I think it might actually be possible to port this functionality into an even smaller PIC, the PIC10F322 (maybe even the 320, which is the same as the 322 but with less program memory). If the 1501 is small, the 322/320 are teensy, featuring only six pins and available in itty-bitty little SOT-23 packages. I've started laying out a board for this and it's looking delightfully compact, with barely any space between the DA-15 and DE-15/VGA connectors, yet leaving room enough for a small DIP switch bank and maybe a pushbutton, depending on how many different sense pin arrangements it ends up supporting.

On which note, the obvious choice is to try and support all the possible sense pin arrangements, but how many do people really use in practice? Probably 640x480 and VGA/SVGA would cover most use cases. That could be done with only two switches and that'd cut way down on not just the size of the adapter but also the complexity of actually using the thing - no bewildering charts of modes and switch combinations. I don't know, I might be getting ahead of myself, but I'm interested to know what folks think.

This is an interesting project for me for numerous reasons, but a big one is that it's forcing me to think about power consumption for the first time, as I'd like to run this off parasitic power instead of having a dedicated connection to a real power supply. All my previous projects have just pushed the PICs at full speed, never gearing down or sleeping. The PIC10F322/320 seem to be pretty lightweight on power consumption, with the spec sheet putting their maximum current consumption at 1.3 mA, typical 0.85 mA, and something like 17 µA in sleep mode. And they can stay in sleep mode for a significant percentage of their operating time, mostly just waking to do some signal magic during the vertical sync interval, so hopefully that's low enough that parasitic power shouldn't be too hard to achieve.

I do need some advice in that department, though, as I'm not much of an electrical engineer. It looks like, on the IIsi at least, the horizontal and vertical sync lines are set high when composite sync is in use, they might be a good candidates for parasitic power for the circuit, though I don't know if every Mac that uses composite sync drives them high. The other possibility is the sense lines, though this might be more difficult as I'm assuming that in some cases, at least, they're pulled high with resistors (because the early scheme for the sense lines has the monitor pull one or more of them to ground), so the amount of available current might be pretty low.

Thoughts? =)

 

[daanvdl]

Thanks! I will definitely take you guys up on that once I get something a bit

I have to wrap up some other projects, but i have a PK3 so i will order a PIC12F1501 to do some testing

 

[Tashtari]

I have to wrap up some other projects, but i have a PK3 so i will order a PIC12F1501 to do some testing

Cool! Grab a PIC10F322 as well while you're about it, they're super cheap.

 

[Tashtari]

Grab a PIC10F322 as well while you're about it

On second thought, don't. It's a neat little chip but experimentation reveals that it's missing too many features to do this job well. The 1501 will do much better. (And, failing this project, I already have a few others that it can be used for...)

 

[Tashtari]

I did a rewrite of the code that profiles the composite sync signal and freed up a considerable amount of code space... I am now where I was before but hopefully a on a bit more solid ground. Going to have to do some more testing with real Macs and see whether my signals are precise enough for the monitors I have around. Now all that's left is the other 90%...

 

[Tashtari]

It works! On one combination of computer (IIsi) and monitor (Dell E151FP), anyway. This is the first time I've tested it with real hardware and not just a PIC I programmed to spit out simulated sync signals, and it passed with flying colors! I suppose the next thing to do is to knock together a PCB of some kind. I'll probably have to start off with external power and leave figuring out parasitic power until later... I'll have to enlist some outside help for that, I think. But still, this is a big step in the right direction! \o/

 

[Tashtari]

On a whim, I took a look at my IIgs's sync signal (probably should have done this sooner) and discovered it's a fairly different animal than the IIsi. Where the IIsi has the falling edges of the sync signal in the same place throughout the frame - it just moves the rising edges further ahead for the vertical sync interval - the IIgs really appears to be XORing two signals together to get the composite sync signal. It'll be easy enough to separate the signals once the firmware knows this is what's happening, but the detection/profiling logic is going to need some retooling...

Before I get too deep into that, though... does anyone out there have a Toby card and a scope and the willingness to get me a trace with some measurements of its vertical sync interval? Up to now I've been working off of a PIC that I programmed to mimic the real thing since I don't have a Mac II (let alone a Toby card) and while TashSync produces the desired effect when faced with that, I want to make sure I have an accurate picture of what's really going on.

 

[CC_333]

I have some Tobies!

And a Mac II!

But, alas, no scope.

And My Mac II needs a recap to be operable.

*sigh*

c

 

[Juror22]

does anyone out there have a Toby card and a scope and the willingness to get me a trace with some measurements of its vertical sync interval?

Check, Check and Check (including working Mac IIs)... I may need you to talk me through the operation and its not what I planned for the weekend, but I would like to help. Feel free to pm.

 

[Tashtari]

Check, Check and Check (including working Mac IIs)... I may need you to talk me through the operation and its not what I planned for the weekend, but I would like to help. Feel free to pm.

Great, thank you! PM sent.

 

[Tashtari]

Rambling ahead, you've been warned.

Continuing to chip away at this. Rewrites are always a bit disheartening, but I have to remind myself how many times I had to start over on TashTalk before I made it work. In any case, I think the architecture will be more flexible than before with this rewrite - rather than trying to boil every composite sync waveform down to the same set of parameters, it will have a small set of translators that are able to recognize different waveform shapes and synthesize accurate horizontal and vertical signals from them.

One of the things that is interesting (and sometimes worrying) about this project is the question "how accurate is accurate enough". The PIC runs with an instruction clock of 4 MHz, divided down from an internal RC oscillator that runs at 16 MHz, so signals controlled by firmware can't have a higher resolution than that. However, changes to the output signals that correlate to changes in the input signal can happen near-instantly thanks to the use of the PIC's Configurable Logic Cells. That is, if there's a rising or falling edge in the composite sync signal that needs to correlate with a rising or falling edge in the horizontal or vertical sync signal, it's usually a relatively simple matter to make that happen. The tricky part is when that isn't the case - like with the Toby card, where the composite sync signal goes completely flat for the duration of three horizontal sync pulses, leaving the PIC with only its own internal oscillator for a timing reference. It's certainly doable to have the PIC use its PWM peripheral to synthesize a signal with three pulses and patch it into the empty space, but having those pulses align perfectly with the preceding horizontal pulses isn't possible - there's always going to be some amount of drift. Not much, mind, but where video signals and individual pixels are concerned, the reciprocal of 16 MHz is quite a long time. Time and experimentation will tell.

Still enamored with the idea of making the itsy-bitsy PIC10F320 do something useful (but unable to fit the logic for a multi-standard sync processor into it), I'm also creating an offshoot of this firmware that is for the Apple IIgs only. Dead simple, no DIP switches, no choices to make, just DA-15 goes in, DE-15 comes out. Of course, the user will still need a monitor compatible with a 15 kHz horizontal rate, but there's no getting around that without considerably more complicated processing.

Speaking of DIP switches, I keep returning to the question of how complicated a sync-processing adapter needs to be. None of us likes having to consult a table of resolutions and DIP switch combinations, but that's what every adapter seems to stick us with. Maybe that's inevitable with later Macs that support resolutions like 832x624 and 1024x768, but those Macs (if I'm not mistaken) tend to be the ones that output horizontal and vertical sync themselves anyway, no composite sync processing necessary, and can be handled with one of the easily-found passive adapters out there. If TashSync were used in an adapter that just represented itself as an AppleColor 13" RGB (640x480) monitor without needing to be configured as such, what functionality would really be lost? This is a genuine, non-rhetorical question - there may well be monitor/card configurations I'm not aware of that wouldn't fit into that box. I'm just thinking, are we losing usability by trying to make a one-size-fits-all solution that includes both a sync processor and a bank of DIP switches when only one or the other is necessary in a given configuration?

Lay your collective wisdom upon me, forum-goers. =)

 

[Tashtari]

I took a small break from the main project to make a sync processor for the Apple IIgs (and just the Apple IIgs) and was astonished to find that it actually worked the very first time I ran the code, which never happens. Code is up on Github in case anyone's interested.

I'm having a few PCBs fabbed to make testing easier. Still not a final product (the problem of where and how to pull power from the video port remains on snooze, so external +5V is required) but I'm hoping I can rope a few volunteers in for early-days testing in the near future.

'Course, my PCBs are on the slow boat from China, so the future is less near than I might like...

 

[rfc6919]

Not sure what voltage you need to drive out, but do you actually need a full 5v to drive the PIC? If you can take a diode's voltage drop, would it work to feed *all* the candidate power lines in through individual diodes to give a PIC power rail at ~4.3v? Janky, but could work?
With the timing drift question I was wondering if you could watch level changes on the colour signal lines and use those to correct timing drift between hsyncs like serial autobauding, but I guess supporting arbitrary-ish pixel clock rates in the cycles you've got available might be pushing it.

 

[Tashtari]

Not sure what voltage you need to drive out, but do you actually need a full 5v to drive the PIC? If you can take a diode's voltage drop, would it work to feed *all* the candidate power lines in through individual diodes to give a PIC power rail at ~4.3v? Janky, but could work?

Ah, interesting. The PIC can take as little as 2.5V, so that has potential... the only worry would be that the logic levels go down with the supply voltage and I'm not sure what happens with that. Outputting 4.3V would be fine as that's enough to be considered a logic high, but if the PIC's supply voltage is 4.3V and the sync lines are coming in at 5V, that violates the stipulation on the "Absolute Maximum Ratings" page of the datasheet that voltage on any GPIO pin can't exceed supply voltage plus 0.3V. I guess I could just stick another diode on the sync input lines, too? Is there any downside to that?

With the timing drift question I was wondering if you could watch level changes on the colour signal lines and use those to correct timing drift between hsyncs like serial autobauding, but I guess supporting arbitrary-ish pixel clock rates in the cycles you've got available might be pushing it.

Yeah, I think your instinct is right, I feel like that's going to require more time than I have available if for no other reason than I think I'd have to use the ADC to sample the color lines (it'd probably have to just be one out of three)...

 

[rfc6919]

Ah, interesting. The PIC can take as little as 2.5V, so that has potential... the only worry would be that the logic levels go down with the supply voltage and I'm not sure what happens with that. Outputting 4.3V would be fine as that's enough to be considered a logic high, but if the PIC's supply voltage is 4.3V and the sync lines are coming in at 5V, that violates the stipulation on the "Absolute Maximum Ratings" page of the datasheet that voltage on any GPIO pin can't exceed supply voltage plus 0.3V. I guess I could just stick another diode on the sync input lines, too? Is there any downside to that?

Caveat I'm absolutely no electrical engineer, but yeah I think that should work.

Yeah, I think your instinct is right, I feel like that's going to require more time than I have available if for no other reason than I think I'd have to use the ADC to sample the color lines (it'd probably have to just be one out of three)...

Oh, yeah of course the colour signal is analogue. Trying to pull level change edge timings out of that through the ADC isn't going to be a win.

 

[rfc6919]

Hrm. So with a 4MHz INTOSC, and a 25.175MHz pixel clock as the slowest option in VGA, in the best case you've got over 6 pixels flying past per clock so *nothing* controlled by the CPU can be pixel-perfect given arbitrary phase on INTOSC.
I know squat about PIC, but is there any way of tuning INTOSC on the PIC12? (Doesn't look like those have OSCTUNE). Could it be viable to fully synthesize the output HSYNC (never pass through from the video source, just have the PWM do it all) and tweak INTOSC up and down to drift the PWM'd HSYNC into frequency and phase match with the inbound HSYNC? Like, use a CLC to see if inbound HSYNC goes low before or after the PWM'd output HSYNC, and then next time you're back in the CPU tune the INTOSC frequency appropriately?
(just spitballing an interesting problem, I hope I'm not suggesting ideas you've already discarded)