Running 1-2-3 R3 in a VM

I recently tried to install the infamous Lotus 1-2-3 Release 3 from 1989 in a VM. The program disks included both DOS and OS/2 executables, and both were failing. The DOS version stopped with “Cannot initialize system driver” immediately after showing the splash screen, while the OS/2 version failed with the message “Error loading driver file LTSNW” at about the same point. Google was of no help whatsoever, as often happens with software that old. Continue reading

Posted in DOS, PC history, VirtualBox | 3 Comments

Need for Speed SE video glitch

When attempting to play the classic racing game Need for Speed SE in a virtualized environment (VirtualBox), I was dismayed to discover that all the in-game videos were completely garbled. Curiously, the introductory video played when the game is first launched looked fine, even though there was no reason to think it should be any different from the in-game videos.

Continue reading

Posted in DOS, VirtualBox | 8 Comments

WordStar needs address wraparound?

The CP/M compatible interface in DOS was initially documented, later forgotten, and then re-discovered every once in a while.

In 1989, John Switzer described parts of the CALL 5 system call interface mechanism in a slightly hysterical article as a “back door” into DOS and called it a security risk, despite the fact that it was a compatibility interface very deliberately maintained in every version of DOS. However, the article correctly pointed out that the CALL 5 interface bypassed INT 21h hooks. In theory, that could have been used for nefarious purposes; then again, worrying about that on the DOS platform was like being gravely concerned that cold wind could get in through a small crack in the window in a house without a roof. DOS simply wasn’t a secure foundation and patching a tiny hole couldn’t fix the fact that any program running on DOS effectively owned the entire system. Continue reading

Posted in DOS, PC architecture, WordStar | 11 Comments

Who needs the address wraparound, anyway?

The infamous A20 gate is well known and documented in hair-raising detail. What’s much less well documented is the real purpose of the A20 gate, that is, who actually needs the 8086 address wrap-around to be emulated in the first place.

There is precious little information on that topic. But as it turns out, all versions of DOS, including the OS/2 DOS box and NTVDM in Windows NT, implement a CP/M-like system call interface which cannot work without address wrap-around being emulated one way or another. In other words, any DOS application may in fact need the wrap-around, without necessarily being even aware of the fact. The key is the so-called ‘CALL 5’ compatibility interface, invoked by a near call to the offset 5 of the PSP (Program Segment Prefix). This interface was intended for COM programs, but will work as long the CS register points to the PSP regardless of the program type. So what’s at offset 5 of the PSP? Continue reading

Posted in DOS, PC architecture | 4 Comments

IBM DOS 5.0 QBASIC hangs on non-IBM systems

Much like its predecessors, IBM DOS 5.0 has no trouble running on clone systems, as long as they’re sufficiently compatible. That includes virtual machines. However, the QBASIC.EXE (and consequently EDIT.COM) program dated May 9, 1991 consistently hangs on any non-IBM system. Why is that?

Analysis shows that the key is the presence (or absence) of ROM BASIC, which was built into the ROM of all IBM PC systems (including PS/2) from the very first PCs until approximately 1991, sometime after IBM DOS 5.0 was released. But why does QBASIC care when it’s supposed to replace the ROM BASIC anyway? Continue reading

Posted in BIOS, DOS, PC history | 20 Comments

Hang with early DOS boot sector

While installing various versions of DOS for the DOS history series of articles, I was faced with a mysterious problem: Some versions of DOS would hang right away when booting from fixed disk, but not from floppy. I already knew that DOS 4.x is very sensitive to BIOS stack usage; if a BIOS needs more than 100 bytes or so of stack to process a disk read request, it will fail to boot DOS 4.x from fixed disk, even though the same DOS 4.x can access the same disk just fine when booted from floppy.

However, the hangs I was observing were happening with DOS 2.x and 3.x, and those do not have such tight stack usage requirements. I quickly realized that the problem is caused by a bug in the DOS boot sector: the boot sector code tries to optimize the loading of IBMBIO.COM and attempts to read a whole disk track at a time. That sounds like a good idea, but it’s not. Continue reading

Posted in DOS | 32 Comments

Happy 30th Birthday!

In honor of the thirtieth anniversary of the IBM Personal Computer, the OS/2 museum started a new series of articles, this time dealing with the history of DOS—the predecessor of OS/2 and the first OS developed by Microsoft in cooperation with IBM. The first two installments deal with the prehistory of DOS and with the DOS 1.x releases. As usual, VirtualBox was quite helpful for supplying screenshots of vintage software.

Posted in DOS, PC history | Leave a comment

The Danger of Knowing Too Much

A few days ago I had to look a little closer at Microsoft’s KEYB.COM because it was misbehaving in a virtualized environment. As a reminder for those readers who perhaps forgot, KEYB.COM was the DOS keyboard “driver” with support for international keyboard layouts. The MS-DOS version of KEYB.COM was incorrectly detecting the keyboard type (thought an 84-key variant was attached, when it was a 101/102-key of course), but IBM’s KEYB.COM from PC DOS 7 had no problem, and the FreeDOS version likewise worked fine. What I found in KEYB.COM was a little surprising.

The authors of KEYB.COM clearly had a lot of  inside knowledge about PC hardware. It’s quite likely that IBM had a hand in writing the utility, but Microsoft probably maintained it and made sure it worked (more or less) on non-IBM systems. Continue reading

Posted in DOS, PC architecture | Leave a comment

IBM PC/AT 8042 Keyboard Controller Commands

Anyone trying to use the classic 8042-style keyboard controller (KBC) found in the IBM PC/AT and nearly all later PCs typically runs into a problem with lack of accurate documentation. The 8042 (or 8742, or any number of compatible parts built into later Super I/O chips) is actually quite well documented. The catch is that the 8042 is a programmable micro-controller with its own control software in (usually) ROM. Until recently, no one outside a few companies (IBM, AMI, Phoenix) knew exactly what the control software did.

IBM documented a number of commands the host can send to the KBC. It should be understood that all those commands are a pure software construct, with nothing about the 8042 hardware dictating that the commands need to follow any specific format, function, or that they even need to be there at all. Therefore understanding the 8042 ROM code is the only way towards understanding exactly what the commands are and what they do, with the caveat that different controllers may and do have somewhat different code in their ROM. Continue reading

Posted in PC architecture | 22 Comments

Detecting floppy drive presence and type

Detecting floppy drives is surprisingly tricky and poorly understood. The difficulty lies mainly in the interface between the floppy disk controller (FDC) and the actual drive(s). The interface isn’t particularly complex, but it isn’t straightforward, and it does not follow the intended design of the original NEC µPD765A FDC.

Many if not most operating systems do not even attempt to detect floppy drives and use the value configured by the user in the non-volatile CMOS memory. Even the excellent Undocumented PC (van Gilluwe) cops out and uses the BIOS to detect floppy drives. Yet a simple and reliable method for drive presence detection has been published in the mid-1980s, in the classic IBM PC/AT Technical Reference. Continue reading

Posted in BIOS, PC architecture | 1 Comment