• Please review our updated Terms and Rules here

My latest Xenix build

resman

resman

Veteran Member
Joined
Jan 1, 2014
Messages
603
Location
Lake Tahoe
An Epic:

Spotting a pristine Compaq amber monitor and an original DeskPro on ePay prompted a headlong descent into building the perfect 8086 Xenix computer. After procuring a Compaq Extended keyboard (I really dislike the original keyboard, and the DeskPro didn't come with one anyway), I almost had a complete machine. Unfortunately the DeskPro was packed in nothing from the seller. Just wrapped in cardboard. As a testament to the build quality of these beasts, some of the internal support plastic shattered (including the door cam on the floppy drive) and the ST-225 just wouldn't write and read anymore. So I had to get another one of those, which arrived in short order and only had about 300K of bad tracks. Now, most of you know the exterior plastics used in this generation of computers shifts to a nasty brownish color over time. The solution (pun intended) is to give them an OxyClean bath in bright sunshine for a day. No peroxide required, and it brings them back about 90-95%. Without further ado, here is the result:

Deskpro1.jpg

I installed the Xenix 8086 that is available on the net, but I wanted to be able to develop on it. I don't know of any development system just for the 8086, but there is the 286 version here: http://www.vintage-computer.com/vcforum/showthread.php?30490-Xenix-Development-Systems

Take note of the close-up of the screen:

xenix-dev.jpg

To install the development system, know that the image files are just tar files. You can un-tar them in the root directory and get all the files installed. Afterwards, there are scripts in /tmp that have to be run to finalize the install. Getting the tar files onto the DeskPro was a bit of a challenge, though. The image files are for 1.2 Mb floppies, the DeskPro only has 360K floppies. The approach I took was to break the 1.2 Mb image files into 360K chunks under Linux, transfer them to a Zip100 drive, move to a Compaq Portable to write the images to floppy with rawrite, then import them into Xenix with dd. Finally, each 1.2 Mb image was reconstructed with 'cat', from the 4 360K files. Then the image file (really a tar file), was un-tarred and the constituent files deleted to make room for the next image. I only have a 20 Mb hard disk in the DeskPro, so free space is at a premium; there is much juggling to be done to get everything installed without running out of space.

Not all is perfect, though. For some reason, the <sys/*.h> files don't get installed. I can't find them in the development system images. The DOS versions are there, but not the Xenix versions. Maybe I'm missing something. I'd love to hear back if anyone knows where they exist.

Well, that was the past week-and-a-half project. Returning to the regular scheduled program.

Dave...
 
Very impressive. I did not expect to ever see anyone programing for Xenix again... Did you see the 7th post in that thread? The guy claims that these contain the missing system header files... Maybe that would help you. Try transfering files via serial if you have a cable. Slow but less annoying than all the disk juggling and converting.
 
Hi kyodia- those are the images I used to install the development system with - version 2.2.a, in my case. Oddly, both this and the 2.2.0b installations are missing the <sys/*.h> files for Xenix (all the main header files are there). The other version is for the 386 and probably won't work with the 16 bit development tools. I'll continue my search, they must be there somewhere. I do have uucp working between this and my 486 OpenStep box, maybe that will be the old skool transfer method of choice when I do find the headers.

Update:
I discovered my problem - somehow I didn't get the link kit installed when I originally installed Xenix. If anyone else comes across this issue, I typed 'install' and inserted the Xenix install floppies N4, N5, and N6. I had to reenter the s/n and activation code, but afterwards everything was there. Whew, now I can sleep at night. The DeskPro makes a much better Xenix platform than the 4.77 MHz 8088. I can almost imagine using this back in the day. To be honest though, I would have immediately jumped on the first 386. I have Xenix 386 installed on a Compaq Portable 386/20 and there is no comparison.

Dave...
 
Last edited:
Xenix 8086 Development System

Xenix 8086 Development System

As a follow up to the development kit installation on 8086 Xenix, here are some utility routines for the DeskPro. First, the 8086 version of Xenix is missing the simple, but useful 'clear' command. Using some sample code from "Inside Xenix", I wrote one using the termcap library:

Code: 
#include <stdio.h>
#include <sgtty.h>

int outc(c)
char c;
{
	putchar(c);
}

int main(argc, argv)
int argc;
char **argv;
{
	char *tname;
	char terminfo[1024];
	char *tgetstr(), *getenv();

	tname = getenv("TERM");
	if (tgetent(terminfo, tname) > 0)
	{
		tputs(tgetstr("cl"), 1, outc);
		tputs(tgetstr("ho"), 1, outc);
		fflush(stdout);
	}
	return 0;
}

Compile with 'cc clear.c -ltermcap'.

Then, I wanted to fix some of the issues I had with the DeskPro hardware. First, the turbo mode on my machine switches off during boot, so I have to remeber to set it with the keyboard sequence at the 'boot:' prompt. If I forget, I have to reboot. Second, the Xenix console driver sets the CGA mode using default values, turning off the hires MDA style characters the Compaq VDU is capable of. So I needed to write a program to set the turbo mode and put the VDU in hires character mode. To do so requires I/O instructions. Normally Xenix running in a protected mode environment won't allow this, but the 8086 doesn't have a protected mode, so we can use in/out instructions in our code.

With the 286 development system I installed, the Microsoft C compiler works fine on the 8086. However, the Microsoft assembler, masm, must have 286 instructions as it returns "Syntax Error" on every line. I just couldn't get it to work. The C compiler has no intrinsic inp/outp routines like the later DOS versions do, so I needed to get an assembly file that implements the inp/outp routines assembled and linked with the C code. To get around this, I compiled a dummy C file that had empty inp/outp routines, but had it output the assembly listing. I copied this assembly file to a DOS floppy, edited it for functionality and assembled it with the DOS version of MASM 5.1. The /Mu flag is needed to retain the case of the public routines. Copying the resultant object back to Xenix, it linked in just fine with the C compiler. The C code to set the DeskPro I/O ports:
Code: 
#include <stdio.h>

int inportb();

char *mode[2] = {"Off", "On"};
unsigned char vreg[] = {0x61 ,0x50, 0x52, 0x0F, 0x19, 0x06, 0x19, 0x19, 0x02, 0x0D, 0x0B, 0x0C};
int main(argc, argv)
int argc;
char **argv;
{
	int r;

	/*
	 * Set DeskPro Turbo mode.
	 */
	outportb(0xCF, 1);
	printf("Turbo mode = %s\n", mode[inportb(0x62) & 1]);
	/*
	 * Set DeskPro Hi-Res character set.
	 */
	for (r = 9; r < 12; r++) {
	outportb(0x3D4, r); outportb(0x3D5, vreg[r]);
	}
	return 0;
}


Compile with 'cc deskpro.c portio.o'. You can download portio.o here: http://schmenk.is-a-geek.com/tarfiles/portio.o.

I don't expect too many people to embark on a similar odyssey. But, at least it's possible.

Dave...
 
Very cool indeed!
I've been fascinated somewhat by Xenix... the only UNIX I know that runs on less than a 386.
It would be interesting to play around with it on an 8088 system. I wouldn't mind porting some of the 8088 MPH routines to 8086-based Xenix :)
But not having an assembler (is there inline asm in the C compiler?) would be an issue.
 
Scali said:
... the only UNIX I know that runs on less than a 386....
Click to expand...

Coherent doesn't count? Xenix and Coherent were competitors back in the day, but Coherent isn't actually based on AT&T Unix code. Coherent is also open-source at this point, released under a 3-clause BSD license. Finding install media for 8088 might be fun, though.

There are others; PC/IX that IBM sold was real Unix for the PC XT, but the first of them was Venix/86. Both were based on AT&T sources, just like Xenix.

But that's of course not the first microcomputer Unix-like system; that distinction goes to Cromix on Z80's.

I somewhat prefer Xenix between these competitors, but, then again, TRS-XENIX 1.3 on a TRS-80 Model II with the 16 upgrade was my first Unix. TRS-XENIX 1.x was a V7 Unix; later the Tandy 6000 had the System III-based Xenix 3.x.

As to the assembler, at least on the Tandy Xenix distributions the bog-standard AT&T as assembler was available, as I recall. I'll have to do a bit more digging. If someone were to come up with the 8086 Xenix devsys, the MS as (masm) should be there and should work.
 
Scali said:
Very cool indeed!
I've been fascinated somewhat by Xenix... the only UNIX I know that runs on less than a 386.
It would be interesting to play around with it on an 8088 system. I wouldn't mind porting some of the 8088 MPH routines to 8086-based Xenix :)
But not having an assembler (is there inline asm in the C compiler?) would be an issue.
Click to expand...

Unfortunately the C compiler doesn't have inline asm - at least that I could figure out. I tried asm, _asm, and __asm to no avail. Finding a working version of masm would really make this a nice development system for DOS. It's interesting that all the tools work fine on the 8086 except masm. Perhaps I'm doing something wrong.

Dave...
 
resman said:
Unfortunately the C compiler doesn't have inline asm - at least that I could figure out. I tried asm, _asm, and __asm to no avail. Finding a working version of masm would really make this a nice development system for DOS. It's interesting that all the tools work fine on the 8086 except masm. Perhaps I'm doing something wrong.

Dave...
Click to expand...

With OpenWatcom you might be able to set up a nice cross-development suite, which also allows inline asm.
OpenWatcom can compile to .obj format, so I assume it is compatible with the linker used by MASM and the C compiler included with Xenix. Besides, OpenWatcom is open source, so if you feel like it, you may be able to compile the whole thing and get it working natively on Xenix :)
 
Hello there!
Well... awesome build. I haven't been drooling after a computer in a while! :D
Would you mind taking a good 3/4 angle hi-res shot for my desktop? If you have time and means to do it, of course! I am really impressed by it...
Thanks in advance, nice work!
Bye,
~Jack
 
It's been some time, but cc will assemble files with the .s suffix. The syntax isn't the same as conventional MASM-type files; to get an idea of what it is, look at the .s file produced when the -S option is used with a C source file compiled by cc.

To get the equivalent of an inline assembly, use -S to create an assembly source from a C file, then edit the s file and compile using cc.
 
Chuck(G) said:
It's been some time, but cc will assemble files with the .s suffix. The syntax isn't the same as conventional MASM-type files; to get an idea of what it is, look at the .s file produced when the -S option is used with a C source file compiled by cc.

To get the equivalent of an inline assembly, use -S to create an assembly source from a C file, then edit the s file and compile using cc.
Click to expand...

That is unfortunately one of the first things I tried. The Xenix C compiler appears to behave exactly like the MS DOS C compiler and compile .c directly to .o files. For .s files, it passes them to the asm command, which is really masm, and it barfs just like calling masm directly. I did pass the output of the -S option to the DOS based masm, which is how I generated the .o file with the inp/outp routines. So apparently the obj file format is compatible between the Xenix compiler/linker and DOS masm. It would be nice to find a self-hosted way to get those asm files assembled, though.

Dave...
 
Scali said:
With OpenWatcom you might be able to set up a nice cross-development suite, which also allows inline asm.
OpenWatcom can compile to .obj format, so I assume it is compatible with the linker used by MASM and the C compiler included with Xenix. Besides, OpenWatcom is open source, so if you feel like it, you may be able to compile the whole thing and get it working natively on Xenix :)
Click to expand...

I also looked at nasm, as a replacement for masm, but it's all ANSI C. Now, if we could compile a DOS version of nasm, then link the resultant object files under Xenix for a native binary....
 
Jack. said:
Hello there!
Well... awesome build. I haven't been drooling after a computer in a while! :D
Would you mind taking a good 3/4 angle hi-res shot for my desktop? If you have time and means to do it, of course! I am really impressed by it...
Thanks in advance, nice work!
Bye,
~Jack
Click to expand...


Glad you like the build! I will attempt a better picture, but space is tight and the background is nothing to get excited about (plywood). I gave all the plastics a bath in OxyClean and bright sunshine which brought them back about 95% of their original color. It was all a nasty brown to start with.

Update-

I hope you're good with PhotoShop. PM me for the full size:

IMG_0178.jpg

Dave...
 
Last edited:
resman said:
That is unfortunately one of the first things I tried. The Xenix C compiler appears to behave exactly like the MS DOS C compiler and compile .c directly to .o files. For .s files, it passes them to the asm command, which is really masm, and it barfs just like calling masm directly. I did pass the output of the -S option to the DOS based masm, which is how I generated the .o file with the inp/outp routines. So apparently the obj file format is compatible between the Xenix compiler/linker and DOS masm. It would be nice to find a self-hosted way to get those asm files assembled, though.
Click to expand...

Yes, the development tools are all Microsoft based. While the compiler can generate assembler output it also generates object code directly so the C tool chain does not require the presence of masm. I don't recall what the status of masm was wrt to the x86 XENIX development system and, in any case, that (just) predates my own involvement with those tools.

My recollection is that the Microsoft C compiler of that vintage (and the version in the XENIX development system was always significantly down rev of whatever was available at the time one MSDOS) did not have any support for inline asm.

You *may* just possibly have something called "asx" on the system which, if memory serves, was a somewhat primitive assembler that operated on files in what we would now call "AT&T" syntax - or you might not - in any case it probably isn't what you really want ...

XENIX 2.1.3 was a very long lived release an was, I think, the last release that really still supported the 8088.
 
resman said:
I also looked at nasm, as a replacement for masm, but it's all ANSI C. Now, if we could compile a DOS version of nasm, then link the resultant object files under Xenix for a native binary....
Click to expand...

You'd probably have to rewrite the nasm code to be DOS/16-bit-compatible, with use of far pointers and such...
However, OpenWatcom comes with an assembler as well, called wasm, and it is more or less masm-compatible. And you can build that with OpenWatcom itself. So it might be possible to build that for 8086, and then link it under Xenix.
 
Last edited:
Scali said:
You'd probably have to rewrite the nasm code to be DOS/16-bit-compatible, with use of far pointers and such...
However, OpenWatcom comes with an assembler as well, called wasm, and it is more or less masm-compatible. And you can build that with OpenWatcom itself. So it might be possible to build that for 8086, and then link it under Xenix.
Click to expand...

I've downloaded OpenWatcom and will try just that. I'll try building itself under NT, then get the 16 bit OMF obj for wasm over to Xenix. Thanks for the idea. Fingers crossed,

Dave...
 
I checked the devsys documentation and I am about 98.5% certain that you should have "asx" and that it should run on an 8088/8086 system.
If all that you want to do is to poke a few i/o ports to tweak the hardware settings that should be sufficient.
 
You must log in or register to reply here.
Back
Top