At Mon, 26 Feb 2007 15:53:56 -0500 (EST),
der Mouse wrote:
> 
> > Now that I'm sitting with another rejuvianted hires monitor in front
> > of me (thanks very much to my friend and video wizard Doug Lee!)
> 
> Might this Doug Lee be willing to give me some pointers on doing
> likewise to mine?  I have a 1600x1280 1bpp monitor I'd very much like
> to get back in operation, but it dimmed into unusability.  I'm pretty
> sure I kept it against finding someone who could help it....

I have _lots_ of parts (in the form of about seven dead and partly-dead
monitors) and I'm sure Doug could help with repair instructions.

What he did for the monitor I got from him was to repair the main power
supply, which basically involved replacing some/most of the electrolytic
capacitors.  Apparently sometimes other parts can be damaged when the
cap goes, but usually replacing the caps is all that's necessary.  Note
the HV power supplies are usually the potted variety and pretty much
impossible to fix.  The main power supply is, in my experience, usually
the first thing to go.

Unfortunately once the tube starts to go the best you can do is
carefully crank up the master brightness until fixing the focus results
in the various focus controls getting pinned to their limits.  Even this
new monitor doesn't have much headroom any more, though it's now bright
enough to use during daylight hours and without eyestrain.  I don't know
if I have another tube that's worth spending time on, though I have two
good main power supplies, several good HV power supplies, and several
with other good circuit boards.

Let me know what you need!

> > I could mabye try to do the job for bwtwo though [...] (as I don't
> > have any hardware specs for it to work from, though if someone has
> > those they would be handy!).
> 
> The bwtwo is about as dumb as framebuffers get.  I think the only bits
> you need to care about are the video RAM and the "video off" bit used
> by screenblankers.  (I think there's some timing goop and such, but
> that's set up by the PROM code at POST and you don't need to touch it.)
> The existing bwtwo driver should tell you everything you need, I think.

That's no doubt true!

What's missing though in my head from what I've read through so far is
good internals documentation for the API between the main part of wscons
and the underlying device drivers.

Once upon a time I thought I had a pretty good idea of how the rcons
code hooked into the underlying drivers, but wscons seems quite
different to me on first glance.  I'm not much of a graphics programmer
either, unfortunately.


> > I only have just one working bwtwo sbus card and it's driving this
> > monitor from my desktop SS20 (though I sure would like to have a
> > spare bwtwo if anyone's got one).
> 
> I'm pretty sure I've got a spare.  I'll check when I get home.

That would be very much appreciated.

Having another bwtwo sbus card would certainly make testing a lot
easier.  I use this workstation for all my main programming, sysadmin,
and e-mail, etc., work.  It's inconvenient at best to reboot, or even
restart X.  Normally I like it to have uptimes, and a login session, in
the range of hundreds of days at minimum.  :-)

I have another SS5 handy for testing on though, but at the moment it
only hast a monster LEO/ZX 24-bit card in it, and of course I could
throw a CG6 in too (if that wouldn't be too much for its power and
cooling capacity).  It needs a bunch more RAM though to be a real test
as it's only got 32MB at the moment.  I've got a couple of Ultra-2's
here that I'd like to set up for testing on too, but at the moment
they're just sitting idle.

I've got a build of netbsd-4 using xsrc-current for sparc finished
successfully last night and I'm going to try to set it up on my netboot
server for testing on the spare SS5, with the LEO/ZX, to see if xfree86
really can drive the LEO with either the XFree86 and/or Xsun24 binaries.

I'm beginning to suspect that the Xsun* binaries built by the recent
/usr/src/x11 reach-over makefiles include all the MESA/GL and RENDER
extensions, given their size, but at the moment it looks like the
XFree86 binary I finally see being built is useless when linked
statically as the right things aren't set up to be referenced and linked
into it.  Currently it's the tiny one:

$ pwd 
/build/woods/always/netbsd-4-sparc-ssv8-destdir-no-g/usr/X11R6/bin
$ /build/woods/always/netbsd-4-i386-sparc-tools/bin/sparc--netbsdelf-size X* 
   text    data     bss     dec     hex filename
1847306  198396  104864 2150566  20d0a6 XFree86
2985982  184864  140296 3311142  328626 Xdmx
4515706  310904  168192 4994802  4c36f2 Xnest
2520306  181888  128728 2830922  2b324a Xprt
4149234  377672  169520 4696426  47a96a Xsun
4353186  378560  169528 4901274  4ac99a Xsun24
3975062  376032  169328 4520422  44f9e6 XsunMono
4114998  301792  187272 4604062  46409e Xvfb

I really don't want my Xserver dynamically loading code -- I want
everything I need it to support statically bound into it and ready to
use at all times.  It needs to have as stable a memory footprint as
possible too.

-- 
						Greg A. Woods

H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>       Secrets of the Weird <woods@weird.com>