Mike Brown wrote:
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!
I will keep an eye on the thread, it is looking good!