Everyone mentioned this yesterday…

275,000 transistors of awesomeness!

275,000 transistors of awesomeness!

Kind of interesting is that Linux has finally dropped support for the 80386 microprocessor.

The 386 is perhaps one of the top ten things that has changed our world, along with 4.3BSD .

No, really!

The 386 microprocessor was the first CPU by Intel that was single sourced.  This means that Intel, and only Intel would fabricate the 386 processor.  Before this time, Intel had licensed their processors to other companies (Siemens, AMD, Harris, IBM etc) So that if there was some kind of production issue at Intel other companies could manufacture 8086,80186s and 80286s.  However this all changed with the 386, as Intel stopped renewing these agreements with other companies (IBM had a license that included the 386, although they were slow in making their own), so now Intel was in charge of its destiny.

The 386 brought three major changes onto the then champion processor the 286.  The first being a 32bit processor where it could handle larger data sizes than the 16bit 286 & 8086.  The 386 also included a larger memory model, the so called “flat mode” where it could directly address 4GB of combined code+data, while the 286 could address 1GB it was limited to 64kb segments.  Lastly the 386 introduced hardware virtualization, the “v86” mode where the 386 could emulate multiple 8086 processors, allowing people to have multiple ‘virtual machines’ on the desktop.

At the time the only consumer grade 32bit processor was the hybrid 32/16 68000 from Motorola.  The 68000 could work with 32bit data, but it was restricted to a 16bit data bus, and only could address 24bits of RAM (16 megabytes).  The 68000 however did not include any kind of memory management unit (MMU) making things like porting UNIX improbable (The SUN-1 workstation included a custom MMU).  Because of the open nature of the IBM PC, clone manufacturers were able to leapfrog IBM, and release 386 based machines before IBM got around to releasing the PS/2 model 80.  It was this that effectively brought 32bit computing to the masses with the Compaq Deskpro.

Compaq's 386 Deskpro

Compaq’s 386 Deskpro

The 8086 processor could address 1MB of RAM, with its 20bit address bus.  However to preserve some compatibility with the 8080 processor it was decided that the 8086 (and 8088) CPUs would work with 64kb segments.  This became a massive headache for years as you could not easily contain more than 64kb of data at a time as you would exceed a segment.  Compiler vendors made some workarounds via the large & huge memory models, but porting a program from a 32bit minicomputer (VAX) would prove difficult if it addressed large amounts of memory, and would require a rewrite.  The 286 increased the addressable memory to 16MB, and included a limited MMU, which enabled an address space of 1GB.  However the 286 was flawed in that again the 286 could only work in 64kb segments, and in order to work with large amounts of memory, the processor had to be shifted to protected mode.  However in protected mode, you couldn’t (easily) switch back to real mode.  This needlessly delayed the adoption of protected mode environments, as you would then lose access to the sizable, and growing, library of MS-DOS programs.  Although workarounds were in place for things like OS/2 and DOS Extenders, they were hacks and couldn’t fix the fundamental 64kb issue.  The 386 built upon the 286’s foundation and included a flat memory model where it could address all 4GB of addressable memory in a single segment.  This meant that you could now use massive amounts of data on a consumer grade machine.

For a while the only 32bit environments were Xenix and MS-DOS via DOS Extenders this proved to be a huge liability and effectively stagnated the industry for a long while.  The 286 was a massive determent.  Making things worse was IBMs insistence that the new OS/2 be able to run on the 286, while Microsoft wanted to create OS/2 to run on the 386, and ignore the IBM AT all together. Basically the 286 was created with the assumption that the 8086 wouldn’t be anywhere near as popular as it was.

With the ability to address large amounts of RAM programs only seen on minicomputers and mainframes were finding their way to the microcomputer such as AutoCAD, Oracle, Links 386 Pro, and of course many in house programs where departments now wouldn’t have to pay to run on then ‘big’ minicomputers.  Combined with the 386’s MMU it was also possible to use more memory than was available in the computer, also known as virtual memory.  The 386 made this transparent to the program, only the 32bit environment needed to handle the swapping.

Finally the last big feature of the 386 was v86 mode.  V86 mode in short is a hardware virtualization platform where the 386 can emulate multiple 8086 processors in hardware.  Each virtual machine can get its own isolated memory space, virtual hardware.  Effectively 8086 programs (such as MS-DOS) can run unaltered inside of v86 mode, with the added benefit of being able to run more than one at a time. Windows/386 lead the charge into this new world of virtual machines for the end user.  Before this point, the only wide scale virtual machine environment was the IBM 370 mainframe which could also create virtual mainframes within itself allowing groups to share a single mainframe, but run incompatible software platforms all at the same time.

Thanks to its capabilities the 386 also brought UNIX to the end user.  First with Xenix, then Microport SYSV, and with the removal of AT&T code BSD was able to be released on the 386 via 386 BSD (and later BSDi’s BSD/OS).  During this timeframe the research OS, Minix was extended by Bruce Evans to be able to use some of the 386’s features which then gave rise to Linux.

Thanks to cheap commodity based 32bit computers, and the GNU projects development tools (binutils, gcc, bash) people could then finally realize GNU’s dream of bringing a free and open UNIX like operating system to the masses.

Needless to say, a lot has changed since 1991, and Linux now moving beyond the 386 processor is no surprise.  The rapid adoption of 64bit computing via AMDs extensions, and the new forthcoming 64bit ARM processors do signal the eventuality that one day Linux will even drop support for 32bit processors… Although I wouldn’t expect that for another 20 years.  Even Intel has ceased manufacturing the 386 processor in 2007.

So it is now time to say good bye to the 386 processor.  At the same time thanks to full software emulation, you will never truly be dead. And as always you can check out Linux’s early versions.

Dell UNIX Lives Again!

(please note that this is a guest post from Antoni Sawicki)

Dell UNIX is so ultra rare among rare Unix species that it doesn’t even have a Wikipedia entry. I have been hunting this elusive but important piece of computer history for well over 15 years now. Fortunately thanks to Charles H. Sauer and his excellent blog post I was finally able to lay my hands on disk and tape images and the restoration process begun.

The install tape

The system can be installed from either a tape or network server (presumably NFS). Unfortunately no virtualization software can emulate a tape drive. Hopes for a network install are even slimmer since the required network support floppy disk has been lost and chances of suitable Ethernet driver working in Bochs or Qemu are equal to that of finding the lost floppy disk.

I have decided to try a hard disk image from a readily pre-installed system. The original Dell 486 workstation had a 1GB SCSI hard disk. Unfortunately neither Dell UNIX supports LBA mode nor Qemu/Bochs support the Adaptec 154x controller required by the OS.

As all normal install options have been exhausted, the only option left was to use a second hard disk image as source of cpio archive files. Booting from the two install floppies and attaching two disk images was a snap. The next step was to inject the tape “file” in to a right place on the disk, so it can be read by cpio command. A hard disk in Dell UNIX is pretty much unusable without a valid SysV partition and VTOC. Fortunately dellsetup command does it all for you. Once VTOC was put in place I’ve attached the transfer disk image as a loopback device in my host OS. In couple of iterations I was able to aim the host os dd if=file1 of=/dev/loop0 bs=512 seek=offset at the right place, which you work out using prtvtoc /dev/rdsk/1s0 command. Then cpio -ict < /dev/dsk/1s1 was able to list contents of the emulated tape… with errors…

In my infinite wisdom, for some unknown reason I’ve assumed that LBA addressing is required above 540MB. So to be on a safe side I have made the hard disk images 512 MB. What a mistake it was! I have lost several hours trying to figure out cpio header errors coming from the disk… By pure coincidence, while the tape archive was installing (with errors) I was researching for this very blog article and found that LBA starts at 504 MB… Recreating the hard disk images just few MB smaller took all tape and prior boot problems away!

Once the cpio archive was extracted I have made few final touches taken from the original tape install script. After a reboot Dell UNIX booted perfectly. You can experience this by using the firstboot image file. The final part of installation was injecting the second tape file containing System V PKG file to the transfer disk image and running pkgadd -d /dev/dsk/1s1. This is what’s included on allsoft.img.

Dell Unix at First Boot

Some final notes on running the OS:

  • To enable mouse to work:
    • Qemu just add “-chardev msmouse,id=msmouse -device isa-serial,chardev=msmouse” to the launch arguments.
    • Bochs add to the config file:
      mouse: type=serial, enabled=1      
      com1: enabled=1, mode=mouse
      then you have to kill mousemgr process and prevent from starting by deleting /etc/rc2.d/S25mse
      then edit /usr/lib/X11/Xconfig:
      disable Xqueue      
      enable Microsoft Mouse
  • To enable keyboard to work correctly in VirtualBOX start with Num Lock OFF.
  • You can use qemu-img utility to convert the image to VMware vmdk to use in VirtualBox.
  • To run X window type startx

X11 and all its glory

  • To attach it to internet use SLIP as there is no working Ethernet driver.  Contrary to most UNIXen of the time, the command is not slattach, but rather slipattach.  Thankfully it does work the same way.  I have found that running Dell Unix with VirtualBOX, along with Windows NT 4.0 I was able to connect into the Dell Unix VM, and get network access.  Just set the two VM’s up for a named pipe (\\.\pipe\dellunix) and make one of them a server, and start that VM 1st.  The steps to prepare Windows NT have been outlined before.

Telnet via SLIP

Legal disclaimer: Dell UNIX is a commercial software and should not be distributed without manufacturers permission. However as the operating system has been dead for 20 years and with a long tradition from Unix Heritage Society and Bitsavers I’m publishing this in good faith under abandonware category. If Dell or any other copyright holder wishes this software removed, please let me know.

Attached are:

  • firstboot image
  • all (pkg) software installed
  • setup instructions if you wish to install from scratch.


You may also be interested in my post about a sister System V operating system – Interactive UNIX:

BBS’ing with Windows/386 & Windows 3.0 under Qemu or how I learned to love rlfossil

A while back I had seen this fantastic site, “Hates the internet” with a great write up on setting up a BBS on Qemu.  In retrospect it did inspire me a bit later to get my BBS going with Qemu, but I chose to use OS/2 once I found out about SIO’s vmodem feature.

HTI (Hates the internet) chose this program called rlfossil, which is for MS-DOS..

RLFOSSIL is an implementation of multi-line serial port driver corresponding to the Fido/Opus/Seadog level 5 specification and a simple HAYES-compatible modem emulator. It allows applications usually worked through BBS’s to run on the Internet, or in IP-based local net.er, and rlogin and telnet emulation using IP services numbers 513 & 23. RLFOSSIL allows combined work with other FOSSIL drivers (X00,BNU etc.).

So I thought between that, and all the Windows/386 excitement I’d try for something even more insane.  How about running a multiline BBS on Windows?

So in the same effort, I was going to use Qemu 0.14.1, with MS-DOS 4.01 (the first version I could find that came with share.exe), and Windows/386 2.11.  The installation of MS-DOS 4.01 worked fine on an 80MB disk image, thankfully it was one of the things that DOS 4 could do better then 3 is large disk images… Yes I know 3.31 could as well, but it didn’t come with share so it was out.  One strange thing after install was this message…

It is kind of forboding that DOS is warning me that because of my “large” disk I better run share.  Since I plan on having a multi node BBS all in one computer, I need to run share anyways.


The next exciting part was installing Windows/386 2.11.  The installation went pretty smooth, and with Qemu the mouse worked fine.  So far, so good.  I couldn’t use himem.sys that comes with Windows/386, nor could I use the himem.sys that comes with MS-DOS as the Windows/386 version complains that that A20 line is already active (?) and the MS-DOS one has Windows complaining that the HMA is already in use.  Sadly then my conventional memory footprint will be unsatisfactory, but I don’t see any way around it.

The next part is configuring rlfossil.  rlfossil needs a driver to talk to the network card, and you can find them on crynwr, namely the ‘other‘ packet archive, which contains NE2000 drivers.  Keeping with HTI, I’m going to use the NE2000 and configure Qemu with the PCI NE2000 driver.

Packet drivers are loaded from the command line something like this:

ne2000 0x60 11 0xc100

This loads the driver on software interrupt 0x60, and by default the PCI NE2000 is configured for IRQ 11, port 0xc100.  Qemu 1.6.0 changed the PCI NE2000 to use port 0xc000 for what it is worth..

So keeping with the HTI tradition, I’m going to put my packet driver (ne2000.com) and unpack the rlfossil archive in c:\packet.  The next thing to do is configure rlfossile which uses the wattcp configuration file.  Since I’m going to use the usermode NAT and a redirect, I configure my VM like this:




With that all in place now it’s time to configure the config.sys/autoexec.bat.  Some things are going to be different from a normal install because we plan to run a BBS, and multiple instances of it!

So my config.sys looks like:


And my autoexec.bat is like this:

NE2000 0x60 11 0xC100

And of course launching Qemu I do it like this:

qemu.exe -L pc-bios -m 16 -net nic,model=ne2k_pci -net user-redir tcp:23::23 -hda telegard.qcow2

This configures the VM for 16MB of ram (which would have cost a FORTUNE back then), the PCI NE2000, and it’ll redirect telnet from my host machine into the VM.

And just like HTI, I went with telegard, because it supports fossil based ports.

Well that sure was a *LOT* of work, and surprisingly testing it with a single node, actually works.  And you can bring up a few other MS-DOS prompts and it’ll work fine. But if you launch the second node…

Disaster struck.  So needless to say, while Windows/386 was pretty slick for the day it just couldn’t measure up.  So I figured for the hell of it, I’d try Windows 3.0  I mean I would have imagined that Windows 3.0 most certainly could NOT handle this kind of challenge.

So with some disks shuffled, I fired it up and..

Two node telegard under Windows 3.0

It actually worked!  So with a LOT of chaos going on I managed to get Trade Wars 2002 running, although I couldn’t figure out how to automatically figure out the node.. Hell the whole door configuration thing is.. bizarre. Synchronet really kicks ass in regards to easy of configuration.

Running TW2002, two copies

And using PIF’s to configure each node for some easy of launching, and some reduced memory, I could easily run all four nodes that rlfossil can support.

Four Nodes!

I have to admit, Windows 3.0 really is impressive considering all the UAE’s and how generally crappy we thought it was at the time.  I’m sure even emulated having a multiple Ghz cpu helps quite a bit.

460KB free!

And look at all that memory.. I guess it’s pretty impressive it even works.  Since Windows anything throttles the CPU at 100% I’m not going to put this online…. Although at the same time combined with an CPU idle program (is there a Windows 3.0 idle vxd?) it sits ok, but who wants a single user system in 2011?



So I picked up this old 386 multitasker on amazon called.. VM/386. I remember seeing ads on how awesome it was back in the day.

VM/386 diskettes

VM/386 diskettes


VM/386 1.2 splash screen

VM/386 1.2 splash screen

So much to my luck, I not only got 1.2 but 1.22! Even luckier all the disks read! However what ever magic they employed doesn’t work under any emulation … 😐

Sure it’ll load up, and let you do some options.. But this is all I get.

VM/386 in action

VM/386 in action

I’ve tried it on various Qemu levels, I’ve even used a real cirrus logic video ROM (from an ISA board, I’ll have to find a PCI cirrus logic ROM…) VMware, Virtual PC, and Virtual BOX.

Has anyone ever used this thing? I was under the impression it was multiuser as well as multitasking but it seems from what little I’ve been able to use that it’s only multi tasking…

Oh well I guess another sem-interesting update in MS-DOS multi-taskers.

— edit

And… I just got word of a copy of 2.0 and it’s being shipped.. 5 user version too!

Notes on fat binaries & OS X

I suppose this also applied to NeXTSTEP/OPENSTEP but I didn’t cross build that much between the m68k and i386…

So let’s start with a 3 way compile…

$ gcc -arch i386 -arch x86_64 -arch ppc7400 dhrystone.c -o dhrystone
$ file dhrystone
dhrystone: Mach-O universal binary with 3 architectures
dhrystone (for architecture i386): Mach-O executable i386
dhrystone (for architecture x86_64): Mach-O 64-bit executable x86_64
dhrystone (for architecture ppc7400): Mach-O executable ppc

This builds the single file for all 3 machine types of OS X..

For anyone that cares, this is my quad core box..

$ ./dhrystone
Dhrystone(1.1) time for 500000000 passes = 83
This machine benchmarks at 6024096 dhrystones/second

Ok, now let’s pull out the PowerPC executable, and run that….

$ lipo -extract ppc7400 dhrystone -output dpc
$ file dpc
dpc: Mach-O universal binary with 1 architecture
dpc (for architecture ppc7400): Mach-O executable ppc
$ ./dpc
Dhrystone(1.1) time for 500000000 passes = 214
This machine benchmarks at 2336448 dhrystones/second

Which isn’t too bad, seeing the emulator runs at 1/3rd speed of the native exe.. It’s no wonder that IBM bought transitive, and shut them down. This kind of technology would make it far too easy for everyone to move away from expensive CPUs…!

Now let’s extract the 32bit i386 exe.

$ lipo -extract i386 dhrystone -output di3

Nothing to really see here.

And for the final part, let’s combine the extracted PPC & i386 executables.

$ lipo di3 dpc -create -output dip
$ file dip
dip: Mach-O universal binary with 2 architectures
dip (for architecture i386): Mach-O executable i386
dip (for architecture ppc7400): Mach-O executable ppc

And there we have it.. Using this I guess I can try to find versions of Qemu that will hopefully cross build on my machine that I can stitch together so that some platforms (PPC) have *SOMETHING* to run at least…..

Or maybe it’ll help someone at least make a stub ‘we are sorry, nothing to see here’ vs an exe error.


(please note that this is a guest post from Tenox)


I’ve been hunting for a complete INTERACTIVE UNIX System for past 12 years or so. While I had the basic set of it for a good bit of time, no one seem to have have the real stuff – Looking Glass graphical environment. In November I got my hands on a box containing a massive set of 50 5.25″ floppy disks. There is the first time you can look on the GUI:

Through the looking glass..

The fun really begins with this page:
As of 2010 it has an Oracle logo and tells about an operating system by Sun Microsystems (now Oracle) for which support ended just 4 years earlier. In reality the OS was rather little known to the general population.


First introduced by Kodak in 1985 was mostly used for specialized applications. Later Sun bought it to help porting Solaris to x86 platform. Enough of history.

Version 3.0 presented here unfortunately only works on Bochs 2.4.2. There are some issues with the IDE/ATA controller that make it boot up only every second time while clicking on reset button. Version 4.x has issues partitioning disks under VMware but I’m sure this can be worked around.

The installation is straight forward once you have correct settings for the emulator (bochsrc.bxrc included). With this blog post included is a fully working, ready installed system, just double click run.bat. If it hangs, click on the Reset button. The root password is root. To shutdown the system cleanly type “init 0”, but this must be done from the text mode console.

I’ve spent a bit of time trying to bring it to a higher resolution but so far I only managed 800×600. You have a number of graphics drivers available under the “xconfig” program. One of the most curious features of Looking Glass are the icons. Some of them ROTFLMAO.


The next task will be to install and configure networking. But this is for another post.


Unfortunately the floppy disk is all but unreadable.

Making bootable ISO images

I know for most people using mkisofs is second nature, but I needed to get a machine running MS-DOS without floppies… and it had to be on the bare metal.. Oh joy.

Now I’ve kind of done this before but I’ve never gotten it to preserve the directory structure.  It seems that it’s important to specify some output…

The ‘fun’ thing is that I was able to use virtual pc to build the boot diskette with IDE cdrom drivers, and make sure it works in that it mounted the CD and set the path there…

So I have extracted my MS-DOS install from the floppies into a directory on my pc and I keep the file dos622_1.img in the same directory so mkisofs can place it in the image.  Then it’s just a matter of running:

..\mkisofs.exe -o ..\x.iso -J -r -v -V test_disk -b dos622_1.img .

And I get an x.iso that can boot MS-DOS, and has all the dos commands in place, I can partition & format the hard disk and copy DOS into place.

It’s not much to see, but if you need legacy stuff it’ll be a life saver.. and I know I’ll end up losing the flags and needing them again!

Qemu 0.90 patched for NeXTSTEP 3.3 i386

Patches for Qemu 0.90 are available here:
http://www.vaxenrule.com/Shared%20Documents/patchesforNeXTSTEP-on-Qemu-0.9.diff The busmouse patch still survives here.
The win32 exe is here.

A PowerPC macosx 10.4 binary is available here:

This moves the soundblaster to IRQ 7, and incorporates a bus fix & busmouse additon. Remember to remove the parallel port for this to work correctly. Tested with NeXTSTEP 3.3

Why all the patches, you may ask? Well for some reason NeXTSTEP is unable to correctly drive the mouse in Qemu. Nobody has tracked it down, but I suspect it’s some wierd issue with the BUS… Anyways I found this busmouse patch ages ago, and I’ve just been finagaling it for ages so that it will keep on working. I know that there are a hand full of enthusists left, but I figure that for all interested they would appreciate this.

Running Xenix on qemu

Neither Bochs nor Qemu can boot the Xenix floppy diskettes all the way. Virtual PC & VMWare seemed to have no luck when the kernel transitions to protected mode. While on the way to work I had an idea. What if you had an old hard disk and a machine capapble of installing? Simply imaging the hard disk may be enough, since after that point you don’t need any floppy disks!

So this is what I have to show for the work today:

Freaking awesome, if I do say so myself.

OK, now how to do it? First you need an existing system running Xenix. If you have any plans on migrating an existing installation take note! This will preserve your install, just don’t format! On the Xenix boot screen take note of the geometry of the disk. We will need the geometry for later. Although I did a test boot without it, its a good thing to preserve it.

For virgin users, you will need a small disk to install on. I had a 2.5 GB disk that was too big, and 132MB disk that worked fine. I used a dell pc with 2 ide controllers for this. The longest task honestly was installing Xenix. I think that ran about 20 minutes. Once I was done, shutdown xenix, and put the disk in a machine running Windows (Linux fans can put it in their box, and just dd the Xenix disk into an image). Us poor Windows users don’t have dd. Anyways take not of what disk # it is, as Windows of course will not assign it a drive letter since it does not understand Xenix’s filesystem.

As you can see it’s disk #2 in this computer. Ok now we need to read the disk and write it into a disk image. I couldn’t find a util offhand to do it, so I wrote one real quick. Here is the source code, you’ll need a C compiler on your PC to compile it. I guess I could ‘neaten it up’ some, but for now here you go:

Source code


Yes I know its horrible, and blogger does a wonderfull job of formatting my program. Anyways compile it & run it. Now you’ll have a disk image of your hard disk!

Now for the fun part, running Xenix! We simply specifiy the hard disk geometry that we got earlier, and pass it the disk image that we created! I’m using an Quantum Pro drive ELS with the following geometry:

919 Cylinders
16 heads
17 bytes/sector

That translates into the following command:

qemu -M isapc -m 16 -hda xenix386-2.3.4.disk -hdachs 919,16,17 -L .


Let the good times roll!

–Update from 2011!

It is *NOW* possible to install Xenix in Qemu 0.14.0. You can read more about it here.