Mike wrote:Hi!
> I'm currently doing some thought experiment involving hardware
> synchronisation of multiple Orics to try to get them to have their ULA
> synced together so they can get merged into one single video output to
> drive one screen.
OK, sounds crazy enough, I'm interested!
> using four C64, each one drawing a quarter of the screen, but just done
> manually with four video projectors use space-bar to "sync" them.
I can see how that appeals for simplicity, the 4 machines don't need to
be locked together *at the video level* for that to work, 4 independent
non-synced videos, 4 projectors. Easy. Something (anything) can sync the
drawing software. OK.
But what you are talking about for Oric is more fun. In the real world
you would solve this problem with a "genlock" - in the analogue TV/video
days you could (up to a point) send a clock signal OUT to studio cameras
and get them to use it to return perfectly synced video signals. But with
external sources, videos (tape) you would not be able to do this. So
genlock was used to effectively acquire a video signal, store it, resync it
and reproduce it. This way you could cut between video sources without
glitch. Probably a very expensive solution to sync two Orics though ...
But it seems you are trying to make 2 Oric's work together *in the
first place*, giving you a video output of R,G,B,R',G',B',Vsync/HSync
which could then be used to create a larger palette etc. Or to overlay
picture A on B (240x200 drawn twice as quickly from 2 sources). OK.
Well. You are on the right track. The power supply mods (clean 5v feed)
simplifies problems you *would* have if you feed a common 9v to both, and
then ever accidentally joined the grounds together. So that's a good
step.
The modification resistor isn't anything hugely relevant, it's just
to improve the quality of the clock signal driving the ULA by shifting
it a bit more to positive voltage.
Commoning the 12MHZ clocks is good, that will guarantee they stay in
lockstep with each other.
As you've discovered, the ULA is a free spirit and cannot be started
or stopped -- no reset pin, reset must be built into the ULA's
silicon, as it needs some kind of power-on-reset for all those registers
and toggles inside it.
The observation on the slip between the video outputs is correct, there's
no guarantee that both ULAs will start up the same, even powered on "exactly
together". In normal use, there's no need for this to be a concern.
But whatever offset you do find will (should?) be constant, with a
shared clock.
I would say that asking the user to line things up and repeatedly
powering on and off is a bit rough and ready, so ... as we're already
into hardware mods and fiddling with the clocks :-
[ ... Brain dumping ... warning ... ]
(1)
I think that it might be possible to measure the error between the two
vsync outputs to work out which machine is ahead or behind, and use this
to *drop* a clock cycle out of the 12MHz clock to one machine UNTIL the
two slide into line, and then leave it alone.
Does this make sense? If A leads B, drop a clock cycle of A.
If B leads A, drop a clock cycle of B. It *may* be acceptable to interrupt
the timing like this, by just dropping 1 cycle in n cycles, that way
it won't overly screw up DRAM timings and cause all the data to fall
out of memory You can't just stop the clock outright.
So you need 1 clock source, something to selectively gate it to drive
Oric 1 or 2 (or not, when dropping a cycle). Then, much like a quadrature
encoder rotary switch/optical encoder can indicate rotation left or right
by whether signal X leads X' or X lags X', you can combine the two VSYNCs
to decide whether to be dropping clocks for Oric 1, or 2.
Best of all, this would be a non-software solution -- so no need to modify
ROMS to get things aligned. They would align soon after power on and stay
there.
(2)
If it turns out you can't drop a clock cycle without the ULA immediately
rejecting it ... the next step up would be to use two 12MHz clocks, locked
together (like a PLL). But the VSYNC-difference signal I mentioned above would
have to be used to speed up, or slow down, by a small amount, one
(or both) clocks until there is no error signal any more -- which means
the video signals must now be aligned.
(3)
Now I think about it .... two 12MHz clocks that are NOT locked together
(umm, much like two independent Orics *without* modification!) will drift
past each other in this way. What you need to do is notice when they
*are* lined up (in respect of the VSYNC signal), and LOCK THEM TOGETHER
only then. Now that would be fun ... is this a winning idea yet?
So let's say we XOR together Oric-1 and Oric-2's VSYNC lines. When they
disagree with each other, allow the clocks to free run and slip. When
they agree with each other lock the clocks together.
(If necessary, nudge one Oric to deliberately run a bit off speed
to ensure there is a slip: It would be embarrassing if they just sat
there perfectly unaligned and stayed like it! A trimming capacitor
across the crystal could do this!)
What this would do (I hope) is this ... because of the nature of
the sync signals, they will mostly agree just by chance -- let's say it
spends most of it's time LOW. And goes HIGH for a short duration once
every 20ms (frame). So at startup, the clocks will spend most of the
time locked, just by chance/coincidence.
When one machine asserts VSYNC and the other HASN'T, briefly there
will be a discrepancy, the XOR gate will show this up, and clocks
will be allowed to unlock and drift for the duration of the discrepancy.
And then lock together again. This will keep happening until there are no
more discrepancies, at which point the clocks can stay locked.
Unlocking may make the discrepancy worse (let's say A leads B, and you
unlock, and A runs a bit quicker ... now A will lead B EVEN MORE. Eventually
it will have lead so much that ... it's a whole frame ahead and meets
the video signal coming the other way, and ends up lining up!)
So: To sense the difference: XOR together the sync signal (maybe from IC25
Pin 1/2) where it is still TTL levels. Use this "error signal" to operate
a link between the clocks. Unlock when disagreeing, lock when agreeing.
You lock them by simply forcing the things to run together -- like a
three legged race -- by connecting the two clock circuits via a
link (using something like a bilateral switch used to couple analog signals
together). Maybe not a direct link, but a low enough value resistor to force
them to oscillate absolutely together.
For example, coupling R9 to the corresponding R9 on the other board via
a 1K resistor could well lock the oscillators together without causing any
distress. Opening up that link = free run drifting.
If that worked -- one XOR gate, one bilateral switch and a resistor, I
would be as amazed as you ... but it might just work
I'm aware the sync signal isn't purely VSYNC (annoyingly it's combine h and
v sync). But the principle still seems to make sense, yes, it might inadvertantly
"lock" with the HSYNCS matching, and the VSYNCS mismatching, but that won't
last long -- as long as there IS a mismatch between the signals, then
something is wrong, and they must be allowed to drift.
If any of this is helpful, let me know, or if you see a stunningly obvious
flaw that I've missed ...
> Thierry from the CEO has done some hardware tests, but we have some
> synchronization issues, so I wonder if you could take a look at my forum
> post and give me your opinion on the topic.
Also: In my opinion, the delays you have describe of ± 83ns, 160ns etc. are NOT
caused by the "bad edges of the 12MHz clock" as a later post suggests. As you
have noted, they cluster at multiples of 83.3ns, which is the clock cycle
at 12MHz. This is very relevant.
It is that the ULA is starting after a different number of whole-cycles
of the 12M clock. I'm sure if you were measuring *really* carefully, hard to
do on a scope, you'd see that the numbers are EXACT multiples of 1/12x10^6
(83.33ns).
If you are down to the level of worrying about the ULAs not synchronising
due to the rise/fall time (bad edges) of the 12MHz clock, you are looking
at details too small to matter :-
The pixel clock is effectively 6MHz (6 visible dots per 1MHz column of screen).
So the 12MHz clock is worth "half pixels".
The width of the rise time of that 12MHz clock is ... irrelevant on this scale
If you wish to reproduce any of the above ramblings on the forum, you have my
permission.
Mike.