Sun Monitor (UK) (2)

From: Richard Erlacher <edick_at_idcomm.com>
Date: Tue Jul 20 20:51:31 1999

Please view comments embedded in the quoted text below.

Dick

-----Original Message-----
From: Tony Duell <ard_at_p850ug1.demon.co.uk>
To: Discussion re-collecting of classic computers
<classiccmp_at_u.washington.edu>
Date: Tuesday, July 20, 1999 6:39 PM
Subject: Re: Sun Monitor (UK) (2)


>>
>> Unfortunately the "few weeks' training you get from programming the VGA
>> chips on most display boards is worth less than nothing because it's
>> consuming too much time and effort and using time which could be used in
>
>By that argument just about anything to do with classic computers is a
>waste of time and effort. I don't agree with that, and I don't agree that
>hacking aVGA card is a waste of time. You _will_ learn about graphics
>chipsets, video, etc. You will find that knowledge comes in useful the
>next time you have to do something like this.
>
>> more valuable pursuits. I can assure you that soldering a resistor onto
the
>> back of a display adapter is sufficient to verify that the monitor can be
>> used, and no programming of any sort is needed. If the card is capable
of
>> 60 Hz non-interlaced 1280x1024x256-color display, programming it won't be
>> necessary, as it will support that format. If it's not, all the
programming
>> either of us could do won't help.
>
>You are confused, very...
>
>No normal VGA card (I am not talking about the special ones designed to
>work with sync-on-green monitors) has the hardware for sync-on-green. So
>programming the card, however you do it, won't produce a sync-on-green
>output. That is what your resistor mod is for - to stick sync pulses (I
>wouldn't have thought they met the specs either...) on the green signal.
>
I seem to recall that several of the Brooktree DAC's, almost excusively
what's used on VGA cards and later adapters, including the ones internal to
other mfg's devices, are entirely capable of generating a bias on the video
sufficient to allow the sync to be run negative with respect to nominal
black. Others, also from Brooktree or Inmos, (they made similar products by
arrangement) would, in the presence of sufficient negative level on one of
the DAC pins, had the ability to impose negative sync on the green video as
well.
>
>What programming can do - on some cards - is support strange scan rates
>that the on-card BIOS doesn't give you. Things like xfree86 do this
>anyway on some cards (mostly the ones where the programming information
>is available). But you might want to modify the on-card BIOS ROM so that
>the BIOS/MS-DOS work with this card/monitor combination.
>
I've seen some of these attempts, some good, some not so good. They're all
limited by the performance of the DAC. Most cards with a fast enough, hence
much more costly, DAC have that DAC because they support the high pixel
rate. If they do, they probably already have a special mode in their BIOS
to allow the exploitation of that costly feature. If they don't have the
DAC, all the programming in the world won't make it adequate.
>
Multiple encounters with this particular task have taught me that this
entails a >1K-hour involvement for a specialist who has experience and all
the precise specifications at his disposal, including the unpublished ones.
I have no idea how long it would take someone who knows little about
graphics and less about the undocumented features of the display controller
LSI.
>
>>
>> The sync mixer I have used, and instructed others to use, many times
since
>> the mid-to-late '80's is quite simple, uses a current mirror, a dif-amp,
and
>> a couple of diodes configured as a negative logic OR, with the aid of a
half
>> dozen resistors. It's a circuit any first year EE student should be able
to
>> build and fully understand. If the first year EE student can do it, so
can
>> anyone else! It was probably designed by a student and then cleaned up
by
>> the guys at Brooktree, from one of whose app-notes I pinched the circuit
>> back in days of old. I had to add details about the hookup, but it's
>> essentially their circuit. The benefit is that it will happily tolerate
>> either polarity of one or the other sync signals if you fiddle with it a
>> bit.
>
>I am not disputing that the circuit works. There are plenty of good sync
>mixer circuits out there. But this won't solve the scan rate problem. Nor
>is it necessary with a GDM9150.
>
>I have no worries _myself_ in working with VHF (and the sort of dot rates
>we're talking about are VHF). But it's a lot harder than simply linking
>up a 74LS04 to invert the sync signals.
>
>At VHF you may well have problems if you try to make it on stripboard.
>Dead-bugging would work. A proper double-sided PCB with a ground plane
>would be even better. Decoupling is going to be very important.
>
>Compare that to inverting a 64kHz signal (less than 1 thousandth of the
>frequency) with a 74LS04. You can stick that on stripboard, tag a 0.1uF
>capacitor across the power lines for decoupling and expect it to work
>first time.
>
With orderly and precise assembly techniques, the little circuit I recommend
and use will work every time. The transistors are spec'd to 500 MHz and the
actual rate at which they switch is not harmed by the fact that the
switching is done in a DIF-AMP and the result of switching is simply that
the circuit draws current from the opposite transistor each time the amp
switches. It sinks the current into a current-mirror-controlled sink so
there's little noise. If the circuit is neatly built it can be
double-sticked onto an open ground plane on the video adapter card, which is
nearly anywhere on the board, these days, since they have little circuitry
other than a few memories and a control LSI. If it's built such that its
profile is low and there are no protrusions aside from a judiciously located
bypass cap or two, it will occupy little more space than the DIP in which
the transistor array lives. This location also facilitates the use of a
negative supply from within the computer.

I've never tried this circuit with a CA3083 which, though MUCH slower, has
the same pinout and array configuration as the very fast CA3127 or the
somewhat slower (than the 3127) CA3227 which is still a VHF array, but I bet
it would work, since the video doesn't go through it. My mod only requires
that the sync be drawn via the termination resistor in the monitor during
the blanking interval. That's why the blanking will work.
>
>>
>> I'd not consider trying to program this display format in to a board
which
>> doesn't normally support it because that normally indicates it isn't
>
>Depends on what the board also supports. There's no point in taking an old
>plain VGA (not SVGA) card and tying to get this sort of rate out of it,
sure.
>
>But if the card already supports something near the right rates, it's
>worth giving it a go. Maybe the card supports 1024 lines at 60Hz
>vertical. Your monitor uses 52Hz vertical (I've seen monitors that have
>that, for some odd reason), also at 1024 lines displayed. You probably
>could reprogram the card to do that.
>
I keep forgetting that a major part of the world doesn't use 60 Hz. ( !!! )
This means that you have to do your own arithmetic. I've designed and
supervised the build and test of scan-rate-converters intended to display
output from a variety of sources on a (US) standard television projection
system in an auditorium in several instances, and never had to deal with the
European video scheme. I don't know what the pixel rate would have to be
for a DAC supporting a 1280 x 1024 formatted display, but it's pretty high
at 60 Hz. The 1024 x 765 is barely supported by the fastest (65 MHz) of the
common 28-pin DAC's they no longer use. I'd have to say that at 50 Hz
vertical rate, which is used on cards offering the 87 Hz interlaced rate as
do most cards today, isn't far off the mark for this monitor if it's set up
for a 50Hz vertical rate. The rates can all be reduced by 17%.
>
>A lot of the better SVGA cards _do_ have the bandwidth to drive these
>workstation monitors. They just don't support them in software.
>
>> capable. You might want to get out your slide rule and figure out how
fast
>> the pixels have to fly out of the DAC if you want 1280 of them in the
active
>
>Sure, I know it well. That's the standard PERQ mode (albeit in 1
>bit/pixel monochrome) and I've had to debug the video output often enough.
>
>IIRC the dot rate would appear to be a little under 90MHz, apart from the
>fact that you have to consider the flyback time as well. In other words a
>'line' consists of 1024 displayed pixels + flyback time. That sticks the
>effective pixel clock to somewhere between 90MHz and 100MHz.
>
>> >Inverting a TTL signal (particularly one < 1MHz) is IMHO a lot easier
>> >than making a sync mixer which has to handle video signals aproaching
>> >100MHz. Still, it's up to you.
>> >
>> You're right, it is easier, but this circuit is already designed and
proven.
>
>Are you seriously claiming that using a 74LS04 to invert a slow-ish TTL
>level signal is _not_ a proven circuit. I can't think of a circuit that
>is more likely to work first time :-)
>
>> It simply needs to be built faithfully to the schematic and such that it
>> looks good. So long as there are no excessively long (meaning longer
than
>> absolutely necessary) wires, and so long as the soldering is neat and
clean,
>> everything should go well.
>
>At these sorts of frequencies it's worth taking care with the layout,
>decoupling, etc. After all, ghosting on green (only) is going to look
>terrible. I am not saying it can't work. It can. I would also claim that
>you could have problems with it.
>
You'll see it's dirt simple to build one of these that works fine because
the switching speed is relatively leisurely, though the Brooktree folks
spec'd a 1/2 GHz transistor array. The one I used is spec'd faster than the
CA3227. Like I wrote above, it's likely a 100 KHz version would work since
all it switches is the sync.
>
>> >You've forgotten the education you'll get doing this :-). You'll learn
>> >about programming VGA chips, working with video/sync signals, maybe
>> >getting inside the monitor and tweaking the scan rates, etc.
>> >
>> at $1(US) per hour you'll save a fortune by buying a good 20" monitor at
a
>
>Rubbish!
>
>You seem to think of everything in terms of money. You are totally
>forgetting that (a) you'll learn a lot from doing this (or are you in
>favour of knowing nothing and letting everybody else do the work). (b)
>that some people enjoy doing this sort of thing. (c) that the 20" monitor
>from the PC shop is most likely a cheap/poor design which gives a
>marginal picture even when new. That Sony looks like a good design from
>the schematics.
>
. . . and you're assuming that, perhaps like you when you started this
stuff, one knows nothing about this stuff. The third time you do this job
it gets old! It's always the same story . . . fix the other guy's mistakes
and then spend a year coding a device that was taken out of production ten
years ago. That's not terribly useful information unless it's your first or
second time.

I remember the monitors we bought for $30K each back in the mid-'80's, which
are comparable in the most superficial way to this GDM1950. The 20"
monitors down at the discount have everything superior in almost every way
to the SONY except for the tube. The ones with a SONY tube cost $500
instead of $400. However, if you want to be able to see the display from
Windows2050 as the first stabile display you see on the thing, then go ahead
and hack the ROM. That might work with one of the *NIX versions which don't
whip the display format around as much as WIN/DOS, but if you want to use
current stuff within this life, you need equipment today, not in the next
millenium.

>
>It's for the last reason that I spent a couple of afternoons fixing a
>colour TV monitor that I was given. Yes, I could buy a new onr for not
>much money. But it wouldn't have been anything like as good as my Barco...
>
>> computer store. You'd be better off shining shoes for it than trying to
>> program a board which doesn't already do what you want.
>
>You seem to be of the opinion that it's not worth learning how to do
>something if somebody else (doesn't matter who or where) can do it for
>you. This is a strange attitude for a hobby. It also probably explains
>the state the computer industry has got into.
>
Well, if it's an industry, it's not a hoby to everyone, and the state it's
gotten into is PROFITABLE, which means it will be around a while longer.
Because of volume increases on the order of 1000%, those monitors like the
one on the floor to my left, for which I paid >$5k some 8 years ago, now can
be had for $500. I guess if you only want to do what people did 20 years
ago, then fixing stuff isn't a priority, since it will be much more of an
antique once you get it fixed. I always figured it's good to know what is
happening out there now. That's particularly true since that's how I intend
to continue making my living.

What the computer industry is about is MAKING MONEY. It's good that there
are some people working in the industry who realize that it's about GETTING
PAID, and not so much about having fun.

>
>> >
>> >Or at least that's how I justify spending a few weeks mending something
>> >when I could buy one for a few pounds down at the local PC shop :-)
>> >
>> Don't they say, "penny-wise, pound-foolish" where you live?
>
>Yes, they do.
>
>But time is something that I have a lot of. Money (not from choice) I
>don't. So it is worth me spending time to fix things. If I was being
>payed at <n> pounds an hour it might be rather different.
>
>Anyway, it's impossible to justify the money you spend on hobbies IMHO.
>Sometime in the future I intend to make a mechanical clock. The necessary
>tools are certainly not cheap. And it's going to cost me around \pounds
>100 for the metal, etc to do it. The result will be less accurate than a
>\pounds 5.00 quartz clock. So what!
>
Well, some of us already know enough about how a mechanical clock works and
even how to build one. Of course that's not everybody's goal, but . . .
>
>-tony
>
Received on Tue Jul 20 1999 - 20:51:31 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:32:12 BST