Please find below an idea to test...
with a NAND gate and an input to Vcc to replace a NOT gate --> Only needs 2 packages DIL14.
The 3 last gates delays (3x10ns) the clk, to try to have a better synchro. between the clks (perhaps it is better with less or more gates...).
I do not know if it works, need to try... differents setups!

@NightBird As you probably figured out, I'm not able to answer these actual hardware questions, hopefull ISS or Mike Brown can help on that

@Chema I think it's a case of "Go big or go bust"

@ibisum That may or may not be difficult, probably depends of how Oricutron is implemented: If it's possible to instantiate more than one CPU/Ram/Etc... at the same time, it maybe possible. Alternatively, maybe it's possible to run 4 Oricutron at the same time, from a custom shell that redirects inputs and outputs and generate the final picture based on what each Oricutron outputs

The cool thing when you get this kind of setup, is that you can do funky things, like stereo audio output: The main motherboard playing on the center, one playing on the left, one playing on the right, or you can connect on one of the machine some peripherals that would not normally play well with the rest of the hardware, like a speech synthesizer (which you can also redirect and merge with the rest of the audio output).

Far far from working, but things are looking optimistic.
Unfortunately I think that something on the upper board died during dozens of power on/off
and I have no proofs that the synchro scheme works.@NightBird: your scheme looks OK for me. I'm only little concerned that it will be too pretentious for tuning using the propagation time of logic elements. But it's worth to try!

Additionally I made one quick and dirty ROM for testing.
On the pictures above you see vertical lines - it's not coincidence!
Attached are the sources, 4k and 2k ROM files. You can load them in Oricutron - edit 'oricutron.cfg' and set the 4k file as atmos rom or the 2k file as microdisk rom then start Oricutron. Pressing F3 (i.e NMI button in Oricutron) will draw vertical lines on odd or even offsets. The idea was with 2 Orics to have OR-ed picture .

At least this showed one thing: Even when not perfectly in sync, the resulting video signal is still valid, and we can generate valid video data in the normally blanked area of the screen... you did some left and right hardware overscan

I've to give Kudos to Xeron for having designed something which is not full of global variables all over the place

I had to do some ugly things to the rendering and initialization code, but it kind of mostly work.

Muhahahahahaha.

(and yes, since the four emulated machines run in the same Oricutron executable, adding the merging is mostly an academic exercise at this point, but I have issues with my version of SDL, audio on my machine cuts, and moving the window resizes it!)

I guess its not too hard now to wire them up once the hardware design is somewhat settled?

The thing is, there are many different ways to do the hardware mixing, some are simpler than other, some provide more benefits than other.
My idea is to implement a few mixing alternative in software, and see what can be done with that, the idea being to try to find what gives the more bangs for the bucks while being humanly programmable without ripping one's hairs out.

This is today's best result. We are getting closer and closer....
For now I have the same results with extra ULA and without it, so which is better - I still don't know.
About the video mixer - having an emulator for experiments and development will be really great!
Else I think everything is doable. Maybe we need to design the mixers like modules, so it's easy to change them.
Next I want to focus on the storage...

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.
Obviously it's largely limited compared to what could be done, but that gives one clear result: You can now make perfect pictures using the original 8 colors wherever you want, without any constraints at all.

I only did the test using a painting program, so it's pretty basic, but that should give you an idea.

On both cases you have:
- The original (resized to 240x200) picture on the left
- The split channels (red, green, blue) in the center (monochrome pictures)
- The original lib-pipi conversion on the top right
- The merged channels on three ULA on the bottom right

I find that LibPIPI doesn't do a nice job on the Turrican character: Color-clashes seem too numerous for me. With my own conversion tools, running others/ostro_oric.lua under graphx2, I get this which should respect oric gfx constraints:

xxx.gif (8.49 KiB) Viewed 1214 times

Now it is certain that the best is to have 3 independent colors without constraints, [ADVERT]but without it, you can always use my own conversion tools for GrafX2 [/ADERT]

Last edited by sam on Fri Dec 15, 2017 10:03 pm, edited 1 time in total.

Well, I only need to look a the picture with a 6x8 grid to tell you it's not Oric compatible
From what I see, you are using two colors per block of 6 pixels (which is correct) but you do not leave any room in between for the color changes.
You can't have a block with two different colors, followed by another block of two other different colors (except if they are both the exact inversion of the two previous ones).

If nothing is displayed, you should be good to go, if you see things like "Line 23 max:38" it basically tells you it gave up trying all combinations.
If also displays if you have more than two colors on the same block with something like "[3 colors bloc 22]"