PDA

View Full Version : My latest Xenix build



resman
September 4th, 2015, 04:08 PM
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:

26282

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:

26283

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...

kyodai
September 5th, 2015, 05:02 AM
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.

resman
September 5th, 2015, 06:18 AM
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...

resman
September 9th, 2015, 09:11 PM
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:



#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:


#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...

Scali
September 10th, 2015, 12:13 AM
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.

lowen
September 10th, 2015, 06:24 AM
... the only UNIX I know that runs on less than a 386....

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
September 10th, 2015, 06:27 AM
Coherent doesn't count?

I didn't know about Coherent or others. Might have to check them out.

Caluser2000
September 10th, 2015, 10:53 AM
What about Minix http://minix1.woodhull.com/faq/srvr286.html
http://www.minix-vmd.org/pub/minix/2.0.3/

lowen
September 10th, 2015, 01:03 PM
What about Minix http://minix1.woodhull.com/faq/srvr286.html
http://www.minix-vmd.org/pub/minix/2.0.3/

Well, of course! Forgot about the system that inspired Linux.....

resman
September 10th, 2015, 01:50 PM
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.

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...

Scali
September 10th, 2015, 02:00 PM
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...

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 :)

Jack.
September 10th, 2015, 02:38 PM
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

Chuck(G)
September 10th, 2015, 03:17 PM
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.

resman
September 10th, 2015, 03:40 PM
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.

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...

resman
September 10th, 2015, 03:44 PM
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 :)

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....

resman
September 10th, 2015, 03:48 PM
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


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:

26544

Dave...

md95065
September 10th, 2015, 09:09 PM
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.


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.

Scali
September 10th, 2015, 11:33 PM
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....

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.

resman
September 11th, 2015, 05:45 AM
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.

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...

md95065
September 11th, 2015, 06:59 PM
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.

resman
September 11th, 2015, 09:49 PM
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.

It does, indeed, come with asx. I'm just not sure what syntax it expects. I tried some basic AT&T style mnemonics, but it gives syntax error on anything resembling x86 code.

My other experiments involved OpenWatcom, JWasm, and Turbo C++ 1.0. First, I installed OpenWatcom and attempted building itself. I picked the wasm project and built it for DOS16. I transferred the object files to Xenix and attempted to link them, but the Watcom compiler puts in an OMF record type that the Xenix linker doesn't understand (type B2). My next attempt was to take the JWasm project that extends the wasm project and supports more compilers. I tried Turbo C++ 1.0 because I could take an object file generated by that compiler and link it with Xenix correctly. Unfortunately, JWasm uses newer constructs that break Turbo C++.

At this point, I've invested waaayyyy too much time in this. I may have to punt on getting a native i86 assembler for Xenix.

Dave...

md95065
September 12th, 2015, 12:04 AM
I suspect that if you poke around in the link kit files you will find at least one assembler file in whatever syntax asx uses. Unfortunately, after almost 30 years, I don't remember exactly what that is although, thinking about it, I suspect that, among other things, it probably doesn't use a % prefix on register names.

Overall, though, I agree with you that it is probably unrealistic to get any of the other available assemblers running on the system.

resman
September 12th, 2015, 09:20 AM
I suspect that if you poke around in the link kit files you will find at least one assembler file in whatever syntax asx uses. Unfortunately, after almost 30 years, I don't remember exactly what that is although, thinking about it, I suspect that, among other things, it probably doesn't use a % prefix on register names.

Overall, though, I agree with you that it is probably unrealistic to get any of the other available assemblers running on the system.

You got me thinking more about this. The asx assembler is also known as the Ritchie assembler, which was written for the PDP11. So, I decided to think like some Microsoft engineer in 1980 porting the PDP11 version to the i86. I put on my PDP11 hat, and started making some guesses as to how it should behave. It took some time to figure out the I/O instructions - the PDP11 is memory mapped. Notice that the register dst/src syntax matches the Intel orientation, not AT&T. Here is the asx version of my simple I/O functions:


.text
.globl _inport
_inport:
push bp
mov bp, sp
mov dx, 4(bp)
inw
mov sp, bp
pop bp
ret
.globl _inportb
_inportb:
push bp
mov bp, sp
mov dx, 4(bp)
in
xorb ah, ah
mov sp, bp
pop bp
ret
.globl _outport
_outport:
push bp
mov bp, sp
mov dx, 4(bp)
mov ax, 6(bp)
outw
mov sp, bp
pop bp
ret
.globl _outportb
_outportb:
push bp
mov bp, sp
mov dx, 4(bp)
movb al, 6(bp)
out
mov sp, bp
pop bp
ret
.end


Thanks for the mental push. I think this syntax is much cleaner than the masm style syntax.

Dave...

P.S. This helped: http://wwwlehre.dhbw-stuttgart.de/~helbig/os/v6/doc/as.ps

md95065
September 12th, 2015, 09:29 AM
OK, one last thought on this ...

I'm not sure of you are aware of this, but the XENIX "link kit" (as the name implies) contains all of the files needed to relink the XENIX kernel which is something that you need to be able to do if you want to add or remove device drivers or reconfigure certain parameters.

For licensing reasons (the MS C compiler was an "extra cost" item) the base operating system does not include development tools such as a C compiler, but it does include the linker and, importantly, an assembler (which is needed to rebuild the configuration files). The assembler is, however, disguised to make it less obvious what it is by giving it a different name and that is what I have been trying to remember ever since I saw this post. Finally, this morning, it came to me. You *should* find that you have something called "storel" (read it as "s-to-rel" as in "something that transforms ".s" files into relocatable (ie ".o") files and the name becomes a little less obscure) on the system - I *think* that it lives in /bin. but it *might* be somewhere else such as /etc. Anyway, that should be a fully functional assembler that will run on your system. As suggested in my previous post, look for .s files in the link kit to confirm exactly what the syntax should look like (I am beginning to think that it will probably turn out the be masm, but best to check anyway). You should also be able to find some clues by looking in the link_xenix shell script that relinks the kernel.

resman
September 12th, 2015, 10:14 AM
OK, one last thought on this ...

I'm not sure of you are aware of this, but the XENIX "link kit" (as the name implies) contains all of the files needed to relink the XENIX kernel which is something that you need to be able to do if you want to add or remove device drivers or reconfigure certain parameters.

For licensing reasons (the MS C compiler was an "extra cost" item) the base operating system does not include development tools such as a C compiler, but it does include the linker and, importantly, an assembler (which is needed to rebuild the configuration files). The assembler is, however, disguised to make it less obvious what it is by giving it a different name and that is what I have been trying to remember ever since I saw this post. Finally, this morning, it came to me. You *should* find that you have something called "storel" (read it as "s-to-rel" as in "something that transforms ".s" files into relocatable (ie ".o") files and the name becomes a little less obscure) on the system - I *think* that it lives in /bin. but it *might* be somewhere else such as /etc. Anyway, that should be a fully functional assembler that will run on your system. As suggested in my previous post, look for .s files in the link kit to confirm exactly what the syntax should look like (I am beginning to think that it will probably turn out the be masm, but best to check anyway). You should also be able to find some clues by looking in the link_xenix shell script that relinks the kernel.

It appears that the link kit only include libraries, headers, and just a couple of .c (and matching .o) files. the link_xenix script is just one long ld invocation. Unfortunately, no storel, either.

Dave...

md95065
September 12th, 2015, 10:22 AM
Hmm, that is a little surprising but my XENIX knowledge only really goes back as far as the 2.2.2 release so it is possible that 2.1.3 did things slightly differently.

Anyway, at least you managed to get asx to work.

resman
September 12th, 2015, 10:29 AM
Hmm, that is a little surprising but my XENIX knowledge only really goes back as far as the 2.2.2 release so it is possible that 2.1.3 did things slightly differently.

Anyway, at least you managed to get asx to work.

Indeed, thanks for all your help.

Dave...

tingo
September 13th, 2015, 01:01 PM
Nice work!

First, the 8086 version of Xenix is missing the simple, but useful 'clear' command.

So Xenix doesn't have 'tput' either?
I have always been using 'tput clear' to clear the screen.
But I don't have much "hands on" with Xenix.

resman
September 13th, 2015, 03:16 PM
Nice work!


So Xenix doesn't have 'tput' either?
I have always been using 'tput clear' to clear the screen.
But I don't have much "hands on" with Xenix.

No, it doesn't have 'tput' (that is a new one for me). It is a pretty minimal installation, but considering it was just a handful of 360K floppies, still fairly complete. One item I thought was a little odd to be installed was the 'ratfor' translator, even though I didn't install Fortran.

Because Xenix 8086 runs without protection, it's easy to play with the hardware directly. One thing I learned is the console driver uses hardware scrolling with the CGA. Clearing the screen resets the screen start address to 0, but scrolling increments it to the next line, instead of scrolling the screen contents in software.

Dave...

Krille
September 15th, 2015, 08:53 AM
Here is the asx version of my simple I/O functions:

The 'mov sp, bp' instructions are not needed since the functions are not using any local variables. Remove them to save 8 bytes. :)

resman
September 15th, 2015, 02:48 PM
The 'mov sp, bp' instructions are not needed since the functions are not using any local variables. Remove them to save 8 bytes. :)

Yeah, the code originally came from the compiler and it was also used to make figure out the src/dst orientation of the operands. Then I thought: "I'll optimize this and remove the bp register all together and index off the sp register". Except you can't do that with the 8086 (you can with the 386). It's been so long since I wrote 8086 only code, Reagan was in office. Oh well ;-)

Dave...

Klee
September 16th, 2015, 07:04 PM
I may have to give this a go, i've played around with DOS both compaq 3.31 and compaq 5.0 , minix 2.0.2., elks linux, tried to install PCIX but failed. See http://www.vintage-computer.com/vcforum/showthread.php?11151-PC-IX-Images


But I have not tried Xenix 8086 yet.


http://img190.imageshack.us/img190/7141/img0601o.jpg


Specs, 640k ram, 2 mb addon memory board, XTIDE version 1.0 , 312 mb hard drive, 3 com 503 network card, microsoft bus mouse,original 360k f;oppy drive, black 1.44 mb floppy drive connected to a 16 bit floppy/harddrive card with only the floppy connected.

EDIT: I forgot completely that it has a NEC V30 cpu swapped in.

Deskpro fun... http://www.vintage-computer.com/vcforum/showthread.php?28922-My-Compaq-8086-configured-to-get-the-time-via-the-net-some-pics

resman
September 17th, 2015, 07:03 AM
Ooooohhhh, Deskpro Pr0n (DeskPr0n). Klee, you certainly have a decked out machine. I would be curious to know if Xenix could take advantage of the larger hard disk and network card. I didn't see any network programs in the installation, but if the kernel has support for it, maybe the 286 installation has some programs that will work. I am curious, how does your 16 bit floppy controller work in the 8 bit slot? Does it have a jumper for 8 bit operation?

I thought I'd add my motivation for my Deskpro build: I worked at Compaq from 1988 to 1992. One day I discovered a pre-production Deskpro in the lab closet, missing almost everything. So I pulled it out and started to track down bits and pieces to get it running again. I finally had it running Windows 2 with an EGA card. But when I left Compaq, I also left the Deskpro behind. I always wished I had brought it home (although they had gotten quite touchy about machines going home by '92). For this Deskpro, I thought it would make more sense to install an OS that would take advantage of the 8086 and faster processing speed. I had installed Xenix on my Compaq Portable, but it definitely suffered on an 8088 at 4.77 MHz. This Deskpro running Xenix makes a nice counterpoint to my Lisa 2 running Xenix, and I have a little background story to go along with it.

Dave...

Klee
September 17th, 2015, 03:43 PM
The 16bit controller is a generic 16bit MFM and floppy controller, no jumpers at all because ALL the floppy data connections are going through the 8-bit part of the card. It will let me boot natively either a 360k floppy drive or a 3.5 1.44 mb as a 720k floppy drive. In DOS using 2m-xbios I can access the 3.5 floppy as a 1.44 mb.

resman
September 17th, 2015, 09:20 PM
Very nice. I just ordered a V30 myself. I should have the 8087 tomorrow and it will become a UNIX graphics workstation with my 160x100 16 greyscale library. Would have been awesome in 1984.

Klee
September 18th, 2015, 05:32 PM
Very nice. I just ordered a V30 myself. I should have the 8087 tomorrow and it will become a UNIX graphics workstation with my 160x100 16 greyscale library. Would have been awesome in 1984.

And INCREDIBLY expensive ...LOL

resman
September 19th, 2015, 07:04 PM
I'm very happy with this Xenix 8086 build. Its been stable and moderately fast enough to do some development. Having multiple virtual consoles makes this a much more productive environment than MSDOS. As proof, I leave you with a Deskpro Selfie, coded all in Xenix (with image pre-processing on a Mac and Photoshop):

26728

Dave...

Klee
September 19th, 2015, 07:41 PM
Sweet!!

My Deskpro developed issues today with the eeprom on the XTIDE so I put the old MFM drive in and ran fdisk off a dos floppy the rebooted and then formatted the hard drive then it died...I guess the format was its last gasp. That was the original hard drive for the deskpro and my last MFM drive that worked. Im going to try both the MFM and the XTIDE in an 386 just to make sure that the problems are with the XTIDE and the MFM.

resman
September 19th, 2015, 07:48 PM
Sweet!!

My Deskpro developed issues today with the eeprom on the XTIDE so I put the old MFM drive in and ran fdisk off a dos floppy the rebooted and then formatted the hard drive then it died...I guess the format was its last gasp. That was the original hard drive for the deskpro and my last MFM drive that worked. Im going to try both the MFM and the XTIDE in an 386 just to make sure that the problems are with the XTIDE and the MFM.

Have you tried a LL format? That might get it going again. Xenix will do a bad track scan before the install.

Klee
September 19th, 2015, 08:33 PM
The MFM controller no longer detects the drive.....:cry:

Klee
September 20th, 2015, 03:06 PM
My MFM drive suddenly works now, got to love old hardware. Swapped it to another slot again and now it works.

I'm installing Zenix 86 as I type this.

resman
September 21st, 2015, 05:25 PM
Just installed the V30 and 8087. The bits are just flying though the Deskpro's copper and silicon veins.

If you need any help with the dev sys installation, let me know. I hope the install went without too many hassles.

Klee
September 23rd, 2015, 05:42 PM
Just installed the V30 and 8087. The bits are just flying though the Deskpro's copper and silicon veins.

If you need any help with the dev sys installation, let me know. I hope the install went without too many hassles.

The install failed .......

After the partitions are created and the system says something about creating filesystem, it then displays "no room on 2/4" three times.

Then it displays : " divvy: mount on /mnt failed: Structure needs cleaning
Cannot set up new /dev directory on new device"
I tried the default with the partitioner and played around with the size of the root swap and recover partitions and with the " overwrite" option with no luck.

Default config.
26812
Errors out
26813

resman
September 23rd, 2015, 08:07 PM
I think I kind of ran into this problem after a few failed installations attempts. Try re-writing the N1 and N2 floppy images from the source image and start again. It looks like you are installing on the 20 Mb MFM drive, correct? Did you do the full track scan?

Dave...

Klee
September 23rd, 2015, 08:25 PM
I am running the 20 mb drive, did a full scan....took a while tho lol. I'll try rewriting the disks and then try that.

resman
September 24th, 2015, 07:26 PM
I am running the 20 mb drive, did a full scan....took a while tho lol. I'll try rewriting the disks and then try that.

I hope that works. My install failed on my original hard drive, and I think it left the floppy uncleanly unmounted so it failed the next install attempt. Good luck...

Klee
September 25th, 2015, 05:07 PM
Broke out the new and never used 360k floppy's and making some new discs to try another Xenix 86 install attempt.

EDIT: Well its looking better since it did not error out making the file system like EVERY other time. LOL

EDIT 2 : It booted off the hard drive now, i'm continuing the install.

EDIT 3: Still installing, so far so good.


It WORKS !!
26841


The first thing I did was make a MSDOS 6.22 360k boot disk with just fdisk and format so I could wipe out the previous hosed Xenix install then create a msdos partition so I could start fresh then made some Xenix install disk with new 360k floppy's.

And that did the trick.

resman
September 25th, 2015, 08:57 PM
Sweet! If you feel up to the development system install, I put a zip file together with the 1.2 MB floppy images split into 360K chunks and some (very) brief instructions to reconstruct them on the Xenix installation: http://schmenk.is-a-geek.com/tarfiles/devsys-2.2.1a.zip

Klee
September 26th, 2015, 05:28 PM
Sweet! If you feel up to the development system install, I put a zip file together with the 1.2 MB floppy images split into 360K chunks and some (very) brief instructions to reconstruct them on the Xenix installation: http://schmenk.is-a-geek.com/tarfiles/devsys-2.2.1a.zip

Thanks , i'll give it a go.

Klee
September 29th, 2015, 08:17 PM
I was able to copy all the developer system floppy images to the deskpro and cat them to create the D1.rar , D2.rar ect. I unrared all four and when I run the scripts in the /tmp directory it asks for the serial number then activation key then it errors out.

Error: "./tmp/xds.ser: cannot create"

I am not out of room as I have about 20000 blocks free.

So i'm stuck.

I copied everything in the /tmp directory to a /bu folder to save everything before I did a shutdown.

resman
September 30th, 2015, 05:30 AM
I was able to copy all the developer system floppy images to the deskpro and cat them to create the D1.rar , D2.rar ect. I unrared all four and when I run the scripts in the /tmp directory it asks for the serial number then activation key then it errors out.

Error: "./tmp/xds.ser: cannot create"

I am not out of room as I have about 20000 blocks free.

So i'm stuck.

I copied everything in the /tmp directory to a /bu folder to save everything before I did a shutdown.

First, make sure all the files are in their place. Check for a populated /usr/include and things like /bin/cc. If that all looks good, move the files you saved back into /tmp. If memory serves (and it rarely does anymore), run the scripts from root, i.e."cd /; /tmp/script1". There may be some script dependencies on the current directory being at the top. I used the serial # and activation code from the _Readme.txt file. Hope that works,

Dave...

Klee
September 30th, 2015, 05:15 PM
THANKS!! that did the trick.

Next is to configure the higher res mode and faster cpu speed, kind of tired setting the turbo speed as it boots up.

Oh by the way I have only a few months of HTML programming experience about 15 years ago, I'm more of a hardware guy and user and about the last time I really messed with Xenix was in the mid 90's on a 286.

Klee
September 30th, 2015, 06:24 PM
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:


#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...



Tried this and it errors out with "fatal error 13: cannot open 'deskpro.c'"


Oh and I just started to read "sco_xenix_sysv286_programmers_guide.pdf " its for version 2.2 dated 1987.

resman
September 30th, 2015, 07:17 PM
Tried this and it errors out with "fatal error 13: cannot open 'deskpro.c'"


Oh and I just started to read "sco_xenix_sysv286_programmers_guide.pdf " its for version 2.2 dated 1987.

You will have to either type in the code above into vi or cut-and-paste, then sneaker-net it to the Xenix machine. Either way, save the source to the file name "deskpro.c". For the portio.o file, you can either download the object file and sneaker-net it, or type in the assemble source from a few pages back and assemble it with "asx portio.s". Once you have those two things, you can build the executable with "cc deskpro.c portio.o -o deskpro". That will build the binary file called "deskpro". I put mine in /usr/bin and call it during the initialization sequence in the /etc/rc script like so:



# Set DeskPro specific features.
/usr/bin/deskpro


If you can find a copy of the original K&R C book, that will help out as well. tenox sure has a nice collection of manuals to peruse. I put them on the iPad sitting next to my Deskpro.

Dave...

Klee
September 30th, 2015, 10:15 PM
Thanks to resman It works!!

26951

I HATE vi
I ended up copying the /etc/rc file to a floppy then copying it to my win 98 diskmaking pc then copied the rc file over to a debian pc via my lan and then editing it with Leafpad. Oh did I mention that I HATE vi?

I forgot how much I hate that program....

Before I edited the rc file I executed the "deskpro" binary and it worked great so I edited the rc file to let it start up on boot.

kb2syd
October 1st, 2015, 05:35 AM
Thanks to resman It works!!

26951
Oh did I mention that I HATE vi?

I forgot how much I hate that program....

Any Xenix/Unix hack is doing themselves a disservice if the don't learn vi and ed. I haven't used it on a daily basis for years yet I still remember it. All you need are a few basic move/edit commands for vi and you're golden.

w - move forward a word
b - move backward a word
l - move forward a character
h - move backward a character
j - move down a line
k - move up a line
i - insert at cursor
ESC to end insert
x - delete character
dZ (where Z is one of the movement characters above) deletes the way you tell it to. (e.g. dw will delete a word).

Knowing those few commands you could have logged in from putty/telnet, opened a file with vi, started insert mode, copied from windows, paste and the entire file would be there.

resman
October 1st, 2015, 07:04 AM
It's true that knowing vi can save a great deal of hassle. The really good news is that it is an option for Xenix. Many of the contemporary unices and clones for the XT didn't have vi (or any of the BSD goodness). We should thank someone at Microsoft for supporting the XT in 1986 and keeping a majority of the tools as 8086 code (except for whoever compiled MASM with 286 instructions). It feels surprisingly modern considering it's 30 years old.

With that said, here is the "showpbm" (Show Portable BitMap) project so you can amaze your friends with the graphics prowess of your DeskPro. I've bundled it as a tar file you can download: http://schmenk.is-a-geek.com/tarfiles/pbm.tar

Un-tar on your Xenix machine, cd into pbm and run as: "./showpbm deskpro.pbm" for the selfie. Or use the portable.pbm image for the other Compaq picture. Note, this version of showpbm resets the video mode for the DeskPro's VDU with hires characters. It will freak out a normal CGA board. I've included the source for anyone wanting to build their own. Exit showpbm by pressing the 'RETURN' key.

If you want to compile your own version of showpbm, build the binary with: "cc -M0e -O showpbm.c lores.c portio.o -o showpbm". Now, the unique and powerful feature of Xenix is the ability to build DOS programs, too. For a DOS version of showpbm, you would enter: "cc -dos -Me0 -O showpbm.c lores.c port.o -o showpbm.exe". Pretty cool, huh? A little known fact: many Microsoft DOS programs were built under Xenix. Indeed, the Xenix developers hated that DOS used "\" as a path separator and "/" as a switch prefix so they added a config.sys option to make it look like Xenix with the "SWITCHAR=-" setting. I think this disappeared after version 3 of DOS. I remember using this back in the mid '80's on my XT clone because I was using the Dual VAX 11/780 running BSD for class assignments at Purdue. No need to complicate things between systems.

Dave...

Klee
October 1st, 2015, 04:28 PM
I could not save my edited rc file. After hitting the escape key it would go back to insert mode after hitting only one key. Very frustrating at midnight and I have to be up at 5:00 am LOL.

Klee
October 1st, 2015, 04:32 PM
Any Xenix/Unix hack is doing themselves a disservice if the don't learn vi and ed. I haven't used it on a daily basis for years yet I still remember it. All you need are a few basic move/edit commands for vi and you're golden.

w - move forward a word
b - move backward a word
l - move forward a character
h - move backward a character
j - move down a line
k - move up a line
i - insert at cursor
ESC to end insert
x - delete character
dZ (where Z is one of the movement characters above) deletes the way you tell it to. (e.g. dw will delete a word).

Knowing those few commands you could have logged in from putty/telnet, opened a file with vi, started insert mode, copied from windows, paste and the entire file would be there.

I would have LOVED to networked it my deskpro but no network is configured nor is uucp and floppys work well enough for now. My eyes were straining on that low resolution and that was a top priority.

Caluser2000
October 1st, 2015, 04:41 PM
It's true that knowing vi can save a great deal of hassle. The really good news is that it is an option for Xenix. Many of the contemporary unices and clones for the XT didn't have vi (or any of the BSD goodness). We should thank someone at Microsoft for supporting the XT in 1986 and keeping a majority of the tools as 8086 code (except for whoever compiled MASM with 286 instructions). It feels surprisingly modern considering it's 30 years old..It's probably just the one cli *nix looks like any other :) Not at all dissimilar to any Dos variant prompts looking like another.

Didn't old SCO do all the hard work anyway?

It's more a dig at linux but this link does contain some interesting tidbits all the same;

http://www.softpanorama.org/People/Torvalds/Finland_period/xenix_microsoft_shortlived_love_affair_with_unix.s html

resman
October 1st, 2015, 05:30 PM
It's probably just the one cli *nix looks like any other :) Not at all dissimilar to any Dos variant prompts looking like another.

Didn't old SCO do all the hard work anyway?

It's more a dig at linux but this link does contain some interesting tidbits all the same;

http://www.softpanorama.org/People/Torvalds/Finland_period/xenix_microsoft_shortlived_love_affair_with_unix.s html

Not that the shell is that different, but the include programs give it a certain "flavor".

I thought this site had some interesting tidbits, too. This from inside the Microsoft Xenix group: http://seefigure1.com/2014/04/15/xenixtime.html

Certainly Microsoft had a lot to do with the tools used to build Xenix (at least after the CMERGE compiler). I think that all changed with SCO Unix.

md95065
October 1st, 2015, 06:23 PM
Certainly Microsoft had a lot to do with the tools used to build Xenix (at least after the CMERGE compiler). I think that all changed with SCO Unix.

Yes, essentially all of the x86 XENIX tools were from Microsoft - the C compiler. masm and the linker were just XENIX ports of the equivalent MSDOS tools (although considerably down rev in terms of version). Microsoft did pretty much all of the core kernel porting work for XENIX on both the 286 and the 386 with SCO providing additional drivers and tools. There had also been an 8086 port which ran on the Altos 586 (and possibly a few other machines) and I believe that these systems all had some rudimentary "memory management" hardware implemented in discrete logic external to the cpu. The 8086 (8088 actually) port to the IBM XT was, however, an SCO effort and a version of it also ran on on some 8086 based Burroughs systems as a task under the native OS, "BTOS".

SCO UNIX was based on AT&T's System V Release 3.2/386 - the development tools for early SCO UNIX systems were a curious hybrid of Microsoft and AT&T tools including several object format converters. Those systems could also run both 16 and 32 bit XENIX x.out format binaries as well as 32 bit COFF binaries.

It was quite a long time before the last of the MS development tools finally disappeared.

Scali
October 1st, 2015, 11:12 PM
Yes, essentially all of the x86 XENIX tools were from Microsoft - the C compiler. masm and the linker were just XENIX ports of the equivalent MSDOS tools (although considerably down rev in terms of version).

Then I guess the C compiler is actually Lattice C. Microsoft licensed Lattice C in the early days, and continued developing that codebase up to Visual Studio .NET, when they finally had a C compiler that they had written from scratch.
You'll notice that some 'quirks' from Lattice C are not present in the newer compilers.
One well-known example is the scoping of variables in a for-loop in C++:
for (int i = 0; i < 10; i++)
{...}

This will put int i outside of the scope of the for-loop in Lattice C. So you can access its value below the for-loop (and you cannot redefine i in the next for-loop because it is already defined in that scope).
In most other compilers the scope of i is only in the for-loop itself.

Funny enough on Amiga I used SAS/C, which is also a Lattice C-derivative. It had this same quirk, as well as some others I was used to up to VC++ 6 in the Microsoft world :)
I bet the XENIX tools are based on this compiler core as well (although I suppose back then there was no C++ support yet).

kb2syd
October 2nd, 2015, 04:48 AM
I would have LOVED to networked it my deskpro but no network is configured nor is uucp and floppys work well enough for now. My eyes were straining on that low resolution and that was a top priority.

I figured you would at least have getty running on one serial port. Not the best to make an assumption like that. That would have been my first step once I got it running, but that's me.

resman
October 2nd, 2015, 08:54 AM
Then I guess the C compiler is actually Lattice C. Microsoft licensed Lattice C in the early days, and continued developing that codebase up to Visual Studio .NET, when they finally had a C compiler that they had written from scratch.
You'll notice that some 'quirks' from Lattice C are not present in the newer compilers.
One well-known example is the scoping of variables in a for-loop in C++:
for (int i = 0; i < 10; i++)
{...}

This will put int i outside of the scope of the for-loop in Lattice C. So you can access its value below the for-loop (and you cannot redefine i in the next for-loop because it is already defined in that scope).
In most other compilers the scope of i is only in the for-loop itself.

Funny enough on Amiga I used SAS/C, which is also a Lattice C-derivative. It had this same quirk, as well as some others I was used to up to VC++ 6 in the Microsoft world :)
I bet the XENIX tools are based on this compiler core as well (although I suppose back then there was no C++ support yet).

Your example uses an ANSI construct that doesn't seem to be recognized, even with the -Me flag. I ran the Xenix compiler (and passes 0 through 3) through 'strings' looking for anything interesting and only found a build date in 1985. According to Wikipedia (https://en.wikipedia.org/wiki/Visual_C%2B%2B), this should be version 3.0. Running masm through 'strings' found a version of 3.09.

md95065
October 2nd, 2015, 02:14 PM
Then I guess the C compiler is actually Lattice C. Microsoft licensed Lattice C in the early days, and continued developing that codebase up to Visual Studio .NET, when they finally had a C compiler that they had written from scratch.
[ ... ]
I bet the XENIX tools are based on this compiler core as well (although I suppose back then there was no C++ support yet).

Well, there wasn't even the first ANSI C standard at the time - we are talking about mid 1980's here and the standard wasn't finished until 1989.
That being said, the Microsoft C compiler had support for quite a few ANSI features from early on - notably function prototypes - and I believe that least one of the Microsoft compiler team, Ralph Ryan, was on the X3J11 committee.

I had previously used Lattice C in around 1983 when it was one of the few x86 compilers available and I had access to all of the XENIX source code when I worked at SCO from 1987 onwards and never saw any indication that the Microsoft compiler was based on the Lattice compiler (but I had never seen the Lattice source code and it certainly is possible that is where the code originated).


Your example uses an ANSI construct that doesn't seem to be recognized, even with the -Me flag. I ran the Xenix compiler (and passes 0 through 3) through 'strings' looking for anything interesting and only found a build date in 1985. According to Wikipedia (https://en.wikipedia.org/wiki/Visual_C%2B%2B), this should be version 3.0. Running masm through 'strings' found a version of 3.09.

Yes - version 3.x sounds right - we never got much beyond that - Microsoft wasn't really interested in maintaining support for XENIX by then so newer versions of the compiler always needed a substantial amount of work to get them running on and generating code for XENIX. Source code control was almost unheard of at that time and there was a lot of code churn going on making it both difficult and expensive to attempt to stay up to date.

The compiler in question was known as the "cmerge" compiler and, as I recall, also had a BASIC front end. There was also some evidence that someone at some time had tried to leave open the possibility for Fortran and Pascal front ends as well - presumably to allow the new compiler to replace the much older Fortran and Pascal compilers that Microsoft had at the time (and while I don't know for sure, I think that it is a very safe bet that *those* older compilers were almost certainly bought from someone else, but I don't know who) - but there was no real commercial interest for either of those languages from Microsoft's customers so, AFAIK, none of that ever happened.

The four people that I know were involved in the development of the Microsoft C compiler at the time were Ralph Ryan, Greg Whitten, Hans Spiller and Dave Weil and in some of the earlier versions of the compiler if you ran the binary for one of the intermediate passes of the compiler (p2 or p3, I think) by hand with the "-1234" flag it would print out their names.

resman
October 2nd, 2015, 03:38 PM
The four people that I know were involved in the development of the Microsoft C compiler at the time were Ralph Ryan, Greg Whitten, Hans Spiller and Dave Weil and in some of the earlier versions of the compiler if you ran the binary for one of the intermediate passes of the compiler (p2 or p3, I think) by hand with the "-1234" flag it would print out their names.

I went looking for these names in all the compiler passes, but didn't find them. However, I must have missed running 'strings' on p3 earlier, as it displays "Microsoft C Compiler version 3.00.17", built on August 30, 1985. Thanks for all the historical information, very interesting.

md95065
October 2nd, 2015, 04:26 PM
I went looking for these names in all the compiler passes, but didn't find them.

I really can't remember which version of compiler it was that had that "feature" - although I said that is was an "early" version it may actually have been an "early 386" version. I also have a feeling that the names were trivially encrypted and would not have shown up as plain text in the binary.

Scali
October 3rd, 2015, 03:09 AM
I had previously used Lattice C in around 1983 when it was one of the few x86 compilers available and I had access to all of the XENIX source code when I worked at SCO from 1987 onwards and never saw any indication that the Microsoft compiler was based on the Lattice compiler (but I had never seen the Lattice source code and it certainly is possible that is where the code originated).

Well, it's on the Wikipedia page: https://en.wikipedia.org/wiki/Lattice_C

The compiler was subsequently repackaged by Microsoft under a distribution agreement as Microsoft C version 2.0.[3] Microsoft developed their own C compiler that was released in April 1985 as Microsoft C Compiler 3.0.[4]

As far as I know, their C compiler was more of a fork of Lattice C than an actual rewrite (unless Microsoft tried REALLY hard to be completely compatible with Lattice C, including various quirks and compiler-specific features, which stuck with them until they did another rewrite for VS.NET).
So it seems that versions 1.x and 2.x are just rebranded Lattice C, and with version 3.x, Microsoft started doing actual development on the compiler.

md95065
October 3rd, 2015, 06:58 AM
Well, it's on the Wikipedia page: https://en.wikipedia.org/wiki/Lattice_C
As far as I know, their C compiler was more of a fork of Lattice C than an actual rewrite (unless Microsoft tried REALLY hard to be completely compatible with Lattice C, including various quirks and compiler-specific features, which stuck with them until they did another rewrite for VS.NET).
So it seems that versions 1.x and 2.x are just rebranded Lattice C, and with version 3.x, Microsoft started doing actual development on the compiler.

OK, that makes sense.

The compiler that we are talking about here, which is the only one that I had any direct knowledge of, is 3.x and, according to that Wikipedia article:

Microsoft developed their own C compiler that was released in April 1985 as Microsoft C Compiler 3.0.
Which is also consistent with my recollection that Microsoft were actively working on that compiler at the time.
My guess is that, by time I saw it most of it was either completely new or had been substantially rewritten.

resman
November 20th, 2015, 07:03 PM
A follow up to my original XENIX build involved changing the keyboard to the original Deskpro keyboard. I wasn't a real fan of the layout, but it did have the control key in the proper location, as opposed to the Enhanced keyboard that gave me carpal tunnel syndrome trying to reach for it. I was worried the keyboard construction was going to be similar to the Portable's design that used the foam pads (that all disintegrate over the past 30 years). Luckily the Deskpro's keyboard uses a rubber membrane, which doesn't give the best tactile feedback in the world, but didn't fall apart:
27928

The next addition was a second Seagate ST-225 20Mb drive for my home directory. Now, there is 20 Mb for XENIX & swap, and 20 Mb for my files. Oddly, when I went to do a low-level format on the drive I chose an interleave of 4 (the default is 6). I figured the 7+ Mhz V30 should be able to handle a tighter interleave. This was the value I used for the first drive - it gave me about 300K of bad sectors, but has worked well. The second drive gave a ton of read errors with an interleave of 4, At an interleave of 3, almost every block gave a read error. Going back to the default of 6, there were zero errors. So an interleave of 6 it is ( I would have expected the interleave to change the read rate, not affect the error rate). The second drive is above the first:
27929

Lastly, with 20Mb to fill up, doing the floppy shuffle just wasn't going to cut it. XENIX 86 doesn't have any network support, but it does have UUCP. I already had a serial connection between my OpenStep 4.2 machine which I could 'cu' into from XENIX 86. But, to get UUCP working between the two requires editing some configuration files to make all the pieces happy. XENIX 86 uses an incredibly ancient version of UUCP from Unix 5.0 (uucp v2), probably because it was small. Finding documentation for such an old version is a little difficult. The magic involves two files that live in /usr/lib/uucp; L-devices and L.sys. Here are my versions to directly connect the serial port.

L-devices:


DIR tty1a 0 9600


L.sys:


next Any tty1a 9600 tty1a ogin:-@-ogin: uucp


These are very minimal to directly connect to another machine, 'next' in my case (for NextStep). I can move a file from XENIX to OpenStep with a command like 'uucp myfile next!~/myfile'. Although the XENIX 86 configuration is pretty easy, the real hassle is in setting up the host machine. UUCP configuration has caused much gnashing of teeth and pulling of hair. That part is up to you. However, I can now transfer files back and forth between OpenStep and XENIX 86. It doesn't seem to want to recurse into directories, so a tar file is the easiest way to move all the files in a directory tree.

I think I've taken this setup as far as it will go. I think all my other machines are jealous.

Dave...