• Please review our updated Terms and Rules here

My latest Xenix build

md95065 said:
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.
Click to expand...

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...
 
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.
 
md95065 said:
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.
Click to expand...

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:
Code: 
	.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
 
Last edited:
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.
 
md95065 said:
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.
Click to expand...

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...
 
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.
 
md95065 said:
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.
Click to expand...

Indeed, thanks for all your help.

Dave...
 
Nice work!
resman said:
First, the 8086 version of Xenix is missing the simple, but useful 'clear' command.
Click to expand...

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.
 
tingo said:
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.
Click to expand...

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 said:
The 'mov sp, bp' instructions are not needed since the functions are not using any local variables. Remove them to save 8 bytes. :)
Click to expand...

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


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
 

Attachments

  • IMG_20150916_214355.jpg
    IMG_20150916_214355.jpg
    41.9 KB · Views: 6
Last edited:
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...
 
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.
 
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.
 
resman said:
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.
Click to expand...

And INCREDIBLY expensive ...LOL
 
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):

Deskpro Selfie.jpg

Dave...
 
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.
 
Klee said:
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.
Click to expand...

Have you tried a LL format? That might get it going again. Xenix will do a bad track scan before the install.
 
You must log in or register to reply here.
Back
Top