Developer blog: miod [on VAXen and frame buffers]

This is also the oldest processor modern BSD operating systems run on. The oldest vax model, the VAX 11/780, was introduced in 1978, but the VAX ARM (Architecture Reference Manual) mentions work on this processor started in 1975, more than 30 years ago.

Of course, such a design is not on par with modern standards. The MMU using a single-level page table, and the floating point being non-IEEE754 are the two main drawbacks of the vax (although some may reasonably argue the latter is actually a good thing). Yet it is incredibly rad. How many processors come with a built-in instruction which computes polynomials of degrees up to 31? And how many processors have been implemented as CMOS logic, and as such, patchable by end-users, as long as they have enough electronics skills? Last but not least, how many processors are binary compatible with the PDP-11 instruction set, to the point of being able to run the first International Obfuscated C Code Contest entries?

Of course, VAXen are obsolete by today's standards, and have been for a long time. You might nevertheless be surprised by the performance of the last models - some running up to 100MHz, and running circles around your 10 years old 100MHz Pentium - not so bad, for machines made in '90 (but then, not surprising for a processor which has more registers than the x86 family).

Vax machines have historically been associated with BSD development, so it's no surprise that when NetBSD was created, a port to the vax architecture appeared quickly.

When OpenBSD was forked from NetBSD, it had the existing vax codebase, but there was no real interest in maintaining this port; no developer was then willing to admit he had a vax, so no real effort was made besides checking it still compiled from time to time. In particular, there was no distribution at all.

Things changed in early 2000, where Brandon Creighton (bjc@) wanted to bring the OpenBSD/vax port back in shape. He started merging the NetBSD improvements and fixes, and fixing bugs on his own; Hugh Graham (hugh@) was also interested and together they got the port alive in a few months.

OpenBSD 2.8, released for that year's fall, was the first officially supported vax release. Since then, development has continued, supporting a few more models, fixing bugs, as usual, at a reasonable pace.

Initially, all VAXen were running with serial terminals only; however, there were some desktop workstations produced (the VAXstations), which are quite popular; these machines were able to run X11 (err, DecWindows) like any other workstation at the time.

Although the support for various VAXstations appeared in NetBSD between 1996 and early 2000, there was no real effort made to support a graphics console on them - mainly because there was no known documentation about these various frame buffer models. Only the built-in monochrome frame buffer on VAXstation 3100 was supported, but I doubt it was really used.

The first VAXstation I got my hands on had the unsupported gpx frame buffer, and I experienced the need for an MMJ serial console cable the hard way. But I have always wanted to address this problem and be able to use this machine with a glass console. Doing some vax frame buffer work was on my list anyway, it was just a matter of getting in the mood for serious hacking.

Then came Blaz Antonic: he found some incomplete Digital documentation for the VAXstation 4000/60 lcg frame buffer, tinkered a bit, disassembled the self-tests in its ROM to find how the frame buffer operates, and wrote a preliminary driver, which unfortunately was left in oblivion despite positive end-user feedback.

Unfortunately, lacking driver writing knowledge, Blaz modeled his work like the only vax frame buffer driver he had as an example: the smg monochrome driver. And this driver was a pretty bad example.

If you go back in time, the first vax frame buffers were Q-bus cards on MicroVAX II, and they had both the video logic and a dual uart for the keyboard and mouse ports. The old 4.3BSD driver used to manage all of this as a single tty.

However, those days, both NetBSD and OpenBSD use the wscons console framework, with independent keyboard, mouse and display drivers which, together, provide a tty.

The smg driver was adapted from the old 4.3BSD code, with the keyboard interface removed, but it was not using much of the graphics console facilities the wscons framework provides (better looking fonts, multiple display support, color, etc).

My recent work consisted of basically rewriting smg to make it a modern wsdisplay driver, and importing Blaz's work, after adapting it in the same way. Then I had to enable the keyboard and mouse drivers, fix some bugs, check that everything works perfectly, etc. And as a bonus I added a driver for the low-end color frame buffer found on the VAXstation 3100 models 30/38/40/48 (the gpx frame buffer, not the spx one), so that I could finally run my VAXstation 3100 m38 as it was intended to be used.

The next logical step, of course, was X11 support. Since none of the supported frame buffers use acceleration (yet), the dumb Xwsfb X server will do the job; all it took was minor tweaks to the X server code to let it compile again on vax, as well as keyboard information for the LK-201 and LK-401 keyboards used on VAXstation. There are still endianness problems to solve before the smg frame buffer is supported by the X server, though.

And works continues...