home *** CD-ROM | disk | FTP | other *** search
/ Black Box 4 / BlackBox.cdr / ansi / ansit100.arj / ANSITUT.DOC < prev    next >
Encoding:
Text File  |  1992-05-01  |  11.5 KB  |  231 lines
  1.  
  2.  
  3.             ██████▄
  4.             ███  ██ ████▄ █▄   ████▄ ██     █▄ █████▄ █████▄ █████▄
  5.             ███  ██ ██  █ ██   ██    ██     ██ ██   █ ██   █ ██
  6.             ███▄▄██ ██  █ ██   ██▄▄  ██  █  ██ ██▄▄▄█ ██▄▄▄█ ██▄▄
  7.    ▓▓▓▓▓▓▓▓▓███░░░▓▓██░░█░██░░▓██░░▓▓██░▓█░▓██░██░░▓█░██░░█░▓██░░▓▓▓▓▓▓▓▓▓▓▓▓
  8.    ▓▓       ███     ██▄▄█ ██▄▄ ██▄▄▄ ██▄▄█▄▄██ ██   █ ██  █▄ ██▄▄▄▄        ▓▓
  9.    ▓▓                                                                      ▓▓
  10.    ▓▓                             PRESENTS                                 ▓▓
  11.    ▓▓                                                                      ▓▓
  12.    ▓▓           ANSIT!  ANSI driver benchmark ANSI tutorial.               ▓▓
  13.    ▓▓                                                                      ▓▓
  14.    ▓▓           This file is a small ANSI tutorial to give you the         ▓▓
  15.    ▓▓           basics of the ANSI and screen write mechanics.             ▓▓
  16.    ▓▓           It's intended for the ANSIT users, not as a general        ▓▓
  17.    ▓▓           tutorial. This file only scratches the surface, but        ▓▓
  18.    ▓▓           it's enough to make you understand what ANSIT! does.       ▓▓
  19.    ▓▓                                                                      ▓▓
  20.    ▓▓           Copyright (c) 1992 Steve Danielsson                        ▓▓
  21.    ▓▓                                                                      ▓▓
  22.    ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
  23.  
  24.  
  25.  
  26.  
  27.                           OVERVIEW OF THIS FILE
  28.               ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
  29.  
  30.         If you have a clear understanding of what an ANSI driver is, what
  31.         it does and how text is written to the screen, you don't really need
  32.         to read this file. This is intended to give some basic technical
  33.         background information concerning this benchmark.
  34.  
  35.         The contents covers Screen write techniques as well as ANSI escape
  36.         sequences. The ANSI driver supplied with DOS is called ANSI.SYS,
  37.         when I'm referring to 'ANSI driver' in this text I mean ANSI.SYS or
  38.         whatever replacement driver you're using.
  39.  
  40.         Note: If you don't know if you have ANSI.SYS loaded, check your
  41.         CONFIG.SYS file, it should include this line
  42.         DEVICE=ANSI.SYS
  43.         or perhaps something like
  44.         DEVICE=C:\DOS\ANSI.SYS
  45.  
  46.  
  47.  
  48.  
  49.  
  50.                                SCREEN OUTPUT
  51.                                ▄▄▄▄▄▄▄▄▄▄▄▄▄
  52.  
  53.  
  54.         To write text to the screen, MS-DOS calls the ROM BIOS Output
  55.         routines. If an ANSI driver (ANSI.SYS) is installed, the driver
  56.         intercepts the call, interprets the ANSI escape sequences (if any)
  57.         and then calls the ROM BIOS routines.
  58.  
  59.         It's possible to bypass the MS-DOS and BIOS routines by writing
  60.         the text directly to the screen, that is; accessing the hardware.
  61.         A lot of programs do this to get fast screen writes, but DOS
  62.         don't and the drawback is that a program doing this will work
  63.         on IBM Hardware Compatible machines only.
  64.  
  65.         Now, the trouble is that the ROM BIOS I/O routines aren't very
  66.         fast. To get around this someone came up with the idea to write
  67.         an ANSI driver (ANSI.SYS replacement) that did _not_ call the
  68.         ROM BIOS to output text, but bypassed the BIOS routines and
  69.         wrote directly to the screen. This speeds up the text output and
  70.         screen scrolling. Today there are a lot of ANSI.SYS replacements
  71.         doing exactly this.
  72.  
  73.         Another way is to write a Software BIOS, install it as a device
  74.         driver and let it replace the ROM BIOS I/O routines.
  75.         There are some Software BIOS replacements available too.
  76.  
  77.         Obviously, the effectiveness of the routines used to replace
  78.         the ROM BIOS routines depend on how well they are written.
  79.         If you load an ANSI device driver that _does_ take care of
  80.         the output itself you probably won't get a faster output by
  81.         also loading a software BIOS replacement.
  82.  
  83.         Where does the ANSIT benchmark come into all this ?
  84.         Some of the tests performed by ANSIT measure the text output.
  85.         When you run the test you will notice that an ANSI driver
  86.         that uses it's own routines to write to screen rather than
  87.         calling ROM BIOS will be _very_ much faster than drivers that
  88.         don't (for example the original ANSI.SYS).
  89.         Common sense tells us there's no reason to choose an ANSI
  90.         driver that uses the ROM BIOS output routines.
  91.         To find out who wrote the fastest replacement routines, you
  92.         got ANSIT.
  93.  
  94.  
  95.         ANSI ESCAPE SEQUENCES
  96.  
  97.         The reason the ANSI.SYS driver exists is to parse and interpret
  98.         ANSI escape sequences. So what is that ?
  99.  
  100.         American National Standards Institute (ANSI) has approved
  101.         a series of Escape Sequences used to define functions for
  102.         intelligent computer terminals. This was originally intended
  103.         as a "data terminal standard" for mainframe terminals.
  104.         Actually there isn't any terminal in existance that is completely
  105.         ANSI standard (the DEC VT-100 terminal come pretty close, though).
  106.         As usual the dream of standardization is just a dream, the
  107.         equipment manufacturers want to "develop" their products and
  108.         the development make them unique, that is; non-standard.
  109.  
  110.         Movement of the cursor, graphics functions and setting the
  111.         graphics mode are among the functions availible. The two
  112.         first are the ones that concern us here. To make MS/PC-DOS
  113.         machines (somewhat) ANSI compatible, the ANSI driver is loaded.
  114.  
  115.         The ANSI device driver is really a filter between DOS and the
  116.         hardware, intercepting all screen output, searching it for ANSI
  117.         escape sequences, parsing and executing them, if any.
  118.  
  119.         An ANSI escape sequence is a series of characters beginning
  120.         with an Escape (ASCII code 27).
  121.         What the ANSI.SYS driver (or replacement driver) does is to
  122.         interpret these escape sequences and perform the actions or
  123.         functions defined for each sequence.
  124.  
  125.         For example the sequence:  ESC [2J  is the ANSI sequence to
  126.         clear the screen (called 'ED' = Erase Display).
  127.         The ANSI-driver filters all characters from the keyboard
  128.         (or from STDIN actually) and when an escape sequence is
  129.         encountered, the driver performs the action (in this case,
  130.         clears the screen) instead of writing the escape sequence to
  131.         the screen. DOS reads a file, for example, and sends the text
  132.         in the file to the screen via the ROM BIOS (Binary Input/Output
  133.         System) routines. When the "invisible" ANSI driver finds the
  134.         escape sequence it intercepts it and performs the action defined
  135.         by the ANSI commitee instead of passing the characters on to the
  136.         ROM BIOS.
  137.  
  138.         If you like to see what (and how much) the ANSI driver
  139.         interprets for you, REMark the line in your CONFIG.SYS that
  140.         loads the ANSI driver you're using, reboot your machine and
  141.         try TYPEing the ANSI file included with this program called
  142.         TYPEME.ANS.  Since there isn't any ANSI driver to interpret all
  143.         the Escape Sequences in the file, all of them will be written
  144.         to the screen, and it will _not_ look pretty.
  145.         Then, un-REMark the line in CONFIG.SYS, reboot your machine to
  146.         load the ANSI driver again, and try TYPEing the file.
  147.         The result is the interpreted ANSI and the output is alot
  148.         better looking.
  149.  
  150.         A common ANSI escape sequence is the one used to set the text
  151.         and background colors. Think for awhile, every time a color is
  152.         changed on the screen (using ANSI) an escape sequence is sent
  153.         to the driver. The sequence we're talking about (SGR) is 6
  154.         characters long. If the color is changed 30 times in a full
  155.         screen write the driver has to interpret 180 extra characters.
  156.  
  157.         Needless to say, this takes time. The better written the
  158.         interpretation routines are, the faster they will execute.
  159.         MS-DOS original ANSI.SYS is _not_ an example of a well written
  160.         piece of software.
  161.  
  162.         So, someone wrote a faster ANSI-interpreter device than ANSI.SYS
  163.         And then someone else wrote an even faster... this is called
  164.         development. To help you determine which ANSI device driver is the
  165.         fastest, you have ANSIT!
  166.  
  167.  
  168.  
  169.         NON STANDARD ANSI ESCAPE SEQUENCES
  170.  
  171.         There are some ANSI.SYS replacement drivers that can handle,
  172.         interpret, some extended, non-standard, escape sequences.
  173.         These are often an extension to the ANSI capability to define
  174.         function keys etcetera. You may or may not have use for them.
  175.         If you don't they only make the device driver bigger, taking up
  176.         more of your RAM. No extended set of sequences can make the
  177.         standard ANSI handling go faster.
  178.  
  179.  
  180.  
  181.         PUTTING IT ALL TOGETHER
  182.  
  183.         Now, considering the above, if you have an ANSI device driver
  184.         installed that both uses the slow ROM BIOS I/O routines and
  185.         is itself slow at interpreting the ANSI escape sequences, you
  186.         do have a slow screen output. You can do much better!
  187.         An example of a device driver of this kind is the ANSI.SYS.
  188.         If you use it, get another ANSI-driver !!!
  189.  
  190.         Using one that has fast ANSI interpretation _and_ uses it's
  191.         own (hopefully well-written) routines instead of ROM BIOS will
  192.         obviously give you the fastest screen writes and ANSI handling.
  193.  
  194.         Before you start benchmarking every ANSI-driver in sight, keep
  195.         this in mind:
  196.  
  197.      *  The ANSI escape sequence handling affects animated ANSI files or
  198.         any application which uses ANSI escape sequences to change the
  199.         colors of the text or/and background, moves the cursor and so on.
  200.         This is measured by ANSIT, Test 1 and Test 3 in particular.
  201.  
  202.      *  The BIOS or replacement output routines affects anything written
  203.         to the screen using BIOS writes. It does _not_ affect applications
  204.         writing directly to the screen by accessing the hardware.
  205.         This includes all DOS output, TYPE'ing of text files and all
  206.         programs using BIOS to output text. Screen scrolling in particular
  207.         is affected!
  208.         This is measured by ANSI Test 2, Test 4 and Test 5.
  209.  
  210.         As mentioned before, this tutorial only gives you a basic knowledge.
  211.         There's a lot more to ANSI than this.
  212.         This, however, is all you need to know unless you have a special
  213.         interest in the subject. For a more detailed technical information,
  214.         refer to the Microsoft/IBM technical reference or any good litterature
  215.         concerning the ANSI terminal standard. The ANSI escape sequences that
  216.         ANSI.SYS interprets is listed in detail in the MS-DOS manual.
  217.  
  218.  
  219.         I hope this file has helped anyone on their way to understanding
  220.         ANSI, if it does, it was worth the time writing it.
  221.         The file is intended to help ANSIT! users to understand what the
  222.         benchmark tests, but if you have gained a general knowledge on what
  223.         the ANSI driver does, so much the better.
  224.  
  225.         Any error in this file is my fault only.
  226.         If you find one, whether it's a result of misspelling or
  227.         misunderstanding. Please do not change the text, write me a Netmail
  228.         about it and I'll release an updated file.
  229.  
  230.         Steve Danielsson, Stockholm, 1992.
  231.