So, I did some testing, playing with one idea at a time.
This time the idea was: Just use three Orics, each one is in charge of one component (so one only display red, one only display green, one only display blue) and just use these as inputs.

...

Plenty of other possibilities to explore, but it's a start

I don't know if it's so obvious as not to require statement, but the substantial other possibility arising is easy upgrade the graphics of many existing games; anything that has the graphics stored somewhere as regular data is a great candidate.

As to emulation, it would be ideal if a means of declaring as a hint that a program has completely coupled CPUs — that the intention is that all program flow is identical across all boards, only the data which isn't the subject of conditional decisions varies — would be extremely nice. A conforming emulator that spots the hint can then just run a single instance of the processor that happens to have four A, X and Y registers, but only one status, stack and program counter, four copies of memory, and performs each manipulation four times in parallel, with only one of them affecting flags. That would not only make performance a lot better than running four completely separate systems, but would help to keep debugging rational.

I don't know if it's so obvious as not to require statement, but the substantial other possibility arising is easy upgrade the graphics of many existing games; anything that has the graphics stored somewhere as regular data is a great candidate.

True, same code, doing the same thing, just different graphical data, the only difficulty become to make the four cpus start exactly at the same time.

As to emulation, it would be ideal if a means of declaring as a hint that a program has completely coupled CPUs (...) That would not only make performance a lot better than running four completely separate systems, but would help to keep debugging rational.

I don't see having four totally separate machines running as a debugging nightmare, specially if you have an emulator with a built-in debugger

In my idea, a program designed from the start for this architecture would alternate between effects exploiting more colors at the same time, and other using more processing power.

Hi,
Still thinking about hardware mods...
How did you merged the RGB signals?
Do you have a schematic?

I've done a bunch of software tests using emulators, but some are easier to implement in hardware than other.
The most basic one is basically to use a OR gate per component.
The most flexible one would require some kind of look up table in order to provide the most flexible system

An example: trying to merged RGB outputs to one input:
- Red level #1: 100% of the signal.
- Red level #2: 0% of the signal.
- Red level #3: 0% of the signal.
- Red level #4: 0% of the signal.
Desired output for Red is 25% of the level? Is there a simply analog electronic schema to connect these inputs? Without going through an analog-digital-analog converter?

But for the first tests, we can use OR gates, to solve the synchronization issue?

If you're going with one machine to produce R, one for G, one for B (?) then why not just replace the colour ROM with one that's plain grayscale, no colour subcarrier at all, and combine the composite outputs?

I don't know if it's so obvious as not to require statement, but the substantial other possibility arising is easy upgrade the graphics of many existing games; anything that has the graphics stored somewhere as regular data is a great candidate.

True, same code, doing the same thing, just different graphical data, the only difficulty become to make the four cpus start exactly at the same time.

Couldn't they just sync up later? Damned if I can find a pinout for the connector so I don't know what's easy available, but if you waited until all four processors had asked for sync and entered some sort of small loop, then simultaneously asserted NMI and RDY, then waited at least (length of longest instruction + 4*) cycles, then released RDY, wouldn't all processors then be in sync?

* I make the first read in an NMI/BRK the fourth cycle: push PC low, push PC high, push status, read low byte of vector.

The processors are not causing any problem at all, the issue is purely the ULA because they have some non deterministic internal value which make them start from one out of four different values.

When the ULA are correctly synced - this requires the use of a common clock signal, as well as some fancy throtling on the individual input clock signal they are then perfectly in sync, and just merging the wires works perfectly in RGB. No need to use the composite at all.

The challenge is not really in merging the output, it's more in finding the most bangs for the bucks, which for me at least implies to be able to still be able to run normal oric software on one machine and have it work normally: It should still be an Oric at the core.

Nightbird: The problem of this approach is that basically it makes it impossible to just use one machine to output a normal Oric game output.

A few weeks ago I formulated the question like that to some friends:

What would be the simplest/economical way to implement the following digital circuit:

Let say we have four TTL inputs (each is either 0 or 1) names A, B, C and D.

Using a simple OR gate, I can get a simple TLL mixer that outputs a 0 or 1 depending if any of these four inputs is non null, so we get a 0 output if we have all 0 inputs, and we get a 1 if at least one of the inputs is non null.

So far, so good?

What if... I wanted to get intermediate values?

Say, I still want to be in the same 0 to 1 range of voltage, but I'd like to have intermediate values based on the number of inputs that are set to 1?

- If all the inputs are 0, then we get 0
- If one input is 1, then we get 0.25
- If two inputs are set to 1, we get 0.5
- If three inputs are set to 1, then we get 0.75
- And finally if all the inputs are 1, then we get 1

How would you achieve that without using modern components?

Now, what if... I wanted the same thing, but not in the same order:

- If all the inputs are 0 -> 0
- If one input is 1 -> 1
- If two inputs are set -> 0,5
- If three inputs are set -> 0.75
- If all four inputs are 1 -> 0.25

Is that still doable using small component logic (gates, transistors, resistors, ...) or does that require something much more complicated?

Thanks to anyone who can provide some hints on how that could be achieved, or some documentation, or even "names" of things, because I've no idea how to even search for it.

It's kind of DAC, but using the number of inputs as a value instead of the binary representation of the inputs...

That's basically what I came up with, which would allow the largest flexibility:
- Possibility to have any machine able to display a fully compatible Oric image just by itself
- Which imply that you can use two machines to draw the same thing twice faster, and with four machines you can do that four time faster
- and when you add the possibility of multiple machine actually changing the same pixels, you get intermediate shades of colors

So, it's not optimal in term of what could be achieved with this number of bits, but it's manageable in term of programming, a good example would be a game with a scrolling playfield and a score board: The score board does not move, so you can use overlapping layers on the four machines to generate a very colorful and detailed board, while the playfield itself can be drawn by two machines to be twice faster, and two other machines are just in charge of displaying sprites.

I have to admit that I find it very hard to think of what would have a relevant response to "the only difficulty become to make the four cpus start exactly at the same time" given that it's also true that "the processors are not a problem at all". I guess I'll opt out of further discussion in order to avoid being hit in the head by the moving goalposts.

I have to admit that I find it very hard to think of what would have a relevant response to "the only difficulty become to make the four cpus start exactly at the same time" given that it's also true that "the processors are not a problem at all".

I guess my "them" was misunderstood.
It was referring to the ULA not the processors.
The CPU are not a problem, their are slaved to the ULA that is in charge of generating all the signals.

The master sync is the input to the ULA, which generates all the sub frequencies, that the CPU's are not exactly synced to the same exact cycles is not a problem, but the fact that the video display is not synced, is one.

I guess I'll opt out of further discussion in order to avoid being hit in the head by the moving goalposts.

What I meant there is that the synchronization of the cpus have been validated as not being a problem.
If they get the common clock, and receive the reset signal, they are in sync to a perfectly sufficient level.

Well, thanks to the recent great work of Mike Brown on ULA documenting we can move on!

Important: All information about the undocumented feature of ULA's pin19 - Red video line is confirmed and working exactly as in the MJB Documentation/Schematics !

Here is the new simple schematic I've created:

The idea is when the button is pressed pin19 is pulled high (ULA counters are cleared) and CPU reset line is set to 0,
when the button is released ULA and CPU start. I'm still using external 12MHz generator for easy monitoring.

... and to summarize although it's possible to control ULA counters, it's not enough for stable work (with more than 2 Orics it will be nightmare). I think the best is to have a way to be able to drop single pulse from the 12MHz clock.
Any other ideas?

My next step is create new ROM with vertical and horizontal color-bars to see how they look when mixed.

@iss excellent news -- your circuit (posted) covers basically what I described regarding diodes to isolate the "R" outputs (p19) from each other, and to also kick the processor into reset, just to be sure.

You were probably getting contact-bounce from the switch that was upsetting things. A clean reset signal must be important -- also it must be held high for at least 20ms (absolute minimum) to ensure both ULAs have reached their HSYNC point independently, noticed P19, and shut down awaiting P19's release. If the pulse is too short, one (or both) ULA will miss it. And no sync.

As to combining the RGB outputs of two Orics, there's a bit too much heavy thinking about how to combine 4 TTL "reds" into different levels -- this is really easy. It's just a resistor ladder/weighted sum of the TTL 0/1 values. If you look up R-2R ladders on Google, it's right there.

A similar scheme was used in Oric Owner to create a monochrome/greylevels signal from the R-G-B output of one Oric. Although the first attempt (Issue 5/P21) was wrong -- it used equal resistors for R,G,B which would lead to Black, Grey 1 (Red, Green, Blue), Grey 2 (Yellow Magenta Cyan) and White. This is not useful, as red on blue would be Grey1 on Grey1, it only provides 4 distinct levels. And the sync wasn't included properly!

There was a correction posted in a later magazine (Issue 7/P13) which is better, but not quite right. What should happen is Green is the lowest value resistor, Red in the middle, Blue the highest value resistor (as our eyes perceive green>red>blue for luminosity). But at least this version gives 8 levels of grey.

If you use that scheme to combine Red (From oric-1) with Red (From oric-2) you can get 4 levels of red from the 2 binary bits. Same for green, blue.

Now regarding the color mixing, there are multiple things to consider:
- We probably still want normal Oric software to run as before (even if still exploiting only one machine)
- We would like more color tints (like what mike wrote), more levels for red, green, blue, gives us shades
- We also would like to limit attribute constraints (so we can have six pixels of different color side by side on the same byte, for example)
- We also probably want to be able to do faster graphic manipulation (with four cpus, you can scroll the HIRES screen pixel per pixel @50fps)
- We would like to have some smoother/less flickery graphic updates
- In a game, you probably want a mix of all the above: A faster scrolling, with less color constraints, and more shades, and possibly a super colorful area where the scores and dashboard is displayed!

Depending on how things are mixed, some solutions are mutually exclusives.

The simple merging of components (let call that OR-ING the inputs) that ISS is currently using does not add any new colors, but it allows a number of things:
- You can still run the main machine normally (assuming the other machines just display BLACK)
- If you put each machine in charge on just a section of the screen, you can speed-up the display by the number of machines (so with two machines one can do the top part, one can do the bottom part, or left/right split,
- You can even have one preparing the next frame while one is showing the current frame - double buffer display)
- With three machines, you can use one for each component and display attribute-constraint-free graphics

The resistor ladder method suggested by Mike on the other hand does not lift any of the constraints we have, but allow us to have
- 4*4*4 = 64 different colors on screen at the same time using only two machines,
- 8*8*8 = 512 colors with three ULA
- 16*16*16 = 4096 colors with four ULA

What would be cool is to find something - not too complicated - that would allow to switch between these two modes, possibly even during the actual display (assuming of course the code is using the VSYNC and counts the number of cycles, or use properly timed IRQs), but I guess that would require some kind of signal control pin used to select between the two merging methods...