Learn Something Old Every Day, Part XVIII: How Does FPU Detection Work?

Posted on March 28, 2026 by Michal Necasek

This post ended up being much longer than originally intended because halfway into writing it, I found that 286 and later CPUs don’t behave the way I had assumed they would…

While investigating a bug related to a program using floating-point math on a 386SX system with no FPU, I started pondering how exactly FPU detection works on 286 and newer CPUs. Although math co-processors became standard some 30 years ago, on old PCs they were an uncommon and expensive add-on, and a 66 MHz 486SX2 would still have a usable yet FPU-less processor in the mid-1990s.

The CPU/FPU interface and FPU detection on the 8086/8088 was discussed before. To recap, the 8086/8087 interface is a little odd because it is in fact a generic co-processor interface. The 8086 was launched in 1978; probably sometime in 1979, the Intel 8089 I/O Coprocessor arrived; the 8087 only appeared in 1980.

The ESC instruction (opcode range D8h-DFh) was used for communication with a co-processor on the 8086. While the CPU didn’t exactly execute the instruction, it had to know how to decode it. The ESC instruction used a standard ModR/M byte to indicate an optional memory operand, which the CPU needed to be able to write to or read from the co-processor.

If there is no co-processor attached to an 8086, the ESC instructions simply do nothing because the co-processor isn’t there to read or write any data. However, the WAIT instruction designed for synchronization will (in a typical 8088/8086 PC design) hang indefinitely because the missing co-processor acts as if it were permanently busy. For that reason, FPU detection must use the non-waiting FNINIT/FNSTSW sequence (or an equivalent) to avoid hangs on 8086-class machines.

Additional information about what things look like from the 8087’s perspective has been recently published.

Continue reading →
Posted in 286, 8086/8088, x86, x87 | 2 Comments

Bitfield Pitfalls

Posted on March 20, 2026 by Michal Necasek

Some time ago I ran into a bug that had been dormant for some time. The problem involved expressions where one of the operands is a bit-field.

To demonstrate the problem, I will present a reduced example:

#include <stdio.h>
#include <inttypes.h>

typedef struct {
    uint32_t    uf1 : 12;
    uint32_t    uf2 : 12;
    uint32_t    uf3 : 8;
} BF;

int main( void )
{
    BF          bf;
    uint64_t    u1, u2;

    bf.uf1 = 0x7ff;
    bf.uf2 = ~bf.uf1;

    u1 = bf.uf1 << 20;
    u2 = bf.uf2 << 20;

    printf( "u1: %016" PRIX64 "\n", u1 );
    printf( "u2: %016" PRIX64 "\n", u2 );

    return( 0 );
}

The troublesome behavior is demonstrated by the lines performing the left shift. We take a 12-bit wide bit-field, shift it left by 20 bits so that the high bit of the bit-field lines up with the high bit of uint32_t, and then convert the result to uint64_t.

The contents of u1 will be predictable. The contents of u2 perhaps not so much. Or more specifically, the resulting value of u2 depends entirely on who you ask.

Continue reading →
Posted in C, Development, Standards | 4 Comments

DOS Memory Management

Posted on February 27, 2026 by Michal Necasek

The memory management in DOS is simple, but that simplicity may be deceptive. There are several rather interesting pitfalls that programming documentation often does not mention.

DOS 1.x (1981) had no explicit memory management support. It was designed to run primarily on machines with 64K RAM or less, or not too much more (the original PC could not have more than 64K RAM on the system board, although RAM expansion boards did exist). A COM program could easily access (almost) 64K memory when loaded, and many programs didn’t rely on even having that much. In fact the early PCs often only had 64K or 48K RAM installed. But the times were rapidly changing.

DOS 2.0 was developed to support the IBM PC/XT (introduced in March 1983), which came with 128K RAM standard, and models with 256K appeared soon enough. Even the older PCs could be upgraded with additional RAM, and DOS needed to have some mechanism to deal with that extra memory.

The DOS memory management was probably written sometime around summer 1982, and it meshed with the newly added process management functions (EXEC/EXIT/WAIT)—allocated memory is owned by the current process, and gets freed when that process terminates. Note that some versions of the memory manager source code (ALLOC.ASM) include a comment that says ‘Created: ARR 30 March 1983’. That cannot possibly be true because by the end of March 1983, PC DOS 2.0 was already released, and included the memory management support. The DOS 2.0 memory management functions were already documented in the PC DOS 2.0 manual dated January 1983.

Continue reading →
Posted in Development, DOS, Microsoft, PC history | 23 Comments

Cracking DXP and SXD

Posted on January 16, 2026 by Michal Necasek

There are situations where software is available only in the form of a floppy image. This goes especially for historic hardware drivers and patches, which were often distributed only in the form of floppy images. This method was quite popular with large OEMs like IBM or Compaq.

Initially, floppy images were distributed as data files, with a separate program required to write them onto a physical diskette. Typically, such programs could only write the image to a floppy and had no ability to extract individual files from the file system on the floppy image (more or less universally the FAT file system). IBM’s LOADDSKF utility is one example of such a program.

Around 1990, someone realized that the program to restore an image onto a physical floppy could be small enough (5-20 KB) that self-extracting floppy images were feasible, similar to self-extracting archives. Compared to the size of a high-density floppy, the size of an self-extracting stub was negligible. Especially for distributing software that fit on 1-2 floppies, it was far simpler to publish 1-2 self-extracting floppy images than to provide a separate utility and documentation how to use it. The self-extracting floppy images also tended to be self-explanatory, and separate documentation was not necessary.

Continue reading →
Posted in Archiving, Development, Floppy Images | 4 Comments

A 100 Year Old Consul Typewriter?

Posted on January 9, 2026 by Michal Necasek

Spurred by a discussion about Polish keyboard layouts, I tried to find more about the history of Czech keyboard layouts. Unfortunately, finding actual documents turned out to be very difficult.

What I did find is that prior to the current Czech keyboard layout standard (ČSN 36 9050, published in 1994), typewriter keyboard layouts were governed by ČSN 17 8151 from March 1974, titled “Psací stroje. Klávesnice s latinkou, česká a slovenská mutace.” (Czechoslovak State Norm 17 8151, Typewriters. Keyboards with Latin keyboard, Czech and Slovak variants.). There was also ČSN 17 8152 specifying Cyrillic layouts (quite uncommon). Computer keyboards, unsurprisingly, tended to closely match typewriter layouts.

Prior to that, since about 1953, typewriter keyboards were specified by ČSN 01 6906 (Czech and Slovak layouts) and ČSN 01 6907 (Cyrillic). These supposedly replaced ČSN 1408 from 1949. I have not been able to find out anything about the content of these standards, or if there was any attempt to standardize Czech typewriter layouts before 1949. I am not even entirely sure that ČSN 1408–1949 really existed.

However, I did remember that my family still owns my grandfather’s typewriter that must have been made sometime before WWII, perhaps in the 1930s. It’s a portable typewriter in a wooden case, and research showed that it is in fact a well known model… mostly.

Image
A 1926 Remington Portable with Czech-German keyboard

The typewriter is quite clearly a Remington Portable No. 2, easily recognizable from the shiny type guards which need to be raised together with the type bars when the typewriter is prepared for operation. Even better, Remington serial numbers are well documented and the typewriter’s serial number (NE61083) indicates that it was made in August 1926, a century ago.

But then there were questions that I had no answers for. Did Remington really make Czech typewriters in the US? If not, how did the typewriter get Czech types? And what’s with the Consul label?

Continue reading →
Posted in Computing History, Keyboard, Typewriter | 33 Comments

NetWare Pure IP on DOS

Posted on December 10, 2025 by Michal Necasek

It is fair to say that Novell struggled with moving from the IPX protocol to TCP/IP. Of course a big part of the problem was that IPX worked extremely well on LANs and IP brought absolutely no advantages for basic file sharing, only additional complexity. Specifically in DOS environments, a major disadvantage of TCP/IP was that it is far more complex to implement and therefore consumes significantly more memory.

But in many corporate and government networks, there was a strong push towards TCP/IP from the early 1990s, greatly accelerating in the mid-1990s when the Internet started becoming popular and very soon, indispensable. TCP/IP support became a requirement which Novell (or Microsoft for that matter) could not stop. And once TCP/IP had a foot in the door, there was understandable pressure to get rid of other protocols.

Novell’s first serious attempt at a solution was NetWare/IP (1993), or NWIP for short. NWIP was an add-on product for NetWare 3.x and later came bundled with NetWare 4.x. The trouble with NWIP was that it was relatively difficult to set up and manage, and heavily relied on DNS.

With NetWare 5.0 (1998), Novell implemented a different solution, often called Pure IP. The design of Pure IP was closer to IPX and used SLP (Service Location Protocol) to let clients automatically find the nearest server, just like classic NetWare did. Clients still needed some way to configure their IP address but by then, DHCP was widespread and unlike NetWare/IP, Pure IP did not need any special DHCP options.

When Novell ported their networking services to Linux in OES, Pure IP was the only option. While “proper” NetWare offered IPX support until the end, OES never did and Pure IP was the only game in town.

Image
SUSE Linux based Novell OES2 server (2005)

Note that Linux did support IPX in the past, and there were IPX-based NetWare clients and even servers.

For migrating existing IPX and NetWare/IP networks to Pure IP, Novell offered IPX Compatibility Mode Driver (CMD) which acted as a bridge between IPX and Pure IP networks. Of course CMD required NetWare and did not run on Linux-based OES.

Continue reading →
Posted in DOS, NetWare, Networking | 29 Comments

Wait here. No, wait here!

Posted on November 11, 2025 by Michal Necasek

While working on a hobby project, I set up an OS/2 MCP2 (Convenience Package 2 for OS/2 Warp 4) virtual machine with a debug kernel and an expectation that I’d reboot the VM a lot. I was disturbed to find that there was a consistent 30-second delay on boot while setting up networking, which accounted for something like two thirds of the VM’s boot-up time.

At first I thought maybe the DHCP client was being silly, or perhaps there could be a bug in the NIC emulation. Upon closer look, it turned out that the delay was happening in the MPTSTART.CMD script, which looks like this:

@ECHO OFF
IF NOT EXIST C:\MPTN\BIN\SETUP.CMD GOTO NBSETUP
INETWAIT 1>NUL
IF ERRORLEVEL 1 GOTO END
CALL C:\MPTN\BIN\SETUP.CMD
:NBSETUP
IF NOT EXIST C:\MPTN\BIN\NBSETUP.CMD GOTO END
CALL C:\MPTN\BIN\NBSETUP.CMD
:END

The referenced SETUP.CMD script does exist on the system, and NBSETUP.CMD does not. The 30-second delay was occurring in the somewhat mysterious INETWAIT command.

Continue reading →
Posted in Bugs, Debugging, OS/2 | 6 Comments

The OS/2 Display Driver Zoo

Posted on October 14, 2025 by Michal Necasek

I have recently explored (again) the possibility of writing a high-res display driver for virtualized OS/2. But I ran (again) into a dizzying array of possible solutions, each with its own advantages and a good deal of drawbacks.

OS/2 display drivers underwent something of a rapid evolution in the 1992-1996 timeframe. The OS/2 Warp 4 DDK comes with no fewer than four significantly different display driver code bases, which reflect this evolution.

Warning: This article is long! It contains notes from research into the evolution of OS/2 display drivers, DDK sample code, and accompanying documentation. Much of the article is something of a signpost, showing where to find what.

OS/2 1.x

In the days of OS/2 1.x, things were simple. Display drivers were 16-bit, written in assembler (out of necessity more than anything else), and there was only one driver model. The drivers for OS/2 Presentation manager (PM, code name Winthorn) were circa 1987 cloned from Windows 2.x display drivers, since the inner workings (bitmaps, patterns, brushes, fonts, ROPs, and all that jazz) were very similar. Like Windows drivers, OS/2 display drivers worked by “compiling” (dynamically constructing) code to implement various drawing functions.

Image
800×600, big enough for OS/2 1.1 command prompt window

OS/2 1.1 (1988) supported device driver interface (DDI) version 1.0, being the first Presentation Manager release. The interface resembled Windows 2.x and was just as ugly.

In OS/2 1.x, the Presentation Manager shell (PMSHELL.EXE) directly linked against the display driver, which had to be named DISPLAY.DLL–much like in Windows 3.x and earlier the display driver had to be called DISPLAY.DRV.

Continue reading →
Posted in Development, Documentation, Graphics, IBM, OS/2 | 31 Comments

Messy Mastering

Posted on September 29, 2025 by Michal Necasek

Large companies like IBM, Microsoft, or Novell typically had a well defined process for releasing software on floppies. More often than not, files were not directly copied onto a physical floppy; instead, a tool was used to create an image of a floppy disk from distribution files, and the image was then sent off for mass duplication.

Quite often, timestamps of files were set to a predefined value when creating the image. That practice is probably as old as timestamps in the FAT file system. PC DOS 1.0 kept track of the date when a file was modified, but not the time of day. PC DOS 1.0 has all non-system files set to a 08/04/1981 date, although it is theoretically possible that this was a result of normal file manipulation.

Image
A somewhat strange IBM TCP/IP 2.0 for OS/2 Base Kit (1994)

With PC DOS 1.1, there is no ambiguity. The timestamps of all files are set to 12:00:00 on 05/07/1982. Floppy disks are not nearly fast enough to write all those files within two seconds (the FAT timestamp resolution), even in the extremely unlikely case that someone sat there waiting until exactly noon to start the operation. It is a given that IBM artificially set the timestamps of all files to match, and that was before the PC was even a year old.

It is notable that Novell followed a different strategy and strictly kept the original timestamps of shipping files. It was common that different releases had some files with matching timestamps and some files different. One could be reasonably confident that two files with the same name and timestamp were in fact identical. That was not always the case with IBM or Microsoft, where two files with different timestamps were often identical. And in rare cases, two different versions of a file were distributed with the same timestamp, arguably completely defeating the purpose of timestamps.

Continue reading →
Posted in Archiving, Floppies, IBM, Kryoflux | 20 Comments

8×19 Text Mode Font Origins

Posted on August 15, 2025 by Michal Necasek

I was recently made aware of something that I had noticed before, but never paid much attention to. Consider this screenshot of a BIOS POST screen:

Image
Intel AN430TX board POST screen

VGA text modes usually use 720×400 resolution and 8×16 fonts (expanded to 9×16). The above screenshot uses 640×480 resolution (VGA graphics), but it is with a high degree a certainty a text mode, using a custom 8×19 font. The BIOS is a Phoenix BIOS 4.0 Release 6.0, running on an Intel Anchorage (AN430TX) board.

For the sake of clarity: The screenshot was taken by digitizing the analog VGA output of a physical AN430TX board with an integrated ATI Rage 3D graphics chip. The VGA connector was plugged into a Lantronix Spider KVM, which was used to save the screenshot. It is not a screenshot of an emulated system.

Some of the earliest examples of boards with an 8×19 font were reportedly Intel Anchorage AN430TX (see above) and Intel Atlanta AL430LX (one of the first AGP-capable boards), both released in 1997. These were probably the first boards using Phoenix BIOS after Intel had been using AMI BIOS for several years, a fact which may or may not be relevant.

Continue reading →
Posted in BIOS, Computing History, Intel | 39 Comments