Now, you are not excluded in giving your opinion on what you think would be desirable features - in the hypothetical situation where you would support the system -, if only for a small funny game/tech demo ?

Double buffering and top-bottom splits are all possible. (Or splitting by odd-even columns, allowing one ULA to set an attribute, while the other is displaying a character, allowing the colour changes to get closer together). No more "leaving a blank space" for an attribute?

- 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)

That's probably the most hard to achieve from your list ...

The ULA as it stands cannot be convinced to do that, and I'm struggling to think how two ULAs could work together to confound that limit.

Given that ULA-1 has to produce either FG or BG colour in any one-microsecond of screen (column), you can get two colours from one ULA, and two different colours from a second. But however you mix or switch between them, that's only 4 possible colours at a time. We're starting to get into 3 ULA territory, or more, for this. ULA1 outputs black or red pixels. ULA2 outputs black or green, ULA3 does black or blue. Over the whole screen. This means that to set a pixel to a colour would need to write to 1-3 locations in memory, depending on colour.

Also, you will still have to set up the colours in the preceding byte/bytes (always a limit with serial attributes).

As to syncing the Orics together, aside from the hardware VSYNC loopback into the cassette port trick -- don't forget my comments section in the PDF on putting two/three ULAs in one Oric (manipulating address lines) would mean you wouldn't need to sync between the two computers at a software level in the first place.

I don't want to interrupt discussion but just to share that after I created real button de-bouncer now synchronization is simple and works fine!

Let's make some final decisions related to the design of the future needed hardware:
1. How many Orics we need ? In my opinion 4 is OK! I'm asking because this is related to the design of the future video mixer.
2. Do we need 16K RAM overlay? It's possible but I think it will be just an unnecessary complexity.

And don't forget about the audio possibilities - with 4 Orics we will have real quadraphonic sound!(this is of course a joke although it's actually the reality )

As to syncing the Orics together, aside from the hardware VSYNC loopback into the cassette port trick -- don't forget my comments section in the PDF on putting two/three ULAs in one Oric (manipulating address lines) would mean you wouldn't need to sync between the two computers at a software level in the first place.
So many possibilities!

Oh, clearly I plan on having the VSYNC trick applied to all the connected machines, and the idea is to use the VIA timers to synchronize the machines over long operations: I assume that we can have the entire machine reset in a known state, including the 6502 and 6522?

iss wrote:
I don't want to interrupt discussion but just to share that after I created real button de-bouncer now synchronization is simple and works fine!

Let's make some final decisions related to the design of the future needed hardware:
1. How many Orics we need ? In my opinion 4 is OK! I'm asking because this is related to the design of the future video mixer.
2. Do we need 16K RAM overlay? It's possible but I think it will be just an unnecessary complexity.

And don't forget about the audio possibilities - with 4 Orics we will have real quadraphonic sound!
(this is of course a joke although it's actually the reality )

In my idea, 4 machines was the ideal setup because it's the minimum amount of hardware to reach 50fps full screen HIRES animation.

Regarding the audio, yes of course I did not forget, but connecting the audio output of the 4 YM is kind of trivial, and we can easily do things like for example having PSG 1 and 2 in the center, PSG 3 on the left and PSG 4 on the right.

The tricky part is the data exchange: I don't think we want to have one cumulus or microdisk per machine, the simpler is probably to have one machine (let's call it the master) which behave 100% like a normal ORIC, can load from tape, from microdisc, hxc, cumulus, etc... which is responsible to load everything and then send it to the other machines.

What I'm not sure, is how to do that, but we have to consider that the three other machines have unused devices:
- Fully available expansion bus
- Fully available keyboard connector
- Fully available print port
- Tape output as well as relay motor control are available too, but tape input is probably going to be used to get the master SYNC signal.

(That being said, we could still probably still use tape loading between machines, like MIDI basically, just making sure SYNC is disabled when we do that, can probably use the relay control to disable/enable the SYNC signal).

Regarding the overlay, well, that would be nice to have, because that's 16KB that can be used to do things like violent unrolled copy loops, or storing sample data for your awesome quadrophonic sound. Also the overlay is what makes fast sample sound interrupts doable: If you have to go through the ROM IRQ to replay sound, things like Oric Tech are basically impossible to do (way too slow)

Generally speaking, the problem is to bootstrap the system: After we have a small kernel of code running, we don't care about the ROM at all.

There is one small detail related to the direct video mixing - RGB outputs are not TTL levels but the signal goes through resistors 200 Ohms. The result is absolutely similar to the internal audio channel mixing discussed in Oric's 8912 volume scale.
But this actually will lead to nice effects .

Actually, regarding the color mixing, somebody the other day asked about the MultiColoric card, maybe that could be a solution: Instead of doing complicated logic to decide how the color should be interpreted, just go through a programmable CLUT... I guess the only problem would be that with four Orics that would give us 4*3=12 bit input, so a giant 4096 colors clut, that does not seem very reasonable

There is one small detail related to the direct video mixing - RGB outputs are not TTL levels but the signal goes through resistors 200 Ohms. The result is absolutely similar to the internal audio channel mixing discussed in Oric's 8912 volume scale.
But this actually will lead to nice effects .

I think this is why the values of "mixing" resistors I quoted were used, to get a better ratio of R-G-B.

With an internal 220R resistor in series, and any other resistance in the chip driver/monitor input (series resistor of 50-75R sometimes), instead of 100/510/1300 ohms you get 320/730/1520 - adding 220, or 395/805/1595 - adding 220+75, which is almost perfectly 1:2:4 ratio!

Thanks, mikeb, your math is correct .
I only mean the simplest case - without any additional resistors, simply short connected R, G and B outputs on SK2.
BTW, can you do the R-values math for 4 Oric's?

I like the idea of a 12 bit RGB output. This is equivalent to the Amiga/STE color range and allows very impressive images.

The issue though being that - as Mike mentioned - one would still have to deal with the constraints of attributes which would be even trickier as one would have to somewhat know on a given machine what values the two other machines would be displaying in order to determine if it was acceptable to use an attribute switch at a given point on screen.
For still images this would just be a tooling problem but for typical demo effects this would be quite tricky to coordinate in real time.

The ideal would be to figure out a hardware mixing method which would not rely on the theoretical maximum bit bandwidth but on the actual practical maximum bit bandwidth attainable without ever using attributes.

For example, if each Oric only uses pixel data, this is equivalent to one bit of output data and we are essentially wasting two bits of RGB output.
But, if color inversions are used on top of pixel data, then the mixing hardware can detect the inversion which gives us a second bit of information which can be manipulated with a 6 pixels precision. This is still wasteful and a bit tricky to code for but maybe this is better than having to deal with the consequence of attribute switching on three/four connected machines?
Of course, it remains to be seen whether being able to manipulate the MSB of R, G and B with only six pixels precision is compatible with good images.
But I guess it would be easy to adapt an image converter to test this.

This is of course just an idea, there might be better ones but an individual Oric is really not capable of manipulating the three RGB bits at will for each pixel so any mixing solution we come up with should probably contend with that limitation.

Thanks, mikeb, your math is correct .
I only mean the simplest case - without any additional resistors, simply short connected R, G and B outputs on SK2.
BTW, can you do the R-values math for 4 Oric's?

It's not my maths, those resistor figures were from Oric Owner, but it's my explanation, given that they didn't justify why those particular values

So if you mean for proper binary weighting, it's easy, just pick values of R that are double the previous one. Then knock 220 (or 220+75, depends on the monitor circuit) off each value, and use the closest preferred value. It doesn't have to be super accurate, just good enough to properly perceive the steps in level.

If you are just joining the R (then G, B) of 2 or more Orics together with a simple short, then you get somewhere between simple OR and reliable analog mixing. 0 0 = 0v, 0 1 or 1 0 = partial signal, 1 1 = ~5v.

Beyond that you'll have to work a little harder with multiple R values.

I'm still trying to come up with a "not too complicated" way of having both of best worlds:
- Possibility to have independent Orics used together to remove Attribute Constraints
- Possibility to have more shades of colors

The idea of using the resistors to build color graduation, could that also work somewhat revert (like subtractive instead of additive) ?

I'll try to explain...

Basically, I would like to keep the possibility to have one single Oric able to display a single Oric normal picture without any modification, basically a way to show that yes, it's still 100% Oric compatible, no cheating, all games and demos run on it perfectly with the same colors and general behavior.

Would it be possible to make it so the more voltage we get on a component, the darker it gets?

Let say we have 4 Orics, that means that potentially each of the components can have from 0+0+0+0 when a color is not used to 1+1+1+1 when all the Orics display the same color. If we could somewhat use this summation inverted, it would allow us to have all these crazy combinations of Orics working independently to achieve more speed (without additional colors), less constraints (by splitting the bitplans on three machines), and optionally to have more shades by having multiple machine set the same color for the same pixel.