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

Nehalem and 4 Gbit DDR3

Posted on February 5, 2021 by Michal Necasek

While discussing Intel desktops with DDR2 memory using 2 Gbit technology (4 GB UDIMMs), the question of Intel’s next generation and 4 Gbit DDR3 (8 GB UDIMMs) came up. It’s more or less the next iteration of exactly the same problem.

I decided to focus on the LGA1366 platform which was the first post-Core 2 generation and Intel’s first platform that used exclusively DDR3 memory (recap: later Core 2 chipsets supported both DDR2 and DDR3). Reviewing Intel’s documentation turned out to be… confusing.

The datasheet for the first generation Bloomfield Core i7 (45nm Core i7 LGA1366, Nehalem microarchitecture) says that DDR3 “512Mb, 1Gb, 2Gb, technologies/densities are supported”, 24 GB RAM maximum. The memory controller in the CPUs could handle 6 DIMMs, and with 2 Gbit technology/4 GB UDIMMs, that obviously results in 24 GB maximum.

Can this 2008 desktop CPU support 48 GB RAM? Intel says no…

The datasheet for the follow-up Gulftown processors (32nm Core i7 LGA1366, Westmere microarchitecture) does not state what technologies or memory limits are supported. It was not hard to find reports of people using Westmere generation LGA1366 CPUs with 48 GB RAM so I started digging further.

I only have one desktop LGA1366 board that could possibly take 48 GB RAM, Intel’s own DX58SO2 (Smack Over 2). That’s where it gets interesting. The DX58SO2 Technical Product Specification clearly says 24 GB maximum. But the DX58SO2 Product Brief just as clearly says “Maximum system memory up to 48 GB using 8 GB double-sided DIMMs.” Who do you trust, Intel or Intel? Could they be both both wrong?

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

The Phantom Intel GM47 Chipset

Posted on February 2, 2021 by Michal Necasek

I spent a bit of time recently putting together technical documentation for Intel’s 4-series chipsets, partly motivated by research into Intel’s support of 4 GB DDR2 memory modules, partly driven by idle curiosity about one of Intel’s many hyped up and failed projects, Turbo Memory.

There are plenty of mentions of the Intel GM47 chipset. And that Turbo Memory article explicitly says that Intel’s Turbo Memory 2.0 is available on the Cantiga GM47 chipset as announced by Intel on July 15, 2008. Although the phrasing in the Wikipedia article may be misleading in that Turbo Memory 2.0 was probably available on the Cantiga (Mobile 4 Series) chipset and not just GM47. of course there’s no reference given for the statement… so who knows.

At any rate, there were certainly rumors that GM47 was to be released in 2008, and then in Q1 2009. But then 2009 came and there was no GM47 chipset. It appears to have gotten Intel’s typical second-class burial—a decree comes from up on high, the victim product is no longer mentioned, must not be spoken of, and references to it are scrubbed. Thus GM47 is notable only by its absence, say, here on Intel’s ark, or in the Mobile 4 Series Chipset Specification Update.

Perhaps the somewhat confusing status of the GM47 chipset’s existence is what led to curious statements like the one in this Italian Wikipedia article. “Cantiga (the 4-series mobile chipset) is marketed in three variants: GM47, GM45, GS45, PM45.” Now which one of the four listed was not actually marketed?

Continue reading →
Posted in Intel, PC history, PC press | 7 Comments

DDR2 4GB DIMMs

Posted on January 29, 2021 by Michal Necasek

Last week the OS/2 Museum got its first ever set of real (i.e. not fake) 4 GB DDR2 desktop (unbuffered) DIMMs, a pair of Samsung 4GB PC2-6400U modules. Such modules are quite rare and correspondingly tend to be unavailable at a reasonable price. Moreover there is a lot of fake “AMD only” modules. But why are the real DDR2 4 GB UDIMMs so rare?

The short answer is “because they’re almost useless”.

The long answer is that DDR2 modules based on 2 Gbit memory technology became available too late in the DDR2 life cycle, which led to such modules being rather poorly supported. They are not unsupported—there are DDR2 boards which not only accidentally happen to work with such modules but where the manufacturers officially support them.

A case in point is the Intel DQ45CB board. It came out in mid-2008 and when it was released, it did not list 4 GB modules as supported, most likely because they weren’t available. The board has four memory slots and it was initially specified to support up to 8 GB memory maximum (with four 2 GB modules). Sometime between April 2009 (specification update E53961-004US) and May 2010 (specification update E53961-006US), Intel officially changed the board’s specification to support up to 16 GB RAM when using 4 GB DIMMs based on 2 Gbit memory technology.

SPD for Samsung 4 GB DDR2 UDIMM (Intel DQ45CB board)

Obviously at that time DDR3 RAM was already available. In fact the same Intel Q45 chipset supports both DDR2 and DDR3 (though any given board would naturally only support one or the other type). This led to some curious situations; the above mentioned Intel DQ45CB board eventually supported up to 16 GB DDR2 memory, but the “better” DP45SG board from the same generation used DDR3 memory and never (at least officially) went beyond 8 GB maximum memory support.

Continue reading →
Posted in DDR RAM, Fakes, PC hardware | 21 Comments

Booting Windows XP, Or Not

Posted on January 22, 2021 by Michal Necasek

For a number of years now I’ve been using a SATA SSD with a “portable” Windows XP installation on it. Portable in the sense that it was capable of booting on a number of my machines, either in IDE mode or in some cases, in AHCI mode. But not anymore—now it no longer booted on some boards either in IDE or in AHCI mode, and failed with everyone’s favorite, bug check 0x7B (INACCESSIBLE_BOOT_DEVICE). I couldn’t make heads nor tails of it; it still worked perfectly fine on a number of boards, but on some it just wouldn’t boot.

I suspected that this was triggered by my failed attempts to get the XP install booting on my DX79SR Stormville board in AHCI mode. In the end I concluded that it couldn’t be done, but not before I tried installing several different AHCI drivers; to be clear, those drivers did make a difference—they made the OS crash at boot-up with bug check 0x7E (completely different from 0x7B and indicating a buggy driver). The Stormville board has a somewhat uncommon IDE/AHCI chip (related to the C600 chipset rather than any Intel desktop chipset) and it was released late enough (2011) that XP support was not provided.

After my failed experiments, I was no longer able to boot on the Stormville board even in IDE mode. I was also no longer able to boot that XP install on an older Intel D975XBX2 (Bad Axe 2) board, which previously worked fine in AHCI mode. But now it just sulked and gave me INACCESSIBLE_BOOT_DEVICE in both IDE and AHCI mode.

I attempted various fixes including a number of attempts of fix_hdc from Hiren’s boot CD. It did something, but that definitely did not include getting rid of the INACCESSIBLE_BOOT_DEVICE bug checks.

In desperation, I hooked up the XP install to a kernel debugger. It was already set up for kernel debugging (not that it would have been hard to do) and the Bad Axe 2 board is old enough to have a real serial port on the back panel. I booted up with the SATA controller in AHCI mode and kernel debugger attached. What the kernel debugger told me was odd.

Continue reading →
Posted in Debugging, PC hardware, Windows XP | 16 Comments

Seek and Ye Shall Find…

Posted on January 20, 2021 by Michal Necasek

…in the strangest places!

Lately I’ve been digging up marketing materials related to Intel’s desktop boards (I’ve long been toying with the idea of writing up a brief history of the circa 10 years of Intel Extreme Series boards).

There is no real archive of the information but random PDFs from years ago pop up in various places, most often various computer resellers around the world, sometimes academic institutions. But this Intel desktop board product matrix from 2004 really takes the cake—check out the URL. It is not fake.

Also note that this is the only copy of said PDF (Intel Confidential!) on the web. It only survived because of Al Qaeda and CIA. $DEITY sure works in mysterious ways.

Posted in Archiving, Intel, PC hardware, PC history | 2 Comments

It’s In Style Now

Posted on January 10, 2021 by Michal Necasek

Retrocomputing has now made it to the Style section of the New York Times. There is nothing particularly new about the article, except where it appeared. I guess people have noticed that retrocomputing is a thing, and that old gear is quickly turning into collectibles.

For my own part, I was very lucky that the OS/2 Museum acquired some equipment before retrocomputing was a thing. For example PS/2 machines are now worth hundreds of dollars, and I got a few at a time when shipping cost more than the machine.

These days, I find that prices of 5-10 year old server gear can be surprisingly low, although high-end desktop boards and CPUs still sell for surprisingly high prices (Core 2 Extreme, Core i7 Extreme) that never dropped down enough to reflect their actual practical value. Interesting times.

Posted in PC history, PC press | 10 Comments

Disabling Quick Edit Mode

Posted on December 18, 2020 by Michal Necasek

Last week I decided to finally solve a minor annoyance that’s been pestering me since I switched my main development machine from Windows 7 to Windows 10 over a year ago. As it is with these things, a certain threshold of pain needs to be reached before delving into the unknown, because one never knows how many rabbit holes it will lead to.

The problem: Every now and then, I use the Open Watcom tools, often for cross-development to DOS or OS/2. When I do that, I tend to use the console-based tools, including the vi editor and wd debugger, in part because they work the same across platforms. Both tools can work with a mouse, and especially the debugger is just much productive when used with a mouse. On Windows 7, that works fine. Not so much on Windows 10, because instead of sending mouse events to the application, Windows tries to select text in the console window. Not helpful:

Quick Edit Mode makes the mouse unusable for a console application

Anyone who has fought with this problem probably knows the answer: Quick Edit Mode. When Quick Edit is enabled, mouse selects text from the console window, Enter copies, right-click pastes. Great for a shell, much less so in a mouse-driven text mode UI. On Windows 10, Quick Edit mode is on by default, and that is what caused me grief.

Continue reading →
Posted in NT, Undocumented, Watcom | 22 Comments