OT: Color, the SCO console vs FacetWin

[Bill Vermillion]

On Sat, Apr 03, 2004 at 04:36:56PM -0500, John Esak thus spoke:

> I'm going to ask a very off-topic question here just in case
> anyone knows the answer. I'm also forwarding this to FacetCorp
> support.

> I have a 2 position (manual, passive no electronics) KMV
> switch. (A keyboard, mouse and video switch)... It lets me
> change between my Unix machine and my PC. I never use the Unix
> side... except in very rare occasions when I might reboot the
> machine or something. My current uptime is 142 days (knock on
> wood :-) Anyway, the other side of the switch puts me onto a PC
> with very fast CPU, big (you know, powerful) video card running
> Win 2k Professional.

You've been lucky with the mechanical switch.  Depending on
phase-of-the-moon, brand-of-motherboard, and probably some old
vodun icantations Unix systesm sometimes stop talking to those.
I have a client and we had a mechanical switch for the monitor -
that is OK as all it is doing is taking the output from the video
card pins and directing to the monitor.

However mice and keyboard can and often do go away - and part of
that is because of the methods MS uses - it polls everything -
while the Unix side uses interupts - and they can get lost.  That's
why the electronic one that always present signals to the computers
attached as if there was a keyboard are much better. 

That's just a point of reference for anyone who might have problems
with those.

> This question is, oh I don't know... about the electronic level
> of things inside the drivers of each system I guess. Here is
> the situation. If I run FacetWin's terminal emulator on the
> PC side into the Unix box and issue a "setcolor" command, I
> get the display of colors just fine. Everything looks great.
> I mean really, how can you judge these things? It looks fine
> to me and everyone else. No problem. The very same is true of
> the Unix side of the switch. If I issue a "setcolor" command,
> the display is perfect, crisp clear, just fine. The only
> difference and it is significant and dramatic to me... is
> that the brightness of the colors on the Unix side (direct
> console in other words) is WAY brighter. I don't mean a little
> brighter. I mean WAY WAY brighter.

Yup.  That goes back to the roots of the first color montiors on
PCs.  There are three color leads - and three bits gives a grand
total of 8 - so you got 8 basic colors.  Then there was the lead
for the brightness.  That was used for high or low.  

So if you look at the man on setcolor you will see that it
basically has 16 colors - and they really are just 8 colors with 
varying brightness.   Black with a higher level is grey.

So it it just depends on what the terminal emulator set.

I just ssh'ed into an SCO OSR5 and got the man for setcolor and
edited down we see this:

==============================

....
  ____________________________________________________________________________
  setcolor, setcolour -- set color and other attributes	of the console screen

  Syntax
  ======

  setcolor - [ bcgknopr	] argument [ argument ]

  Description
  ===========

  setcolour- set colour	and attributes of the console screen

  The setcolor command allows the user to set the screen color on a color
  console screen. Both foreground and background colors	can be set
  independently	in a range of 16 colors. setcolor can also set the reverse
  video	and graphics character colors. setcolor	with no	arguments produces a
  usage	message	that displays all available colors, then resets	the screen to
  its previous state.

  For example, the following strings are possible colors:

   blue		magenta		brown	      black
   lt_blue	lt_magenta	yellow	      gray
   cyan		white		green	      red
   lt_cyan	hi_white	lt_green      lt_red

===============

And from another OS

===============

     The color attribute byte is further broken down in to the low nibble,
     which specifies which of 16 different foreground colors is active, and
     the high nibble, which specifies which of 16 different background colors
     is active.

	   0	   Black
	   1	   Blue
	   2	   Green
	   3	   Cyan
	   4	   Red
	   5	   Magenta
	   6	   Brown
	   7	   White
	   8	   Grey
	   9	   Light Blue
	   10	   Light Green
	   11	   Light Cyan
	   12	   Light Red
	   13	   Light Magenta
	   14	   Yellow
	   15	   White

     It can be seen that the last 8 colors are brighter versions of the first
     8.

     For example, the two bytes

	   65 158

     specify an uppercase A (character code 65), in yellow (low nibble 15) on
     a light blue background (high nibble 9).

===============

The SCO listing has the standard color without the brightness on
listed and the name right below that is the same color with the
intensity.  The other listing in numerical order shows what you
send to the driver in that OS to get the desired color.

Notice that 0 is black and 8 is gray, and all the others match in
the sam order.

> So much so, that I can see the little word "red" next to the
> red block of color. When I switch to the PC side (Windows
> running the video driver now) the little word "red" is
> _completely_ invisible to me.

Boy do I know that feeling too.

> Now, my wife says it is fine, still very visible, so it is not
> wrong or anything, just very, very dim in comparison to the
> Unix/console driver side.

I have the same problems with some of the lighter shades that are
close.  You not being able to see the low value red on the PC while
your wife sees it indicates to me that you have some degree of
color blindness - and I recall reading that 8% of the males
population is affected that way.  Mine is a bit worse than normal
but not as bad as others.  True color blindness - just shades of
gray is exteremly rare.  And most people who have some color
blindness aren't aware that they have it.

> (Incidentally, she does say that the Unix/console display of
> setcolor is WAY brighter to her also... but she has no problem
> seeing the red in either case. She tells me that the colors
> on the Windows/driver side is probably 30% dimmer than the
> Unix side... the word "red" is much harder to see, but doesn't
> present a problem to her.

Windows of course has the umpty-jillion-colors possiblity -
depending on video card and drivers.  I just checked my XP drivers
and I have a choice of 16 bit color or 32 bit [and most people run
in 32 bits] but the setcolor mode for the text mode is basically
the a 4 bit color mode - 3 bits for color and one bit for
intensity.

> Well, you all know I can not see most of any day, but the times
> when my eyes do come on, I like to see whatever I can even if
> it is just for minutes and just for very short periods of time.
> So, you have to believe me I can not see the little word "red"
> at all on the Windows/driver side... not even a tiny bit. There
> is just the pure black of the background screen there where the
> word should be.

Undestandable - the same for me - but I've not had problems like
yours.

> Now, of course, this has to do with my retina and the whole
> functioning (or lack of it) in my eye. No problem. I can deal
> with that. However, what I want to know is this... What in the
> world can the SCO/console driver be issuing to the pins on
> that 15 pin DB video connector that the Windows driver is not
> issuing? I mean, there are no _varying_ degrees of intensity
> for the color scheme on SCO O/S5. Other than blinking the
> color, there is no way to get various shades of red, or what is
> more important to me, various levels of intensity. I believe
> it's just high and low... that's it.

I think the page from the setcolor man and the numerical listing
from vidcontrol for the FreeBSD I excerpted above will show that.

> So, why is it that the display on the Unix side of the switch
> where the Unix box drives the monitor directly SO much brighter
> (and completely and easily visible to me) is so much different
> from the Windows side which is running through some sort of a
> sophisticated full color driver first.

I have one client whos ap vendor set the different console logins
to different colors so they could easily tell what color they were
on.  I could not read the one that was set to red.  And when I had
to use more than one screen - and the monitor was old and dim - I
had to type blindly to enter    setcolor hi_white  to get anything
useable.

> Like I say, the colors all look very similar just the one
> side is very very dim comparatively. Is there some number the
> FacetWin side could add to its color pallet values that would
> duplicate the intensity of the direct Unix console driver?

I can't help on the FacetWin configuration - but I think the above
that I wrote tells you why.  I would think Facet would have a way
to configure it so a user could specify colors they need, but that
will have to come from current Facet users as my dwindly number of
SCO clients are all using AnzioLite.

> What I'm getting at is how can the brightness be raised in the
> Windows driver to match that of the SCO console? Don't they
> both have to present equal electronic configurations of the
> signal to the DB15 video connector for the monitor's use? To
> make one signal so much brighter than the other, there _must_
> be something different in the SCO video driver.

It's as above - a total of 16 possible colors from the SCO side
while millions from the MS side.  The old video cards were
basically TTL type controls as I recall.  The signals did NOT vary
in level - you had either a signal on any one of the three color
wires and the combination picked the base color, and you had a
signal or lack of signal on the luminance leads to generte 'bright'
as some called them, or 'hi' as SCO calls them.

Notice that yellow is nothing more than brown with intensity bit
set.  Pretty crude.  I even had more colors in my box of Crayolas
in the first grade, though there were some cheap versions of
Crayolas that gave less range than the first PCs :-)

> Thanks in advance for any advice about this. Anyone out there
> with a SCO OpenServer box a windows box and a passive switch
> that can do this simple test for me, please let me know if
> you see it the same way. Of course, I'd be interested if the
> problem exists on an active, software driven, electronic KMV
> system as well, but my bet is the displays would match exactly.

The active KVMs do nothing but present an 'alive' signal on the
keyboard and mouse, and just basically pass the video signals
through.  There will be no difference as when they are in the
circuit they are just switched, and it's only when they are not
turned to a computer that they present fake keyboard and mouse
signals.

I hope that gave you enough insight into the problem.  My thoughts
are that the Windows side needs to be made similar to the Unix
side.

Think of the way colors are specified in a web page.
You will see something like BGCOLOR="#FFFF0000" [that's yellow as I
looked at a page source].

So instead of the 0x0F for ALL the colors in the SCO type mode
you have 256 values for each of the colors.  256*256*256 gives
you 16 million which most color cards claim they are capable of.

Bill
-- 
Bill Vermillion - bv @ wjv . com