... and here is the setup.
The idea was to power-on the thing, so all ULA's are well "saturated" and then using the button to enable the clock signal, hoping that all ULA's will run synchronized. It didn't work, but at least it was easy to build.
This weekend I'll try to make something more advanced based on Mike Brown's schematic.
Crazy project ...

Yep, I think the parallel port is the best option for communication between machines - easy to drive and no additional hardware. Maybe it will be better to use it as kind of (a)synchronous serial interface with two lines STB (for output) and ACK (for input), emulating something standard as protocol for instance OneWire.
For software loading in my opinion the easiest option is TAP - you can "stream" the tap file to all machines simultaneously . As player you can use smartphone (btw, my TapOric is ready to be released) or PC (I think I can reuse my java streaming library from TapOric and quick create an application for Windows/Linux working with the audio card), of course TAP-to-WAV is always available too.

Yep, I think the parallel port is the best option for communication between machines - easy to drive and no additional hardware. Maybe it will be better to use it as kind of (a)synchronous serial interface with two lines STB (for output) and ACK (for input), emulating something standard as protocol for instance OneWire.

Is the printer port bi-directional?
I thought it could only send data.

For software loading in my opinion the easiest option is TAP - you can "stream" the tap file to all machines simultaneously . As player you can use smartphone (btw, my TapOric is ready to be released) or PC (I think I can reuse my java streaming library from TapOric and quick create an application for Windows/Linux working with the audio card), of course TAP-to-WAV is always available too.

The biggest problem with TAP is that that removes the ability to access the overlay memory, or maybe we can come up with an alternative way to enable the overlay signal without using a disk controller

Is the printer port bi-directional?
I thought it could only send data.

I'm sure you know this well , it's bi-directional, every bit can be set independently as IN or OUT, think about the joysticks...
About the RAM overlay - if it's requirement then maybe microdisc for every machine is best choice, but it's possible to make small hardware which drives MAP signal and provides the communication between machines... Meditate on this, I will...

I was wondering about other benefits of having a common clock. Do you thinks that technically it probably means that the communication between the various Orics could be done with synchronized code that does not even need to acknowledge anything and just bang the busses as fast as they can?

Hello all! Below are updated schematic and test results.
I think we have working synchronization

In short how it works: I used one ULA (U2) as reference, its SYNC signal is compared with the SYNC form a "child" ULA (U5,U6,U7), so if both SYNC's are the same then the clock signal (CLK) is passed to the ULA, else it's hold and child ULA 'waits' for the reference ULA i.e. the logic drops pulses from the child's CLK until the SYNC signals become equal.

On the traces CLK, CLK1,CLK2,CLK3 are 12Mhz clocks and VSYNCH/HSYNC are visible.
You can see how the reference SYNC is 1/2 of the 12MHz period before the child's SYNCH's.
I think It's worth to sacrifice one ULA as reference.
(continue below...)

Here, after power-on the reference ULA started with 60Hz but the child ULA's with 50Hz.
This actually confirms that the synchronization logic works .
To not happen such case, the reference ULA should be fed with proper data to initialize 50/60 Hz mode.
Because the ULA's data lines are only inputs this can be done (for instance) with jumpers.

@NightBird: Can you repeat the schematic and confirm that it works with full Oric boards ?

@Dbug: I think It's possible to have the communication between the various Orics with synchronized code.

You can see how the reference SYNC is 1/2 of the 12MHz period before the child's SYNCH's.
(...)
@Dbug: I think It's possible to have the communication between the various Orics with synchronized code.
So, what's next?

First, I've to say I'm impressed by your work

Is the master ULA absolutely mandatory to use? It's definitely not possible to sync the second ULA on the master one, maybe using some delay in the signal, like generate from the master 12mhz another 12mhz but shifted by half phase?

Now, regarding what's next, I was thinking out of the box: Recently the Amstrad people released a pretty impressive Amstrad CPC+ demo, which relies on being on a cartridge. That obviously solves a lot of problems, like you don't need a loader, etc... it's just a giant ROM with bank switches.

What I was wondering was the following: Is it possible to do the equivalent on the Oric, replacing the 16KB BASIC ROM by say a 256KB ROM (or EPROM) with some simple logic to do select the right bank? That would make the need for handling the overlay signal not really necessary, and that would solve a lot of problem in synchronisation since there would be no loading time: Each of the Oric motherboards would get a CPU reset at the same time, initialize their VIA and stuff at the same time, each boot from their own ROM (I assume that can't be shared between multiple machines?), and start running their own small bit of code.

Extending the idea, if it's possible, would it be possible to have something more practical than EPROM so testing the code is easier (programming eproms takes forever, plus the time it takes to remove it and reinstall it), something like some battery backed-up RAM chip maybe, with a way to write to it from the PC without removing it from the ORiC?

That was for the storage part.

Obviously the next part is the actual video signal mixer, which can be done in multiple ways, with different degrees of complexity and different visual results:
- 1) Just OR the signals together: We still get a 8 colors Oric picture, but we can display it twice as fast, and with a bit of brainstorming can bypass some of the color constraints by complementing the picture using the two frame buffers
- 2) Interpret the different values (00, 01, 10 and 11) to generate different intensities, this allows for shades of colors, but means it's impossible to display a full Oric picture on only one machine while the other displays something else.
- 3) What I was originally suggesting, have 00, 01 and 10 cases handled as OR, which allows any of the two machines to freely display a fully standard Oric picture, but handle 11 as a way to generate half bright intensities so we can get things like ORANGE or GRAY.
- 4) Go the "Multicoloric" way, and take the inputs of the two ula and use them as some color index in a color palette chip to do a color lookup to get the final color. The advantage of that is by programming the right palette, you can do anything you want, from standard Oric colors to improved Oric colors, up to 64 simultaneous colors (3 bits per ULA, so 6 bits graphics with two ULA) from something 4096 available tints. I let you imagine the graphic potential, specially if the original problem of the multicoloric could be solved (changing color registers during display generates "snow" glitches on the screen)

Obviously the 1) is super easy (just merge the inputs with a simple OR gate) and pretty much does not require any fancy components, while 4) requires tome page 3 addressing to change the color palette registers. I guess in 2017 it's probably possible to do with a fraction of the original 1985 component list

A this point, I guess I need to make some commitment:If one of you builds this machine so it can be reasonably programmed without the programmer getting mad, I'm willing to write the best possible demo I can do for it. That would be obviously a one of a kind machine, the type of thing you release in a special category in demo compos. That also means I would probably need to hack PictConv and Oricutron to be able to do some testing, but also that I would need to have the machine with me (I can send it back later of course).

This is the kind of simple circuit I thought, to avoid something complicated like a complete PID controller.

I will study the practical application on real Orics.

But in your opinion is it possible to simplify again? (eg if you remove the LS04 between the 86 and the NAND, and replace
the NAND by an AND, clkx would be of the same sign as clk? - watched quickly without thorough study...)

If dropping clock pulses really works, then that's fantastic! Let's see how
reliable it is on running Orics

And I 95% approve of iss's embodiment of my idea (see below why ...)

Four thoughts from reading the thread ...

1) Absolutely stick with VSYNC, do not get sidetracked into focussing on syncing up at the 1MHZ-clocks level.

Although the green scope traces showed two 1MHZ clocks being in-and-out of sync over a ± 500ns range, this is potentially an optical illusion, caused
by the signals being a 1000ns square wave

What I am saying is that the offsets may be MORE than 500ns, and it would look like a smaller offset to the "next" clock along. If that makes sense. Like successfully lining up two rulers to the nearest whole inch, nudging in 1/8" steps, only to step back and see they are perfectly aligned at 4 inches = 7 inches!

The reason I mention this is that if the 1MHZ clocks line up perfectly it is possible the ULAs are still out of step when it comes to the video signal.

You must synchronise the VSYNC/HSYNC.

I suspect (but have no proof) that the reset circuit inside the ULA is implemented as a counter, of unknown size, which counts the 12MHz clocks. This counter starts in a random state, as any memory based/flip flop would do.

As it counts around, when it (for example) eventually hits 0000, a reset pulse is generated and the counter disables itself. This is why the random delay, despite the matching clock input and power rails.

If the counter was 8 bit, that is a potential 256 states, and therefore an offset of up to 256 x 8.3ns = ~ 21us. Almost half a screen line's worth of delay.

So we must follow and match the VSYNC!

2) PID controllers as per the links posted ...

Way too complicated, in my opinion, these are for complex analogue systems where the aim is to move something like a motor/tmeperature to hit a target as quickly as possible, without overshoot, without excessive cycling on and off.

We can easily measure the error and go directly to a correction, without overshooting, and are working in known lumps of time (8.3ns)

Dbug wrote:
At least it's nice to know that the whole thing is technically doable
(on a board without any other components at least!)

This is very good news.

On the colours side of things, I was surprised to see the "00=black, 01=10=half colour, 11=full colour" -- as that wastes one potential colour

Weight the signals as 2 bit binary, 00=black, 01=dim, 10=medium, 11=full at the very least, into an analogue signal, a simple resistor ladder would do this.

A palette lookup is much more fun to implement, if you want to go there.

3) 50Hz vs 60Hz

A real Oric can indeed come up in either mode, depending on how it feels.

One job of the software in BASIC ROM is to write a known 50Hz/Text attrib and wait for it to be consumed by the ULA, before diving in to setting up text or hires mode as required.

You can (for a lone ULA), "force 50Hz with jumpers", by wiring the databus so all the ULA reads is endless 50HZ/txt attributes, but that's not useful in a real Oric ... (and see point 4).

While the "sync circuit" monitors V/HSYNC, then once all Orics have started, and written their 50Hz/text attribute, then the sync circuit should pull them into line with the master even if they DO come up in mixed 50-60Hz and therefore start out of step, they will come into alignment very quickly after.

4) "Extra ULA"

Here's the 5% disapproval part

There is *no* reason, that I can think of, to consider the "reference" ULA as an extra *just* a ULA for creating a reference. I see why iss did, but let's not do that -- the reference ULA could be in a real Oric, the "first one" of the network, and being used to drive an actual Oric. Don't waste it!

As above, it will end up being 50Hz as a result of that first Oric starting up as normal.

The scheme, as pictured, could easily be FOUR Orics flying in formation!

@NigthBird: No, I don't think this simplification will work. After the XOR we must have NOT to invert the logic and enable the clock only when the clocks are the same.BUT, (looking again at the traces) if we change the NAND to AND (7400 -> 7408) then maybe the 1/2 cycles delay will be eliminated, because I just realized that the reference CLK and the children CLK's are simply inverted! I'll make this change and will post the results bit later...

Well, this are samples with the changed schematic (AND instead NAND), now the reference SYNC is BEHIND the derived SYNC's with exactly 1 full period, so no big difference and in common it doesn't matter which variant will be used. For me the important thing is that with this design the extra ULA is obligatory, because there will be always a delay! In our case I think one ULA is not big waste. I have >10 pcs (not counting these on boards) available and If someone needs I can share them.
I'm ready to experiment with other solutions, but for the moment I don't have anything else that seams to be better, more practical or more working.
The plan for the weekend is to connect the "driver" board to real Orics - I have some ideas how to do it without (or at least with minimal) damages on boards and create the OR-video controller then fill different hires patterns and see them combined on the TV .
If it works (and the time allows) I'll go further - developer friendly storage... will see .