IDENTIFY ESDI DRIVE

Posted on May 25, 2022 by Michal Necasek

As previously mentioned on this site, the IDENTIFY DRIVE command in the ATA specification almost certainly first appeared in ESDI controllers supplied to Compaq by Western Digital.

Since I have now finally secured a working ESDI hard disk, I could do some probing. Unfortunately I don’t have access to a WD1005 ESDI controller that should be extremely close to what Compaq used circa 1986, but I have two of its successors, WD1007A and WD1007V. A spare WD1005 anyone?

My WD1007A (1987) clearly came out of a Compaq machine and it is a rather interesting piece of hardware. It is a hard disk controller only, with no floppy support. It also has no BIOS (though other models did, and the PCB clearly has room for it).

The newer WD1007V-SE2 (1989) might be a retail model; it includes a floppy controller and a BIOS, although the BIOS can be disabled since it wasn’t necessary in many PC/AT compatibles.

WD1007A and WD1007V ESDI controllers

Now, what’s very interesting about these WD ESDI controllers is that from a software perspective, they would be very difficult to distinguish from an IDE drive. They support the exact same registers and commands as a standard PC/AT controller, but additionally also implement the IDENTIFY DRIVE command. At least in the case of the WD1007V, the controller also supports READ/WRITE MULTIPLE commands, READ/WRITE BUFFER commands, and probably some form of cache control. In other words, the WD1007V even acts like a not so basic IDE drive.

Now back to IDENTIFY DRIVE. That would have been the big difference between a controller for ST506 style MFM or RLL drives and an AT-compatible ESDI controller. ST506 (or ST412, if you’re Seagate) drives simply have no mechanism to report their characteristics to the controller. But ESDI drives do. Anyway, let’s look at the details…

Continue reading →
Posted in ESDI, IDE, PC hardware, PC history, Western Digital | 20 Comments

The Strange Case of GetEnvironmentStringsA

Posted on May 22, 2022 by Michal Necasek

It was recently pointed out to me that a simple “hello world” style application built with Open Watcom C/C++ 1.9 does not run on Win32s version 1.30, even though the same executable runs just fine on Windows NT 3.51, Windows 95, or Windows 10.

More specifically, the program crashes rather early on Win32s. With the help of map files and source code, I established that the crash occurs in an internal function called __setenvp, which tries to dereference a null pointer stored in an internal variable _RWD_Envptr.

The _RWD_Envptr variable is filled in by the GetEnvironmentStrings API in the C runtime startup code. The GetEnvironmentStrings API call ends up importing GetEnvironmentStringsA from KERNEL32.DLL. And clearly GetEnvironmentStringsA is failing on Win32s, although it works just fine on NT and Win9x.

Further probing revealed that the GetEnvironmentStrings API has curious history. On Windows NT 3.1, there was only GetEnvironmentStrings (no A or W suffix). On all later Win32 implementations, starting with NT 3.5, there’s GetEnvironmentStringsA and GetEnvironmentStringsW, as well as FreeEnvironmentStringsA and FreeEnvironmentStringsW.

On NT 3.1, there was no FreeEnvironmentStrings, presumably because GetEnvironmentStrings returned a pointer to existing memory that couldn’t be freed (and would be freed at process termination anyway). On NT 3.5, GetEnvironmentStringsA converts the strings provided by GetEnvironmentStringsW and allocates memory for the converted strings, so there is something to free.

A quick experiment with Microsoft Visual Studio 4.0 showed that a test application does run on Win32s; reading MSVC 4.0 runtime source code also revealed that Microsoft calls GetEnvironmentStringsA and immediately terminates the process if GetEnvironmentStringsA fails. So… how can that work on Win32s?

Continue reading →
Posted in Development, NT, Watcom | 23 Comments

1989 Networking: OS/2 NetWare Requester 1.1

Posted on May 7, 2022 by Michal Necasek

When I wrote about the pre-release NetWare Requester for OS/2, the oldest archived officially released NetWare OS/2 Requester was version 1.2 from 1990. In the meantime, version 1.1 of the requester showed up, although I only became aware of that very recently.

Technically the 1.1 Requester does not appear to be vastly different from the 1.0 pre-release. Which is unsurprising, because the OS/2 1.1 kernel was not that different from OS/2 1.0; the big news in OS/2 1.1 was the Presentation Manager GUI, but that was not something Novell cared about at the time.

The Requester was shipped on three disks, labeled SYSTEM, PUBLIC-1, and PUBLIC-2. As the names suggest, the PUBLIC-1 and PUBLIC-2 disks were meant to be copied on the server, whie the SYSTEM disk needed to be installed on each OS/2 workstation.

Unlike the pre-release, the 1.1 Requester came with an actual installer, although what it did was a little underwhelming.

NetWare OS/2 Requester installer

The installer copies files but does not actually change CONFIG.SYS at all. Instead, Novell provided a template which can be appended to the existing CONFIG.SYS and edited to enable the desired components (SPX, named pipe support, NetBIOS).

The user also has to pick the right driver. Novell provided a good selection of drivers, for Ethernet (Novell NE1000, NE2000, 3Com 3C501, 3C503, 3C505) as well as IBM PC Network, Token Ring, and Novell RX Net.

Continue reading →
Posted in NetWare, Networking, OS/2, PC history, Virtualization | 11 Comments

Learn Something Old Every Day, Part V: Early IBM PS/2 Hard Disks

Posted on May 1, 2022 by Michal Necasek

So I have been (again) trying to properly archive old MS OS/2 SDKs. The version 1.02 SDK from December 1987 (corresponding to OS/2 1.0) turned out to be a bit of a poser.

The SDK came on both 3.5″ and 5.25″ media (unlike the older 1.00 and 1.01 SDKs, which as far as I can tell only existed on 5.25″ media). My Kryoflux tells me that the Install floppies were modified in both the 3.5″ and 5.25″ disk sets. Now, it’s very common for OS/2 install disks to be modified, because the installer writes an INSTALL.LOG file. But I could find no evidence of that happening.

Instead, it looked like Microsoft made some changes after mastering the disks, but exactly what those changes were is difficult to tell.

On the 5.25″ Install disk, Microsoft almost certainly updated the INSTAID.EXE file (the main installer executable). The allocation chain for INSTAID.EXE is not contiguous, which is a strong hint that it had been overwritten with a larger file. Yet the timestamp for INSTAID.EXE is the same as the other files (12/15/1987) and the entry for INSTAID.EXE is in the middle of the root directory, alphabetically sorted.

Okay, so that makes some sense. Microsoft made some last-minute installer change and had to update the already mastered disks. One might expect to find the same sort of change on both 3.5″ and 5.25″ media… but no.

Continue reading →
Posted in ESDI, IBM, PC history, PS/2 | 18 Comments

OS/2 6.304: Finally Complete

Posted on April 29, 2022 by Michal Necasek

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 | 7 Comments

Page Too Big

Posted on April 22, 2022 by Michal Necasek

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

Posted on April 15, 2022 by Michal Necasek

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

Posted on April 7, 2022 by Michal Necasek

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

Posted on April 3, 2022 by Michal Necasek

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 | 16 Comments

Reconstructing the EGA BIOS

Posted on March 19, 2022 by Michal Necasek

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 | 32 Comments