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.
Updated Football from December 1987
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 panic due to stack mishandling
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.
Implementation
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.
My favorite is the hacks to allow OS/2 1.0 code to be reused. For example, PhysToVirt could have been done by switching from V86 to protected mode instead, but V86 mode code should not even have access to DevHlp in the first place.
Needless to say, Win3.x was a much cleaner design than this. Of course, Cruiser aka OS/2 2.0 was what MS eventually turned into an entire fiasco that I have a bad opinion of.
BTW, I think the “DOSCODE” and “DOSGROUP” segments was still shared among all V86 VMs and protected mode too, right? This would mean that this “source of instability” would not actually be completely removed.
Interestingly, I just checked and even Intel VT don’t allow emulating this. They actually check that “the address must be the selector field shifted left
4 bits (multiplied by 16).”
Football may have had no direct impact but it disproved some of the conventional wisdom as to how a new OS needed to be designed. The method of developing OS/2 by adding virtual machines, memory paging, 32 bit drivers (Pinball’s HPFS386), and finally 32 bit application to a 16 bit OS core was largely repeated during the progression of Windows development from Win 2 to Win 95 in close to the same order.
I’m not sure which part of “proof of concept” was unclear?
It’s pretty obvious why it was in Intel’s own interest to get rid of LOADALL…
@Richard Wells
“The method of developing OS/2 by adding virtual machines, memory paging, 32 bit drivers (Pinball’s HPFS386), and finally 32 bit application to a 16 bit OS core…”
Errr… No really.
Since Windows/386 you had the option to have the whole core code running in 32bit by using Windows 386 enhanced mode. Since Win3.11 you had the option to have core and drivers running in 32bit mode only by using *.386 vxd drivers for all your devices (Network (Bypass realmode netwoks stack components)/FastDisk (Bypass INT13H entirely)/Display (Bypass VGABIOS routines)).
In 386 mode VMM Windows architecture top core code, the VMM and Base VMM Drivers are always 32bit code. In VMM architecture 16Bit code runs as slave code of the VMM. Then isn’t adding 32bit pieces to 16bit core, but the inverse… Very different from OS/2 case.
From OS/2 Museum Windows/386 2.01 article.
I’m not sure which part of the article you’re referring to. With Windows/386 the system ran in protected mode, sure, but it executed almost entirely 16-bit real-mode code (both DOS and Windows). With Windows 3.0, Windows apps moved optionally to protected mode, and Windows 3.1 forced protected mode and added the option to skip disk BIOS. Windows 3.11 added the option to run the filesystem code in 32-bit. The 16-bit code was far from gone in Windows 95, and let’s not forget that there never was much protection (major difference from NT).
If we consider the “core OS” to be memory management, process management, and filesystems, then Windows/386 was absolutely a 16-bit OS. The bits to implement paging and V86 mode were entirely optional. Calling the 16-bit code a “slave” of the VMM is misleading because it’s a slave without which the master can’t start, can’t load new applications, can’t handle devices, and generally can’t do anything users would actually want to do.
I consider Richard’s point valid. 32-bit native application support was the last thing added to DOS-based Windows. And Windows 3.x was no more a 32-bit OS than DOS with EMM386 was.
Which also reminds me of the “Win16Mutex” they used for compatibility with Win16 code too.
@Michal Necasek
Probably you’re right. Since Win95 VxDs are always 32bit code (except initialization code in some of them, which is used mostly to deal with special cases and is discarded once initialization phase ends), and things like…
http://www.yale.edu/pclt/WINWORLD/WFWG311.HTM
(Read “Microsoft spent the first half of 1994 developing a new, modern 32-bit “VxD” version of the TCP/IP support…”)
I’m assuming wrong than [Windows/386]/Win30/Win31/Win311 VxDs are also 32bit mode code. Ofc protected mode isn’t the same as 32Bit mode as you said.
Question would be… Are Win386/30/31/311 VxDs 16bit or 32bit code? If the case is that VxDs in these windows versions are 16bit protected mode code, then Richard’s point is valid as you said. Here with “core code” i’m also meaning memory management, process management, and filesystems, things which are done almost entirely by the VMM in 386 mode of these OSs as you know (Being KRNL386/USER/GDI VxD “clients”, in the same way Kernel32/User/Gdi are NTOSKRNL/NTDLL/WIN32K “clients” in NT OSs).
VxDs has always been 32-bit code as far as I know.
It’s complicated. Windows was certainly not done “by the book” and it doesn’t neatly fall into any sane categories. I believe VxDs have always been 32-bit, but… they are “virtual devices”. They’re not an OS. The thing is that if you take away the 32-bit code in Windows/386 (and even Windows 3.1), you still have a functioning 16-bit OS. On the other hand, if you take away the 16-bit code, you’re left with an inert pile of bits. That does not sound like a 32-bit OS to me.
32-bit filesystems were implemented as an optional component in Windows 3.11. You may be making a mistake of looking at Windows 9x and projecting backwards. The move towards 32-bit was very very gradual. Even Windows 95 was more of a “requires 386” than “32-bit” system.
In the end it’s a bit like RISC vs. CISC. The ends matter, the means much less so. And again, if you want to argue that VxDs make Windows a 32-bit OS then EMM386 makes DOS a 32-bit OS. Most people would strongly disagree with that.
The part of a VXD most people care about is 32-bit. However, there is a real mode 16-bit piece that determines whether the VXD should be installed at all and collects information about the physical hardware. That 16-bit piece is partially responsible for why Windows startup takes some time and why most hardware needs to be active before Windows is loaded.
For those very interested in the topic of VXDs, one of the longer discussions of VXDs is in Dan Norton’s Writing Windows Devices Drivers. Chapters 7-10 are VXD specific plus the sections covering 16-bit drivers have short explanations of how running in enhanced mode alters operation of the 16-bit driver. Disclaimer: I worked for Mr. Norton prior to the publication of the book which may have influenced how I perceived his knowledge.
Another good source of information is “Writing Windows Virtual Device Drivers” by Thielen & Woodruff. That covers VxDs only, not other types of drivers. See here.
I wonder if the source of confusion is the huge disparity between what VxDs could theoretically do and what they actually did as shipped by Microsoft in the Windows/386 and 3.x days. Also worth pointing out is that VxDs are essentially unprotected — because they run in ring 0 and have access to all system structures, a slight mistake quickly brings down the whole system.
Of course, my favorite is the dependence on 16-bit DOS that continued through Win9x because it allowed the Caldera lawsuit to continue.
Pingback: OS/2 2.0 at 25 | OS/2 Museum
>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.
By “impossible”, do you mean “impossible with any current hypervisor or emulator”, or do you mean “completely impossible”?
(I’m having a hard time believing it’s the latter and not the former – you can write an emulator for just about anything if you try hard enough…)
For the purposes of this discussion, a 386 emulator is not “non-386 hardware”. I hope that answers the question 🙂
Ah, OK – so a 386 emulator can run Football. Thanx! 🙂
Thinking about it, at the time of the Compaq Deskpro 386 non-IBM EGA cards existed but only barely.