|DÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ |Dº |5The Happy Hacker |DºÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ |DÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ ^C^1Bits 'N PC's ^Cby ^CGeorge Leritte To be compatible or not to be compatible, that is the question. In the IBM PC world, everyone and their brother is selling IBM compatible computers and equipment. From Tandy and their line of computers to the machines made overseas, they are all touting their machines as compatible, or worse, clones. From a programmer's viewpoint, it is a nightmare. This will be a short and, I hope, enlightening discussion on compatibility of the IBM machines. First, let me say that most of the "compatibles" really are compatible. The heart of an IBM machine is the ROM-BIOS (Read Only Memory-Basic Input Output Services). These are a set of routines that high level languages call to perform various things like printing to the screen, control disk drives, and reading and writing to files. A compatible must have these routines, but, because of copyright laws, they cannot be identical to IBM's routines. Compatible makers had to make changes in their routines. Some of these changes are improvements and some contain bugs or do not operate in exactly the same manner as IBM's ROM-BIOS, so that differences in operation do occur, especially when software makes use of a hardware specific function like our screen bounce. Another example of this is the timer function. DOS has a function that returns the number of seconds since midnight. The original IBM and most compatibles return a decimal number from this function. A few machines, however, return integers for this interrupt. A program that needs an exact timing function will malfunction if it is expecting fractional seconds and gets whole seconds. These functions or calls may work exactly like they are supposed to on a compatible or clone, but only if the hardware works exactly like IBM's. Buyers generally get upset at the programmers who write such software because their machines are "compatible" and the programs do not work as advertised. But it is really the manufacturer's fault for not detailing the incompatibilities of their machines. IBM made changes in their ROM-BIOS for their PC-jr, so that software written to take advantage of the jr's video capabilities will not run on other machines. IBM also decided to place the jr's screen memory in RAM, I suppose to save on hardware costs (no video board). But this means that every jr actually has at least 16K less usable memory than they claim and is about 1/3 slower than a standard PC. A 256 Kilobyte PC jr has a maximum of 240K of memory to load DOS and run programs. Alternate video modes of the jr take up even more memory. The first Tandy 1000 is PCjr compatible, not a PC compatible, so you have the same problems you would get if you had bought a jr. There are also significant differences in the way a standard PC and the jr process keyboard input. These could cause program crashes if the programmer bypasses the normal DOS keyboard interrupts. From the discussion of ROM-BIOS and the jr, you can see that compatibility is a relative word. Add in the various versions of DOS and the problems multiply. The BIOS interrupts in each version of DOS are placed in different locations but the interrupt table at the bottom of memory references all of these interrupts properly. If a programmer uses standard DOS calls in his programs, there should be no problem when it is run. However, if a programmer directly changes a BIOS interrupt when his program is loaded, and then changes it back according to his DOS version when exiting, the program will probably crash when it is run on different versions of DOS. A prime example of this is PC-RR, a public domain model railroad simulation. Some programs peek at the ROM-BIOS and expect to see certain things there, usually IBM's signature bytes defining the type of machine. If these bytes are not in place, the program usually crashes or displays an error message. When you consider the enormous variety of video boards, the problems increase exponentially. The monochrome display adapter (MDA) is placed at one spot in memory and the color graphics adapter (CGA) is placed in another, and they require different monitors. You can't do graphics on the first, and doing direct screen writes requires checking which is present (and active, if you have both). The AT&T 6300 has a graphics card that runs on a monochrome monitor. This card simulates the CGA colors with different intensities. However, blue and white are the same intensity, as are red and black. Then Hercules came out with their monochrome graphics adapter (HGA), but few programs were written to take advantage of it, and because the resolution is different from the CGA, graphics programs would not run on HGA's. Next came boards like the ATI Graphics Solution board, which allows more colors with the same resolution as the CGA. Programs written for these boards either don't run properly on CGAs or don't run at all. Then IBM developed their Enhanced Graphics Adapter (EGA). The EGA allows quadruple the resolution with even more colors. However, programs written to take advantage of the EGA's resolution will run on nothing but machines with an EGA. Then other manufacturers jumped on the EGA bandwagon and developed their own boards and all of these boards operate differently. For example, the Genoa Spectrum EGA places its video routines at one spot in memory and changes the normal video interrupt to point directly to itself. The Digicom and Vega EGA cards change the video interrupt to point to a memory resident routine, which then points to its video routines elsewhere in memory. Now, with their new machines, IBM is using the VGA, an entirely different method of video display. A programmer with a low budget is doomed from the start. He cannot afford the multitude of boards and equipment it takes to properly evaluate his software on all of these machines and video boards. For example, just detecting an EGA is difficult, since each installs itself differently. There are software routines that a programmer can purchase that detect these boards with relative accuracy, but as new boards hit the market, the routines become unreliable. So a programmer is forced to make compromises, and it usually is something like using only CGA modes in his graphics work. In an aside, there are two shareware programs available that bring CGA graphics to the Hercules monochrome computers. They are SIMCGA and HGCIBM. They are memory resident programs that translate most CGA graphics calls to HGA graphics. I have run both programs and they work fine on my HGA here at work, and caused problems only when I switched back to my CGA. They can be found on our SoftFido BBS if you cannot get them anywhere else. The phone number is 318- 222-3503. After bending your ear (eyes) for all this, I think we'll skip the "compatible printer" portion and say so long for now.