OS/2 6.304: Finally Complete

Some time ago, I lamented that even though the OS/2 Museum had a good number of disks of the final OS/2 2.0 beta, level 6.304, there wasn’t enough to install the OS, let alone any of the development tools or add-ons (Extended Services, LAN Server).

And now, more or less exactly 30 years after build 6.304 was released (February 1992), an IBM DAP (Developer Assistance Program) CD-ROM turned up with the complete 6.304 disk set, plus Developer’s Toolkit, C Set/2 compiler, Extended Services, LAN Server 2.0 Entry/Advanced, documentation, and a couple of other goodies. IBM also sometimes referred to OS/2 level 6.304 as EEP, or Early Experience Program, and provided a helpful “Product Considerations” booklet.

There was also one surprise: It was possible to install this pre-release of OS/2 2.0 directly from CD-ROM (that was also possible with the Limited Availiability Level 6.177 CD-ROM, but with completely different storage drivers).

As far as I know, OS/2 2.0 was never available on CD-ROM, although IBM shipped OS/2 on CD-ROM with certain PS/2 Ultimedia models. It was only with OS/2 2.1 (1993) that IBM started offering OS/2 on CD-ROM, thought by the time Warp 4 was released (1996), OS/2 was available on CD-ROM only.

When OS/2 6.304 came out in early 1992, CD-ROMs were just starting to ramp up. The trouble was that the market was rather fragmented. There were SCSI CD-ROMs (and IBM sold those), but there were also several proprietary interfaces from Philips, Sony, and others. Even SCSI CD-ROMs weren’t all that standardized before the SCSI MMC (Multi-Media Commands) specification appeared.

The upshot was that even though OS/2 6.304 included CD-ROM support, it was far from certain that a user equipped with a CD-ROM would be able to use it on a non-IBM machine. Even with a “standard” SCSI CD-ROM, the user might need to supply a driver for the SCSI HBA (IBM only shipped drivers for the most common Adaptec 154x/174x HBAs with OS/2, plus a couple of Future Domain models), and that wasn’t enough either; a separate CD-ROM support driver was required, and CDROM.SYS shipped with OS/2 only supported IBM and Toshiba SCSI CD-ROMs.

Continue reading
Posted in CD-ROM, IBM, OS/2, PC history, Pre-release | 3 Comments

Page Too Big

The other day I was able to look at an IBM OS/2 pre-release CD-ROM from early 1992. The CD-ROM appears to have been produced by IBM UK under the DAP (Developer Assistance Program) umbrella.

The CD-ROM contains about 250 MB of data and would have been the perfect medium for distributing the OS/2 pre-releases. The alternatives were either a huge pile of floppies or many days of downloading over a 9,600 bps modem (and filling up one or two typical hard disks in the process).

On the CD-ROM there’s not just the base OS but also a matching pre-release of LAN Server, Extended Services, Toolkit, and C Set/2 compiler. In addition, there’s all product documentation in electronic format—an alternative to many pounds of manuals.

I should add that IBM did ship these pre-releases on floppies, as seen e.g. here. But the full set would have been about 70 floppies, with no documentation. A single CD-ROM would have been vastly cheaper to produce and mail. As for printed documentation, I’m not sure if IBM even provided any; printing reams of manuals that were going to be obsolete in a month or two probably made little sense.

Obviously IBM didn’t ship the documentation as PDFs, because PDF wasn’t available until 1993. IBM also didn’t ship the documentation in PostScript format (Microsoft used that for NT pre-releases), perhaps because not everyone had a PostScript capable printer, but also because IBM already had a format which solved much the same problems as PDF, and it was called AFP.

The documentation was shipped as ZIP archives containing compressed .LIS files. The .LIS files were in LIST3820 format, a form of AFP. Also included on the CD was an IBM “internal use only” program called LP3820 by Ken Borgendale. The LP3820 utility ran under DOS or OS/2, took the AFP .LIS files as input, and printed them on HP LaserJet or PostScript printers, but could also produce plain ASCII files.

Continue reading
Posted in Documentation, IBM, OS/2, PC history | 4 Comments

Xenix 2.2 vs. VGA

The other day I started wondering why certain old versions of 286 and 386 XENIX look a bit weird in emulation:

XENIX 2.2 on a VGA, unable to reprogram fonts

The characters are cut off, because XENIX sets up an EGA text mode with 8×14 character matrix but uses 8×16 VGA fonts.

Investigation showed that the XENIX console driver rather closely follows the inner workings of the EGA BIOS, no doubt because finding out exactly what IBM’s EGA BIOS did was not difficult.

Specifically, text modes normally access memory in EGA/VGA plane 0 where character codes and attributes are stored. Fonts are stored in plane 2 and the video hardware needs to be reprogrammed to let the host CPU access that plane. For whatever reason, the EGA BIOS uses a rather heavy-handed but very straightforward method: It defines two “fake” modes in its internal mode table, namely mode entry 0Bh for color and 0Ch for mono modes. The EGA BIOS simply internally sets mode 0Bh or 0Ch, uploads the font bitmaps, and then sets the real desired mode.

XENIX 2.2 uses the exact same method. If the BIOS does not fill out mode table entries 0Bh/0Ch, XENIX will be unable to program the fonts and the original VGA 8×16 font will remain in place, but there won’t be other ill effects.

So obviously the BIOS could just supply the EGA compatible mode table entries 0Bh/0Ch. And indeed that helps with some XENIX versions, such as 2.2.3c, which now gets the right 8×14 font:

XENIX 2.2.3c properly reprogramming fonts

But oops! With other XENIX versions, such as 2.2.3b, the result is much, much worse:

XENIX 2.2.3b with garbled fonts

Why would that be? Finding out requires a little more digging…

Continue reading
Posted in 286, 386, PC architecture, PC history, VGA, Xenix | 14 Comments

Vague Standards are Trouble

Through the course of time I’ve been going over the IDENTIFY data of various old IDE hard disks. Today I happened to come across a Conner CP30254H drive, apparently made in June 1993 or so.

This is a circa 250 MB drive, but looking at the contents of IDENTIFY words 57-58 (current CHS capacity in sectors), I see the value 2,195,324,935 which just does not look right, as it’d be about a terabyte; completely impossible for a drive without 48-bit LBA support. The drive reports 895/10/55 CHS geometry, so the capacity really should be 492,250 sectors. That’s rather far off from the reported value.

Now, 492,250 decimal is 782DA hex, whereas 2,195,324,935 decimal is 82DA0007 hex. Obviously not a coincidence. So what does the ATA standard say? The ATA-2 standard (1996) is quite clear (section 7.1.15): Some parameters are defined as 32 bit values (e.g., words 57 and 58). Such fields are transferred using two word transfers. The device shall first transfer the least significant bits, bits 15 through 0 of the value, on bits DD15 through DD0 respectively. After the least significant bits have been transferred, the most significant bits, bits 31 through 16 of the value, shall be transferred on DD15 through DD0 respectively.

The Conner drive is clearly doing it wrong. Except… a drive made in 1993 obviously can’t conform to a 1996 standard. So what does the original ATA standard which was finalized (but not yet officially ratified and published) in 1993 have to say about this?

Continue reading
Posted in Conner, IBM, IDE, PC history | 4 Comments

FantasyLand on VGA

In 1984, Joel Gould of IBM Cambridge (that is Cambridge, Massachusetts rather than Cambridge, UK) Scientific Center wrote a demo program named FantasyLand. This demo was meant to show off the capabilities of IBM’s brand new Enhanced Graphics Adapter, or EGA.

The demo was strictly a demo and was never sold. A few years ago, the demo resurfaced and perhaps the best way to experience it is PCjs, because PCjs faithfully emulates an EGA card. That last bit is important.

The FantasyLand EGA demo

I’ve attempted to run the FantasyLand demo on a number of VGA cards and in the end concluded that it cannot run properly. Even though the VGA is in general highly backwards compatible with the EGA, the FantasyLand demo exposes a couple of minor points where that’s not the case.

Continue reading
Posted in IBM, PC hardware, PC history, VGA | 11 Comments

Reconstructing the EGA BIOS

A few weeks ago I had a sudden need to understand certain finer points of the operation of EGA/VGA BIOS. I found common reference materials to be inadequate—they tend to do a good job of documenting the data structures the video BIOS uses, but do not even attempt to explain what those structures are for and how exactly the video BIOS uses them.

Partly it’s IBM’s fault. The technical references covering VGA products did not quite explain everything in detail either. For the EGA, IBM solved the BIOS documentation problem the old-fashioned way—by publishing the complete BIOS listing.

Now, the EGA BIOS listing included a fairly decent documentation of the INT 10H interface as part of the source code itself (IBM had previously done the same thing with the PC/XT/AT system BIOS). Decent documentation but not great. But naturally anyone who needed to know more could just read the BIOS listings! For the VGA, BIOS listings were never published, although the VGA BIOS did not do too much new that the EGA didn’t do already.

For answering my questions, the EGA BIOS listings were sufficient. Except the available documents weren’t terribly well OCRed and thus were difficult to search properly. That is mostly IBM’s fault too—the listings were printed in rather small font. It’s not hard to see why IBM did that: Even at about 130 lines per page, the EGA BIOS runs over 60 pages of dense text!

To avoid any problems with searching the BIOS listings, I decided to reconstruct the source code of the EGA BIOS from the published listings, using the poorly OCRed text as a basis.

Continue reading
Posted in BIOS, Development, Documentation, Graphics, IBM, PC history | 28 Comments

Learn Something Old Every Day, Part IV: Ctrl+Scroll Lock is Ctrl+Break

The other day I tried running NSNIPES, a multiplayer networked game that came with old versions of NetWare. The game worked fine, but I couldn’t get out of it. Esc did nothing, any “usual” combinations like Alt+X, Alt+Q or similar had no effect. So I found the game documentation (because of course it was documented in NetWare reference manuals just like any other program shipped with NetWare), and learned that to quit the game, one has to press Ctrl+Break.

Only pressing Ctrl+Break elicited no reaction from NSNIPES. But then I noticed that pressing Ctrl+Scroll Lock did. So… why is that?

There are really two mostly separate questions. Why does NSNIPES treat Ctrl+Scroll Lock as if it were Ctrl+Break, and why does actual Ctrl+Break not work, or only works very intermittently? Let’s answer that one at a time…

Continue reading
Posted in NetWare, PC architecture, PC history | Leave a comment


After writing about the likely origins of IBM code page 852, I thought I should revisit the homegrown Czech alternative solution, the Kamenický brothers encoding and their keyboard driver. Its existence is well documented, and the so-called (somewhat misnamed) KEYBCS2 encoding even has its own Wikipedia article. The encoding itself lives on in various conversion tables, and utilities to convert text to or from the Kamenický encoding are easy enough to locate. Sometimes the encoding is also called MJK—the initials of its authors, Marian and Jiří Kamenický.

But finding the actual KEYBCS2 utility turned out to be ridiculously difficult. I scoured the Internet for it. I could not find it. At all. I found a fair amount of text talking about it, but not the actual utility.

In desperation, I started searching my NAS. I must have had the utility in the early 1990s, but after I switched to primarily using OS/2 in the mid-1990s, the DOS keyboard driver wasn’t all that useful, and OS/2 had its own reasonably well functioning support using CP852 (compatible with the built-in DOS support).

After much searching, I found an archive with KEYBCS2.EXE dated 07/27/90 on my NAS. Sadly, all my attempts to run it ended up in failure:

What is this nonsense?!

Obviously I was not trying to debug the program, but I was forced to do so.

Continue reading
Posted in DOS, I18N, IBM, x86 | 29 Comments

Where Did CP852 Come From?

In the 1990s, a lot of my documents were written in code page 852 (CP852), also known as PC Latin 2. This code page is sometimes called “Eastern European”, which is a bit misleading, given that it does not cover major Eastern European countries like Ukraine; sometimes it is also called “Slavic”, which is no less misleading because it covers languages like Hungarian or Albanian that aren’t remotely Slavic.

In those days, fighting with code pages was a constant source of annoyance and pain. DOS and OS/2 used CP852, Windows used CP1250, and Unix/Linux used ISO 8859-2. Of course these code pages were all incompatible with each other. The worst problem was early web where content was often offered in some 8-bit encoding but with no hint as to which encoding that might have been (let’s play a guessing game!). It is a real shame that UTF-8 hadn’t come a bit earlier.

In the early to mid-1990s the situation was further complicated by several non-standard encodings, like the Kamenický brothers encoding in Czechoslovakia or the Mazovia encoding in Poland. Those encodings originated in the mid-1980s and tended to preserve most of the CP437 semi-graphic characters; code page 852 did not, on the other hand it covered quite a few languages. Users initially preferred the non-standard national encodings because those worked better for them, but built-in operating system support pushed those out.

And now I started wondering: When did CP852 become available to users, and where did it actually come from? The first question can be answered reasonably accurately, while the second remains unclear.

Continue reading
Posted in DOS, I18N, IBM, Microsoft, OS/2, PC history | 47 Comments

XMVM Surgery

Last week I was prompted to take a look at the Intel Code Builder compiler from 1991, a 32-bit compiler targeting 386 extended DOS and shipping with its own DOS extender. It is what one might call an extremely obscure compiler; it had to compete with established offerings from MetaWare, Watcom, or Zortech, and soon also with the compiler heavyweights Borland and Microsoft.

One of Code Builder’s very few claims to fame is that early alpha releases of id Sofware’s DOOM were built with Intel Code Builder 1.1, before id switched to Watcom compilers for the DOS releases of DOOM.

There is one poorly preserved archive of Code Builder 1.0 available. As others have noticed, it won’t even build the trivial hello world program that comes with it:

Linker error caused by missing XMVM

There should be a file called XMVM installed with Code Builder, but it’s just not there. Since it is required by default for linking of 32-bit executables, nothing works unless the /XNOVM switch is passed to the compiler/linker.

The OS/2 Museum happens to have an archive of the Intel 386/486 C Code Builder Kit v1.0 installer which clearly explains why the other copies have no XMVM file. It is in the installer archive… corrupted, and cannot be uncompressed:

XMVM is missing because installer was corrupted

The compiler can be installed, but the XMVM file will be missing.

But wait! If the XMVM module is linked into executables produced by Code Builder, perhaps there is a way to recover it from Code Builder itself?

Continue reading
Posted in 386, Development, Intel, PC history, Software Hacks | 10 Comments