386MAX and EISA DMA

Posted on September 28, 2023 by Michal Necasek

A few weeks back I was reminded that the source code to the 386MAX (later Qualitas MAX) memory manager was released in 2022 on github. Back in the 1990s I used primarily EMM386 and QEMM, but I have some experience with 386MAX as well. It’s quite comparable with QEMM in terms of features and performance.

The source code itself is quite interesting. The core memory manager is of course written 100% in assembler. However, it is very well commented assembly code, written in uniform style, and it generally gives the impression of a well maintained code base (unlike, say, MS-DOS).

The github release also includes enough binaries that one can experiment with 386MAX without building a monster code base.

Qualitas MAX 8.03 booting up

I was able to get enough of it installed to have a functional 386MAX setup. Then I thought that for easier experimentation, perhaps I should set up a boot floppy with 386MAX. And that’s where trouble struck.

Continue reading →
Posted in 386MAX, DOS, EISA, Source code | 11 Comments

Learn Something Old Every Day, Part IX: AHA-154xB and ASPI4DOS.SYS

Posted on August 31, 2023 by Michal Necasek

The other day I had a pressing “need” to examine the behavior of Adaptec 154x and compatible SCSI HBAs and their DOS drivers. I found the hard way that the AHA-154xB does not work with Adaptec’s last DOS drivers from circa 1999. That includes the drivers still available for download (ASPI4DOS.SYS version 3.36), as well as the driver shipped with OEM versions of Windows 98SE (ASPI4DOS.SYS version 3.36S).

The error message is far from enlightening; effectively the driver acts as if there were no HBA at all.

ASPI4DOS.SYS 3.36 and AHA-154xB don’t like each other

Quite unsurprisingly, this problem has been noticed before. It has been also observed that ASPI4DOS.SYS version 3.35 works fine, as do older versions. But why is the 3.36 driver really not working with AHA-154xB?

Continue reading →
Posted in Adaptec, Bugs, BusLogic, SCSI | 6 Comments

Learn Something Old Every Day, Part VIII: RTFM

Posted on August 22, 2023 by Michal Necasek

In my quest to understand the intricacies of x87 behavior and especially floating-point exceptions, I pulled out my trusty old Alaris Cougar board. The system board had a 100 MHz Intel OverDrive 486 DX4 plugged in and worked quite well. I could run applications, edit and compile programs, copy files to and from network, run Windows 3.1, that kind of stuff. No problems really.

Intel 486 DX4-100 OverDrive processor

But when I tried to test how floating-point exceptions behave, I had a bit of a shock: They didn’t happen at all. The machine just blazed through any and all code that was supposed to trigger FPU exceptions without a second glance. There was just nothing, no exceptions.

In an attempt to isolate the problem, I removed the DX4 OverDrive and used the onboard Blue Lightning CPU with the already installed 387 coprocessor (actually a rare Chips & Tech 387 but that doesn’t really matter). Lo and behold, math exceptions did work.

So I unplugged the 387 and put the DX4 OverDrive back. Sure enough, that did change things… but not exactly in a good way. Now any math exception hung the system instead!

Trying to obtain further data points, I plugged in a Pentium OverDrive instead of the DX4. To my great surprise, math exceptions suddenly worked properly. They did get delivered as expected and did not hang the system.

Trying to make sense out of this, I wondered if the board’s manual might perhaps have some useful information…

Continue reading →
Posted in 486, Documentation, Intel, PC hardware, x87 | 9 Comments

This Code Smells of Desperation

Posted on August 5, 2023 by Michal Necasek

A few weeks ago I had the questionable pleasure of diving into the math exception handler of WIN87EM.DLL, the Windows 3.1 math emulator and FPU support library. Actually WIN87EM.DLL appears to have been first shipped with Windows 3.0, and the version in Windows 3.1 is more or less identical. The version shipped with Windows 3.11 is byte for byte identical to the one in Windows 3.1.

The main function of WIN87EM.DLL is, as the name suggests, an x87 floating-point emulator. It appears to be an outgrowth of the math emulation packages shipped with many Microsoft languages. But even on a system with x87 hardware, WIN87EM.DLL has some work to do.

Namely WIN87EM.DLL intercepts math errors (exceptions). Depending on the system type, WIN87EM.DLL hooks either NMI vector 2 (PC and PC/XT) or IRQ 13 (PC/AT and compatibles).

The math interrupt handler in WIN87EM.DLL is very, very strange. It bears all the hallmarks of code that was written, rewritten, rewritten again, hacked, tweaked, modified, and eventually beaten into submission even if the author(s) had no real idea why it finally worked.

Continue reading →
Posted in Bugs, Microsoft, PC architecture, x87 | 20 Comments

Retro-Porting to NT 3.1

Posted on July 26, 2023 by Michal Necasek

In another useless project, I decided to find out why even trivial programs created with the Open Watcom compiler refuse to run on Windows NT 3.1. Attempting to start an executable failed with foo.exe is not a valid Windows NT application. But this time, the surgery was successful.

Failure and success running on NT 3.1

There turned out to be several problems, some related and some not. The biggest issue was the problem previously discussed in this post. To recap, the Open Watcom runtime calls the GetEnvironmentStringsA API, which does not exist on NT 3.1. This also causes trouble on Win32s; although newer Win32s versions do implement GetEnvironmentStringsA, it just always fails.

The solution is to use the original GetEnvironmentStrings API (which is equivalent to GetEnvironmentStringsA) . But that’s not enough.

Continue reading →
Posted in Development, Microsoft, NT, Watcom | 12 Comments

Retro-Porting to OS/2 1.0

Posted on July 20, 2023 by Michal Necasek

A few weeks ago I embarked on a somewhat crazy side project: Make the Open Watcom debugger work on OS/2 1.0. This project was not entirely successful, but I learned a couple of things along the way.

The Open Watcom debugger components for OS/2 are 32-bit modules, but didn’t use to be. At least up to and including Watcom C/C++ 11.0, the OS/2 debugger components were almost entirely 16-bit. That allowed them to work on 32-bit OS/2 but also on 16-bit OS/2 version 1.x.

Needless to say, debugging 32-bit programs with a 16-bit debugger required a bit of extra work and there was an additional interface module (os2v2hlp.exe) which called the 32-bit DosDebug API on 32-bit OS/2 and interfaced with the 16-bit debugger ‘trap file’ std32.dll.

Building the 16-bit components again was not particularly difficult. And they even mostly worked on OS/2 1.2 and 1.1. But I wanted to get the code working on OS/2 1.0 as well. Because why not.

Running the Open Watcom debugger on OS/2 1.1
Continue reading →
Posted in Development, IBM, Microsoft, OS/2, Watcom | 10 Comments

Failing to Fail

Posted on June 16, 2023 by Michal Necasek

The other day I was going over various versions of the venerable DOS/16M DOS extender from Rational Systems (later Tenberry Software). The DOS/16M development kit comes with a utility called PMINFO.EXE which is meant to give the user some idea about the performance of a system running in protected mode.

I know that the utility has trouble on faster CPUs and I expected it to fail about like this:

DOS/16M PMINFO.EXE failing with a FP division by 0

But running the utility on an older laptop with an Intel Haswell processor, I instead got this:

The same PMINFO.EXE crashing with a #GP fault

Rather than cleanly exiting after catching a floating-point division by zero, the program crashed with a general protection fault. That looks like a bug, but why would it be happening? And where is the bug?

Continue reading →
Posted in Bugs, Intel, PC architecture, x87 | 11 Comments

Unintended Side Effects

Posted on May 23, 2023 by Michal Necasek

I’ve been lately trying to understand and improve the idling behavior of DOS programs and one of my guinea pigs has been the Open Watcom vi editor.

While the 16-bit real-mode DOS variant of the editor idles nicely, the 32-bit DOS extended version that’s actually shipped with the Open Watcom tools just refuses to idle. What’s notable is that it won’t idle with DOS POWER.EXE, with DOSIDLE, and it also won’t idle when run under Windows 9x or XP. And it doesn’t idle with my DR-DOS $IDLE$ driver either.

So I decided to track down what’s going on in the DR-DOS case. What I could see was that the DRIDLE.SYS driver never went into idle mode because every time it decremented the INT 16h idle counter, it was already reset to the initial (maximum) value by a timer tick.

In other words, as far as the DRIDLE.SYS was concerned, the editor wasn’t idle because it was only calling INT 16h very rarely. But I know that the editor polls INT 16h in a tight loop!

While trying to characterize the problem, I also found another oddity: The refusal to idle happens with the (default) DOS/4GW extender. But when the same vi.exe program is run using the CauseWay or DOS/32A DOS extenders (both also shipped with Open Watcom), the editor idles just fine!

Initially I thought there could be some problem specific to the protected-mode version of the editor, since the code is necessarily slightly different from the real-mode variant. But if it were the editor itself, it would behave the same with all DOS extenders, wouldn’t it?

Continue reading →
Posted in Development, DOS Extenders | 1 Comment

IDLE DR-DOS

Posted on May 13, 2023 by Michal Necasek

I have a laptop. Sometimes I run VMs on it, and some of those VMs run DOS. When a DOS VM does not have any power management, the laptop quickly lets me know by kicking up the fan speed. It is Very Annoying. So annoying that I really want to avoid the situation.

In newer versions of PC DOS and MS-DOS, the included POWER.EXE utility takes care of it, for the most part. But DR-DOS does not ship with any power management utility. That is despite the fact that since version 5.0, DR-DOS has a very promising-sounding IDLE command built in. Sadly, it does nothing:

DR-DOS 6.0 refuses to even try idling

The online help in DR-DOS 5.0/6.0 or Novell DOS 7.0 does not even mention the IDLE command. Scouring the depths of the Internet revealed a potentially helpful document titled Implementing Power Management (BatteryMAX) in DR-DOS.

In short, said document explains that DR-DOS has hooks for power management, but requires a driver called (internally) $IDLE$ to be installed in order to actually do anything. OEMs were supposed to ship such a driver. DRI/Novell/Caldera had a development kit with sample drivers that OEMs could use as a starting point.

But alas, it appears that the development kit didn’t survive, and I failed to find a single release of DR-DOS that would include a power management driver. So close, and yet so far!

Continue reading →
Posted in Computing History, Development, Digital Research | 11 Comments

Tracking Down a Bug

Posted on May 1, 2023 by Michal Necasek

When I first encountered the Unix vi editor many years ago, I recoiled in horror. It was nothing like the editors I was used to—Borland IDEs, DOS 5.0/6.x EDIT, or OS/2 and Windows editors. But over the years, I learned to use vi.

It turns out that on many exotic *nix systems, vi is the only game in town. Sure, there might be some way to install pico or nano or whatever, but even if that is possible, it might be very difficult to get there without editing a couple of files… with vi. And when the system in question is some ancient XENIX or PC/IX or Microport UNIX or whatever, the effort of installing some other editor vastly outweighs the effort of learning vi—and that’s if the system in question even comes with a compiler.

Some time later I started using the vi editor that comes with the (Open) Watcom compilers. It’s a decent vi clone, not great but workable. It has the nice property that there are console versions for DOS, OS/2 (both 32-bit and 16-bit), and NT available (and *nix, too). The DOS version that ships with the compiler is a 32-bit DOS-extended version, but it’s also possible to build a 16-bit version. Which will run on a 286 or even an 8086, and that’s occasionally useful.

Open Watcom vi/286, a 16-bit DOS version with EMS/XMS support
Open Watcom vi/os2, a 16-bit OS/2 version running in OS/2 1.1

I’ve been using the 16-bit DOS version of Open Watcom vi for some time, and it works well… except sometimes it hangs the system. But only sometimes and not very consistently. When it does hang, it usually happens when quitting the editor, but rarely also when starting it up.

I’ve never been able to track down the problem because it doesn’t happen frequently enough and when it does, all I can see that the system ends up in a corrupted state. Until yesterday.

Continue reading →
Posted in Debugging, Development, DOS, Watcom | 14 Comments