IBM Compatibility Issues

By Mark Dahmke
BYTE Magazine, Fall, 1985
Special Issue: Inside the IBM PCs

OF LATE, IBM has seemed to adopt a “let’s keep changing it” philosophy. This philosophy can be one of the most powerful tools a large company has to keep its customers from purchasing third-party plug- compatible computers, add-on boards, and software. But this same philosophy can force a giant like IBM into a difficult position. I refer mainly to the IBM PC AT and IBM’s TopView Because of a poor operating-system design and little concern on the part of software authors for writing well-behaved applications programs (see the text box “The Levels of Software Behavior” on page 188), both of these products have features that make life miserable for anyone trying to write programs that will run correctly on the entire line of IBM Personal Computers and compatibles. TopView is an add-on operating-system product that turns an IBM PC into a multitasking system capable of supporting windows and concurrency. Because of poor planning back in the days of PC-DOS 1.11 it has several major performance problems. First, device ownership is rarely checked by off-the-shelf software. This means that programs are written with the assumption that all hardware devices are owned implicitly by the program and are at its disposal at all times. Some application programs even reprogram the serial ports, counter-timer chips, DMA (direct memory access) channels, and video-display adapters without bothering to see if any other program (or the operatjng system) is using them. A large number of the most popular application packages read and write characters directly to or from the video-display buffer. In bypassing the BIOS (basic input/output system) in the ROM (read-only memory), the program gains speed but severely limits the ability of the operating system to retain control of all physical hardware devices. BASICA the Microsoft BASIC interpreter, reprograms the serial ports because the BIOS doesn’t support all the error-checking and time-out functions the language requires. This means that if another program is using the serial ports, or if one or both serial ports are in use as multiuser consoles, BASICA can crash the system. In terms of hardware IBM has stated that it will maintain compatibility with the following features in future products: l. The sound channel of the counter-timer. Channels 0 and 2 control the time-of-day interrupt and the speaker and cassette ports. 2, The game-control adapter port 201 (hexadecimal). 3. The interrupt-mask register 4. Absolute addresses of the video- display buffers for the color- and monochrome-adapter cards. 5. The ROM BIOS data areas. What this means is that IBM will, in all future products, support these absolute hardware memory and I/O (input/output) port addresses.

WINDOWS

TopView and Digital Research’s Concurrent PC DOS and GEM (Graphics Environment Manager) are the three main contenders vying to become the standard in window technology. All three must deal with the problems created by programs that directly access the video buffer. IBM gets around this problem by adding a software interrupt vector that returns the address of the video buffer for the window the application is running in. This lets the application modify the buffer as if it were the real video-display card and then call another interrupt vector to update the video display from it. If this procedure is not followed, a program may rewrite the screen or, even worse, reprogram the display (such as switching from 80-column by 25-row text mode to medium-resolution graphics mode) without telling the operating system about it.

SOLUTIONS
IBM’s choice of PC-/MS-DOS 1.1 and its original BIOS have practically eliminated any hope of standardization and have made it very difficult to write well-behaved programs. (It is interesting to note that choosing TopView as a multitasking/windows add-on to PC-DOS doesn’t necessarily give you more compatibility than buying Concurrent PC DOS. In fact, in my experience, Concurrent PC DOS may be the better choice.) Several things should have been done (and could still be done) to solve these problems and make the IBM standard a viable one (as viable as the S-100 or the Apple II) for the next 10 years. First, there should be an easy way to do equipment determination through the DOS (disk operating system) or BIOS calls. There is no excuse for writing programs that don’t look to see how many disk drives there are and whether there is a B: drive installed. Similarly well-behaved programs should at least try to check out device ownership. For example, suppose you load a program that installs itself into the system like the PRINT command or Borland’s SideKick. The program replaces interrupt vectors and reprograms a counter-timer channel for its own purposes. You then load a second application program that also tries to reprogram the counter-timer channel and modify interrupt vectors. The result is a crashed system and no clues as to why. Copy-protection schemes are notorious for reprogramming the hardware, especially the disk-controller board. IBM points out in its documentation that certain schemes may not work on the PC AT with its new high-capacity disk drives. Either copy-protection schemes should be abandoned, or the BIOS should have a “return serial number” interrupt call (I prefer the former). Whatever method is used, the copy-protection scheme shouldn’t reprogram the hardware without telling the operating system about it first. (See the text box “Requests to Operating-System and BIOS Designers” on page 188.) All software developers inevitably want to squeeze as much processing speed out of a microcomputer as possible. The old cliché is that programs expand to use the available resources. Because of inherent limitations in the hardware and the operating systems of current microcomputers, it is sometimes necessary to reprogram the hardware to maximum efficiency (See the text box “Suggestions to Software Developers” at left.) Regardless of what programming methods software developers use it is in their best interest to at least allocate devices through the operating system and avoid device contention. This technique will save them a great deal of recoding when new hardware and software products are introduced by the manufacturers.

SUGGESTIONS TO SOFTWARE DEVELOPERS

If you have to write directly to the screen buffer, try to do some equipment determination and check to see if you are operating in a windowed or concurrent environment. If you must write to the screen buffer don’t change the video mode (e.g., from medium-resolution graphics to text) by writing to the video-controller chip. Use a BIOS call for this function. Allow files to be assigned to physical disk drives. Don’t assume that everyone has two floppy-disk drives. Don’t use undocumented 8088 instructions in programs. The 80186 and 80286 probably won’t support them, and any redesign to the 8088 itself could change or eliminate undocumented machine instructions. Try not to use the scan-code values returned by the keyboard as they may not be supported in future products. Don’t write code that loads at absolute memory addresses. Allow print files to be sent to disk instead of directly to the printer. Future operating systems will probably provide print-spooler function calls that allow your program to write a print file to disk and issue a spool command to send it to the physical printer.