What video display do you use?

Nagging hardware related question? Post here!

What video display do you use?

Regular CRT TV
1
3%
Regular LED TV
4
14%
QL Vision monitor
3
10%
RGB CRT monitor
5
17%
Multisync CRT monitor
2
7%
LCD/LED monitor
14
48%
 
Total votes: 29

User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: What video display do you use?

Post by mk79 »

Peter wrote:What tofro uses, and I also own, looks exactly like the SCART-HDMI converter in your link.
But with my QLs, the picture only appears shortly from time to time. Even with identical SCART cable wiring.
Strange. As I said, this works perfectly here (using the retrocomputershack scart cable), except the problem of the missing characters. It would only need a very slight tweak in the timing, but unfortunately all chips markings have been thoroughly removed, so it's pretty difficult to change anything :( I even had the idea of tweaking the sync timing externally using some Arduino or so, but I don't have the time to tinker that much at the moment and would probably spend the time rather on a FPGA based converter.
So I also had to resort to the GBS RGB-VGA converter. Not very sharp output, and it takes a minute to "heat up" before the picture gets stable.
Ah, wow. Not sure how long I waited back then, but the picture was really terrible. Also couldn't rule out the VGA input of the monitor is not up to par anymore, so abandoned it for now. Would prefer a DVI/HDMI solution anyway.

Cheers, Marcel


User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: What video display do you use?

Post by Peter »

mk79 wrote:I even had the idea of tweaking the sync timing externally using some Arduino or so, but I don't have the time to tinker that much at the moment and would probably spend the time rather on a FPGA based converter.
Would that converter use 68008 bus snooping or the RGB signals?


User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: What video display do you use?

Post by mk79 »

Peter wrote:
mk79 wrote:I even had the idea of tweaking the sync timing externally using some Arduino or so, but I don't have the time to tinker that much at the moment and would probably spend the time rather on a FPGA based converter.
Would that converter use 68008 bus snooping or the RGB signals?
I haven't even thought about bus snooping to be honest, though this would remove the problem of having to regenerate the pixel clock from the synch signals alone. But still sampling the RGB seems like a more generic solution.

Marcel


Nasta
Gold Card
Posts: 443
Joined: Sun Feb 12, 2012 2:02 am
Location: Zapresic, Croatia

Re: What video display do you use?

Post by Nasta »

The QL pixel clock is 10MHz in mode 4 (and in mode 8 it will just do double sampling so no big deal), and it can be reconstructed from CPUCLK by multiplying it by 2 and dividing by 1.5 (or in PLL terms, multiply by 1.3333333). There are a couple of cheap chips that can do that and at the same time provide a slightly different clock for the output, that would take care of the over-scan issue. Most midrange FPGAs have enough internal RAM to make up the two line buffers needed for scan conversion assuming the field rate remains the same, since it's only 3 digital RGB bits. Horizontal synch can be had from CSYNCHL XOR VSINCH, to generate the proper timing.
Just recently I was thinking of adding some external trickery to the 8301 ULA that gives it variable clock depending on where it is in the scan line. On the original QL, the line is 640 pixels long (64us) of which 512 pixels are visible (51.2us), whereas per standard, a maximum of 48us is reserved for visible pixels. By providing a clock switchable between 16 and 12MHz (24MHz divided by 1.5 or 2), one can clock it with 16MHz during the visible portion and get exactly 48us for 512 (narrower) pixels, then clock it with 12MHz suring the (wider) 128 invisible pixels and get the same standard 64us line length. This means the total average clock is still 15MHz as before.


martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: What video display do you use?

Post by martyn_hill »

Now THAT'S very clever (switching clock-speed mid-scan-line) and an approach I hadn't considered....

I too have been toying with some ideas to get a 1024x768 XVGA (at 60Hz) image straight out of RAM, but with limited knowledge/capability around FPGA stuff, had been investigating the bus-snooping approach using a (fast) microcontroller and an SRAM shadowing approach.

XVGA only because that's what I've got lying around and 1024x768 due to the easy pixel-doubling/line tripling multiples compared to the native QL display.

HDMI would be more future proof, for sure.

I'd never gotten my ideas further than what what is being discussed here, so hadn't spoken-up before, but Nasta's suggestion has sparked my interest again...

Clock-switching... Hummm. Can the 8301 go to the extra 1MHz?


Nasta
Gold Card
Posts: 443
Joined: Sun Feb 12, 2012 2:02 am
Location: Zapresic, Croatia

Re: What video display do you use?

Post by Nasta »

Yes, easily. Some early examples of the CLA version could not go as far as the latter plastic ones, but all seem to be able to go quite a ways further than 15MHz.

One thing I really can't understand is why Sinclair did not run the thing at 16MHz in the first place,

At 15MHz, it divides the main crystal by 1.5 and gets 10MHz for the pixel clock in mode 4. This gives it 640 pixels total for 64us per line of a standard PAL display. 512 are visible but there is overscan because the total visible pixels take 51.2us instead of the standard 48us, and 128 are invisible. A 10 bit counter is needed to count the total number of pixels. If the counter MSB is 1, the output is not produced (invisible portion for retrace) and also while MSB is high, other bits are checked for the start and end of the horizontal synch signal. The counter is reset when it reaches 639, which is binary 1001111111, note need to check for 8 1s in the counter.

At 16 MHz, dividing the main crystal by 1.5 would get a 10.666667MHz pixel clock. This gives a total of 683 pixels (actually 682.66), again 512 are visible but during the standard alowable interval of 48us, and this time 171 are invisible. Again, you need the same 10 bit counter, and the MSB is used to determine when the output is visible or not. Again the MSB=1 plus other bits are checked for start and end of the horizontal synch, and the counter is reset when it reaches 682, which is binary 1010101010, note that now 5 ones have to be checked for to generate a reset, so this saves a little logic, this may be required to more precisely determine start and end of the horizontal synch pulse.

In other words, it's basically the same amount of logic. But the latter example runs the CPU at 8MHz, 6.7% faster, and produces a proper picture on any TV and monitor. I would say both would have been a plus for the QL at the time. So why was it not done? I am not sure but it may be the loads of not exactly to spec 64k x 1 DRAMs Sir Clive might have wanted to put into the machine (kind of what he did with the Spectrum...)?

As for creating an XGA display, this requires a hardware approach. The reson is that even as it is, pixels have to be sampled at a very high, and very precise rate (10MHz, synched exactly with the actual pixels or aliasing will occur), and, especially if line trippled, output at 3x that rate, so now we are down to a 33.3333ns resolution.
There are several ways to do this but the simplest is to replace the 8301 with some simple logic to implement the original 128k RAM, and a 32k dual port RAM to shadow the screen area.
A dual port RAM is a special kind of SRAM which _really_ has completely independent access to the same memory from two different sides. Each side has it's own address, data, control lines. In our case, it's even simpler because one side (QL) only needs to write into the DPRAM, and another host, whatever it may be, only has to read. There are actually 16k x 16 DPRAMs out there ideally suited to the task.
Now, the host can easily be a FPGA or CPLD that reads out the display data scan line trippled and to a HDMI port, or it can be another computer, which might as well show the contents of the QL video in a window on it;s display. Once you have a means to read the screen data withut any penalty, or indeed, knowledge of the QL side, you can shose from several options.


User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: What video display do you use?

Post by Dave »

When Nasta mentioned this idea to me a little while ago, I took my US QL and swapped the 15MHz xtal for a 16MHz one. The 8301 runs quite happily at 16MHz and the CPU runs quite happily at 8MHz. The overscan still exists because only the frame rate is increased but the proportion/ratio of time spent reading out the clock remains the same. So, yes, the 8301 WILL run happily at 16MHz.

I haven't tried any of the clock switching trickery to shorten the time to read out the pixels relative to the whole line length. I did have to adjust my QL monitor to adjust for the altered frame rate. It doesn't make the QL 16/15ths faster either.

There will be a solution for this that includes improved video quality in due course. The 'lite' approach being to provide a new, clean S-Video signal with separate chroma and luma from the re-clocked RGB. The 'pro' approach, if practicable, will be a complete replacement of the QL video hardware. But then you're talking about an Aurora.


User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: What video display do you use?

Post by Peter »

martyn_hill wrote:I too have been toying with some ideas to get a 1024x768 XVGA (at 60Hz) image straight out of RAM, but with limited knowledge/capability around FPGA stuff, had been investigating the bus-snooping approach using a (fast) microcontroller and an SRAM shadowing approach.
This is exactly the Q68 VGA output, therefore I've long considered using a half-populated Q68 board as QL video converter.
Everything except RGB input scanning already exists. In theory it looks straightforward to implement. But the QL video signal instabilities I've seen in practice made me reluctant to invest my time there.
martyn_hill wrote:XVGA only because that's what I've got lying around and 1024x768 due to the easy pixel-doubling/line tripling multiples compared to the native QL display.
Another important reason is: It's the most widely used classic VESA timing and even "stupid" interpolation units, be it in monitors or HDMI converters "know" it.
martyn_hill wrote:HDMI would be more future proof, for sure.
The HDMI licensing costs are totally unaffordable for us. So for every device intended to serve QL users in general, HDMI is useless. The best you could do is build something only for yourself.
At the moment, the only solution I can see, is to produce a signal, which is accepted by a cheap HDMI converter mass product.
Nasta wrote:Most midrange FPGAs have enough internal RAM to make up the two line buffers needed for scan conversion [...]
Unfortunately buffering the whole 32 KB screen is still too much for many nice devices, especially flash-based ones. Buffering less, it's hard to produce a 60Hz vertical refresh rate.


Nasta
Gold Card
Posts: 443
Joined: Sun Feb 12, 2012 2:02 am
Location: Zapresic, Croatia

Re: What video display do you use?

Post by Nasta »

Even full frame buffering with 50-60Hz conversion has some problems (remember progressive pull-down on DVDs when 24FPS film was converted to 60Hz video?), so it's not a simple proposition whichever way one goes. On the other hand, is there a 50Hz version of 1024x768 VESA? At some point I remember having to solve this for some of the games machines we developed in my old job. Just tripling the number of lines and keeping the frame rate the same is much simpler and can be done in a FPGA as it involves buffering 2x 512 3-bit words. Each buffer storeas an incoming line from the QL while the other one displays the previously captured one 3x faster. On every QL hsynch the buffers flip.
The question remains if this would be VESA compatible, and this is a real issue because today's monitors have been incredibly stupidified when it comes to detecting real video parameters, it's not even funny. Funnily enough, not so with HDMI - this seems to support nearly anything since the pixels are discretely defined by a clock, rather than a clock having to be figured out from the incoming pixels.

HDMI - transmitter chips that do not have content protection (so no royalties) can still be found. We used one from Ti but don't remember the designation, will try to find out.


User avatar
dex
Gold Card
Posts: 286
Joined: Thu Dec 23, 2010 1:40 pm

Re: What video display do you use?

Post by dex »

RGBI 2 VGA - for resampling of RGB(I) to VGA, probably use of already finished device with some minor changes, mainly in timing, can be possible.
http://dzi.n.cz/8bit/mzvga/
(displays on VGA, 800x600/60 Hz, source is Sharp MZ RGBI 640x400)

Video RAM to VGA - another thing is also possible - monitoring of the data and address buses and mirroring of the videoRAM accesses (probably similar to suggested use of Q68 parts for video display).
http://dzi.n.cz/8bit/mzuni3b/
This card for Sharp MZ-800 monitors address and data bus (Z80) and mirrors VideoRAM content to VGA, moreover it provides simulation of disk drive controller (with SD card access), Quick Disk controller (with SD card access), serial I/O, RTC, RAM disk, even it runs www server for remote set-up and remote screen display!
Everything is done using one STM32F4xx ARM processor.

But I am not really sure, if these particular projects can be adapted the same way for QL.
Translation:
https://translate.google.com/translate? ... ojekty.php


Post Reply