Subject: Re: Unsupported Framebuffers...
To: None <port-pmax@NetBSD.ORG>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: port-pmax
Date: 03/05/1998 19:48:22
On Mar  6, 12:06pm, Chris Collins wrote:
> If I have an unsupported framebuffer on an DECStation 5000/240 - Will I
> get a console - or will I need to use a serial console or something
> along those lines - IE:  Does/will character mode work?

>  According to the source code, it should print out a message saying
>the console device is not supported and that it is switching to a
>serial console.

Yup. That's what it should do.

FWIW, even Ultrix doesn't use the PROM console code wherever possible.
I used it briefly on a 5000/240 while porting the V-kernel to that
hardware about six(!)  years ago.  It's really, horridly slow. Seeing
the PROM console scrolling on a PMAG-AA was enough to stop people
from using the V-kernel.  It also plays heck with interrupt handling.
And having the kernel go into the PROM to poll for keyboard I/O is
just hideous.

I decided it simply wasnt worth supporting PROM output on otherwise-
unsupported graphics heads.  Just use a serial terminal, it's better.

My own preference for unsupported hardware is to say `ship me one and
we'll see''.  The PMAG-C, and PMAG-D/E/F turn out to be not just
undocumented but hideously complicated. A dumb truecolour TC
framebuffer like the PMAG-J should be pretty simple to figure out.

It'd take me one to two days hacking to mmap() the board, figure out
where the cursor chip and the screen dimensions are, and cut-and-paste
together a console-compatible NetBSD driver.  

Whether the Xconsortium X server works is another question: i dont
think it has truecolour support at all.

Linux? Why bother when you can get a more stable, better supported
BSD? I suppose there's no accounting for taste.