Patrick Finnegan <pat at computer-refuge.org> wrote: 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. 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 the user.) 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 server. 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! MS