home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Simtel MSDOS 1992 September
/
Simtel20_Sept92.cdr
/
msdos
/
sysutl
/
csvs.arc
/
CSVS.DOC
< prev
next >
Wrap
Text File
|
1987-04-20
|
29KB
|
521 lines
The Computer Shopper PC Clone Validation Test
By Andrew M. Fried & Kenneth McMillen
Introduction
------------
There has never been a better time to purchase an IBM clone microcomputer than
today. Overseas production and fierce competition have made the computer
consumer master of the industry.
There is generally one question facing most prospective buyers of clone
computers, and that is whether or not the system is, in fact, a true
compatible.
Beginning next month, Comupter Shopper will add another program to its list of
programs used to test a systems compatibility with that of the PC. This
program, called BIOSTEST, invokes almost all of the ROM BIOS calls and checks
them for proper operation.
The purpose of this article is to discuss the various interrupts available in
ROM BIOS and how they can be checked for compatiblity.
Interrupt 5 - Print Screen
--------------------------
When the combination of the Shift-PrtScr keys are simultaneously depressed,
the ROM BIOS generates an interrupt type 5. This interrupt causes the
contents of the screen to be sent to LPT1:.
Our test of this interrupt is simple and straightforward. To begin with, a
ROM BIOS call is made to determine the current video mode. Once the video
mode is known, the active screen memory is known.
The contents of the current screen are saved into a buffer so that they may be
restored upon completion of the test. In order to insure that there is, in
fact, something on the screen to print, a series of printable ASCII characters
are generated and displayed onto the active screen. These characters are
printed sequentially from chr(32) up to chr(127).
BIOSTEST then generates an Interrupt 5. It becomes the responsibility of ROM
BIOS to transfer everything on the screen onto the printer.
Once the interrupt has finished, BIOSTEST restores the screen to its original
condition and waits for you to press a key to continue. In order to determine
whether or not the interrupt functioned properly, you must examine the printer
output to see if the pattern appears correct.
Interrupt 10 - Video I/O
------------------------
ROM-BIOS has a set of routines which handle various video functions. These
routines set screen modes, move and find the cursor's position, select active
graphic pages, up/down scrolling, read/write characters with attributes,
read/write dots, and color selections. Some of them are practical if program
speed is not a problem. However if you wish to do some fancy graphics that
are quick then using these routines are not for you. Their performance is
slow as you will see with the dot testing. The nicer functions are the screen
scrolling and active page selection. To take advantage of the graphics you
will need a color monitor.
Before the test begins it checks to see what type of monitor you are using.
If you are using a monochrome monitor the program will only do the tests
which apply to a monochrome display. There are sixteen functions with this
interrupt. The test will step through each one and ask you to press any key
at the end of each test to continue on to the next one. Some of the tests
will display a pass or fail message while the rest of them require you to
look at the screen to verify certain conditions. Each of the tests will have
a header at the top of the screen to let you know what is being tested.
The first test that is tried is the verification of a table in ROM-BIOS that
contains video initialization parameters. When you boot your system or power
it on the built in diagnostics look at the switch settings for the monitor
type and set up the video card with the correct parameters from this table.
If one of the parameters do not match then the test fails. This table needs
to match 100% if you system is to be compatible.
The next test deals with setting screen modes. If you are using a monochrome
display then there is only one mode. For the color display there are seven
different modes. You should see each of the seven modes set (40x25 BW, 40x25
color, 80x25 BW, 80x25 color, 320x200 color, 320x200 BW, and 640x200 BW).
Using this next function you can set up your cursor type. In the monochrome
mode your cursor is made up of thirteen lines whereas in the color mode you
have just seven. If you use this function it needs the starting and ending
line. This test should display a solid cursor, starting at cursor line zero
and ending at seven or thirteen.
The next two tests position and read the cursor's location. The first test
positions the cursor at row four, column twelve and prints the letter 'X'.
You need to verify this by looking at the screen. The other test does the
same thing and then reads the location of the cursor which should be at row
four, column thirteen. On the screen you should see the blinking cursor at
this position. Press any key when you have finished with each test.
Function number four of this interrupt reads the position of a light pen.
This test was not included since most everyone does not have a light pen.
Function number five selects the active page to display. To fully utilize all
of the memory on the video card IBM included this function which gives you
multiple pages of text. In a 40x25 screen mode you have a total of eight
pages of text that you could flip through if your application takes advantage
of this. In an 80x25 mode you get just four since you are using twice as
much video memory. This function works only with color displays. The test
will first use the 80x25 mode and fill up all four pages with the page
number. Then the test will ask you to press any key to flip through the four
pages verifying that each screen page is filled with the proper page number.
If so then this test passes.
The next two tests test the scrolling functions. The first one fills the
screen with text and scrolls up a window of text. The second on does the same
except it scrolls down a window of text. If you see this happen then both of
these tests pass. You can also see what the character set will look like.
The next three tests deal with the character handling routines. The first
will display a test pattern made up of all the attribute capabilites
(underline, color, blinking...). The test will read the pattern from the
screen and if it matches the test passes. The next test writes the test
pattern on the screen and then it is read back to verify that the pattern
matches. If so then this test passes. The third test also writes the test
pattern to the screen but without any of the attributes so what you should
see is text displayed normally. A trade off with the attributes is that you
have the underline capability only with the monochrome and color only with
the color display.
Functions eleven, twelve, and thirteen are used for graphics. Function eleven
sets the color palette. The test should cycle through sixteen colors. You
will need to verify this. Function twelve handles writing dots or pixels to
the screen at a particular row and column. The test should draw a box on the
screen. To verify that the test did this it will read back all the dots which
make up the box, please be patient while the test does this. If they are all
read back successfully then the test passes. Function thirteen handles
reading the color of a dot at some position. This test should draw a
different box and if the test reads back each dot that the box is made up of
then the test passes.
Function fourteen handles writing characters to the screen and is similar to
the functions describe above which handle characters. This test uses the same
test pattern as used in the above test. If the test pattern is read back
correctly then the test passes.
The last test of the video I/O tests the current video state. Since it gets
its results from a reserved area in memory, for storing system information,
this is where the test was performed. Most applications use this data area to
get system parameters. If this area is not identical and maintained to that
of an IBM machine then compatability might prove to be a problem. This test
first saves the current values and replaces them with test values. The
function is executed to see if it returns the test values and if it does then
the test passes. When the test finishes, it will restore the current values.
Interrupt 11 - Equipment Determination
--------------------------------------
There are some software packages that can determine the type of equipment
your system is using. One of the most obvious reasons for this is that a
program which displays graphics will not work so well if your monitor is
monochrome. So the program will look to see what type of monitor you are
using and execute it's code to handle a monochrome monitor. That way if the
program is not dependent on using graphics, it will still operate.
When you turn on your PC, a set of built in diagnostics are run to quickly
test the condition of your system. The diagnostics must know what to test. It
reads the switch settings you set on the motherboard for the type of monitor,
amount of memory, etc. and stores those settings in a system data area. If
your program requires this information then you would execute an interrupt
11. This interrupt reads the settings from the data area rather than from the
actual switch settings on the motherboard. Since most programs will extract
the switch settings from the system data area, this is where the test was
performed.
The test first of all saves the current switch settings stored in the system
data area. It then replaces this value with a test value. An interrupt 11 is
executed to find out if it returned the test value. If so, then the test
passes. After the test has finished, the current switch settings value is
restored back to the system data area. You could actually fool your system
by changing the switch settings value in this data area.
Interrupt 11 returns the switch setting value in the AX register. Each of the
bits in this register indicate the following:
bit 0 - indicates diskette drives on the system
bit 1 - not used
bit 3,2 - planar ram size
(00 = 16K, 01 = 32K, 10 = 48K, 11 = 64K)
bit 5,4 - initial video mode
00 = unused
01 = 40 x 25 black/white using a color card
10 = 80 x 25 black/white using a color card
11 = 80 x 25 black/white using a monochrome card
bit 7,6 - number of diskette drives if bit 0 set
(00 = 1, 01 = 2, 10 = 3, 11 = 4)
bit 8 - not used
bit 11,10,9 - number of RS-232 ports
bit 12 - game input/output port installed
bit 13 - not used
bit 15,14 - number of printer ports
(00 = 1, 01 = 2, 10 = 3, 11 = 4)
Interrupt 12 - Memory Size Determination
----------------------------------------
When you purchase a software program, it usually will state in the
documentation the amount of memory the program requires to run successfully.
If you have tried running a program which requires more memory than you have
available then you might get the message "INSUFFICIENT MEMORY". The program
most likely has used interrupt 12 to first look at the amount of memory your
system has available before trying to load the main program. This will avoid
the possibility of crashing your system and leaving you in frustration as to
what went wrong.
The memory size is determined when your system is powered on or when your
system is booted up. In the system data area there is a place which keeps the
amount of memory your system has installed. This determination is stored
there. When an interrupt 12 is executed, it reads this value. What the
interrupt returns is the number of contiguous 1K blocks of memory.
The test saves the current memory size and replaces it with a test value.
Then an interrupt 12 is executed to see if it returns the test value. If the
test value is returned then the test has passed. After the test is complete
the current memory size is restored.
Interrupt 13 - Diskette Drive Interface
---------------------------------------
The low level software interface between your diskette drive and system
memory is the ROM-BIOS interrupt 13. It handles the most basic operation of
moving data between your program and the diskette. This interrupt is made up
of six basic functions (reset the drive, getting the status of the drive's
operation, reading data, writing data, verifying data, and formatting the
diskette). DOS is very much dependent upon this interrupt.
Since DOS depends on this interrupt to function properly you can do some of
your own testing by loading and executing a program, writing data to the
diskette, and formatting a diskette. This will cover all six of the functions
listed above. If you can perform these type of functions, without errors
being generated, then you have successfully tested this interrupt and know
whether compatibility is a problem. You would also want to try and use a
program off of a diskette that was formatted and setup on an IBM-PC or known
compatible system.
The interrupt 13 test consists of first placing a formatted, double sided
diskette into drive A with, better yet, some information stored on it. Since
a majority of the diskette drives around now are double sided, this test will
test both sides of the diskette only. Once the diskette is in place then
press any key to continue. The test begins by reseting the drive. Then it
does a series of read/write tests and gets the drive's status for both sides
of the disk, on all forty tracks.
If an error occurs, then an error message will be displayed indicating the
type of failure. The error messages are based on the error codes listed in
ROM-BIOS. If one of the tests fail they are retried two more times to verify
the error. DOS does a better job of determining errors since that is what it
was designed to do. You may then proceed with the testing of the remaining
tracks by pressing any key.
After all forty tracks have been tested then the next test, verification of
data, is executed. To exercise the movement of the heads also , the test
begins on the outside track, track zero, then moves to the inside, back out,
back in, until the center track is reached and tested. Errors are handled in
the same way as the previous read/write tests.
Displayed on the screen, while the test is running, is a status line which
shows you the drive being tested, the current track, the head or side, the
starting sector and the number of sectors involved in the test. This test is
performed on drive A, drive zero, only and works with an entire track, nine
sectors, at a time. When the verify test is running you can watch the drives
head movement by looking at the current track it is on. After the test has
finished you will see the test pass or fail message. If just one error occurs
then the whole test is considered a failure.
Interrupt 14 - Async Communications
-----------------------------------
While the ROM BIOS provides support for the serial ports, most programmers
requiring the use of these ports routinely bypass BIOS and work directly with
the hardware. This is due to the fact that BIOS support for these ports is
minimal, at best.
The ROM BIOS specifically provides four support services to the asynchronous
ports:initialize port, send a character from port, receive a character from
port and return status of com port. Most communications programs will utilize
only service 0 (initialize port) since interrupt driven routines, which are
not directly supported under BIOS, are the preferred method of handling
incoming data.
For this reason, this test will run through diagnostics of service 0 only.
Various baud rates are initialized using BIOS. This diagnostic then goes into
the UART chip itself to ascertain that the correct timing parameters were sent
from BIOS.
This test will display the various baud rates set along with the number which
was found in the divisor latch. If they correspond with the correct value,
the test will pass.
This test will only be performed on COM 1.
Interrupt 16 - Keyboard
-----------------------
There are actually two different interrupts used to support the keyboard. One
interrupt (interrupt 9) is used primarily for low level support of the serial
transmissions from the keyboard. This interrupt is not generally invoked by
user written software.
The other keyboard interrupt, which is often referred to as the "read keyboard
support", is interrupt 16. This is the keyboard interrupt accessed by most
user software programs.
As you could imagine, interrupt 16 could not function properly if interrupt 9
failed to perform its duties. For this reason, BIOSTEST concerned itself with
interrupt 16. Interrupt 9 is not directly tested by the validation program.
Under interrupt type 16 there are three services available. Service 0 reads
the next character entered into the keyboard and returns the code and its scan
code in the CPU registers.
Service 1 is invoked simply to tell us whether or not a key has been entered
and is waiting in the keyboard buffer for processing. Finally, service 2
returns the status of the shift keys.
In order to test these services, information was placed into the ROM BIOS data
area. Since the interrupt itself uses the data area to store information from
the keyboard, simple memory manipulations are performed which trick the
keyboard into thinking that keys were pressed which, in reality, weren't.
This enables us to check the ROM BIOS without addressing the physical keyboard
itself.
For example, by adding a character into the keyboard buffer and changing one
simple pointer, the BIOS thinks that a key is waiting to be processed. When
service 0 is subsequently called, it should return indicating a character is
waiting.
Interrupt 17 - Parallel Printer Port
------------------------------------
Just as in the case with the serial port, the parallel port is supported by
ROM BIOS even though the device itself is not part of the motherboard. This
means that the system may support a device that is not even attached to the
system.
This interrupt contains three separate service routines. Service 0 sends
characters out the port one at a time to the printer. Service 1 is used to
intialize the printer port and service 2 returns the printer status.
BIOSTEST primarily invokes these routines. It is up to the operator to
determine whether or not the hardware is responding correctly. For example,
under service 0 a test pattern of printable characters is sent out the
parallel port using interrupt 17. To ascertain the correctness of the call,
it is necessary to visually examine the output.
Service 1 merely initializes the port. The only testing performed on this
service is to examine the return code for inconsistencies after the call is
made.
Service 2, which returns the printer status, is easily verified by performing
such tricks as taking the printer offline and then invoking the test. If
working properly, BIOSTEST will indicate the condition to you.
Interrupt 18 - Invoke ROM-BASIC
-------------------------------
If you don't have a fixed disk attached to your system, chances are at some
time or another you booted up your system without a disk in the drive. The
result was that the machine finally enters ROM-BASIC. Entry into this
firmware version of Basic is made possible by interrupt 18.
I do not know of any clone that has Basic installed in ROM. Microsoft wrote a
generic Basic language for clones which emulates IBM's ROM-BASIC however it is
a software only version of the language. I'm referring to GWBASIC, of course.
For completness, however, BIOSTEST includes this test. When this test is
performed, an interrupt 18 is invoked which, on an IBM, should call up the ROM
resident version of Basic.
Do not expect this test to perform correctly on clones. It is even quite
possible that the machine may totally hose up when this call is made.
Interrupt 19 - Boot Strap Loader
--------------------------------
As soon as the computer is turned on, ROM BIOS begins initializing the data
area and performing diagnostic tests. At the conclusion of these tests,
control is turned over to the boot strap loader via interrupt 19.
This routine will simple invoke the interrupt 19 code. When this happens,
your computer should simple perform a complete reboot as would occur had you
just turned your system on.
Interestingly enough, not all systems seem to respond this interrupt the same.
In particular, hard disk based systems will sometimes 'hang' when this test is
performed. In general, however, if your system comes up from a power off
condition, the system should be considered ok. This test is optional and not
a true gage of compatibility. It was included in BIOSTEST for the sake of
completness.
Interrupt 1A - Time of Day
--------------------------
Around 6:30 every morning, we all feel as though our lives are controlled by a
clock. Well, we have at least one thing in common with a computer!
In the case of the PC, the second hand of the clock is advanced approximately
18.2 times every second. For you techies out there, the strange timing
interval is the result of a 1.2 mHz clock divided with a counter by 65536.
At each advance, a register is incremented. Determining the actual time is
therefor a matter of transforming this count into something more meaningful by
us mortals. ROM BIOS doesn't give us the upper level support to do this; a
service request under DOS interrupt 21 does, however.
What ROM BIOS does give us, however, is the ability to read the so-called
clock and to set the clock. These facilities fall under interrupt 1A services
0 and 1 respectively.
This test will read the hardware registers and then perform a bios call to
read the registers. If they are identical, the test passes.
The second test performs just the opposite; a new value is set into the clock.
Once done, the hardware is examined to see if the call was successful. Should
the registers differ, a failure warning will be issued.
Printout of ROM BIOS Data Area
------------------------------
ROM BIOS is contained on non-volatile memory. As such, it does not change, it
need not be reloaded every time the system is powered up an can operate much
faster than the volatile memory chips affectionately referred to as RAM.
This is all well and good, but in order to operate certain variables that are
used by ROM BIOS must be able to change. To accomodate this, a certain area
of RAM memory was set aside specifically for ROM BIOS support. This area is
called the ROM BIOS data area.
There is a wealth of information stored within these areas. As a matter of
fact, it is very common for software packages to examine certain locations
within this area for information pertinent to the operation of the program.
If you were to examine a technical manual which lists the actual ROM BIOS
(such as the IBM Technical Reference Manual), each variable in this area has
been assigned a label. This procedure produces a hardcopy listing of all of
the data located within this data area and displays it along with its actual
name as it appears within the tech manual.
This utility is very useful for comparing certain values contained within the
data area from those of the real thing. In order to get the printout,
however, a printer must be attaced to your system.
The Romdate Utility
-------------------
Hidden deep within the recesses of most ROM BIOS are three fields of
information which you might find of interest. These fields include the type
computer system, the date of the ROM BIOS and the copyright notice.
The field containing the type of computer is important since many machine
specific programs examine that memory location in order to determine the host
computers configuration. Rather than return a meaningless code, BIOSTEST
returns the type system identified by the system code.
Another location within the ROM BIOS has historically been used to provide a
date stamp for the ROM BIOS itself. BIOSTEST will display this date.
Finally, a third location yields an ASCII string which consists of a copyright
notice. This is really quite interesting (and important, as well). There are
some software packages that specifically test this area in order to find the
three magic characters "IBM". This was supposedly done to prevent certain
software from running on clones.
In order to maintain compatibility, software houses producing ROM BIOS decided
to install their own copyright notice which also contains the magical letters.
Some are quite humorous and may range from "IBM compatible" to "This is not an
IBM...".
This utility will print the first 60 or so ASCII characters found in the area
traditionally reserved for such purposes.
The Romcheck Utility
--------------------
ROM BIOS is actually nothing more than a collection of software procedures
which have been stored inside the computer non-volatile memory. Software of
this nature is referred to as "firmware".
Many systems contain other devices not directly supported by either the ROM
BIOS or DOS. Two such examples that are most common are the fixed disk
extension to interrupt 13 and the Enhanced Graphics Adapter extension to
interrupt 10. In order to provide support for these devices, the cards
themselves contain either ROMS or EPROMS containing the firmware necessary to
support that device.
During a power on self test, the ROM BIOS tests certain areas of memory for
these ROMS and, if located, pass control to these programs. The programs, in
turn, create the necessary hooks into the operating system which enable the
device to function.
This utility will scan the computers memory from C000:0000 up to F400:0000 in
search of these ROMS. Should a ROM be found, its address will be displayed on
the screen.
The most common ROM will be found at address C800:0000. This ROM provides
support for the fixed disk. EGA cards, on the other hand, will generally be
found at C000:0000.
Conclusion
----------
The program BIOSTEST is an attempt on our part to provide a standard and
meaningful test to ascertain a PC clones compatibility to its predecessor, the
IBM PC.
In developing our test, we tried to simulate, wherever possible, actual
situations where the ROM BIOS would or could be invoked. Our tests are simple
yet quite through.
There is, of course, the possibility that an unknown bug or glitch in the ROM
BIOS could go undetected by BIOSTEST. To remove this possibility would
require programming effort in excess of that used to originally develope the
BIOS itself!
Quite frankly, there are few systems in the market today whose ROM BIOS is not
compatible. Our program will help to identify the small minority of systems
containing a flawed ROM BIOS.