OS/2 1.1 Improvements

OS/2 1.1 can now run through all its installation diskettes and boot from the hard disk. Unfortunately, it still crashes shortly thereafter, but I'm making progress, and you can finally catch a glimpse of the Presentation Manager desktop.

This release fixed the following showstoppers:

• Calls to conforming code segments could crash
• Restartable faults at CPL < 3 might not restart properly
• AT keyboard commands like 0xED (SET_LEDS) were not supported

The SET_LEDS command is still not fully supported, but at least the keyboard responds now. OS/2 1.1 would quietly hang on boot if the keyboard did not properly respond. No error message, no time-out, nothing.

It's a rather remarkable failure, considering how well IBM's own ROM BIOS normally dealt with such errors, and it brings back vague memories of other, similar kinds of problems we ran into with the keyboard, video, and mouse drivers during OS/2 1.x development.

Since OS/2 1.x was a joint-development project between IBM and Microsoft, OS/2 components were "divvied up" between the companies, and since IBM was in the hardware business (and Microsoft not so much), IBM was responsible for writing most if not all of the OS/2 device drivers. I seem to recall some exceptions, like the AT Serial Port (COM) driver, but that was the general rule.

This work-split had some unfortunate consequences. One consequence was that IBM developers adopted their own coding styles, and decided to write their drivers using a home-grown MASM macro package called "STRUC" -- which not only produced rather bloated code, but probably also lulled IBM into thinking that less-experienced developers could write low-level code by simply using high-level constructs. Well, they certainly could, but I think overall code quality suffered -- as the keyboard driver behavior above suggests.

CGA Graphic Modes on VGA Cards

This release is primarily just a regression fix. When I tweaked the Video component last year to fix a display glitch in Windows 95 that occurred during the creation of MS-DOS windows, I inadvertently broke the detection of CGA graphic modes. As a consequence, whenever a CGA mode was set on a VGA video card, it would enter a confused state.

Setting CGA modes on VGA cards doesn't happen very often, which is why I missed the regression for a while (I really need a regression test suite). I first noticed it running Windows/386 on a VGA, because the Windows/386 splash screen uses video mode 0x06, which is the old CGA 640x200 black-and-white graphics mode.

As for why I had to tweak the Video component in the first place: that's still a mystery. For reasons unknown, the Windows 95 VDD (Virtual Video Display Driver) reprograms the physical video hardware during VM creation, even though the VM is fully windowed at that point, when the Windows Display Driver -- not the VDD -- is in charge of the video card.

Simplified ModRegRM Decoding

Before 80386 support was added to PCjs, the approach to decoding ModRegRM bytes (which I usually just call ModRM bytes) used one generated function per ModRM value. This was optimal for 16-bit processors, because the functions were small, and it was maximally efficient, turning the entire ModRM decoding operation into one table lookup and function call.

However, that approach didn't scale well for 32-bit processors, which had extended ModRM capabilities in both the addressing mode dimension and the operand size dimension. So I've rewritten ModRM decoding as 18 functions. The first 9 are for 16-bit addressing modes, and the second 9 are for 32-bit addressing modes. Within each group of 9, there are 3 for 8-bit operands, 3 for 16-bit operands, and 3 for 32-bit operands. And each group of 3 contains functions for register-source, memory-source, and group-source.

Each of the 18 functions must do additional work to examine the ModRM bits, which makes decoding slightly slower, but it's not really noticeable, and the speed difference didn't justify the additional generated code. So one much smaller file (x86mods.js) replaces a host of other files (x86modb.js, x86modw.js, x86modb16.js, x86modw16.js, x86modb32.js, x86modw32.js, and x86modsib.js).

Aside from all that work for absolutely no feature benefit, a few minor new features did slip into this release as well:

• Automatically removing the diskette "Save" button on mobile devices
• Giving auto-starting machines focus, so that you can immediately begin typing into them

Also, since the last release, I've added several new demos to the Home page, most notably:

• Windows 3.0 (running on an 80286 in protected-mode)
• Windows 3.1 (running on an 80286 in protected-mode)
• Windows 95 (running on an Compaq DeskPro 386)

As discussed in the latest blog post, these demos also run fairly well on mobile devices, too -- iPads and iPhones at least. There are still some issues, but those will hopefully be resolved in the near future, with the addition of PCjs custom soft keyboards.

Disk and Machine Save Support

As discussed on the PCjs Blog, this release makes saving disks and machines much easier:

• Floppy disk images can now be saved to your desktop computer by simply clicking the Save button next to the floppy disk controls. Select the drive first, and then whatever diskette is shown as being "loaded" in that drive will be saved in your local machine's Downloads folder when you click Save.
• Saving the entire state of any existing IBM PC machine is also easy now, thanks to the new Save Machine links. You can choose to save a machine in its initial state, or make changes to any of the machine's disks and then save it. All your changes should be preserved.

Per the PCjs Documentation, it's still possible to create a new machine, by writing your own machine XML file and manually copying all the other pieces, but the new Save Machine links are the best and easiest way to save any existing IBM PC and embed it on any other website.

WARNING: Since this feature is still "hot of the press," there will probably be some kinks to work out. Every browser seems to have its own idiosyncrasies in terms of what can be downloaded and/or how large it can be. It's also quite possible that certain machine features or modifications may not be properly preserved.

If you're having trouble with a particular browser or a particular machine, be sure to let me know, and then try another browser and/or machine.

The Super Bowl (FOOTBALL) Release

This release includes two significant improvements for running the project's OS/2 Prototype Disks:

• Support for parallel ports (see parallelport.js)
• Flush physical page mappings whenever the video buffer is reallocated

With these changes, the OS/2 FOOTBALL Boot Disk runs much better now. Other (non-code) changes in this release are discussed in the blog.

80386 Compatibility Update

This version adds the following 80386-specific features:

• The 80386 LOADALL instruction
• 32-bit segment register writes must modify only 16 bits of memory

along with some important fault-handling fixes, such as the restartability of call gates that perform a stack-switch in which the stack points to a not-present page.

As a result, this OS/2 FOOTBALL Boot Disk runs considerably better now, but there are still some lingering issues (eg, a divide-by-zero error when starting a real-mode command prompt).

LOADALL Fix For OS/2 Pre-Releases

This release includes a fix to the LOADALL instruction that allows early pre-1.0 OS/2 disks to run properly, like this disk from October 1986.

Early OS/2 Support

Early (pre-1.0) OS/2 builds required some changes to PCjs:

• Support for the SysReq key (which early builds used instead of Ctrl-Esc)
• #TS fault generation when a TSS contains a null stack selector

Regarding SysReq, PCjs does not currently map any particular physical key(s) to SysReq. All it supports at the moment is a binding that allows a "SysReq" button to simulate a SysReq key press.

More details about those early OS/2 builds can be found here. There are still some unresolved issues, however, so don't expect those builds to run perfectly yet (if, indeed, they ever ran perfectly).

Machine Configuration Overrides

This release provides the ability to override selected properties of a machine XML configuration file.

For example, if you have a machine that auto-mounts a specific diskette in drive A, and you want to use that same machine on other pages with different preloaded diskettes, you can override the machine's autoMount property, by calling the embedPC() function with a parms object containing a new value for the property you wish to override.

For pages on the PCjs website, that happens automatically whenever an autoMount value is specified in the machines section of the page's Front Matter; eg:

---
layout: page
title: PC-DOS 1.00
permalink: /disks/pc/dos/ibm/1.00/
machines:
  - type: pc
    id: ibm5150-pcdos100
    config: /devices/pc/machine/5150/mda/64kb/machine.xml
    autoMount:
      A:
        name: PC-DOS 1.00
        path: /disks/pc/dos/ibm/1.00/PCDOS100.json
---

That's all there is to it. The path property is required, and it must match the path of a disk image stored in the machine's disk XML file. The name property is optional, and in general, it's probably best to omit name, because if no disk with the same path AND name can be found, the auto-mount operation will fail.

The documentation for the embedPC() function will be updated eventually, along with a list of other machine XML properties that can be overridden in similar fashion.

The Happy 2016 Release

Nothing particularly noteworthy in this release:

• Fixed handling/detection of 615-cylinder disk drive images
• Fixed the PC/XT SW1 switch UI so that the Coprocessor (FPU) switch could be toggled

Which are all changes I would have saved for a more significant release, except that it's time again to update all the current-year strings.

Happy New Year!