On Mon, Apr 11, 2005 at 04:51:43PM -0400, Sean Davis wrote:
> On Apr 11, 2005 2:32 PM, Michael <macallan18@earthlink.net>wrote:
>> Hello,
>>
>>> I made another test kernel:
>>> http://macallan.homeunix.org:6704/stuff/BSD/sparc/SPARCbook3GX_04_11.bz2
>>> Changes:
>>> - added MSDOSFS ( for CF cards and such )
>>> - more tweaking of byte-swapping code in the PCMCIA driver
>>
>> These changes:
>>> - working wsmouse ( uses the same code as sparc64 - ms* at zstty?  )
>>> - CG3 emulation in pnozz turned off
>> are mainly for XFree86. I got the cg3 driver to work earlier but started my own a few days ago so the cg3 emulation had to go :)
>> Since XFree86 doesn't know how to talk to a Sun mouse directly there had to be wsmouse support.
>> What works so far:
>> - XFree86 4.4 ( didn't use 4.5 because it had some serious problems on other platforms )
>> - 8 bit colour. Nothing else yet
>> - hardware cursor. So far the only really useful thing the cg3 driver wouldn't do too ;)
>>
>> What doesn't work:
>> - external mice - that's a driver problem in NetBSD
>> - any non-native resolution, mode switching or external monitor support
>> - acceleration, although simple screen-to-screen copy stuff should be
>> very easy to add, Line drawing and colour expansion isn't that hard
>> either. We'll see.
>> - for some reason the Xserver hangs on exit - no idea why yet.
>>
>> If anyone is foolhardy enough to play with it I'll tar the binaries
>> together and make them available for download. The Xserver needs the
>> kernel mentioned above or something newer with my changes to the
>> pnozz driver and cg3 emulation disabled, it will /not/ work with
>> stock kernels, if emulation is in place it will use the cg3 driver.
>
> Sure, I'll give it a shot. Is this a full release we're talking about,
> or tarballs of X and such? I can trivially backup/restore my sparcbook
> using an old 1 gig external sun scsi drive I've got sitting around
> somewhere. (one thing that truly amazes me... I'm used to (and
> admittedly spoiled by) SATA150 drives... hard to believe that what
> these boxes use is called "fast scsi" ;)

I test mine with netbooting the netbsd stuff.  The internal drive still
has Solaris 2.6 on it.

> Also, these boxes *are* technically capable of at least 16 bit color,
> right? I don't mean that it's working in NetBSD now, but that there is
> hope that it will, eventually? I sense great potential for use as X
> Terminals :-)

Technically, up to 32 bit:

# /usr/sbin/fbconfig -l
Framebuffer type 0, width=800, height=600 (Internal SVGA)
Framebuffer type 1, width=800, height=600 (Int & Ext SVGA)
Framebuffer type 2, width=800, height=600 depth=16 (Internal SVGA [Depth 16])
Framebuffer type 3, width=800, height=600 depth=16 (Int & Ext SVGA [Depth 16])
Framebuffer type 4, width=800, height=600 depth=32 (Internal SVGA [Depth 32])
Framebuffer type 5, width=800, height=600 depth=32 (Int & Ext SVGA [Depth 32])
Framebuffer type 10, width=1152, height=900 (Sun 1152x900 66Hz)
Framebuffer type 11, width=1152, height=900 (Sun 1152x900 76Hz)
Framebuffer type 12, width=1024, height=768 (Sun 1024x768 76Hz)
Framebuffer type 13, width=1152, height=900 (Nanao 1152x900 66Hz)
Framebuffer type 14, width=1152, height=900 (Nanao 1152x900 76Hz)
Framebuffer type 15, width=640, height=480 (VESA 640x480 72Hz)
Framebuffer type 16, width=800, height=600 (VESA 800x600 56Hz)
Framebuffer type 17, width=800, height=600 (VESA 800x600 60Hz)
Framebuffer type 18, width=800, height=600 (VESA 800x600 72Hz)
Framebuffer type 19, width=1024, height=768 (VESA 1024x768 60Hz)
Framebuffer type 20, width=1024, height=768 (VESA 1024x768 70Hz)
Framebuffer type 21, width=1280, height=1024 (IBM 1280x1024)

> (I ran KDE remotely from my main workstation displaying on my SB3GX...
> The collide light on my transceiver was blinking even faster than the
> send/recv lights :-P

I tended to go the otherway, serving up xdm on the SB3GX and hitting
it with a Sun Xterminal1 (running NetBSD, of course), to get up to the
whoping 1152x900 display. =)

I normally run mine at mode 4 up there, just so I can get more colors on
the screen.  Sometimes I switch it back to mode 0, so I can run Wabi or
Sun Doom.

>> Besides that it's surprisingly usable even without acceleration. I
>> can't help wondering if Sun's Xserver used any acceleration on this
>> chip at all.
>
> Even with the CG3 emulation, it wasn't bad, and that was with
> everything further limited by what 10baseT half-duplex could handle.
> More color depth plus support for external sun mice and it'd be a
> great little X machine.

While at home, I tend to use the SB more than either of my larger
desktop systems.  With rdesktop, I can remote into my Windows box and
take care of business there too.

-- 
Michael Parson
mparson@bl.org