Merging video output?

If you want to ask questions about how the machine works, peculiar details, the differences between models, here it is !
How to program the oric hardware (VIA, FDC, ...) is also welcome.
ThomH
Flying Officer
Posts: 146
Joined: Thu Oct 13, 2016 9:55 pm

Re: Merging video output?

Post by ThomH » Fri Apr 27, 2018 4:53 pm

Dbug wrote:
Fri Dec 15, 2017 7:49 pm
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.

User avatar
Dbug
Site Admin
Posts: 2635
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Merging video output?

Post by Dbug » Fri Apr 27, 2018 9:26 pm

ThomH wrote:
Fri Apr 27, 2018 4:53 pm
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.
ThomH wrote:
Fri Apr 27, 2018 4:53 pm
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.

Just getting more colors but staying at 1mhz is kind of a shame, imo :)

NightBird
Officer Cadet
Posts: 33
Joined: Sun Nov 24, 2013 7:00 pm

Re: Merging video output?

Post by NightBird » Sun Apr 29, 2018 6:29 pm

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

User avatar
Dbug
Site Admin
Posts: 2635
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Merging video output?

Post by Dbug » Sun Apr 29, 2018 9:14 pm

NightBird wrote:
Sun Apr 29, 2018 6:29 pm
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

NightBird
Officer Cadet
Posts: 33
Joined: Sun Nov 24, 2013 7:00 pm

Re: Merging video output?

Post by NightBird » Mon Apr 30, 2018 10:35 am

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?

Link to RGB generated levels picture:
https://www.gamoover.net/Forums/index.php?topic=33623.0

ThomH
Flying Officer
Posts: 146
Joined: Thu Oct 13, 2016 9:55 pm

Re: Merging video output?

Post by ThomH » Mon Apr 30, 2018 2:44 pm

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?
Dbug wrote:
Fri Apr 27, 2018 9:26 pm
ThomH wrote:
Fri Apr 27, 2018 4:53 pm
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.

User avatar
Dbug
Site Admin
Posts: 2635
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Merging video output?

Post by Dbug » Mon Apr 30, 2018 6:26 pm

Tom: You should probably read back the entire thread :)

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.

Just not sure how to achieve that in hardware :D

ThomH
Flying Officer
Posts: 146
Joined: Thu Oct 13, 2016 9:55 pm

Re: Merging video output?

Post by ThomH » Mon Apr 30, 2018 7:15 pm

Dbug wrote:
Mon Apr 30, 2018 6:26 pm
Tom: You should probably read back the entire thread :)
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.

User avatar
Dbug
Site Admin
Posts: 2635
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Merging video output?

Post by Dbug » Mon Apr 30, 2018 8:06 pm

ThomH wrote:
Mon Apr 30, 2018 7:15 pm
Dbug wrote:
Mon Apr 30, 2018 6:26 pm
Tom: You should probably read back the entire thread :)
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.

Sorry for the lack of clarity.
ThomH wrote:
Mon Apr 30, 2018 7:15 pm
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.

Post Reply