The Sinclair QL Forum

Erratum: when I said MODE 4 I did of could mean MODE 8. There is no blue in MODE 4.

You have not confirmed so far you have a working stable 12V power supply. The PAL circuitry is one of the few places in the QL that actually need this voltage - It could well be the problem is nowhere near the QL as such but in the PSU (which I find very probable).

Tobias

According to the datasheet for the MC1377 - the power input needs to be nominally 12V, around 30ma available. There is an onboard regulator on the chip to drop this to 8.2V That would suggest that the power supply needs to be at least 10V (so if it's 12v or there abouts, that's fine). The 12V is also used for the Serial port drivers.

However, the fact it seems to be 'partially' working suggests that the 12v is probably ok - worth testing this, as it's a quick and easy test to make. You can also test the 8.2 v output to verify the on chip regulator is working correctly - pins 14 (12v) and 16 (8.2v)

http://www.smspower.org/uploads/Develop ... MC1377.pdf

I just tested on my 1377. The drop-out voltage seems to be around 10.1 - 10.2v, which is where you start getting problems - and the problems do not look like as shown.

If the 1377 had a supply problem, it would show up in the luminance as well as chrominance feeds.

From the video and symptoms described, this is a specific V-channel problem, but we'll have more information when OP posts a video showing red, green and blue bands.

Meanwhile, given the high frequency of video problems (ahah, a pun!) I have restarted a project from 2013 to produce an improved video output that is much friendlier to converters and upscalers.

Hello
Today has been a very long day at work.
So i had a very short time for testing.
Only could record the video Dave asked for

https://youtu.be/FMYqZQqE4mA

One thing Dave, what do yo mean when you say L3, i can't find it on the service manual........

Regards

That was informative. The chroma is broken, and not just in the V plane.

L3 looks like a resistor but is a 22uH choke, located between the modulator and the RGB socket, at the very back edge of the board. L5, just below the reset switch, should be the same type/value of component. L5 is used for microdrive power, so you could remove it temporarily if you just want to swap/test parts.

Schematic: Component position: L3 is due north of right edge of R55, at top of PCB.

Hi Dave

Dave wrote:Meanwhile, given the high frequency of video problems (ahah, a pun!) I have restarted a project from 2013 to produce an improved video output that is much friendlier to converters and upscalers.

Oooh - will that be based on Nasta's earlier exposition on the 8301 and the potential to toggle the clock speed during the non-blanked video segment of each scan-line in order to fit within the expected 64us and thus avoid overscan???

Sadly no.

My plan is simpler: to intercept the video signals at the 8301 and treat them differently than the current horrible system. The idea is to provide a clean S-video signal that is much friendlier to video upscalers, a composite video feed, and a new RGB output generated in a completely different way, with proper (non-TTL) levels. Also, protected so the 8301 is harder to damage than through the original RGB port.

Nasta and I differed on how to go about re-clocking the 8301.

His idea was to switch the clock to 12MHz during the small off-screen portion, then 16 MHz during the on screen portion. Timing is critical. The switches between the two clocks also have to occur in the exact right place. Otherwise, there might be pixel jitter if a clock at 1 sometimes switches to the other clock also at 1. It’s the hard but elegant solution.

My suggestion was to put the outputs into a FIFO, detecting the start of a new line and marking that in a spare lane of the FIFO since we’d be using 5 lanes so 4 lanes are free. Then, during the blanking signal, that lane is asserted. On the output of the FIFO you can clock it asynchronously, so you can do the exact same 12/16MHz clock trickery, but without messing with the 8301 timing at all. It’s just as hard, but an element of complexity has been removed. If you had two FIFOs side by side you could make a simple brute force de-interlacer.

My current preference is to split the 8301 into two ICs. One doing video through DPRAM and the other doing the simpler housekeeping logic. This would reduce the time the CPU was robbed of memory access significantly.

What I find amazing about the people on here is that even though the QL is, ahem, 35 years old nearly, we still have people coming up with great ideas on how to make it better.

Sometimes I miss being able to get my hands on the new stuff as it never seems to wotk with QPC due to an incompatible extension slot!

Cheers,
Norm.