home *** CD-ROM | disk | FTP | other *** search
/ Fresh Fish 9 / FreshFishVol9-CD2.bin / bbs / util / aibb-6.5.lha / AIBB / Version_Changes < prev    next >
Text File  |  1994-01-19  |  39KB  |  704 lines
  1.  
  2.                                 A.I.B.B.
  3.                     Amiga Intuition Based Benchmarks
  4.                        Program Release Version 6.5
  5.                     Copyright 1991-1993 LaMonte Koop
  6.                           All Rights Reserved
  7.  
  8.                        Version Change Information
  9.  
  10.  
  11.     Version series' 4.x-6.x of AIBB is a complete re-write from the original
  12. code used for the previous versions 1-3.  Being that this is the case, it
  13. is quite important that the documentation be read thoroughly in order
  14. to completely understand all aspects of the program performance.  The
  15. changes to this version series are detailed below.
  16.  
  17. Changes to version 6.5:
  18.  
  19.     --     AIBB now uses only one window instead of two for the Main and
  20.         System Information displays.  This has two advantages: One,
  21.         when AIBB used the two window system, BACKDROP windows were not
  22.         possible.  Because of this, certain requesters with depth-arranging
  23.         gadgets could end up being lost behind the currently displayed
  24.         window and thus lock the user out.  This is no longer a problem
  25.         now as the single window in use is of type BACKDROP.  Secondly,
  26.         less CHIP RAM is used in this configuration.  The downside to all
  27.         this is somewhat more time is taken when switching between the
  28.         two displays.  This is most noticable on slower systems, although
  29.         every effort has been made to minimize this delay.
  30.  
  31.     --     A race condition in the internal function UpdateSys() has been
  32.         fixed.  Previously it was possible for this function to break its
  33.         own Forbid() state under certain race situations while accessing
  34.         one of the system shared resource lists.  This could possibly
  35.         result in a list entry being pulled out from under the function if
  36.         a context switch to another task took place when the Forbid() was
  37.         broken.  The situation would be rare, but for safety reasons it has
  38.         been corrected as of this release.
  39.  
  40.     --     A bug was fixed in that AIBB would erroneously report memory
  41.         on an A1200 located at $00c00000 as being of the "SLOW-FAST"
  42.         variety.  AIBB now does consistancy checks to ensure that what it
  43.         is reporting is indeed "SLOW-FAST" or "Ranger" memory.
  44.  
  45.     --     Various internal cleanups were done including dead code/data
  46.         elimination and optimizations of existing code.
  47.  
  48. Changes to versions 6.2 - 6.4:
  49.  
  50.         *** Versions 6.2 - 6.4 were internal test releases only.
  51.  
  52. Changes to version 6.1:
  53.  
  54.     --     Some modifications were made to the way AIBB does MMU table
  55.         translations (such as looking up the ROM image location) on 68040
  56.         machines to correct a few problems and wrong results which occured
  57.         with the original setup.  Specifically, AIBB was incorrectly using
  58.         the SFC register to indicate the address space to look at with the
  59.         PTEST instruction rather than the DFC register which is correct.
  60.         This usually worked in the past as the DFC register generally
  61.         already reflected the proper address space, but in a few
  62.         circumstances erroneous results could occur.  Fixed.
  63.  
  64.     --     General code clean up and reduction has resulted in an
  65.         approximate 10K of size reduction in AIBB's executable.
  66.  
  67.     --     A few more boards were added to AIBB's internal expansion board
  68.         database.
  69.  
  70. Changes to version 6.0:
  71.  
  72.      --    AIBB has had its graphics-based tests completely re-written.
  73.         The user is now allowed to select the screen mode to be used by
  74.         AIBB when performing such tests via the "Set Gfx Test Mode" option
  75.         under the "Test Options" menu.  This is done via the ASL.LIBRARY
  76.         screenmode requester, and thus this option is not available unless
  77.         the host system is using V38 of ASL or greater (V38 is found with
  78.         the AmigaOS 2.1 enhancement).
  79.            The default screen mode AIBB uses for its graphics tests is
  80.         a high-resolution ( 640x200 ) 3 bitplane ( 8 color ) setup.  When
  81.         a new screen mode is selected for the tests, AIBB will check this
  82.         against the modes used in the comparison systems and will warn the
  83.         user if the new mode differs in equivalence, as it is necessary to
  84.         be aware of this so that the comparisons can then be weighted
  85.         accordingly. ( eg, if you run a test in a low-res 1 bitplane mode,
  86.         it will almost assuredly perform faster than in a high-res 4
  87.         bitplane mode, so this has to be taken into account when looking at
  88.         the results ).
  89.            This new option was provided for allowing the comparison of
  90.         different graphics modes on the systems used.  It can also be used
  91.         to examine the performance of some of the new graphics boards being
  92.         introduced for the Amiga. ( for example, one can see at which mode
  93.         the board ends up being slower for a given test than the default
  94.         mode used for the comparison systems ).
  95.            AIBB does save the screen mode data within its load module, so
  96.         that this information is available when a new module is loaded.
  97.         Again, when a module is loaded, checks are made against the screen
  98.         modes in use by the other loaded systems, and the host system, to
  99.         warn the user if differing graphics modes were used.
  100.            In addition to these changes, another item under the "Test
  101.         Options" menu allows the user to browse through the graphics modes
  102.         used by the comparison systems, as well as that in use by the host
  103.         system.
  104.            Please note: All of these changes have meant that AIBB's load
  105.         module and preferences file format have changed.
  106.  
  107.      --    The ability to change AIBB's primary screen colors has been
  108.         added via the use of a color requester.  Color selections are
  109.         saved to AIBB's preferences file when the "Save Configuration"
  110.         menu item is selected in AIBB's "General" menu area.  This was
  111.         added upon complaints from monochrome monitor users who were
  112.         having trouble seeing parts of AIBB's display because two or
  113.         more colors would map to the same grey shades.
  114.  
  115.      --    AIBB's help mode requesters have been removed to make room for
  116.         the changes to its graphics tests.  They were giving problems due
  117.         to a compiler bug (bad code generation) in any case, and the entire
  118.         system needs to be re-worked before being implemented again
  119.         (space allowing).  This also freed up a good deal of space for
  120.         other functions within AIBB, and unless it becomes a real problem
  121.         this may not be re-implemented...at least not in the form it has
  122.         taken thus far.
  123.  
  124.      --    AIBB will no longer show 2 gadgets on a requester when only one
  125.         option is available.  This has been changed as it was reported to
  126.         be confusing to some users when two gadgets would appear, though
  127.         they had the same text/action associated with them.
  128.  
  129.      --    Under 1.3 or earlier of AmigaOS, AIBB would sometimes call up
  130.         an Alert indicating a lack of CHIP memory for a particular
  131.         operation when in fact there was no problem.  This was due to a bug
  132.         in the AmigaOS Request() function under 1.3 and below.  This
  133.         function would not always give the proper return value, and would
  134.         make AIBB believe an error occured when it in fact hadn't.  A
  135.         workaround is in effect now for 1.3 and below within AIBB, by
  136.         looking at window->FirstRequest instead of relying on the return
  137.         value from Request() to indicate success.
  138.  
  139.      --    AIBB's TGTest has been changed again to one which carries its
  140.         measure in terms of characters/second output to the screen.  The
  141.         previous use of variously sized windows to hold the output has been
  142.         removed due to various testing which showed it to have a minimal
  143.         value in the test itself.
  144.  
  145.      --    A new entry in AIBB's memory node information reporting has
  146.         been added.  AIBB will now report the a relative "Bus latency
  147.         factor" for all FAST RAM nodes.  This figure represents the lat