PCLP CSD Hunt

Posted on June 21, 2020 by Michal Necasek

Not long ago the OS/2 Museum acquired a boxed copy of the IBM PC LAN Program (PCLP) version 1.3 (1988) on 3.5″ floppies. The IBM PC Network Program (1985), later renamed to the IBM LAN Program, was IBM’s first PC LAN networking software, notable for using NETBIOS and the SMB protocol. Because of its reliance on the NETBIOS software interface, PCLP survived the transition from the original IBM PC Network hardware to Token Ring and later to Ethernet (“later” because IBM supported Token Ring first, not because Token Ring is older than Ethernet).

Rather unusually, it is easy to find a copy of the original PC Network Program and PC LAN Program 1.1 online, but not version 1.2 or the last one, 1.3. PC LAN Program 1.3 is notable for being sold by IBM until 1997 and overlapping with the OS/2 LAN Server in the market. In fact either the DOS LAN Requester shipped with LAN Server or PCLP 1.3 could be used as a LAN Server client.

PCLP 1.3 is also significantly different from the earlier PCLP releases in that it can still be used as a more or less unstructured peer-to-peer network, but also supports “Extended Services” with domains, dedicated servers, user logons, and remote booting (RPL/RIPL) of diskless workstations. At $225 (or $90 upgrade), PCLP 1.3 was not even all that expensive.

The catch with PCLP 1.3 is that came out in 1988, very shortly after DOS 4.0. It supports DOS 3.3 or 4.0 servers and workstations. Now the problem is that DOS 3.3 (at least IBM’s) only supports 32MB partitions, and DOS 4.0 is a memory hog. PCLP itself consumes quite a lot of memory and it is next to impossible to start a PCLP server and still run the user interface required to manage it (the interface can be also run remotely, but that’s an extra inconvenience):

The obvious solution would be to run PCLP 1.3 on top of DOS 5.0 with UMBs. But of course that does not work out of the box because PCLP is too tightly integrated with DOS (notably using the DOS 4.0 IFS interface which is not present in DOS 5.0). And, of course, given that PCLP was sold into the mid-1990s, IBM did have updates that made PCLP 1.3 compatible with DOS 5.0, and the updates are even mentioned in the IBM DOS 5.0 announcement letter. It is finding those updates that turned out to be nearly impossible.

Continue reading →
Posted in Archiving, IBM, Networking, PC history | 9 Comments

Those Win9x Crashes on Fast Machines…

Posted on June 2, 2020 by Michal Necasek

It is well known that Win9x variants prior to Windows 98 have a tendency to crash on fast CPUs. The definition of “fast” is of course fuzzy but the problems were known to occur on AMD K6-2 processors running at 350 MHz or faster as early as 1998. This led to some acrimony when Microsoft attempted to charge $35 for the fix. The crashes were intermittent on the 350 MHz parts but harder to avoid with faster clock speeds.

The problem soon started affecting other CPUs with higher frequencies, but it didn’t affect Intel processors for a while. Were Intel CPUs somehow better? Not exactly, but there was a reason for that; more about it later.

I have been long aware of this problem but never looked into the details. And when I did, at first I didn’t realize it. An acquaintance mentioned that Windows 3.11 for Workgroups no longer works in a VM.

That’s as far as WfW 3.11 would get

After some investigation it turned out that the issue is related to the host CPU. An older Intel i7-2600 host exhibited the crash, but rarely. A newer Ryzen 7 3800X crashed every time. Some unexpected Intel/AMD difference? Well, yes and no…

Continue reading →
Posted in AMD, Bugs, Intel, Microsoft | 26 Comments

Seagate Cheetah Date of Manufacture

Posted on May 12, 2020 by Michal Necasek

Lately I found myself in the possession of several Seagate Cheetah 15K.7 SAS drives. These represent the pinnacle of hard disk engineering; with 15,000 RPM, the drives deliver up to around 200 MB/s sustained throughput (both read and write!) and have average access time approximately 5 milliseconds. They run a bit warm but are surprisingly quiet.

Naturally I’m interested in knowing when the drives were made. But only one of four drives has a clear “DOM: 08/2011” printed on the label:

Seagate Cheetah 15K.7 a Date of Manufacture on the label

The other three drives have nothing on the labels that would clearly identify a date of manufacture:

Seagate Cheetah 15K.7 with no apparent date of manufacture

That is different from most Seagate consumer drives which have a “date code” on the label.

Now, it’s possible to punch the serial number into Seagate’s warranty lookup. But that only works for drives directly sold by Seagate, and two of my drives weren’t (one of them is Dell branded, the other has no other identifiable branding). And even when the warranty lookup does work, it does not determine the actual date of manufacture. For the drive manufactured in August 2011, the five-year warranty expired in November 2016. Since the warranty period starts counting from the date of purchase, it makes sense that it only gives a ballpark estimate—basically if the warranty expired in Nov 2016, the drive was likely manufactured several months prior to Nov 2011.

These Seagate drives do not appear to report the date of manufacture through software (some other drives do), and although Seagate knows exactly what the drives are based on the serial number, the date of manufacture is not shown there either.

But there is one other piece of information on the label—the lot number—that looks like it might include the date of manufacture. Does it?

Continue reading →
Posted in Seagate, Storage, Undocumented | Leave a comment

ThinkPad Audio PnP Hell

Posted on May 4, 2020 by Michal Necasek

The other day I pulled an old ThinkPad 770X (300 MHz Pentium II, good old 440BX chipset, released in late 1998) out of the closet to see if it still works. It does, but I had the terrible idea to get audio support (Crystal Audio CS4239 chip) working in DOS and OS/2. That turned out to be far more difficult than it should have, thanks to Plug and Play.

The laptop has DOS, Windows 98 SE, and OS/2 installed. I never even considered that there might be something physically wrong with the audio chip because it works fine under Windows 98. But it just would not work under OS/2, and when I tried installing audio support in DOS/Windows 3.1, it wouldn’t work either.

The badge on an IBM ThinkPad 770X, circa 1999.
IBM ThinkPad 770X badge

As an aside, the ThinkPad 770X actually has two audio chips: Crystal CS4239, an ISA PnP audio controller with Windows Sound System (WSS) and Sound Blaster compatibility, as well as an OPL3-compatible FM synthesizer. The 770X additionally has a Crystal CS4610 PCI audio accelerator, essentially a DSP capable of multi-channel mixing or MPEG-2 audio and AC3 decoding. The output of the CS4610 chip is routed to the CS4239’s codec. For the problem at hand, the CS4610 is not really relevant as it’s not used by OS/2, Windows 3.1, or DOS.

I tried three slightly different sets of OS/2 Crystal Audio drivers: The ones that came with the OS (MCP2), the ones that Lenovo still kindly offers on their site, and another set from the web. The driver that comes with MCP2 is dated newer than the one from Lenovo (version 2.08), but is in fact an older version (1.x) with a slightly different structure. The set that I randomly downloaded somewhere is a slightly newer version (2.09) of the drivers that IBM/Lenovo provided.

All the OS/2 driver sets have essentially the same problem: They see that a Crystal chip is there, but can’t set it up. The DOS/Windows 3.1 drivers from IBM/Lenovo have that trouble as well, just with slightly different error messages.

A rather bizarre conundrum is the fact that under DOS, Sound Blaster emulation works but not the native Crystal drivers. In practice that means DOS games work with Sound Blaster audio, but the native Windows 3.1 crystal drivers refuse to load. What gives?

Continue reading →
Posted in Crystal Semi, IBM, Sound, ThinkPad | 14 Comments

Memory Trouble in Stormville

Posted on April 18, 2020 by Michal Necasek

The OS/2 Museum recently acquired a genuine Intel DX79SR (Stormville) board. Together with its close siblings DX79SI (Siler) and DX79TO (Thorsby), these were the last “great” Intel motherboards, supporting the big LGA 2011 socket for the Sandy Bridge E platform—but not Ivy Bridge, because Intel treated buyers of its final boards rather poorly and refused to update the board firmware to support Ivy Bridge E CPUs.

The DX79SR is extremely similar to the older DX79SI which it replaced in Intel’s lineup. The only noteworthy differences are that the Stormville adds two additional rear USB 3.0 ports and two internal 6Gbps SATA ports (through an onboard Marvell SATA controller).

A detail shot (voltage regulator heatsink) of an Intel DX79SR destkop board, 2012.
Intel DX79SR board detail

At $299 (price at May 2012 introduction), the DX79SR was a rather pricey board for rather pricey CPUs. Why would anyone want one? Because it was the only way to get a desktop board (from Intel) supporting an Intel CPU with more than four cores and with support for more than 32GB RAM. All “standard” desktop boards for Sandy Bridge and Ivy Bridge platforms (and even for Haswell in fact) were limited to four cores and 32GB RAM.

It is also noteworthy that the board supports not only Sandy Bridge E but also Sandy Bridge EP processors, and can thus run with not just the six-core i7-branded CPUs but also 6-core or even 8-core LGA2011 Xeons, such as the beefy eight-core E5-2687W.

In my testing, the DX79SR coupled with an i7-3930K is an impressive performer, albeit a real power guzzler. The six-core CPU is rated at 3.2 GHz base frequency and 3.8 GHz turbo, but it easily overclocks to 4.6 GHz turbo with air cooling. In multi-threaded workloads, the old Sandy Bridge E can still easily keep up with today’s quad-core CPUs.

That’s all well and good. Unfortunately, getting more than 32 GB (or at first even 32GB) going in the Stormville board turned out to be quite difficult.

Continue reading →
Posted in Bugs, Intel, PC hardware, PC history | 14 Comments

386 Cache Coherency

Posted on April 8, 2020 by Michal Necasek

I’ve been slowly chewing my way through U.S. Patent 5,724,549, titled Cache Coherency without Bus Arbitration Signals, initially filed by Cyrix Corporation in 1992 and published in 1998 (when it was utterly irrelevant, but such is the life of patents).

When Intel designed the 386, it was already well known that an internal (L1) cache is one of the most effective ways to increase processor performance. But given the manufacturing process available at the time, Intel could only squeeze about 512 bytes of cache onto the complex chip, and that was not enough to be effective.

The 386 was designed with external cache (sometimes called L2, although in the case of a 386 there was no L1 cache) in mind and Intel produced its own cache controller for use with a 386, the 82385 (although much like the 80387, the 82385 became available significantly later than the 386 itself).

A classic Cyrix Cx486DLC upgrade processor for the 386 socket, circa 1993.
Cyrix Cx386DLC, 33 MHz

When Cyrix designed the 486DLC upgrade processors for the 386 socket, it was not a problem to put 1K of internal cache on a 386-socket chip, or later even 8K in the case of Texas Instruments 486SXL processors. But keeping the cache coherent was a problem. There were in fact two sources of trouble: External bus masters and our old friend (frenemy?), the A20 gate.

Continue reading →
Posted in 386, Cyrix, PC architecture, PC history | 18 Comments

Linux 2.4 APIC Hang

Posted on March 16, 2020 by Michal Necasek

The other day I set out to install SuSE Linux 7.3 (Linux 2.4.10 kernel) in a virtual machine, primarily with the goal of evaluating if the included MARS_NWE NetWare emulator is any good.

But I couldn’t get anywhere–the boot floppy (or bootable DVD) would just hang. And since SuSE defaults to a graphical boot up, the boot disk would hang with a black screen and absolutely no information.

Soon enough I found out that disabling local APIC support through a Linux kernel argument ‘(disableapic’) gets rid of the hang. And when it did hang, in text mode I could at least see how far it (Linux kernel 2.4.10-4GB) got:

Linux 2.4 hanging on APIC initialization

The “host bus clock speed” is actually the APIC timer frequency. And obviously 0.0 MHz is not right, even though the CPU clock speed is spot on. So how did Linux arrive at the nonsensical number?

Continue reading →
Posted in Bugs, Linux, PC hardware | 16 Comments

OS/2 1.3 on a “Large” Disk

Posted on March 6, 2020 by Michal Necasek

In response to a reader question, I started wondering how difficult it actually is to install OS/2 1.3 on a “big” hard disk, where “big” is defined as more than about 500 MB. In an attempt to reduce the number of potential problems, I skipped IDE and went straight for a SCSI setup, using an (emulated) BusLogic SCSI HBA with a 6 GB hard disk.

The short story is that it can be done, but it’s not entirely trivial:

OS/2 1.3 managing a 6 GB disk

MS OS/2 1.3 does not include a driver for the BusLogic HBA, but BusLogic provided one. The driver can be had for example from here, or from the vendor here (the “vendor” now being Broadcom, where BusLogic ended up after a string of acquisitions (BusLogic to Mylex to LSI Logic to Avago/Broadcom).

Installing the driver is easy enough; the file SPARE001.SYS needs to be copied from the archive to the OS/2 boot floppy. The virtual disk created by the OS/2 installer can be used for file exchange. I used the Installation Diskette B, but I believe Diskette A could have been used just as easily. Note that after the OS is installed, the driver has to be manually copied to the root directory of the boot drive, otherwise the installed OS cannot boot.

Continue reading →
Posted in BusLogic, OS/2, PC history, Storage | 16 Comments

EMM386 and VDS: Not Quite Working

Posted on February 26, 2020 by Michal Necasek

The other day I set out to solve a seemingly simple problem: With a DOS extended application, lock down memory buffers using DPMI and use them for bus-mastering (BusLogic SCSI HBA, though the exact device model isn’t really relevant to the problem).

Now, DPMI does not allow querying the physical address of a memory region, although it does have provisions for mapping a given physical memory area. But that doesn’t help here–mapping physical memory is useful for framebuffers where a device memory needs to be mapped so that an application can access it. In my case, I needed the opposite, allowing a bus-mastering device to use already-allocated system memory.

As many readers probably know, VDS (Virtual DMA Services) should solve this problem through the “Scatter/Gather Lock Region” VDS function. The function is presented with a linear address and buffer size, and returns one or more physically contiguous regions together with their physical addresses.

I already had VDS working for low (DOS) memory, but I just could not get it working for “normal” extended memory. It did not matter if I used statically allocated variables placed in the executable, C runtime malloc(), or direct DPMI memory allocation functions. The VDS call succeeded and filled the result buffer with the same address I passed in, indicating a 1:1 linear:physical mapping, except the memory definitely was not mapped 1:1. So bus-mastering couldn’t work, because the addresses I programmed into the adapter were bogus. But why was this happening?

Continue reading →
Posted in Bugs, Development, DOS Extenders | 2 Comments

A Brief Visit to Disk Geometry Hell

Posted on February 20, 2020 by Michal Necasek

Several weeks ago I thought I’d install NetWare 3.12 in a virtual machine using the BusLogic SCSI controller emulation. While configuring a 1.5 GB virtual drive, I thought I should be safe and not run into any trouble with a “too big” disk.

But I was wrong. The NetWare 3.12 installer created the DOS partition and launched the NetWare OS, but trying to create a NetWare partition resulted in the following error:

NetWare 3.12 reporting an error when attempting to create a NetWare partition, caused by a geometry mismatch between the BIOS and driver.
NetWare 3.12 upset by a geometry mismatch

This error is naturally not specific to virtualization and happens on real systems as well. But why? The geometry of a SCSI disk is entirely fictional, so why is it a problem?

Continue reading →
Posted in BusLogic, IBM, NetWare, PC architecture, Storage | 32 Comments