Big Blue Disk 16/bbd16.zip/BITS&PCS.TXT

Text File | 1987-11-20 | 7KB | 108 lines

|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.