[rescue] LCD hi res 17" monitor wanted

[Arno Kletzander]

In a message dated Thu, 14 Mar 2019 11:43:54 +0100, Romain Dolbeau
<romain at dolbeau.org> wrote:
> >got as far as having a SparcClassic (builtin cgthree) generate RGB+sync
> signals
>
> I didn't realize the CG3 was programmable in any way. Is it only in the
> Classic
> or are the standalone, fixed-resolution CG3 also (somewhat) programmable?

Hmm, this is not totally clear to me, as I only experimented with the
SPARCclassic (correct capitalization this time, finally...) back then. My idea
was to enable it for use as a game console, media center/home automation front
end etc. I'm not even sure I have an sBus cgthree sticking around somewhere
too (but quite probably have), just not the time needed for further
experimentation just now.

But going by e.g.
https://github.com/spotify/linux/blob/master/drivers/video/cg3.c which claims
to be a "framebuffer driver for CGthree chipsets" and has globs of register
values for different modes in it, they should be similar enough. There may be
a thing about the number of available clock frequencies with the sBus boards
having just one (or later, two selectable) xtal oscillator(s) and the onboard
variety giving IIRC 16 selectable clocks from a pre-programmed PLL thingie. (I
remember having to take one to the RF lab at University, probing the circuit
and stepping through the "factors" with OBP commands via serial console to
measure the higher ones with their counter as my own old Genrad nixie tube one
would not go beyond 50 MHz or so).

> > further information to the capabilities of the different frame buffers
(and
> especially meaning of the flag/control bits)
>
> There was some Sun documentation for the TGX on the net once, and the
> BT467 RAMDAC is documented as well...

I think this plus the Sun Framebuffer FAQ is where I gleaned what little I
already know from. The timing however is generated by a Sun house-numbered LSI
ASIC for which I could not scrounge up original documentation at that time.
The rest was reverse engineering of the cgthree fcode ("firmware" written in
Forth) and scoping the sync signals while experimenting with various values,
for which I had generated a worksheet to help me with the back-and-forth
between micro-/milliseconds and dot clock/line times. (All of this was
probably about ten years ago by now, I tried to find the reference in the
classiccmp mailing list archives where most of that took place but those are
only online back to 2014 ATM. I may have to go dig in my private mail archive
at home.)

> As for SDTV - I don't understand the question; it's only 480i or 576i,
> both of which are much lower than the
> standard Sun 1152x900@(66Hz or 76Hz). A TGX can output 720x576 or
> 720x480 non-interlaced, though
> I'm unsure whether the pixel clock can be set _low_ enough ...
> (Interlaced is 13.5 MHz, non-interlaced is 27 Mhz).

The problem is not the performance per se but the framebuffer needing to be
"interlacing aware". I was shooting for 576i which, somewhat simplified, goes
like
[VSYNC][Field1:Line1-HSYNC-Line3-...][VSYNC][Field2:Line2-HSYNC-Line4-...]-re
peat 25 times a second (with the relation of VSYNC to HSYNC changing by half a
line for the 2nd field)
and the best I managed to do was what one might call "288p", like:
[VSYNC][Field1:Line1-HSYNC-Line2-...]-repeat 50 times a sec.

This allows the monitor to sync to the signal and was actually used in some
cheap systems back in the day ("Older video game consoles and home computers
often generated a technically-compliant NTSC or PAL signal, but only sent one
field type rather than alternating between the two. This created a 240- or
288-line progressive signal, which in theory can be decoded on any receiver
that can decode normal, interlaced signals.[1][2][3] Since the shadow mask and
beam width of standard cathode ray tube televisions were designed for
interlaced signals, these systems produced a distinctive fixed pattern of
alternating bright and dark scan lines; many emulators for older systems offer
to recreate this effect. The horizontal resolution ranged from 160 pixels to
720 pixels, depending on the video chip's capabilities (and the skill of the
programmer).", https://en.wikipedia.org/wiki/Low-definition_television ) but
is of course somewhat unsatisfactory as it yields a weird x/y ratio leading to
distorted letters, logos etc.

The best solution I could think of at that time, assuming the ASIC itself had
no interlacing capability at all, was to generate a nominally 576*p* signal
with an additional gap between the fields where an external hardware circuit
could inject a second VSYNC pulse. A driver shim would be needed to direct
access to odd lines to the first half of frame memory and even lines to the
second but I did not pursue this further as I wanted to be reassured there
actually was no easier way before investing more effort.

Best regards,

Arno // DO4NAK