I'm going to design and build an X terminal
msokolov at ivan.Harhan.ORG
Fri Apr 22 02:09:29 CDT 2005
Patrick Finnegan <pat at computer-refuge.org> wrote:
> I'm suprised that you dont want to do this using a VS3100 (or 4000) and
> BSD of some sort. :)
As I already wrote, I obviously considered that, in fact that was the very
first thing I thought. The problem is that the best video I can hope to
get this way is VS3100 GPX (1024x864, 60 Hz refresh, 8 planes). I have
an SPX board (which is what VT1300 and VXT 2000 used), but it's completely
undocumented, so there is no way for me to write an X server for it.
(Even though SPX was specifically designed to run X!) The SPX board is
not only specifically designed for X and therefore faster, but it has
better video too: 1280x1024 at 66 Hz refresh. I feel extremely mad and
outraged at DEC for withholding the documentation for the SPX board,
I feel cheated that the board specifically optimised for X is out of reach
of Free X server developers, leaving them to run on the earlier GPX board
which is NOT optimised for X, and it feels counter-productive to me to
invest a lot of effort into writing a Quasijarus-based X server for the
GPX board which would do nothing but feed that anguish.
And while we are on this subject, the GPX board is not actually documented
either! But the IFCTF possesses a pirate copy of the Ultrix source which
contains a kernel driver for it which provides an ioctl interface that
emulates that of the QDSS driver to run the unchanged Xqdss server.
The VS3100 GPX board is NOT compatible with QDSS at the register level,
the emulation is in the Ultrix kernel sg driver.
And to add insult to injury the GPX board has another misfeature. Apparently
its video outputs are not just outputs, but also have some kind of reflection
detectors, and its ROM self-test that executes on power-up can detect whether
there is a monitor cable attached. However, the test is overzealous and
chokes with a fatal error when my monitor is connected. Apparently it
doesn't like something about it (Viewsonic P810), even though if I unplug
the monitor during the self-test and plug it in later, the picture on the
tube is beautiful. This problem does not happen with the SPX board. That
one also apparently has reflection detectors and also reports an error,
but it's nonfatal and does not stop autoboot.
And even if by some miracle I got programming documentation for the SPX
board and wrote a Quasijarus-based replacement for the EWS/VXT software,
I would still never be able to go past 256 color map entries. I suppose
the problem would be solved if I got full system programming documentation
for the SPXgt 24-place 3D graphics board and for the VS4000 it goes into,
but I won't hold my breath for that.
That's why I decided to design and build my own hardware. Reverse-engineering
undocumented hardware and closed source software feels like peeing against
the wind. I would feel better creating a beautiful new Open Source Hardware
design than digging in DEC's closed proprietary anti-freedom shit.
> Be aware that this shouldn't be all that difficult; Linux supports
> running an LK201/401 on a serial port via a device driver in late 2.4
> and 2.6 kerneles.
It doesn't matter. The only code that will know about and talk to the
LK201 will be the X server and StarMON ROM monitor. For the Linux kernel
(and for the hardware) the LK201 port will be just a bog-standard serial
port, Linux will have no idea what is connected to it. (Keyboard support
is not needed in the Linux kernel because it'll be completely hidden from
> I'd skip USB all-together, and just use a serial or PS/2 interface mouse.
Why not offer it as an option if the extra design cost is negligible? It's
just a USB chip on the PCI bus. There is no extra software development
effort since USB mice are already supported by the Linux kernel and XFree86
> There's no reason you can't run all that off a single ethernet
> controller; for example, on IBM RS/6000 SP's, they have a 10/100MBps
> RJ45 connector, as well as either a 10Base2 BNC or 10Base5 AUI connector
> run off the same interface.
Yeah, I realise it's possible, but separate Ethernets feel a little cleaner
to me and if I use the MPC8250 there is no extra cost for it since there
are enough resources in the chip for two Ethernet instances.
Thanks to everyone for the video chip suggestions!
More information about the cctalk