

                                   SVGA TESTING 
                               ====================



NOTE :
========

Read the text file before running the program to know what to look for.

AT ALL POINTS IT IS POSSIBLE TO SKIP TO THE NEXT SECTION OF THE TEST BY
PRESSING 'q'.



Requirements :
================

At least a 386 computer, capable of running DOS, an SVGA card, a VESA
interface to be used with the SVGA card. The DOS4GW.EXE loader must be in
the current directory or reachable by the 'PATH' variable. DOS4GW.EXE is 
possible to download from the same site and directory as the main program.

The VESA interface is only used to set the SVGA mode. If your card doesn't
come with a VESA interface try to get UNIVBE, which works with many cards.


Purpose :
===========

A problem with the x86 PC is it's 16 bit history. When using a graphic
screen this becomes obvious. If we're working with a 800x600 pixel display
in 256 colors the display will use 800*600*1 = 480 000 bytes. Display 
memory is only given a 64kb size in the Real Mode adress space of 1 MB.
Either we have to use a screen with very few pixels (320x200 for example)
or there must be some way to let the 64kb video space mirror different 
areas of the true display memory. 

Luckily there exists such techniques on all SVGA adapters. The portion of 
the true display memory ( physically located on the graphic card ) is  
referred to as bank  and changing it is called bankshifting. But here starts
another problem. There is no standard. Different manufacturers has implemented 
this mechanism in various ways. A solution to this second problem is the
VESA interface. This works well as long as we're operating from Real Mode.
( 16 bit mode ). When we move into Protected Mode ( 32 bit mode ) the CPU
cannot run the bankswitching code since it's 16 bit code. So the CPU will 
have to be shifted into Real Mode, then the bankswitch is done and the 
CPU is sitched back to Protected mode again. The process might take up to
a hundred thousand clocks or even more. 

Imagine plotting randomly spaced pixels in this way. If the screen uses 
ten banks it's 90% chance the pixel will fall  into a different bank 
than the active one. Say we're on a 100 MHz system. Divide this with a
100000 clock bankshift. We've got the machine performing at rougly 1000 
pixels a second. Practically we've reduced performance by a factor of
roughly 1000 to 5000 times !!!

This is where this test program comes in. It will enable doing bankshifting, 
hardware scrolling, setting up large virtual screens all in protected mode.
The program will be able to treat all cards in a similar way, a few parameters
and pointers to cardspecific functions defines their behaivour fully.

Most cards have a Read Bank and a Write Bank. This allows reads and writes 
to happen at two different places of the screen at the same time. The 
advantage is obvious for example when copying memory from one place to 
another in videomemory. So there are three bankroutines for each card to
test :
   
  SetReadBank
  SetWriteBank
  SetBothBank





Using the program :
=====================

If you want to give feedback after running the program ( I hope so )  
reading the 'report.txt' file might be good, in order to know what sort 
of things to look for.

The program is started from the DOS-prompt by unpacking the SVGATSTx.ZIP  
archive and running SVGATEST. The program will start by identifying the
chipset. For most chips it recognizes it also has protected mode functions
to test. Some cards may only be recognized, but not used. The family, the
name of the card, the memory installed on the card and the version and
subversion number of the chip is presented. Note if any of the information.
is incorrect.

After this a graphics mode has to be specified. The modenumbers are VESA
codes, here are some common :

  257    640x480x256   ( width x height x colors )
  259    800x600x256
  261    1024x768x256

Then three parameters must be given given. When running the program the 
first time make them 0. After this the mode will be set. 

At all times when graphics is set one goes a step forward in the test by 
pressing a key or pressing 'q' to skip to the next test.

There are three GIF files to see what the screen should look like at the start
each of the three tests.


Test 1:  ( See 'SCRN1.GIF' ).
========

The first test uses the 'SetWriteBank' function. The banks will be filled
from top of screen towards the bottom. The first bank will be blue, the
second green, the third red etc. With a high granularity value (65536) the
one colored strips will typically be wider than with small granularity(4096).
When filling a new bank it should not overpaint anything which was painted 
before, nor should there be any black spaces between the color strips. 

This part should be tested with both bank option 0,1,2 .



Test 2:  ( See 'SCRN2.GIF' ).
========

The second test uses the 'SetReadBank' function. A collection of lines
is drawn, after pressing a key the screen will be mirrored vertically. 
What was on the bottom will be on the top. It is done by setting the 
read bank. The screen should be reproduced exactly as before but upside
down. 

The next part of this test uses the 'SetBothBank' function. The screen will
be mirrored horisontally by doing transfers within the same bank. The lines
will slope from right to left instead of left to right. 


Test 2 should be run with bank options 0,1,2 .



Test 3:  ( See 'SCRN3.GIF' ).
========

The third test will setup a display wider than the physical screen, 
typically 1000 pixels, more if using mode 261. First the display memory 
will be filled with green. Actually more than the memory given by the 
ID routines is filled with green. Then the memory specified by the ID 
routines is filled by blue. If there is more memory present on the card 
than reported by the ID routines these portions will be seen as green
when scrolling over the virtual screen.

Then a box pattern is painted all over the screen. The pattern will both
horisontally and vertically be using a black line followed by a colored
line, followed by a black line, followed by a colored line etc. 

If the testpattern does not appear as on the GIF file it's a problem.
Try giving argument 1 or 2 when prompted for a 'scan line length method'
when starting the program. Note which alternative functions properly.


By pressing any key the display should scroll one pixel at a time 
horisontally, with new data showing up at the right side. A colored line 
should disappear every second keypress on the left side. The display
should move one pixel for each keypress. 

If the display moves two pixels at a time or sometimes moves backwards
this is a problem. Try giving argument 1 or 2 when prompted for a 'display
offset method' when starting the program. Note which alternative functions
best. 

Go to the next section by pressing 'q'.

The same thing will be repeated vertically. At every second keypress a colored
line should disappear at the top of the display. The display should not 
'jump' horisontally between the keypresses, nor should it move two pixels.
The process should be smooth all the way until what was originally the
top of the display will reappear from the bottom of the screen.

It is important to note if any continous green portions will start to 
appear (= more memory than found by the ID routines ), what happens when the 
bottom of the display goes past the memory currently installed on the video
card. ( Does the top of the screen come back, does a onecolored area or a 
regular pattern show up? )

The end of video memory will happen roughly at line ( 1000 pixels scanline
length ) :
  
  256  kb => Line 260  ( kb beeing the amount of memory on the videocard. )
  512  kb => Line 520
  768  kb => Line 780
  1024 kb => Line 1040
  2048 kb => Line 2080

If you can come to a conclusion whether your videocard will wrap to start 
of display memory or show 'junk' when going beyond the end of memory this
is valuable.




Some notes : 
==============

If you have possibilty to run the program with different VESA drivers and
note the functioning it's good. 

Running the program as a DOS session under either Win3/95 or OS2 and 
seeing if the behaviour remains the same when going into and out of the 
DOS session is also important. Often the video memory will bot be restored
correctly (=junk shows up). More important is if some card registers don't
get properly restored. This would show up as bankshifting happening
correctly before going back to Win/OS2 but not after returning to DOS etc.



Reporting.
============

Fill in your observations in the 'REPORT.TXT' file or in another text file.
Report which sort of card you have, which VESA interface, which operating 
system the testing happened under, which parts functioned well, which bad,
which ghraphic modes functioned, how the virtual screen and the scrolling 
functioned, if adjusting either of the parameters affected this.

NOTE : Even if the program hangs the computer or functions totally 
       correctly this is of interest.

Send your report file to :

  arst@ludd.luth.se   or    d94-asn@sm.luth.se
   



               <<<<< THANX FOR YOUR COOPERATION !!! >>>>>


               



Finally :
===========

If you have any programming hint on any chipset or any good technical 
specifications for it this is much appreciated. At this moment the XGA 
chipset ( + clones ) is the most problematic one, since it usually not
is accessible through VESA. If you have experience in setting graphic 
modes on the XGA this information is needed.


Chips families supported :
============================

Chips & Tech
Western Digital (Paradise) 
Video 7
Tseng 3000/4000/4000W32
Trident
Everex
ATI
Genoa
Oak
Cirrus Logic
Ahead
NCR
S3
Avance Logic
MXIC
Real Tek
Primus
Weitek 
Compaq
UMC
HMC


A certain card may be named differently such as 'Diamond Viper'( which uses
Weitek chips ) but still use one of above chipsets.


Chip families NOT supported :
===============================

XGA      \
IITAGX    == All are XGA:s.
XBE      /

The XGA should be possible to support.


8514/a + clones
Will not be supported.


+ possible unknowns.





















