It Was a Problem Back in the Day

Posted on May 19, 2021 by Michal Necasek

Several years ago, I found out the hard way that old versions of DOS have trouble with hard disks with more than 17 sectors per track. To recap, DOS versions older than 3.3 may hang when booting from a hard disk with more than 17 sectors per track, but the exact behavior is somewhat complex.

Old DOS versions required IO.SYS to be contiguous and attempted to load it with a single disk read if possible, but perhaps to keep the code size small, the loading code isn’t very sophisticated and reads sectors from the beginning of IO.SYS until the end of the disk track. With 17 sectors per track, there can never be a problem. With lots of sectors (more than 30 can be a problem) DOS can hang, but the behavior depends on exactly where IO.SYS begins relative to the end of the disk track it’s on. Even on a disk with maximum (63) sectors per track, old DOS versions may boot fine if IO.SYS is sufficiently close to the end of the track.

A 1990 Western Digital WD1007V-SE2 ESDI Controller

Where exactly IO.SYS is depends on the size of the FAT tables and the root directory size. In practice the root directory size is more or less fixed, but the FAT size very much depends on the size of the DOS partition. Needless to say, the behavior is unpredictable to users and highly undesirable.

The problem was fixed in 1986 or early 1987, which implies that it was already known. Now I have a good idea why it was known.

Continue reading →
Posted in Bugs, DOS, ESDI, Storage | 27 Comments

Installing IBM OS/2 1.0 in a VirtualBox VM

Posted on April 30, 2021 by Michal Necasek

Some time ago I wrote that IBM OS/2 1.0 and 1.1 cannot be installed in a VM due to the way it switches between real and protected mode. At the time I did not realize that there was another obstacle, namely IBM’s use of the undocumented 80286 LOADALL instruction.

For reasons that are not very clear, Microsoft’s editions of OS/2 used 386 instructions since before OS/2 1.0 was released, but IBM’s versions did not. When Microsoft’s OS/2 kernels detected that they were running on an 80386 (or newer) processor, they used 386-specific code to return from protected mode back to real mode. This was faster than the 286 method which required a CPU reset (OS/2 did not utilize the common method which relied on the PC/AT keyboard controller to reset the CPU and instead caused a processor shutdown through a triple fault, inducing a reset that way; the OS/2 method ought to be faster). Microsoft’s OS/2 kernels also didn’t use the LOADALL instruction when running on a 386.

IBM’s OS/2 1.0/1.1 kernels on the other hand didn’t care one bit about running on a 386, at least not on an AT-compatible machine—perhaps because at the time IBM had no AT-compatible 386 systems on the market or even in the pipeline. IBM’s OS/2 1.0 can still run on a 386 or newer CPU, but it requires a bit of help from the machine’s BIOS.

The calming Big Blue logo

The BIOS must properly support software that sets the CMOS shutdown status byte, resets the CPU (either by triple-faulting, through the keyboard controller, or by any other means), and regains control after the reset while minimally disturbing the machine state. That functionality is common enough because it was also used by DOS extenders and many OS boot loaders.

What’s less common is BIOS support for emulating a 286 LOADALL instruction. Even though the 80386 has its own undocumented LOADALL, a 486 or later CPU has nothing of the sort. However, a 386 or later can emulate enough of 286 LOADALL functionality to satisfy common uses of it, which includes things like old HIMEM.SYS, RAMDRIVE.SYS, or OS/2.

The VirtualBox BIOS has had support for LOADALL emulation for a while now, so it should be able to run IBM’s OS/2 1.0. And it is able to run it… but not install. Or not quite. Fortunately there’s a way around it…

Continue reading →
Posted in OS/2, VirtualBox, Virtualization | 18 Comments

Nobody Expects…

Posted on April 14, 2021 by Michal Necasek

…the Spanish Inquisition!

Well, that too, but also nobody expects that a bland, run-of-the mill Novell NE2000 NDIS driver would crash/hang just because it runs on 486 or later CPUs.

I wanted to try the “basic” DOS redirector shipped with Microsoft’s LAN Manager 2.0 (1990) and more or less by a flip of a coin I decided to use the NE2000 NDIS driver that came with the package. Previously I had no trouble with Microsoft’s NE2000.DOS driver shipped with LAN Manager 2.1 and Microsoft’s Network Client 2.0.

But the old LAN Manager NE2000.DOS driver (16,342 bytes, dated 11-19-90, calls itself version 0.31) loaded and then promptly hung as soon as Netbind was started:

Netbind hangs with LAN Manager 2.0 NE2000 driver

At first I naturally suspected some problem with the card configuration or the NIC hardware, but what I found was much more surprising.

The reason the driver hung actually wasn’t related to networking at all. The driver hung in a routine that was clearly trying to detect the CPU type. How can someone screw something so simple so badly? Well…

Continue reading →
Posted in 486, Bugs, Intel, Microsoft | 7 Comments

Was the NE2000 Really That Bad?

Posted on April 9, 2021 by Michal Necasek

Over the last few months I have been on and off digging into the history of early PC networking products, especially Ethernet-based ones. In that context, it is impossible to miss the classic NE2000 adapter with all its offshoots and clones. Especially in the Linux community, the NE2000 seems to have had rather bad reputation that was in part understandable but in part based on claims that simply make no sense upon closer examination.

A genuine Novell NE2000 card (1992) with DP83901

First let’s recap a bit. In late 1986, National Semiconductor introduced the DP8390/91/92 chip set including a complete Ethernet controller, encoder/decoder, and a transceiver. The DP8390 NIC was a relatively simple design, not as advanced as the Intel 82586 or AMD LANCE, but significantly more capable and cheaper than the low-end offering of the era, the 3Com 3C501 EtherLink.

michaln
Posted in 3Com, Ethernet, Networking, Novell, PC history | 16 Comments

MS LAN Manager NDDK Anyone?

Posted on April 2, 2021 by Michal Necasek

For R&D purposes, I would very much like to get my hands on the circa 1991 Microsoft LAN Manager Network Device Driver Kit which was meant to support the development of NDIS 2.0 drivers. While it is obvious that some kind of development kit for NDIS 2.0 drivers must have existed, the exact name is actually known thanks to the Q80562 KB Article.

That same KB Article also mentions MTTOOL, a test tool that sounds very useful, but unfortunately I’ve not been able to find it anywhere. The tool itself would be helpful even without the rest of the kit.

The closest thing I could find is a 1993 NDDK (Network Device Development Kit) that supports NDIS 3.0 drivers for the Windows for Workgroups 3.11 environment. While the NDDK is valuable on its own, it is quite different and not immediately useful because it is oriented towards Windows NT and 32-bit environments, unlike the 16-bit NDIS 2.0 which supported DOS and 16-bit OS/2.

The old LAN Manager NDDK seems to have fallen through the cracks of the post-IBM-divorce chaos at Microsoft. It wasn’t documented in the older Microsoft Programmer’s Library and by the time MSDN was rolled out, the NDIS 3.0 NDDK was current. And because OS/2 had been disowned by then, Microsoft probably saw no need to widely distribute the older NDIS 2.0 kit.

Which is ironic because although NDIS 2.0 development might be finally dead now, it was not a few years ago, with Intel offering an updated DOS network driver package as late as 2019. The newest NDIS 2.0 driver in the set is dated December 28, 2015, which means NDIS 2.0 survived even past the Windows XP era, leave alone Windows 9x or Windows 3.x!

Update (June 23, 2021): Less than 3 months later, the 30+ year old NDDK popped up. It is now available here.

Posted in Development, DOS, Microsoft, Networking, OS/2 | 10 Comments

8237A DMA Page Fun

Posted on March 28, 2021 by Michal Necasek

The other day I was trying to fill a couple of gaps in my understanding of the Intel 8237A DMA controller documentation. I wrote a small testcase that performed a dummy transfer and modified the base address and count registers in various ways, and then examined what happens to the current address and count registers.

I ended up with printing out the current DMA address and count at the beginning and end of the test. I noticed that the current address changed between test runs, which was quite unexpected. No one else should have been using the DMA channel and the current address can’t just randomly change.

8237A DMA is… fun?

The change itself wasn’t random at all: The current address was being set to the base address. That happens when the base address register is written, but I was pretty sure no one was doing that.

After much head scratching, I realized that my own code was triggering the change. I had some trivial code in place to save and restore the channel’s DMA page register, and it was restoring the page register that caused the current base address to change after the last state printout. That was definitely not expected to happen. So why was it happening?

Continue reading →
Posted in Intel, PC architecture, PC history | 5 Comments

Fake vs. Real

Posted on March 2, 2021 by Michal Necasek

After discussing an Adaptec SCSI HBA that was clearly made from recycled parts and likely fake, I wanted to see what a real one looks like. It looks like this:

A presumably not fake Adaptec 39160 SCSI HBA

For reference and for comparison, here’s the sketchy one:

A likely fake Adaptec 39160 SCSI HBA

The PCB is not quite the same (ASSY 1817206-00 vs. 1817206-01) but it’s close enough. The real one has none of the sketchy labeling—it says “CH 2/B” and not “CH 27B” and so on.

Continue reading →
Posted in Adaptec, Fakes, PC hardware | 6 Comments

Diskette Puzzle

Posted on February 25, 2021 by Michal Necasek

Last week the OS/2 Museum received a classic red NetWare box with all sorts of junk inside: PCI and ISA network cards (most Ethernet, one ArcNET), BNC cabling, one or two manuals, and over a 100 floppies, mostly NetWare but also a handful of 3Com driver disks.

There was a mix of 5.25″ and 3.5″ NetWare floppies, the 5.25″ ones in three original NetWare boxes but most of the 3.5″ disks just more or less loose in the big red crate. As I tried to organize the floppies, I quickly realized that it’s not that simple.

At a quick glance, there were floppies from several NetWare sets:

  • NetWare 2.2 on 5.25″ floppies
  • NetWare 3.11 on 5.25″ floppies
  • NetWare 3.11 on 3.5″ floppies, two sets
  • NetWare 3.12 on 3.5″ floppies

Now the difficulty with NetWare is that unlike, say, Microsoft or IBM, Novell didn’t just label all the disks in a box “NetWare 3.11”. There was in fact significant overlap and e.g. many disks were identical between NetWare 2.2 and 3.11, and later between 3.12 and 4.0. Related to that, NetWare didn’t refresh all disks for each update; only the disks that actually needed updating were changed. It was thus standard for a NetWare disk set to contain floppies with several different revisions.

Same or different?

That gets really complicated if you have a pile of disks and no easy way to tell which sets belong together. And it didn’t end there either: Novell shipped various add-on products with their systems, such as Macintosh clients, OS/2 Requesters, backup and mail software, and so on. And again, these were not labeled as belonging to a specific release, because they were to some extent independent.

Continue reading →
Posted in Archiving, Floppies, NetWare | 20 Comments

Complications, Complications

Posted on February 19, 2021 by Michal Necasek

The other day someone asked how hard it would be to modify the Open Watcom linker, wlink, to properly support exports from IOPL segments in OS/2 LX modules. Not terribly hard it turned out, all it needed was to emit a different “bundle type” for exports from IOPL segments. Rather than a regular 32-bit export, it needs to be a special 16-bit call gate export.

A very slight complication is that the 16-bit call gate export is naturally limited to 16-bit offsets, so the linker needs to error out if an attempt is made to export an entry at an offset 65,536 bytes or more into the segment/object. That is easy enough. There are also complications when calling into IOPL segments from the same module, but that’s a separate topic.

When I tried to do rudimentary testing of whether the linker now produces sensible output, I ran into an unexpected problem. For calling into any IOPL segment, in both NE and LX modules, OS/2 uses call gates. The Intel 286/386 call gate mechanism has a provision for the CPU to automatically copy a certain number of parameters (either words or dwords, depending on whether the call gate is 16-bit or 32-bit) when switching stacks. In OS/2, these call gates are always 16-bit, so there are parameter words optionally copied.

The NE and LX executable formats both use the top 5 bits of a flag byte to specify the number of parameter words (those five bits get copied into the CPU-defined call gate descriptor, which also has 5 bits for the parameter count). The Microsoft and IBM linkers (LINK/LINK386), sensibly enough, accept the number of parameter words through the EXPORTS directive.

Now, the Watcom linker already does that too… but things were not adding up. I realized that the Watcom IOPL_WORD_SHIFT macro is not defined as 3 as I expected, but rather as 2. So the number or parameter words in the resulting executable is wrong. Except… hang on a sec.

Continue reading →
Posted in Development, OS/2, Watcom | 2 Comments

SCSI HBA Recycling?

Posted on February 10, 2021 by Michal Necasek

Several weeks ago I bought this Adaptec 39160 64-bit PCI SCSI HBA in order to experiment with different HBAs:

Adaptec 39160 SCSI HBA, perhaps 2007

The motivation was that although I’ve been a happy user of LSI HBAs (SCSI and SAS, PCI and PCIe) based on the MPT Fusion architecture, the Linux driver for the LSI SCSI HBAs is dumb, broken, or buggy, and ignores certain firmware settings. I have several older SCSI drives (early 1990s) which badly fail if the host tries to negotiate wide and/or fast transfers; the drive in some cases resets but usually hangs and must be power cycled.

All that can be avoided if the LSI HBA is set up to not use wide transfers and not negotiate fast transfers for the given SCSI ID. That works well with the LSI HBAs at POST time, but the Linux driver then just ignores the firmware settings and hangs the drive anyway—unlike the LSI Windows driver. So far I have not found any way to convince the Linux kernel drivers not to do that, and after perusing the source code I’m pretty sure there isn’t.

At any rate, I wanted to try an Adaptec SCSI HBA to check if it has the same problem in Linux (spoiler: it doesn’t) and ordered the 39160 pictured above off eBay. This is a nice dual channel HBA and (for an U160 SCSI controller) somewhat unusual for having both 68-pin and 50-pin connectors on the first channel; that feature looked useful.

The HBA I ordered was sold as new and at 10.50 Euro, it was a bargain. It arrived very promptly, in an original-looking Adaptec box, sealed in an anti-stat bag, and included a printed installation brochure as well as a driver CD.

The adapter works fine, and although it exhibits this extremely annoying error in my Intel Stormville board, I have no reason to think that this particular specimen is defective, especially given that the error does not show up on a Supermicro X7DWN+ board.

Whenever I get a new piece of hardware, I like to have a close look at it simply out of curiosity. When it was made? What chips were used? That’s when I noticed that the HBA just does not look like new.

Continue reading →
Posted in Adaptec, Fakes, PC hardware, SCSI | 10 Comments