The Xenotron XVC2
my recollections from 1983

The world wide web has almost nothing now to say about this pioneering machine, searches will point to The Seybold Report in Publishing Systems  archives, but these archives are proprietary and they really only contain information of interest to buyers and print shop managers but very little by way of technical details.

These technical details are my brain dump and rapidly fading recollections from 30 years ago and will allmost certainly not be accurate. I welcome correspondance from former Xenotron staffers that can put me right.

The reason why the XVC2 was placed in the museum, according to my explorations, was that this machine was rightfully considered to have brought about a major revolution in the typsetting and printing  business by the introduction of one of the worlds' first commercial bit mapped displays and the evolution and commercialization of the WSIWYG concept.  It also significantly reduced the cost and labour involved in the creation of display ads  in the magazine and newspaper pre-press operations which was the XVC2s' primary market.

At this time, the second generation of phototypsetters had made their appearance on the market.

At the lower range, they used glass disks containing the type font and elaborate telephoto zoom lenses to project an image of the character of the specified size onto photographic emulsion or film and a flash lamp would expose one character or rule segment at a time. The next higher option as used by major publishers such as newspaper used CRT based phototypsetters whereby an raster image of the the type on a precision CRT was projected onto emulsion, either single line raster scan or projection of "a" character was used. The font was usually generated by a vector line drawing algorithm because bit mapped fonts used more memory then was commercially available in these days. The top of the line typsetters used a laser raster scan up to broadsheet size such as the Monotype Lasercomp which I used to service as well.

These devices lacked a simple way of inputing jobs. Some had paper tape inputs though by 1983 most were online using RS232 and 9600 baud! The proprietary markup languages were typed in through dumb terminals by true experts. It was amazing to watch compositors  type in what looked like line noise, wait 30 minutes for the typesetter output to appear from the camera dark room and there was a magazine quality display ad ready for the process camera. Not many people could do this and those that could were paid a lot of good money.

Then, sometime in the late seventies, two gentleman , Tim Coldwell and Iain Houghton that I had the honor  of meeting way back in 1983, thought of a way of doing it better and had somehow raised  venture capital to launch Xenotron Plc.

They biult the XVC1, or which there were two in Australia, and then the improved and much more compact XVC2. It contained an Digital Equipment Coorporation LSI11-2 or LSI11-23 minicomputer, 8 to 32K words of memory, a Z80 board containing the floppy disk controller and some other IO controllers for a very large variety of serial and parallel interfaces.  Xenotron made its own disk controller due to the punitive cost of buying the DEC floppy controller. There was some specially custom hardware based on the Q-BUS and a proprietery bus for the image buffer memory boards. The Z80 board possessed the ( much cursed by Xenotron programmers ) "window memory". This was additional memory made available to the LSI-11 by which disk blocks could be passed but more importantly, due to the extreme cost of DEC memory, and limited address space of the LSI-11 (28k words) the entire 64K of the Z80 memory could be mapped to portions of LSI-11 address space. It was slow and mainly used for font storage. The floppy disks were initially Tandon full height drives but these were replaced with the more reliable Teac half height drives. Running the XVC2 from a hard disk never left the prototype stage due to the prohibitive cost of Winchester drives back then. Serial IO for online, keyboard,graphics tablet and auxiliary was provided with a four channel DLV11-J in the Q BUS.

The very large keyboard contained the usual keys and as many special purpose keys which were mapped to general or specific program commands and features. There was also an optional graphics tablet input device which found its primary use in the Formsmaster product. I remember installing a Formsmaster system for the Australian Taxation Office. What an "honor" it was to submit my taxes on a form that I had helped to produce! The good citizens of Australia have not had me executed yet! (if only they knew)

There was no operating system for the XVC2 , it was purely a turn-key system that knew how to talk to discrete disk blocks for program, fonts  and temporary job storage. It has no ability to input floppies from contemporary word processors allthough raw text could be loaded in from another Xenotron product, the low cost XDT, which was meant as the bulk text entry system. The XVC2 was too expensive to be considered as a text capture system. For larger customer sites, there was also the XDS ( Xenotron Data Store) which contained an LSI-11 minicomputer and a Control Data Corporation Hawk Drive with 10 Megabytes. It served as a communications hub and job data store and could connect up to 8 XVCs. Software development was also done on the XDS , at first using DEC RT-11 , MACRO-11 and then in 1984, Microsoft , yes really , Microsoft Xenix !

The special hardware which made XVC2 now sit in the science museum was the remarkable zoom card.

The display controller was implemented in two halves connected by 2 50 way IDC ribbons. One half resided on the Q bus shared with the main LSI-11  processor. The other half implemented a bus which I think was an Intel proprietary bus for the use of their then high density random access memory products. This other backplane had provision for a second memory array card. Functions implemented on the two display controller cards was mainly video memory array screen refresh addressing and super cursor generation and was implemented in 74 series TTL discrete logic. The usage of the display bit mapmemory was unique in that screen control information was stored before each horizontal scan line, so each scan line actually had a unique control register. This controlled various screen attributes, principally the start and finish positions of the supercursors.  The supercursor modulated the video intensity through a user operated contrast control, so the highlighted text/image block was allways visible as it was being zoomed or panned.

The display controller also handled the fact that the amount of displayable pixels was smaller than the amount of video memory, due to the small bandwidth and slow scan rates of then commercially available video monitors. The video display could be panned through the available display memory by a keyboard control.


The display monitors were not made by Xenotron , commercial monitor vendors ( Digivision and others) were used. There were some reliability issues with these early digital monitors. The PC revolution had not had its profound impact at this point in the state of the art.

The museum image shows the keyboard; these were custom keyboards made by Xenotron and made with extremely reliable and costly key switches. These switches lowered a small magnet towards a small reed switch. I had to replace many of these keyswitches because the solder joint would experience fatigue failure under the most heavily used keys. There was an optional mini keyboard with just numbers and common command keys. These keyboards, being proprietary, were very costly to customers. A Taiwanese keyboard maker once cloned the  keyboard, I cannot imagine what they were thinking at the time.

The XVC2 was not a generic device, it required heavy customization for each and every customer whose typesetter had not been seen before.  Each and every model of typesetter, even from the same vendor, had a differant job input method, differant markup languages and differant quirks even in the same model.  Installation involved the personal interest of a Xenotron programmer that would program the XVC2 code to cope with the particular typsetter at hand. Programming was done in the PDP-11 macro assembler language for large scale program development, but on site, the poor programmer had to hand assemble customization code and enter raw octal into a primitive debugger that could display only one line ! There was a blacklist of typesetter models for which  sales of the XVC2 was forbidden, due to inconsistant typesetter performance, no doubt as the result of bitter experience.

The way the program worked, from a particular skeleton code, which was a model of the the typsetters markup language, input keystrokes were marked as blocks to which attributes were given using a semi-gui driven by the myriad of keys on the XVC2 keyboard. This dynamically created the display list. This list was more or less, the markup code for the typsetter. The "d-list" was then interpreted or "rendered" on the display, which, all going well, would be an image of what the typsetter would create. The operator, once happy with the display, would despatch the job to the typesetter through a variety of mechanisms ranging from a paper tape punch (yes, really!), custom IO interface, serial RS232, RS422/3 or for newspapers direct online to their page markup systems.

On of the features of the XVC2 code which must have sold many units, was something called the baseline sort. Normally, even the best compositor could only create the markup code for producing one column of type. If the job called for multiple columns, or worse, multiple columns of differant fonts and point sizes, then two or more seperate jobs would have to be submitted to the typsetter. The baseline sort feature would analyse the "d-list" and perform what was in essence a raster scan. It would output the typesetter code for producing the entire job requiring no "reverse leading" of the typsetter. This meant that in practice, an entire display add, even an entire page could be set in one job, where previously, many "galleys" would have to be run and expensive union controlled compositors had to cut and paste them.