FOOTBALL Design Document

Over at pcjs.org, this interesting prototype version of OS/2 has been unearthed.  What this means is that not only was there prototypes of a 386 aware version of OS/2 in 1986, but by 1987 the base of cruiser AKA OS/2 2.0 was already in place.  With this now somewhat made public, it really is clear that IBM’s meddling in OS/2 prevented it from being a success.

Check out the design document below:
The following text is from an email titled “3xBox Design Document” sent to the football alias on Saturday, February 28, 1987, at 5:02pm.

Overview

The goal for this research project was to demonstrate the feasability of supporting multiple virtual DOS 3.x machines on a 286DOS-based kernel running on an 386 personal computer. Each “3xBox” would have its own virtual screen, keyboard, interrupt vectors, and address space. Furthermore, well- behaved DOS 3.x applications that do text (as opposed to graphic) screen output would run in the background.

In order to acheive this goal in a reasonable amount of time, we started from the 286DOS “sizzle” kernel and made the minimum amount of changes necessary, both in code and fundamental design. The resulting DOS will be referred to as “386DOS” in this paper.

386DOS provides up to four 3xBoxes, depending upon the available RAM. More 3xBoxes could be supported if a slight change is made to the method of allocating page tables.

Well-behaved DOS 3.x applications (i.e., MS-Multiplan, MS-Word, Lotus 1-2-3) can run in the background, multi-tasking against one another and against the foreground screen group. Lotus 1-2-3 (version 2.01) passes its floppy-based copy protection when in the foreground.

It should be noted that 386DOS, while functional, is not an optimal design/implementation of multiple 3xBoxes. In particular, interrupt management, the device driver model, and the existence of V86-mode kernel code should be modified before 386DOS is made a commercial product.

Unless stated otherwise, most of the concepts extant in 286DOS apply to 386DOS.

V86 Mode and the 386

The 386 CPU has three distinct execution modes: REAL, PROT, and V86. REAL
and PROT modes are largely compatible with the corresponding modes of an 286.
V86 modes is exactly the same as RING 3 PROT mode, with the following
differences:

o Memory Address Hierarchy
A 386 has three levels of memory addresses:
– Virtual (Intel refers to this as Logical)
This is either the selector:offset or segment:offset address used by unprivledged machine language code.
– Linear
This is the 32-bit address arrived at either via a GDT/LDT
selector lookup, or via the 8086-compatible (seg << 4 + offset).
– Physical
This is the 32-bit address arrived at by pushing a linear address
through the paging mechanism. This is the address that the CPU
sends out on the bus to select physical memory.

When in V86 mode, the CPU performs the 8086-compatible computation.

o I/O instructions are NOT IOPL-sensitive
Trapping of I/O is done using the IO Permission Map.

o All instructions which modify or expose the Interrupt Flag ARE IOPL-
sensitive.
This allows the OS to simulate the Interrupt Flag, if desired.

V86 IRETD Frame

When any interrupt, trap, exception, or fault occurs in V86 mode, the CPU
switches to PROT mode and switches to the TSS Ring 0 Stack and builds the
following stack frame:

[[code]]czoyNDA6XCIKICAgICAgICAgICAgKDApIChvbGQgR1MpCiAgICAgICAgICAgICgwKSAob2xkIEZTKQogICAgICAgICAgICAoMCkgKG97WyYqJl19bGQgRFMpCiAgICAgICAgICAgICgwKSAob2xkIEVTKQogICAgICAgICAgICAoMCkgKG9sZCBTUykKICAgICAgICAgICAgICAgKG9sZHtbJiomXX0gRVNQKQogICAgICAgICAgICAob2xkIEVGTEFHUykKICAgICAgICAgICAgKDApIChvbGQgQ1MpCiAgICAgICAgICAgICAgIChvbGQge1smKiZdfUVJUCkgJmx0Oy0gKFNTOlNQKQpcIjt7WyYqJl19[[/code]]

CPU Mode Determination

A new implementation of the WHATMODE macro was written in order to distinguish
between the three CPU modes: REAL, PROT, and V86. REAL mode is indicated by
a 0 PE bit in CR0 (a.k.a. MSW on a 286). If the PE bit is 1, then the mode
may be either PROT or V86. These two modes may be distinguished by attempting
to change the IOPL bits in the FLAGS word. At Ring 0 in PROT mode (the only
place WHATMODE is used), the IOPL may be changed. In V86 mode, IOPL cannot
be changed. So, we change IOPL and then check to see if it changed. If so,
PROT mode, else V86 mode.

CPU Mode Switching

The 286DOS kernel relies extensively on switching inbetween REAL and PROT.
This functionality is provided by the RealMode and ProtMode routines.
In 386DOS, RealMode is no longer needed. As soon as we switch to PROT mode
during SysInit, the CPU only uses PROT and V86 modes.

Two new routines, ProtToV86 and V86ToProt, that are analogous to RealMode and
ProtMode. ProtToV86 is quite straightforward. We build a V86 IRETD frame
on the stack with the VM bit set in the EFLAGS image. We set the SS:SP
image to be equivalent to the stack just above the V86 IRETD frame, and
set the CS:IP image to instruction following an IRETD. Then, we issue the
IRETD and the CPU continues processing following the IRETD and in V86 mode.

V86ToProt is a bit trickier. The only way to get out of V86 mode is to
trap or fault or issue a software interrupt. We chose to use a software
interrupt, 30h, which we call the V86 Services interrupt. The INT 30h entry
in the IDT is a ring 3 interrupt gate, so issuing an INT 30 from V86 mode
causes a V86 IRETD frame to be built on the TSS Ring 0 stack and control
transfers to the INT 30h vector. The handler verifies that the INT 30h
was issued by the V86ToProt routine (checks CS:IP on the stack). If not,
the interrupt is reflected back to the requesting 3xBox (See Interrupt
Reflection). If it was V86ToProt, we clean off the stack frame and return to
the caller. NOTE: V86 Services is also used for completing the 386 LOADALL
used by PhysToVirt to map “high” memory in “REAL” mode.

Stack Switching

In order to maintain the 286DOS mode switch and stack switch semantics
when V86 mode is used, we have a new stack (the V86 Stack) in the 3xBox PTDA.

286DOS Modes and Stacks

The RealMode and ProtMode procedures in 286DOS are the only ways to switch
the CPU execution mode. These routines both maintain SS:SP, allowing
RealMode and ProtMode to be reentrant. The TSS Ring 0 stack is always the
current TCB stack in the current PTDA. The only other stacks in the system
are the Interrupt Stack and user stack(s).

386DOS Modes and Stacks

In 386DOS, any interrupt or exception while in V86 mode causes a switch to
PROT mode and the TSS Ring 0 Stack. So we have a new way to mode switch with
an incompatible stack semantic. We had to fix this mode switch to make it
compatible with 286DOS.

Observation

In V86 mode, the current stack must not be the TSS Ring 0 Stack. The CPU
only leaves V86 mode via an interrupt/exception, which causes a stack switch
to the TSS Ring 0 Stack. If the current stack was the same as the TSS Ring 0
Stack, then the stack might get corrupted. In 286DOS, the Ring 0 Stack is
the PTDA. Since we run on this stack in V86 mode, we need a new Ring 0 stack
when a 3xBox is running.

Approach

1) When a PMBox is running, the TSS Ring 0 Stack is a PTDA TCB stack.
+ This is consistent with the 286DOS model.

2) When a 3xBox is running, the TSS Ring 0 Stack is the “V86 Stack”.
+ The V86 Stack is allocated in the 3xBox PTDA.
+ If the cause of the mode switch can be handled without enabling
interrupts (e.g., interrupt reflection, IN/OUT trapping), we stay
on the V86 stack.
+ Otherwise, copy the V86 IRETD frame to the previous stack and
switch back to the previous stack.

Details

1) Leaving V86 mode
a. V86ToProt (analog of ProtMode)
+ Issue special V86ToProt software interrupt. If the interrupt
gate is DPL=3 (and it must be a 386 Interrupt Gate), then the 386
switches to Ring 0 (and the TSS Ring 0 stack) and transfers
control to the handler.
+ To ensure that 3xBox apps don’t use this feature, the interrupt
handler checks that CS=DosGroup and IP is in the correct range.
If not, then the interrupt is reflected (see below).
+ To make V86ToProt compatible with ProtMode, the interrupt handler
switches to the old stack (we get SS:ESP from TSS Ring 0 stack,
which is where we are running).
+ Finally, V86ToProt restores saved registers and flags from the
stack and returns to caller.

b. Software interrupt
+ GP-Fault handler reflects to 3xBox IVT handler in V86 mode.
o Add IRET frame on old stack, taking IP, CS, FLAGS from
TSS Ring 0 Stack.
o Look up handler in 3xBox IVT.
o Edit TSS Ring 0 Stack EIP and CS to point to IVT handler.
o IRETD
+ IVT interrupt handler IRET uses IRET frame we built on old stack.

c. Hardware interrupt
+ To make this operation compatible with 286Dos, the interrupt
handler copies the V86 stack from the TSS Ring 0 stack to
the old stack, then switches stacks to the newly modified old
stack. This allows the Interupt Manager to do an IRETD to
get back to the correct mode.

d. Exception
+ Remain on V86 stack, process exception, and IRETD.

2) Entering V86 mode
a. ProtToV86
+ Build V86 IRETD frame on current stack and IRETD.
b. LinToVirtDM_HANDLE
+ Execute 386 LOADALL with VM bit set in EFLAGS image in loadall
buffer.

Interrupt Management

All software interrupts, hardware interrupts, and CPU traps and exceptions
are vectored through a common IDT, regardless of whether the CPU is in PROT
or V86 mode.

NOTE: Background 3xBoxes get no hardware interrupts. In the commercial 386DOS,
this restriction can be relaxed so that interrupts, other than for the
keyboard and mouse (since those are implicitly for the foreground box),
can be given to background 3xBoxes.

Passing Hardware Interrupts to the Foreground 3xBox

In the interrupt manager:

IF a 3xBox is foreground -AND-
the current mapped 3xBox is background
THEN
MapIn foreground 3xBox;
Dispatch interrupt;

And to make things more interesting, from the later version of FOOTBALL, oddly enough version 4:

OS/2 FOOTBALL Boot Disk (v4.41.00)

This disk contained an updated version of OS/2 FOOTBALL Boot Disk (v4.41.00). It was built in December 1987, using final OS/2 1.0 sources merged with assorted FOOTBALL changes, and although it was originally assigned version number 1.3, this version of OS/2 would ultimately become 2.0.

It crashes on an 80286, jumping to invalid code immediately after performing a processor check. On an 80386, the following version banner is displayed:

[[code]]czoxNzU6XCJPcGVyYXRpbmcgU3lzdGVtLzIgIFZlcnNpb24gMS4zMAooQykgQ29weXJpZ2h0IE1pY3Jvc29mdCBDb3JwLiAxOTgxLCB7WyYqJl19MTk4NywgMTk4OC4KKEMpIENvcHlyaWdodCBJQk0gQ29ycC4gMTk4MSwgMTk4Ny4gQWxsIHJpZ2h0cyByZXNlcnZlZC4KCkludGVybntbJiomXX1hbCByZXZpc2lvbiA0LjQxLjAwLCAxMi8wMi84NwpcIjt7WyYqJl19[[/code]]

The numbering of revisions must have been, um, revised, because despite the lower revision (4.41.00 vs. 7.68.17), it is newer than the 7.68.17 prototype. This is confirmed by the boot message (12/02/87), the file dates (12-23-87) and the higher version number (1.3).

SCSI CD-ROM support for OS/2 1.3

I was passed this in email, that using the BusLogic SCSI adapter, that OS/2 1.3 can use it’s CD-ROM interface for those of you who want to be able to directly mount ISO images!

The driver is here.

So apparently all you need to do is just add in the BusLogic controller, and copy the BOOTBID.BID to C:\ (don’t rename it).

unknown-LW22HX
And there we go!
unknown-POZPHX

 

Apparently, it can even boot from SCSI hard disks. So it’d be a great way to give that SQL 1.0 install access to a bunch of storage.

IDLEHLT16 for OS/2 1.x

Tobias let me know that he’s released his IDLEHLT16 driver for these early OS/2 versions.  If anyone has run them in an emulator, you’ll know they’ll easily soak up 100% of the CPU they are given.  This process will call the HLT opcode found in later (well compared to the 80286!) processors allowing them to ‘sleep’.

IDLHLT16

IDLHLT16

Needless to say, for fans of the beleaguered 16-bit OS, this is a great thing to have!

If anyone wants to know why there isn’t one for OS/2 2.0 and above, it doesn’t need one, it can sleep fine on it’s own.

PCem 0.7 and beyond

Checking out that javascript PCe made me want to check out PCem.  And good reason too, as its latest version 0.7 can run OS/2!

At first I tried version 2.0 and it just reboots once it is going to start the installer, (I haven’t tried a pre-installed disk image yet) but for the heck of it I shoved in an OS/2 1.1 boot diskette, and it came up!  So all excited I tried 1.21 and it worked as well!  The caveat is that OS/2 cannot partition or format the disk.  I didn’t try giving it a HPFS volume, but rather setup for a DualBoot with MS-DOS, and that worked fine.

OS/2 1.21 on PCem 0.7

OS/2 1.21 on PCem 0.7

Some of the cool things about PCem is that it runs REAL firmware, so you get the real XT/286/386/486 experience.  Also it is cycle accurate so things are SLOW like they were back in the day.  I’ve noticed that disk IO is really slow.  Again just like it was back then.  Things like DOOM take forever to load on a 386.  Just like the real thing!

If you have the ROMs the CGA/EGA & SVGA emulation is pretty good.   Again this is largely from running the actual firmware.

Work has slowed on PCem, but there is a source repo here.  I haven’t tried to build it yet.

The only thing I’d say is missing is some kind of ethernet adapter.  It would be cool to get this onto the internet.  But at the same time I’ve got to say this is pretty cool, especially if you want to enjoy the PC experience from 20 years ago, this is the way to go!  Although after a few minutes of running a 286 at 6Mhz, you’ll want to push for the fastest 486 it can emulate!

Upgrading through OS/2; Version 1.3

Keeping with the ping-point tradition, I’m going to upgrade IBM OS/2 1.2 to Microsoft OS/2 1.30.1, the LAN Manager 2.1 install.  At this point Microsoft basically was taking IBM OS/2 1.3 and repackaging it.  All their efforts were shifting out of OS/2 and into Windows NT.  But to support existing customers and build their enterprise market OS/2 was still very much an integral part of the strategy as Windows NT wasn’t ready by a long shot yet.

Products like Microsoft Mail & SQL Server (ported & rebranded Sybase SQL) were the companies future direction, but for now they were OS/2 applications, and they needed an update from OS/2 1.2.

And continuing on, it’s the same bland tradition.

Maybe I just have mixed feelings about the grey background thing, it just feels either military or industrial.  Then again that was what OS/2 was trying to be, industrial computing on the PC.  I suspect there was a color study done by IBM on the whole look and feel.  The schema feels like a design by committee thing.

And please, don’t format my disk!

Now this selective installer is new.  Prior to this you’d get all of OS/2 and from there you could disable or delete as you wanted… But now a selective install.  I went ahead and selected everything.  Naturally this being a ‘server’ version you may not want the MS-DOS stuff at all…

It sounds like a lot more stuff… But go through and select down the line.  It is strange that my control+c (break) on is never honored, I have to always go there and enable it.

Now we just shuffle diskettes, and let the install finish up.

And to select a printer.  I don’t know why it just doesn’t upgrade my old printer, maybe it just wants to show off all the drivers… A sharp contrast from OS/2 1.0!

So with the install done, and a quick reboot we are teleported to the OS/2 1.3 desktop.

Very cool.  And… very.. 1.2’ish.

So I thought I’d first verify my applications work.  Excel launches but Word..

Ouch.  I guess this Microsoft OS/2 doesn’t do upgrades.  Although it did preserve my groups. I’ve got to say this is kinda sad.  At least it did backup the config.sys so I could simply append the lines to the PATH & LIBPATH and get my applications running again. One can’t help but wonder if this was some passive aggressive attack on Word & Excel?

Also new in OS/2 1.3 is the ability to lock the desktop!  Good stuff to keep people out, too bad it’s just a system thing, not an account / role based thing.

The default ‘screen saver’ lockout screen is the OS/2 logo.  I’ve only seen it on the Microsoft BOX, and a few Microsoft books, but here it is.

OS/2 1.3 is said to be more stable then OS/2 1.2, and faster.  I couldn’t tell the difference, I’m sure being under emulation would be one of the reasons, the other being on a significantly faster machine.  Nobody could imagine Ghz CPUs in 1987.

I don’t have much to add to OS/2 1.3 as it really feels like OS/2 1.2.

Next up is OS/2 2.0, the first of the 32bit releases of OS/2… Operate at a higher level!

16bit Fortran …

Ok, so I was looking at this ancient machine the other day, and I was wondering if I could at least build the f2c to run on either Win16 or OS/2 1.x. There was mention of it running on MS-DOS ages ago but I thought it’d be more interesting to try something else…

Well one thing is for sure, QuickC for Windows, wins HANDS DOWN for a ‘nice’ environment for building stuff… Once it was all said & done, on Windows 2000, I had f2c running, and converted the dungeon source, and building dungeon along with the libf2c. I couldn’t find a ‘nice’ way to build libraries with QuickC, and building a windows dll for libf2c would mean re-writing the IO for Win16.. If it were 15 years ago I may have done so, but nobody will use it now, so I just took the short cut of compiling the dungeon program & the library together… Surprisingly on a ‘fast’ machine with Virtual PC, 100,000+ lines of code compiles in under 10 seconds!

So the first result I got for my effort was this:

Dungeon in QuickWin on Windows 3.0 via F2C

 

Which wasn’t that bad, and I’m just amazed it works… You can download it from here. And thanks to the power of jDOSBox, you can run it live here.

The next thing I did was break out some ancient Microsoft C, and start to build f2c. That is when I found out that the resulting exe with C 5.1 doesn’t work, and 6.0a crashes when compiling part of the translator… However using 6.0a for *MOST* of f2c, and building the one faulting module with 5.1 results in a working f2c. The library built without issues, although I had a *HELL* of a time trying to remember how to build a static library for OS/2. I ended up just using lib & gluing it together one object file at a time… Not the ‘best’ but it works.

The next hardest thing was figuring out the linker definitions & response files to build a ‘windowed’ text client for OS/2. Luckily I was able to go through enough things to do it, and it was a LOT of work…. I almost wonder if it’s worth posting about it… But all my build steps are in the zip file located here.

Dungeon on OS/2 in a window via special linking..

 

It was a *LOT* of nonsense work to get this thing in a window for a good screencap… lol but in the end I guess it was worth it. I suppose I could try building it for MS-DOS, but really, where is the fun in that?

One thing is for sure, having this back when I actually used OS/2 1.3 or Windows 3.0 (I had CGA!!!) would have been cool… But now I guess it’s totally pointless, but whatever.

OS/2 1.3 on a real pc

 

Ok so this isn’t much of an update, but I thought I’d share some Microsoft OS/2 1.3 on REAL hardware…. Yeah, so it’s not emulation but this is COOL!

I scored a copy of Microsoft OS/2 1.3 IN THE BOX.

OS/2 1.3 on a real computer!

Which is beyond rare. But they needed something as a ‘server platform’ for Microsoft Mail 3.x before Windows NT (OS/2 NT) was ready.

Virtual disks revisted…

Again for Linux/ OSX users, it’s no big deal as they have access to the ‘dd’ command. Well I was installing AT&T SYSVr4 when it hit me that you can somewhat convert physical disks with Virtual PC & Qemu…
linked disk1
In Virtual PC you can create a ‘virtual disk’ that links to a physical volume..
linked disk2

And again, just select a physical slave disk with your legacy OS already installed.

Once the disk is linked, re-run the utility and you can then convert the linked disk into a dynamic disk. Once you have your .vhd, you can use Qemu’s qemu-img tool to convert the disk image into qcow,qcow2 (Qemu) or even VMDK for VMWare. The syntax is pretty simple..

qemu-img convert –f vpc attsysv.vhd –O qcow attsysv.dsk

I’ve tested it with AT&T SYSVr4 & OS/2 1.3! Much to my amazement with the fixpacks, OS/2 1.3 will actually RUN on Virtual PC 2007. It’s a shame that IBM saw the SDK’s for OS/2 as a revenue generation opportunity, as it’s amazing how quick it is (once it’s done initializing….) but I guess that’s a given of any 16bit OS that’s written in assembly….

For the heck of it, here’s a screenshot.

OS/2 1.3 running from a linked disk

OS/2 1.3 running from a linked disk

 

A minor update….

OS/2 1.3 on Bochs

OS/2 1.3 on Bochs

OS/2 1.3 does infact run under BOCHS. Here is the catch, like Xenix you currently must make an image of an existing installation, and point Bochs towards it.

Here is the flag that I used:
ata0-master: type=disk, path=”os2-1.3.img”, cylinders=919, heads=16, spt=17

Bochs will complain about the geometry not matching… Just hit the ignore button, and it boots up just fine.

Thanks to Geoff Shearer for trying, since I had figured it wouldn’t even work.

I promise, a quick tour of SLS Linux next time… Where the distro wars all started!