The Super Bowl is long over and it’s time to look at different kind of football. In Winter 1986/1987, Microsoft initiated a small skunkworks project called “Football”. The objective was to take “Sizzle”, a development branch of proto-OS/2 that would eventually become OS/2 1.0, and add support for the V86 mode of 386 processors in order to run multiple DOS boxes in OS/2.
Needless to say, that was rather advanced technology in 1986/87 (after all, the first 386 PC had only been on the market for a few months). So why did Microsoft keep so uncharacteristically quiet about this project? Because IBM wasn’t supposed to know about it. There was a worry that IBM might put a stop to Football if it learned about it, because Football took resources away from completing OS/2 1.0, or—perhaps even worse from Microsoft’s perspective—IBM would insist on getting involved in the project.
The project was a proof-of-concept work and culminated in a “BillG demo” (showing the project to Bill Gates, then the CEO of Microsoft) in early 1987 with multiple DOS sessions running simultaneously on top of proto-OS/2. Football was likely entirely independent of the development of Windows/386 which would have been in progress at the same time.
Brief technical outline of Football is available on pcjs.org.
In the Spring of 1987, IBM was told about Football and worked on porting it to the PS/2 Model 80 (IBM’s first and for a while only 386 PC). Whether anything of the IBM project survived is unknown.
Football on Modern Hardware
To mix metaphors a bit, Football scored a few own goals that make it quite hard to run on modern and even old hardware.
Much like the pure 16-bit Sizzle proto-OS/2 builds, Football required an EGA, but with an added twist explained below.
The kernel debugger built into the surviving Football disks accesses test registers TR6/TR7 and therefore crashes on any Pentium or later processor almost immediately, since Intel completely removed those instructions. Football attempts to execute the following instruction sequence (from the Pigskin 7.68.17 build):
0108:00000b2c 66 0f 24 f0 mov eax, tr6 0108:00000b30 66 a3 50 14 mov dword [01450h], eax 0108:00000b34 66 0f 24 f8 mov eax, tr7 0108:00000b38 66 a3 54 14 mov dword [01454h], eax
It’s hard to blame Microsoft for assuming that future x86 processors would be 386 compatible. Other debuggers like the OS/2 2.x kernel debugger or WDEB386 have the same problem.
To run on Pentium and later CPUs, the offending code needs to be patched out. That causes no problems because the test registers can be shown by the kernel debugger but aren’t actively used.
The surviving Football disks are configured to break into the kernel debugger during startup. In order to boot them, there must be a serial terminal attached to COM2 or possibly COM1 and the user must enter the ‘g’ command to continue execution.
Due to an apparent bug, Football does not run on processors beyond the 486 at all. It panics fairly early during startup. The reason for the failure is rather interesting: 386 (and 486) processors, when pushing a selector on a 32-bit stack (either through a PUSH instruction or indirectly during interrupt or exception delivery) only write the low 16-bit word and leave the high word unmodified; Pentium and later processors always write the full 32 bits (with the high word zeroed).
Football inadvertently relies on the old 386 CPU behavior and references invalid (but not random) data on the stack that is zeroed on modern CPUs. Okay, so Football can boot up only on a 386 or 486.
Football does not run in real mode at all (any and all DOS sessions run in a V86 task); one might think that that would obviate any need for LOADALL trickery. Reality is much worse. Football not only uses the 386 LOADALL instruction but uses it in such a way that it is impossible to simulate on non-386 hardware.
For reasons that probably seemed good at the time, Football took a very straightforward approach to handling real-mode code that needed access to memory beyond 1 MB: change the selector bases. In V86 mode. That’s of course not possible. The 386 processor enforces real mode segmentation semantics when entering V86 mode, either through an IRET or a task switch. That’s where the 386 LOADALL comes in—Football changes the selector bases and (in protected mode) uses LOADALL to get back to V86 mode, essentially violating Intel’s V86 design.
So only 386 CPUs can run DOS sessions in Football. That’s still not the end of Football’s problems. Because it’s a proof-of-concept project that was only ever written for and tested on a single machine type (the original 16 MHz Compaq DeskPro 386), it takes certain shortcuts.
Football includes rudimentary virtualization of the EGA controller. It executes BIOS code in V86 mode and traps hardware accesses. Sadly, it only supports byte I/O instructions (OUT, IN). Many graphics cards, even EGA compatibles, use word I/O to improve performance and reduce code size. Football cannot handle those and crashes miserably.
In other words, Football requires a graphics card that is EGA compatible and only uses byte I/O to access CRTC registers. Unfortunately, ATI’s VGA Wonder-16 and Graphics Vantage/Ultra cards which are EGA compatible on the hardware level have a BIOS which uses word I/O and therefore cannot be used with Football to run DOS sessions—even though they are useful for booting proto-OS/2 without a blank screen.
The bottom line is that Football is very particular about the hardware and only runs on a tiny set of machines that reflect the state of the art as it existed in Winter 1986/87, but not the year before and not the year after.
So is there any way to run Fotball? Yes, for example PCjs can run it through its Deskpro 386 emulation.
The above description of the difficulties involved in getting Football to run on just about anything should give a good impression how much it was a proof-of-concept project, far removed from a commercial product.
To be fair to the Football implementors, some of the problems are a consequence of the simple fact that the 386 market was tiny at the time, with just a handful of models from a few vendors (that was about to change quickly). For example it was not unreasonable to assume that a 386 would be equipped with an EGA card—and that was about to change as well.
The problems with 386 LOADALL cannot be blamed entirely on Microsoft either. After all, that’s what Intel recommended as a replacement for 286 LOADALL. Microsoft couldn’t predict that Intel would remove LOADALL-like functionality from following processors.
Football is not even remotely modular or cleanly architected. Again that’s in part due to its being a quick and dirty project and in part because there was almost no variety in 386 PC compatibles yet. Virtualization of specific devices (EGA, FDC) is intermixed with generic 386 architecture code (especially evident in #GP handler code).
Let’s review some of the major differences from 16-bit OS/2. Football was almost entirely 16-bit code, but was forced to use 32-bit interrupt gates (so that the VM flag, which is in the high word of EFLAGS, could be preserved). It used paging although that probably only had impact on DOS sessions.
As mentioned above, Football used V86 instead of real mode; that means it always stayed in protected mode, removing a major source of instability from the DOS “penalty box”.
Despite fairly major internal changes, the user-visible differences were deceptively small: It was possible to start multiple DOS sessions and DOS sessions could continue running in the background. Of course those might have been rather major changes from the perspective of a typical user.
Won Or Lost?
It is difficult to assess the impact of project Football on OS/2 and the wider PC landscape. It took almost exactly 5 years (late March 1992) until OS/2 2.0 aka Cruiser was released with proper VDM (Virtual DOS Machine) support. The major difference between Football and Cruiser was that the latter supported 32-bit demand-paged applications and wasn’t just a 386-specific add-on to an otherwise 16-bit OS.
In early 1990 (technically Dec 31, 1989) Microsoft released the first OS/2 2.0 (Cruiser) SDK which would have been the closest thing to Football available outside of Microsoft; unfortunately no surviving copies of the beta OS have been found… yet.
Acknowledgements: Big thanks to pcjs.org for providing the footballs to play with.