86Box PS/2 model 60 emulation

As a quick aside, on my exploring early OS/2 betas I thought I’d try to emulate the machine that I’d clearly lay the blame as to why OS/2 was fundamentally a failure, the IBM PS/2 model 60.

So IBM machines don’t use built in ROM config programs, but rather you need the reference disk. And this being a Microchannel PS/2 machine you also need the config files to support things like more than 2MB of RAM, the ESDI controller, or even an AdLib/SoundBlaster card.

updated reference disk

Adding in the RAM card, and a sound blaster adds the following cards:

However it’s worth noting that the default ESDI config/driver on the MCA confg disk won’t work on 86box. You will need an updated version.

So inside the diag disk the config will appear like this:

I’ve uploaded the reference disk on archive.org here: 86box PS/2 Model 60 Reference Disk : IBM : Free Download, Borrow, and Streaming : Internet Archive.

Unfortunately, at this moment 86Box’s PS/2 model 60 can’t run OS/2. The model 80 however has much better luck. But for anyone who want’s to play Wolf3D on an emulated 10Mhz 286, well this is your big chance.

PowerPC Solaris on the RS/6000

The following is a guest post by PA8600/PA-RISC! Thanks for doing this incredible writeup about an ultra rare Unix!

One of the weirdest times in computing was during the mid-90s, when the major RISC
vendors all had their own plans to dominate the consumer market and eventually wipe out
Intel. This was a time that led to overpriced non-x86 systems that intended to wipe out the
PC, Windows NT being ported to non-x86 platforms, PC style hardware paired with RISC
CPUs, Apple putting the processor line from IBM servers into Macs, and Silicon Graphics
designing a game console for Nintendo. While their attempts worked wonders in the
embedded field for MIPS and the AIM alliance, quite a few of these attempts at breaking into
the mainstream were total flops.

Despite this, there were some weird products released during this period that most only assumed existed in tech magazine ads and reviews. One such product was Solaris for PowerPC. Now Solaris has existed on Intel platforms for ages and the Illumos fork has some interesting ports including a DEC Alpha port, but a forgotten official port exists for the PowerPC CPU architecture. Unlike OS/2, it’s complete and has a networking stack. It’s also perhaps one of the weirdest OSes on the PowerPC platform.

  • It’s a little-endian 32-bit PowerPC Unix and possibly the only one running in 32 bit mode. Windows NT and OS/2 (IIRC) were the other 32-bit PowerPC little-endian OSes and Linux is a 64 bit little endian OS.
  • It’s a limited access release, yet feels as polished as a released product.
  • It has a working networking stack.
  • Unlike AIX, it was designed to run on a variety of hardware with room to expand if more PPC hardware was sold. You can throw in a random 3com ISA NIC for example and it will in fact work with it.
  • It shares several things with Solaris for Intel including the installer.

I’m going to demonstrate perhaps the weirdest complete PowerPC OS on fitting hardware: the IBM RS/6000 7020 40p, also known as the Power Series 440 (6015) and by its codename “Sandalfoot”. The system is a PowerPC 601 based machine, featuring the PCI and ISA buses in an LPX style case. This is also one of the few machines that can run it. All screen captures are from a VGA2USB card as emulators cannot run anything but AIX.

What you need to run Solaris PPC

To run Solaris, the system requirements are just like that of Windows NT for PowerPC. You need a PReP machine (PowerPC Reference Platform, not to be confused with the HIV prevention pill or PrEP according to Wikipedia). Now finding a PReP machine is perhaps the hardest part of setting up Solaris for PowerPC and to understand why you need to know a bit about the history of the PowerPC platform.

One of the biggest problems with PowerPC hardware to this day has been the sheer inconsistency of how each machine boots. While Alpha machines had SRM/ARC and SPARC machines had OpenBoot, each vendor had their own way of booting a PowerPC machine despite rolling out standards.

There were essentially two different camps building PowerPC machines, IBM and Apple. IBM’s plans for universal PowerPC machines consisted of industry standard, low cost machines built around a PowerPC CPU, chipset, and lots of supporting components lifted from the PC platform along with PCI and ISA. The CHRP and PReP standards were essentially PCs with PowerPC processors in them. IBM’s plan was that you were going to replace your PC with a PowerPC machine someday. This was cemented by the fact that Windows NT was ported to the PowerPC platform, that OS/2 had an ill-fated port, and that a handful of third party Windows NT PPC machines were sold.

Apple on the other hand wanted to build Macs with PowerPC CPUs. Older Power Macs featured no PCI slots or Open Firmware, only NuBus slots carried over from classic 68k Macs. In fact much of the boot and OS code was emulated 68k code. Later on Apple would lift bits and pieces of things they enjoyed from the PowerPC standards such as Open Firmware, PCI, and even PS/2 and VGA ports on the clones. Apple’s plan was to replace the PC with the Mac, and Mac clones featured Apple style hardware on LPX motherboards. While the PCI clones featured Open Firmware, this version was designed to load the Macintosh Toolbox from ROM while “futureproofing” them by adding in the ability to boot something like Mac OS X/Rhapsody or BeOS.

Despite these similarities Macs were their own computers and were nothing like the IBM systems internally, aside from sharing the same CPU and maybe Open Firmware later on. But even Macs with Open Firmware were incapable of booting from hard disks formatted for IBM systems and vice versa. This is a common problem with installing PowerPC Linux as many installers do not check which machine they’re run on. Furthermore unlike modern day Intel Macs, PPC Macs were designed to only boot operating systems specifically written for them. They were incapable of running any OS solely written for the IBM machines.

The confusion between PPC machines has also caused a forum question to pop up, “how can I install PowerPC Windows on my Mac?” Even today the new OpenPower/PowerNV machines use a different bootloader than IBM’s hardware and completely lack Open Firmware.

Anyhow IBM built several different generations of PowerPC UNIX machines under several brand names including RS/6000, pSeries, and Power. Nearly all of them (aside from the Linux models) will run AIX, and later ones will run IBM i as well. Not just any PowerPC IBM hardware will run the OSes designed for PReP hardware however.

To run these old PReP OSes you’re looking at a very specific set of machines from the 1994-95 period, many with no characteristic diagnostic display most RS/6000 machines have. To run PowerPC Solaris much of the same applies here. You need a RS/6000 40p, or 7248 43p (not the later 140 and 150 with the display). The rare PPC Thinkpads and Personal Computer Power Series machines will run Solaris as well. It’s also compatible with the PowerStack machines from Motorola and one BetaArchive user had luck running it on a VME board. These machines are hard to find and unemulated as of writing, though the firmware files exist for the 40p at least and some efforts have been made in QEMU.

Mine features a PowerPC 601 CPU, 192mb of RAM (the max), a Weitek P9100 video card (branded as the IBM S15 IIRC), and a non-IBM 3com NIC. The 3com NIC has issues with the system as during boot if the NIC is connected to the network the system will refuse to boot fully and will either freeze or BSOD (in NT). The NIC is also not supported on AIX as well, and will eventually need to be replaced.

Curiously, not only is the IBM 40p/7020/6015 not listed in the HCL but the NIC it uses is. It’s well known that the Sandalfoot systems were used for early PReP OS development and it makes sense. Unlike the RS/6000 model 250, the 40p features PCI and ISA busses along with the same 601 CPU early PowerPC machines had. 

Installation

To install PowerPC Solaris, you first need to make a boot floppy. This isn’t uncommon with PReP operating systems. PowerPC Windows NT also requires a boot floppy for the ARC loader. The difference here is that there are two boot floppies; one for Motorola machines and one for IBM machines. Even on PowerPC this wasn’t terribly unusual, both the Moto Powerstack and Apple Network Server computers required custom AIX install media as well and Windows NT had specific HALs for each PPC machine.

On the Motorola PowerStack machines you need the same firmware used to install AIX instead of the ARC firmware for NT. On the IBM machines it’s vastly easier, you just need to make the floppy and shove it in. You then press the power switch and you’ll end up dumped to an Open Firmware prompt. As these IBM machines did not have Open Firmware, the bootloader loads Open Firmware from the floppy or hard disk every time you boot the machine. Keep in mind even the system management services are floppy loaded on these machines.

You then run into the first big hurdle to installing the OS, “disk” and “net” are mapped to very specific devices and if the SCSI IDs of these are different it will not boot. If the CD drive is not at ID 3 and the HDD is not at ID 6 the commands will not work. You will need to set an environment variable and tell it to boot from these disks manually for the first install.

Booting the OS is similar to booting it on a Sun, but the installer resembles that of the Intel version. The first thing that happens is you wait for the slow 2 speed CD drive to load the OS as the screen turns Open Firmware white. You will need to set the terminal type, and then then video and mouse input before X will load. The video options are limited to the S3 864/928, the Weitek P9000 and P9100, and Moto’s Cirrus Logic GD5434. Notice how the Power Series 440 (6015)/RS6k 7020 40p is referred to by its codename “Sandalfoot”.

Once you enter this in Solaris will boot load X it does on a Sun or Intel box, and the installer will be exactly the same. This phase is very uneventful as the slow CD drive copies files to the hard disk. I didn’t take a lot of screenshots of this part because you can get the same experience with QEMU or an old SPARCStation. You set the network info, you partition the HDD, you choose what you want, and you sit back as it installs.

Then you’ll be dropped at the Open Firmware bootloader and you’ll enter the right commands to make it boot if “boot disk” doesn’t automatically boot the OS.

The installation is not complete however. The next step is to swap CDs and install the GUI. A default install will drop you at a command line, with the second disk you can install OpenWindows and CDE and get a full working desktop. Login, switch CDs, change to the correct directory, and run the installer.

Once this is done, simply type in reboot and once you login you’ll be at a desktop that looks exactly like a Solaris 2.5.1 install on any other platform with one difference. There is literally zero third party software, and for years there was literally zero way of making software for it. You’re stuck with a stock OS and whatever utilities Solaris 2.5.1 came with. You’ll want to use OpenWindows as well, CDE is vastly slower on the 601 CPU (but not as slow as AIX 4.3 for example). The platform directory also tells you what IBM machines it can run on, and all the RS/6000s are titled PPS. The 6015 is the 40p, the 6040 and 6042 are the ThinkPad models 830 and 850, the 6050/70 are the Personal Computer Power Series variants of the 7248 43p, and the PowerStacks are pretty self-explanatory.

The Compiler Problem (and solutions)

For the longest time Solaris for PowerPC was neglected among those who happened to own a PReP machine for one reason: it lacked a compiler. A compiler is perhaps the most important part of any operating system as it allows one to write code for it. As was the case with UNIX operating systems from the time, the compiler was sold separately. With any UNIX that was widely distributed this wasn’t too much of an issue, as GCC or other third party compilers existed for the platform. Furthermore most compilers for these commercial UNIX operating systems ended up dumped online.

Solaris for PowerPC lacked both of these for ages due to the obscurity and rarity of the port. But in 2018 Tenox dug up the official compiler, yet this remained unnoticed for a while. This led to someone else experimenting with cross compilation on Solaris, and managing to compile PowerPC Solaris software. They then released a port of GCC for Solaris 2.5.1 for PowerPC while posting instructions on how to compile it.

To use GCC for Solaris, you need to unzip the compiler, add it to the path, and then symlink a few files that GCC ends up looking for. This is discussed in the BetaArchive thread about this, but I’ll quote it here.

$ ls -l /opt/ppc-gcc/lib/gcc-lib/powerpcle-sun-solaris2/2.95/
total 13224
-rwxr-xr-x   1 bin      bin      5157747 Feb 16 10:30 cc1
-rwxr-xr-x   1 bin      bin       404074 Feb 16 10:30 collect2
-rwxr-xr-x   1 bin      bin       453525 Feb 16 10:30 cpp
-rw-r--r--   1 bin      bin         1932 Feb 16 10:30 ecrti.o
-rw-r--r--   1 bin      bin         1749 Feb 16 10:30 ecrtn.o
drwxr-xr-x   3 bin      bin         1024 Feb 16 10:29 include
-rw-r--r--   1 bin      bin       673012 Feb 16 10:30 libgcc.a
drwxr-xr-x   2 bin      bin          512 Feb 16 10:30 nof
-rw-r--r--   1 bin      bin         4212 Feb 16 10:30 scrt0.o
-rw-r--r--   1 bin      bin         1360 Feb 16 10:30 scrti.o
-rw-r--r--   1 bin      bin         1104 Feb 16 10:30 scrtn.o
-rw-r--r--   1 bin      bin         7868 Feb 16 10:30 specs
lrwxrwxrwx   1 root     other         24 Feb 22 21:35 values-Xa.o -> /usr/ccs/lib/values-Xa.o
lrwxrwxrwx   1 root     other         24 Feb 22 21:36 values-Xc.o -> /usr/ccs/lib/values-Xc.o
lrwxrwxrwx   1 root     other         24 Feb 22 21:36 values-Xs.o -> /usr/ccs/lib/values-Xs.o
lrwxrwxrwx   1 root     other         24 Feb 22 21:36 values-Xt.o -> /usr/ccs/lib/values-Xt.o
lrwxrwxrwx   1 root     other         26 Feb 22 21:37 values-xpg4.o -> /usr/ccs/lib/values-xpg4.o
$

Once you do this, you can now compile C code at least with GCC. This means that Solaris for the PowerPC platform now is a usable operating system, aside from the fact it has no precompiled software whatsoever. Even Windows NT for PowerPC has more software for it. Software can now be compiled using GCC or the original compiler, and cross compiled with GCC on a non-PPC box. Using the cross compiler lets you compile more basics for compiling PPC Solaris code as well such as make. In this screenshot you can also see me compiling a basic “endian test” code example to demonstrate the little endianness of the PowerPC port.

The only problem is that there’s going to be little interest until someone makes a PReP machine emulator. PReP hardware is very hard to come by on the used market these days and while in the early 2000s it might have been easy to find something like a specific RS6k, but judging by the eBay listings there were a lot more MCA, CHRP, and even later PReP models (like the 43p-140) than there are early PReP machines in circulation. QEMU can emulate the 40p somewhat, but right now its 40p emulation is less like an actual 40p and more like something to please AIX. It definitely has the novelty of being a “little-endian PowerPC Unix” however.

Installing AIX on Qemu!

YES it’s real!

I’m using the Linux subystem on Windows, as it’s easier to build this Qemu tree from source. I’m using Debian, but these steps will work on other systems that use Debian as a base.

First thing first, you need to get your system with the needed pre-requisites to compile:

apt-get update;apt-get upgrade apt-get install build-essential pkg-config libz-dev libglib2.0-dev libpixman-1-dev libfdt-dev

Great with those in place, now clone Artyom Tarasenko’s source repository

git clone --branch 40p-20190406-aix-boots --single-branch https://github.com/artyom-tarasenko/qemu.git

*NOTE from the future (2022) you may want to jump here: to check out building on newer systems. Also don’t forget about networking!

Since the frame buffer apparently isn’t quite working just yet, I configure for something more like a text mode build.

././configure --target-list=ppc-softmmu --disable-sdl --disable-vnc --disable-gtk --disable-gnutls --disable-nettle --disable-gcrypt --disable-spice --disable-numa --disable-libxml2 --disable-werror

Now for me, GCC 7 didn’t build the source cleanly. I had to make a change to the file config-host.mak and remove all references to -Werror. Also I removed the sound hooks, as we won’t need them. remove the following lines:

CONFIG_AUDIO_DRIVERS=oss CONFIG_AUDIO_OSS=m

Now you can build Qemu. it’ll happily build in parallel so feel free to build using the -j parameter with how many cores you have. I have 32, so I use

make -j32

Okay, all being well you now have a Qemu. Now following the steps from
Artyom Tarasenko’s blog post, we can get started on the install!

First we create a 8GB disk

qemu-img create -f qcow2 aix-hdd.qcow2 8G

Next we need the custom BIOS with serial as the console.

wget https://github.com/artyom-tarasenko/openfirmware/releases/download/40p-20190413/q40pofw-serial.rom

You’ll need some AIX. I tried a 3.2.5 CD-ROM and it didn’t pick up, but AIX 4.3.3 did.

Now with all those bits in place, it’s time to run Qemu.

./ppc-softmmu/qemu-system-ppc -M 40p -bios q40pofw-serial.rom -serial telnet::4441,server -hda aix-hdd.qcow2 -vga none -nographic -net none -cdrom Volume_1.iso

Now telnet to your localhost on port 4441 and you will see the console doing it’s BIOS initialize and eventually drop to the OK prompt.

One trick I’ve found is that from the Open Firmware prompt you can find out what partitions are recognized from the firmware. If it see’s partitions then there is some hope that the image you have is valid enough to boot. In the last few days I’ve found quite a few AIX images, which are lacking the partition table, and unable to boot.

.partitions cdrom

simply type in boot cdrom:2 to kick off the installer. It may take a minute or so for the installer to kick off.

If all goes well, you’ll see the BIOS reload itself, then after a minute you’ll be prompted to press 1 to select the console

It doesn’t echo, don’t panic!

Next select your language. I’m doing English.

Next it’ll ask about installation type. Default ought to be fine.

Because this will destroy the contents of the disk (which doesn’t matter as it’s blank) it’ll prompt for confirmation.

After this it’ll begin the installation. Depending on how fast your disk & CPU is this will take a while.


For me, the installation took about 11 minutes. This is using my Xeon E5-2667 v2. It took 17 minutes on my 2006 Mac Pro, with X5365’s it .

After it’s done, right around the 96% time it’ll reboot back to the BIOS

Once you are back at the OK prompt, you can now boot disk:

it’ll look like it’s hung for a minute, then it’ll start booting from disk!

Once the OS is booted up, you select the terminal type. I’m using putty but I’ll select the vt100. Of note the function keys are selected by hitting escape and then the number key. So F3 is ESC 3.

I’m just going to finish the install, as we can always run smitty to mess with the system more, but right now I’m just interested in a base install of the BOS (Base Operating System, and IBM ISM).

A few moments later, you’ll get dumped to the login prompt.

By default there is no password, so just login as root, and there you go, your very own virtual AIX 4.3 system.

# uname -a AIX localhost 3 4 000000004C00

So there you go! All thanks to Artyom’s hard work!

Citrix Multiuser 2.0

Back before selling auto insurance

Citrix Multuser 2.0

Nothing like a little vintage advertising to try to re-capture the feel.  But don’t let the colorful lizard fool you, this certainly was a dark time for Citrix.  Firs they had tooled a product around the future of the PC market, OS/2 to only have Microsoft pull out of active development just as they were launching Multiuser 1.0.  And to be fair it wasn’t just Citrix, the whole industry including Microsoft was in turmoil as people were pulling away from IBM and selecting Windows on MS-DOS of all things!

Citrix, like a lot of vars were caught in this lurch between OS/2 and the forthcoming NT OS/2 3.0, which of course ended up becoming Windows NT.  During this time even Microsoft had to keep selling it’s SQL server on OS/2, along with it’s LanManager file & print server.  Although they had a solution for the end user in the form of Windows they didn’t have any server platform.  That left Citrix chasing the tail end of the application wave again as although they could now finally use OS/2 2.0, with it’s 32bit/16bit hybrid kernel, there remote user solution was still terminal based.

IBM OS/2 ad

As IBM & Microsoft had split up the direction of the OS/2 project, IBM was running with version 2 as a platform for running DOS & Windows applications.  Which ultimately lead to the major problem that OS/2 ran Windows apps better than native Windows thanks to it’s ability to run isolated Windows VM’s using paravirutalized graphic drivers.  It wasn’t until Windows NT 3.5 could Microsoft meet this feat with it’s new platform.  Suddenly Citrix had access to tonnes of MS-DOS based applications, much to my surprise there is even a DPMI driver on the disks I have, meaning that Windows 3.0 standard mode can run, along with DooM!  But for Citrix this would be another one of those ‘not good enough’ moments where PC Servers were just high end workstations that could easily be maxed by one user, commodity multiprocessor machines were years off, and of course everyone was jumping to Windows 3.0.

But this did at least you run MS-DOS applications remotely, over dialup.

Citrix multiuser 2.0 boot

Installing Citrix Multiuser 2.00 starts looking very much like one of the 1.x versions of OS/2 with a far more busier screen featuring the Citrix tree.  However from this point onward it feels a LOT more like IBM OS/2 2.00.  Citrix interestingly enough has two disk 1’s, one that features newer LADDR drivers, and another with the older 1.x drivers.  Although under bochs, the older driver disk crashes out.  The entire OS fits on 8 high density 5 1/4″ diskettes.  As teased before this post, I saw this on eBay, ordered it immediately to only discover that I don’t have the needed drive, and had to order one from pc-rath_de, and I wanted to give a shout out, as he made sure that I had the proper floppy ribbon cable, so I could go ahead with this fun project.

Although I had been expecting this to be inline with the never released Microsoft OS/2 2.00, it clearly has a lot of IBM vestige, even though the OS/2 source code license agreement was between Citrix and Microsoft.

Indeed, even checking the OS level:

IBM OS/2 Base Operating System
Standard Edition 2.00     Component ID 560109001
Current CSD level: XR00000
Prior   CSD level: XR00000

Compare this to the OS/2 2.00 GA:

IBM OS/2 Base Operating System
Version 2.00 Component ID 562107701
Type 0
Current CSD level: XR02000
Prior CSD level: XR00000

So clearly this is not in sync with the General availability of OS/2.  What this is closer to sync with is the OS/2 LA – Limited Availability release.

IBM OS/2 Base Operating System
Standard Edition 2.00 Component ID 560109001
Current CSD level: XR00000
Prior CSD level: XR00000

Well isn’t that interesting?

Having had the misfortune of crashing all three we can look at the internal revisions:

Citrix Internal revision 2.053 6.177H base

LA Internal revision 6.167 91-10-08

GA Internal revision 6.307 92-03-01

So this make the BOS (Base Operating System in IBM speak) newer than the OS/2 LA (Limited Availability) kernel, however quite a few revisions behind the GA (General Availability).  This of course means that Citrix Multiuser 2.0 is basically incompatible with any 32bit OS/2 software.  I was unable to run anything EMX based, nor could I run the vast majority of the 32bit TCP/IP stack for OS/2 2.00.  The best I could do was have it load the drivers, to where I could setup and ping the loopback, but the route command crashes the system, and any of the commands simply refuse to run.  Not being able to run 32bit OS/2 applications greatly reduces the usability of the system, and falls further to the OS/2 trap that it really just excels at running MS-DOS apps.

It was a bit of a surprise to find out that even though Citrix had their source license through Microsoft, the 2.0 components turned out to be the upstream components from IBM.  Just as the included Qbasic is the IBM version, along with the other components.  The terminal support is naturally more robust than version 1, although I think the larger problem I had trying to run OS/2 programs it that many terminals are hard coded for 24 lines, and I don’t think you can change that in Citrix.  And it does mention that if you do try to run on a 24 line terminal that DOS won’t run.

Much like 1.0, all the administration is done via text tools.  It feels weird at first as even on the console there doesn’t seem to be any mouse integration, although the installer does ask if you do have a mouse on the system.

And like 1.0 there is no Presentation Manager, so no graphics on the console.  HOWEVER you can run MS-DOS graphical stuff on the console. Although today I have no real need for it, but I went ahead and setup the included Windows support.

Windows for OS/2

What is interesting is that you are expected to supply your own retail version of Windows 3.00, and Citrix has some updated drivers, along with OS2K286.EXE, and updated program manager, control panel, and print manager.  While IBM included a full copy of Windows 3.00 at this point, this feels like the beginning of OS/2 for Windows – AKA the Borg.

Going Multiuser

First I just setup a COM port on Bochs to Listen on port 8880.  Unfortunately this isn’t resilient, as Bochs will wait for a connect before actually starting, and if you drop off, it won’t let you connect back in.

com1: enabled=1, mode=socket-server, dev=localhost:8880

And then it’s a matter of running CFGTERM, and adding in the Async module.

Citrix add in Async

With the module added you then just have to assign a port.

ICA profile

I didnt’ do anything special other than telling Citrix that there is no modem, it’s a direct connect, and to use the ICA terminal profile.

Using the Citrix MultiLink program, and DOSBox I was able to add an ICA terminal.  On DOSBox I had to specify a modem with an IRQ in the config like this:

serial2=modem irq3 listenport:5001

CML modem settings

In the modem settings I had to set this to Forced connect, otherwise it’ll never see the server.

CML dialup profile

And here is how I ‘called’ the Bochs VM.  And then after ‘dialing’ in Bochs will start up the Citrix VM, and then you’ll get the simple Login prompt.  Login and you’ll get pselect.

Logging in to Pselect

Pselect the the text based UI tool to get around your OS/2 sessions.  It’s a little cumbersome at first, but once you get used to it, it’s just like OS/2 1.0 … Or Multiuser 1.0 for that matter, nothing really changed, except you can start MS-DOS Sessions now.

MS-DOS over the serial port

And yes, you can run Qbasic.  But you can’t do anything graphical. Not even DooM.  Although after loading the VDPMI device driver, DooM v1.1 will run, but then it’ll give you this fun error:

No graphics over the serial line

And that is where I’m going to have to leave this adventure for now.  If you are so inclined, you can pick it up on archive.org.

As requested, PCem v11 with networking

via SLiRP

via SLiRP

injecting networking was no more difficult than it was in version 10.  It’s only a few changes to pc.c, if you look at the USENETWORKING define you’ll see them.  The best notes are on the forum.

I haven’t changed or improved anything it still requires manual configuration.

Downloads are available on my site as pcem_v11_networking.7z.  You’ll have to defeat the password protection, as always.  I included the source, it ought to be trivial to rebuild.

*For anyone using an old version the ‘nvr’ directory is missing, so PC-em is unable to create new non volatile ram save files, meaning you always loose your BIOS settings.  Sorry I missed that one.

Windows 3.0 …

Bill Gates with Windows 3.0 / credit:Carol Halebian

There is no denying it, when it comes to revolutionary products you simply cannot ignore the powerhouse that was, Windows 3.0 .  Simply put this is what made the Microsoft empire, broke the alliance with IBM, and changed the future of OS/2 3.0.

Not only that, but Windows 3.0 changed the way businesses operate world wide, and finally delivered on the ‘dream’ of what could be done with the 286/386 microprocessor where OS/2 had failed.

To really appreciate Windows 3.0 you have to see the world as it was before it was under development.  Back in 1989 the pc market was in turmoil.  While OS/2 had the promise of breaking all the old barriers of the real-mode only OS MS-DOS, it simply cost too much, and hardware compatibility was just too poor.  The other striking thing was that the only 386 specific feature that OS/2 1.2 (current version in 1989) could exploit was that the 386 could quickly move in & out of 286 protected mode.  The LAN server product also had a 386 specific HPFS driver, but that was it.  OS/2 1.2 was still limited to a SINGLE MS-DOS box.

OS/2 1.2’s DOS session

And there wasn’t a heck of a lot you could do memory wise.  Not to mention there was no ability for the DOS session to use EMS/XMS memory.  It’s no wonder it became to be known as the ‘penalty box’.

Meanwhile, Windows/386 circa 1987 could run multiple MS-DOS VDM’s on the 386 processor.  You were only limited by how much extended memory was in your system.  Windows/386 exploited the v86 mode of the 386 processor which allowed for hardware virtualization.  However Windows itself was a ‘real mode’ program, meaning that it had to fit in 640kb of ram, just as the VDM’s it spawned had to.

Windows/386 2.11

So unless your goal was to run a bunch of MS-DOS sessions all your extra memory was for nothing.  That also included Windows programs since they all ran in real mode.  For people with enough disk space you *could* actually install one copy of Windows/386 in say VGA, then another with a lower video resolution (CGA or EGA), then actually run Windows in Windows… in a Window.  But it really wasn’t that useful, it ran better full screen.  And all this had the effect of doing was partitioning your windows programs from each other, if you dedicated a VM per application.  Needless to say with OS/2 2.0’s seamless windows this was far more easier to setup, and frankly far more practical.

In 1989 building large applications meant that you either forced people to use Unix (SCO Xenix!) or OS/2.  For those that could afford it, Xenix would have been the way to go, as they not only ran in 386 protected mode, offered a far larger address space, but it was also multiuser!  But Xenix was expensive, needed specialized knowledge.  And as mentioned the cost of OS/2 development was HIGH, and it required your end users to have OS/2 (naturally).  And the users would have to fight that a lot of PC/AT compatible PC’s on the market were not compatible enough to run OS/2.  Despite this a lot of banks latched onto OS/2, and some still use it today (look at why parallax came into existence!).  Then out of nowhere, PharLap had developed a piece of software that changed everything, the DOS Extender.

Originally for 386 computers, the first DOS extenders required people to use special 386 compilers, runtimes, and of course linkers & extenders.  The tools were expensive, the right to redistribute wasn’t free, but end users could run your multi-megabyte (lol) applications on regular MS-DOS.  Which is what 99% of PC’s were running, and it didn’t require users to change their OS, abandon their applications, it would simply just work.

Links 386 pro

One of the earliest and most popular DOS Extended game/application was Access Software’s Links 386 pro.  That’s right this game ran in protected mode! .. And it would *NOT* run under, or near Windows/386.

It was out of this wildly great but incompatible world that the first DOS Extender vendors, tried to standardize their products with the original and short lived VCPI specification, from Phar Lap.  However in 1989 Microsoft was busy working on Windows 3.0 as the next great thing.  Using a protected mode debugger, they were converting Windows/386 from a real mode ‘hypervisor’ into a protected mode application.  And if Windows couldn’t run these new extended applications, then people would naturally have to exit Windows to run them.  And that was the major problem with Windows is that people may have an application for windows but they spent most of their time in DOS. So Microsoft’s Ralph Lipe came up with the DPMI specification, managed to get all of the major vendors to support and take over it, in exchange for leaving Windows as a 0.9 level client/server.  After all why would you need their products if Windows were to incorporate the entire 1.0 spec?  At the time it was a big deal, but the success of Windows would eventually kill the extender market save for video games until Windows 95.  There is a great article about the rise of DPMI here.

So with a firm dos extended foundation Windows 3.0 could do something the 2.x products could never do, which was to actually utilize all the memory in peoples computers.  And because it hinged on a dos extender (ever wonder what dosx.exe was?) it meant that there was no special disk, mouse, network driver/software needed as it could jump out of protected mode, and call real mode software like the BIOS, or even mouse drivers if need be.  However older protected mode programs would only error like this:

No Lotus 1-2-3 r3 for you!

Another popular application for MS-DOS just happened to be Lotus 1-2-3, and it was *NOT* DPMI compliant.  Oh sure they had DOS & OS/2 support, but would you believe that the OS/2 version wouldn’t run in a Window?  Oh sure the install program may have, but some how someone didn’t think there would be any value in being able to SEE more then one application at a time.  Not to mention the dark horse, Excel was starting to sell in 1987 like crazy, in 1988 Excel actually started to out sell 1-2-3, and by 1989 it was already over.

Lotus 1-2-3 r3 for OS/2

Microsoft Excel 2.2 for OS/2

There is no doubt about it, GUI applications were taking over.  The old ‘DOS’ interface was dead.  And Lotus had basically killed their product line by providing an identical interface and experience to their customers by providing an OS/2 application that looked and felt just like the MS-DOS application.  While you may hear that Lotus got distracted with OS/2 and missed releasing a Windows version of 1-2-3 to counter the rise of Excel, the truth is that they straight up missed windowing UI’s. Their hubris is that the users simply didn’t like the 1-2-3 interface, they wanted a windowed application.

What they did want was graphical Windows, and of course more memory!  And there is nothing more annoying than having say 16MB of VERY expensive memory in a computer like a 286, but being restricted to 640kb or less is just … insane.

So let’s see Excel in action.  Excel 2.1c shipped with a ‘runtime’ version of Windows 2.1.  Mostly because nobody was buying Windows in 1987 Microsoft had to do something to get people running the thing.  So the best way was to allow you to run an application with it.  By late 1989 and early 1990 application vendors were making updates to their products so that they could run under Windows 3.0.  And here is the first version of Excel to do so.

Excel 2.1c and the Windows 2.1 runtime

So here we have Excel running under Windows 2.1 ala the runtime environment.  All you have here is excel.  Also worth noting is that the setup program is 100% DOS text based.

Moving forward we can now upgrade to Windows 3.0.

Excel 2.1c running on Windows 3.0’s real mode

So as you can see Windows 3.0 takes up 30kb more memory then Windows 2.1!  For someone with an XT this could mean bad news!  Now it’s time to see what all the babling was about, running the same application in protected mode to access more memory!

Excel 2.1c running in Windows 3.0’s standard mode (286 and above)

Now we are running in 286 ‘standard’ mode.  Notice that Excel thinks it’s conventional memory, but we now have 14MB of the computers installed 16MB accessible to the application!  Now this is pretty amazing stuff! Now it’s no secret that the 286’s memory management left a lot to be desired, and Microsoft really didn’t want to write for it, as the 386 was where they wanted to be.  So unlike OS/2 the 286 cannot swap.  You are only limited to what extended memory you have in your computer.  But this is different for the 386..

Excel 2.1c running under 386 enhanced mode

And here we are, 386 enhanced mode! So finally  our Windows applications are clearly running in protected mode, with demand paging!  With 36MB of available memory in a computer with 16MB of ram.  The colors are distorted on Virtual PC under 386 enhanced mode… But as you can see the environment runs!  And even graphical programs that for example used CGA could happily run on an EGA system in a window.  Even better you could copy the screen, and paste it into any Windows application you want.  Yes you could buy games and use them for clipart!

Another feature of Windows 3.0 that people didn’t realize is that it could pre-preemptively multitask DOS based VDM’s

As you can see, there it is, the timeslice, and scheduling options..  Great ways to confuse users for decades… 🙂

Who could resist?

As always, there is a great InfoWorld article here.

So why was Windows 3.0 successful? A lot of it is timing, as there was no other environment that could offer people access to their whole machine without upgrading their operating system.  And of course there was the whole thing with bundling Windows, Word & Excel with new computers.  I mean who would resist something like a graphical application like Excel when compared to the klunky and significantly more expensive 1-2-3?  Sure the bundling practices were found to be illegal, but looking back, Lotus & Word perfect basically GAVE Microsoft the market.  And of course, talk about aggressive upgrades!  I’m not sure they even do such things anymore.  Although I’ve heard of big companies, and governments pushing for discounts for running things like Linux.

And there is the other things that Windows 3.0 supported that OS/2 simply did not.  For starters backgrounds (wallpapers), and of course the desk accessories.  Sure they sucked but in a panic at lest you *could* do something… where OS/2 basically left you in the lurch.  Not to mention how much more expensive OS/2 was when compared to Windows.

So with all that out of the way, what fun is a write up without a demo?

 

And thankfully I’ve found all the bits in prior posts, and I can put them together right here.

Windows 3.0 working demo, click to launch!

 

Retro: a PC/XT emulator

A friend of mine just pointed me to Retro, a PC/XT emulator written in Java.

It’s got a few games ready to roll, which is cool. While not a full featured as dosbox, it does feel significantly smaller, compared to jdosbo’s 2mb image. And since it’s browser based, it’s not like it’s all that difficult to check out.

Zork on the IBM Mainframe (VM/370 CMS) it lives!

There we have it, after a LOT of fighting the emulators, missing bits, LOTS of help the hercules-os380 mailing list, and the EXCEPTIONAL of one Paul Edwards, and it’s running.

It seems to be Dungeon version 1.2C

read news
US NEWS & DUNGEON REPORT
01-MAR-81 Late Dungeon Edition
This is a version of Zork on VM/370

The problems with it are:
-Lack of an endgame.
-Simple parser (no compound sentences).
-Numerous bugs and spelling errors.
But so what.

If you encounter problems or find logic, spelling, or usage bugs,
keep them to yourself.

>

It’s a little odd playing zork on a mainframe…

Zork on the Mainframe?

Ok, I know this title 99% of the time is a ‘oh whatever’ as most people seem to have confused mini’s with mainframes… PDP-10’s, PDP-11’s, VAX’s (even the massive 11/780), were all minicomputers…

But I came across this post, which just mentions in passing that there was a port of dungeon (zork) to the IBM Mainframe…

And rescued via the internet archive, is Melinda Varian’s home page, which includes…. Dungeon in VMARC format…

The sad thing is that I can barely remember logging on to TSO, using ISPF, and getting out… I was so bad with the system that I’d use an empty file as a template, as copying files was easy, but creating a file on the host took me a whole day.

I vaguely recall using this IND$ thing to transfer files, but I don’t know what you need exactly to facilitate it…

So I’ve downloaded hercules/380 along with the VM370 SixPack and… remembered that I don’t… remember much, let alone enough to actually operate VM/370.

I tried passing VMARC files through PC ARC, and got.. nothing, I even manually byteswapped the files to get nothing.

Oh well I’m at an impass, but maybe some mainframe dude will see this one day, and take a peek.

Oh it’s the end of 2010, welcome to 2011.

—-edit
I got it to run on VM/370 CMS.