home *** CD-ROM | disk | FTP | other *** search
-
- A.I.B.B.
- Amiga Intuition Based Benchmarks
- Program Release Version 6.5
- Copyright 1991-1993 LaMonte Koop
- All Rights Reserved
-
- Version Change Information
-
-
- Version series' 4.x-6.x of AIBB is a complete re-write from the original
- code used for the previous versions 1-3. Being that this is the case, it
- is quite important that the documentation be read thoroughly in order
- to completely understand all aspects of the program performance. The
- changes to this version series are detailed below.
-
- Changes to version 6.5:
-
- -- AIBB now uses only one window instead of two for the Main and
- System Information displays. This has two advantages: One,
- when AIBB used the two window system, BACKDROP windows were not
- possible. Because of this, certain requesters with depth-arranging
- gadgets could end up being lost behind the currently displayed
- window and thus lock the user out. This is no longer a problem
- now as the single window in use is of type BACKDROP. Secondly,
- less CHIP RAM is used in this configuration. The downside to all
- this is somewhat more time is taken when switching between the
- two displays. This is most noticable on slower systems, although
- every effort has been made to minimize this delay.
-
- -- A race condition in the internal function UpdateSys() has been
- fixed. Previously it was possible for this function to break its
- own Forbid() state under certain race situations while accessing
- one of the system shared resource lists. This could possibly
- result in a list entry being pulled out from under the function if
- a context switch to another task took place when the Forbid() was
- broken. The situation would be rare, but for safety reasons it has
- been corrected as of this release.
-
- -- A bug was fixed in that AIBB would erroneously report memory
- on an A1200 located at $00c00000 as being of the "SLOW-FAST"
- variety. AIBB now does consistancy checks to ensure that what it
- is reporting is indeed "SLOW-FAST" or "Ranger" memory.
-
- -- Various internal cleanups were done including dead code/data
- elimination and optimizations of existing code.
-
- Changes to versions 6.2 - 6.4:
-
- *** Versions 6.2 - 6.4 were internal test releases only.
-
- Changes to version 6.1:
-
- -- Some modifications were made to the way AIBB does MMU table
- translations (such as looking up the ROM image location) on 68040
- machines to correct a few problems and wrong results which occured
- with the original setup. Specifically, AIBB was incorrectly using
- the SFC register to indicate the address space to look at with the
- PTEST instruction rather than the DFC register which is correct.
- This usually worked in the past as the DFC register generally
- already reflected the proper address space, but in a few
- circumstances erroneous results could occur. Fixed.
-
- -- General code clean up and reduction has resulted in an
- approximate 10K of size reduction in AIBB's executable.
-
- -- A few more boards were added to AIBB's internal expansion board
- database.
-
- Changes to version 6.0:
-
- -- AIBB has had its graphics-based tests completely re-written.
- The user is now allowed to select the screen mode to be used by
- AIBB when performing such tests via the "Set Gfx Test Mode" option
- under the "Test Options" menu. This is done via the ASL.LIBRARY
- screenmode requester, and thus this option is not available unless
- the host system is using V38 of ASL or greater (V38 is found with
- the AmigaOS 2.1 enhancement).
- The default screen mode AIBB uses for its graphics tests is
- a high-resolution ( 640x200 ) 3 bitplane ( 8 color ) setup. When
- a new screen mode is selected for the tests, AIBB will check this
- against the modes used in the comparison systems and will warn the
- user if the new mode differs in equivalence, as it is necessary to
- be aware of this so that the comparisons can then be weighted
- accordingly. ( eg, if you run a test in a low-res 1 bitplane mode,
- it will almost assuredly perform faster than in a high-res 4
- bitplane mode, so this has to be taken into account when looking at
- the results ).
- This new option was provided for allowing the comparison of
- different graphics modes on the systems used. It can also be used
- to examine the performance of some of the new graphics boards being
- introduced for the Amiga. ( for example, one can see at which mode
- the board ends up being slower for a given test than the default
- mode used for the comparison systems ).
- AIBB does save the screen mode data within its load module, so
- that this information is available when a new module is loaded.
- Again, when a module is loaded, checks are made against the screen
- modes in use by the other loaded systems, and the host system, to
- warn the user if differing graphics modes were used.
- In addition to these changes, another item under the "Test
- Options" menu allows the user to browse through the graphics modes
- used by the comparison systems, as well as that in use by the host
- system.
- Please note: All of these changes have meant that AIBB's load
- module and preferences file format have changed.
-
- -- The ability to change AIBB's primary screen colors has been
- added via the use of a color requester. Color selections are
- saved to AIBB's preferences file when the "Save Configuration"
- menu item is selected in AIBB's "General" menu area. This was
- added upon complaints from monochrome monitor users who were
- having trouble seeing parts of AIBB's display because two or
- more colors would map to the same grey shades.
-
- -- AIBB's help mode requesters have been removed to make room for
- the changes to its graphics tests. They were giving problems due
- to a compiler bug (bad code generation) in any case, and the entire
- system needs to be re-worked before being implemented again
- (space allowing). This also freed up a good deal of space for
- other functions within AIBB, and unless it becomes a real problem
- this may not be re-implemented...at least not in the form it has
- taken thus far.
-
- -- AIBB will no longer show 2 gadgets on a requester when only one
- option is available. This has been changed as it was reported to
- be confusing to some users when two gadgets would appear, though
- they had the same text/action associated with them.
-
- -- Under 1.3 or earlier of AmigaOS, AIBB would sometimes call up
- an Alert indicating a lack of CHIP memory for a particular
- operation when in fact there was no problem. This was due to a bug
- in the AmigaOS Request() function under 1.3 and below. This
- function would not always give the proper return value, and would
- make AIBB believe an error occured when it in fact hadn't. A
- workaround is in effect now for 1.3 and below within AIBB, by
- looking at window->FirstRequest instead of relying on the return
- value from Request() to indicate success.
-
- -- AIBB's TGTest has been changed again to one which carries its
- measure in terms of characters/second output to the screen. The
- previous use of variously sized windows to hold the output has been
- removed due to various testing which showed it to have a minimal
- value in the test itself.
-
- -- A new entry in AIBB's memory node information reporting has
- been added. AIBB will now report the a relative "Bus latency
- factor" for all FAST RAM nodes. This figure represents the latency
- between a memory cycle, and when another cycle can be performed.
- Lower ratings indicate better response times for a particular
- memory node, with the unattainable goal of 0.0 indicating that no
- latency occured at all. Basically, this gives information as to
- the relative efficiency of various memory nodes. (eg, one with a
- rating of 5.0 would be more efficient, and hence faster than one
- with a rating of 7.0.). Note that this can only be used as a
- valid comparison across systems if other factors such as processor
- type, clockspeed, and bus width are also taken into account. This
- figure is most useful in comparing two different memory regions on
- similar systems, such as two memory boards on a 68030 based system
- against each other for relative efficiency.
-
- -- Two new tests have been added to AIBB's lineup. The first,
- "EllipseTest" is a simple test of one of the Amiga's more complex
- drawing functions, DrawEllipse(). A series of elliptical shapes
- is drawn, with the function timed for speed comparisons. The
- second test, known as LineTest, tests the Amiga's speed at various
- line drawing jobs. This test reports its results in terms of
- Lines Drawn per Second.
-
- -- File requester capability has been added to the Load Module
- Preferences requester as per recommendation by various people.
- The gadgets marked "FR" next to each string input gadget will
- bring up a file requester for that particular entry. This
- alleviates the need to type in path/file names for selecting
- default modules to load up when AIBB is initialized.
-
- -- A bug with AIBB's low memory situation handling has been fixed.
- Previously, it was possible for AIBB to crash in a low memory
- situation when it couldn't open a screen or window. This has been
- corrected in this version and AIBB should now properly handle these
- events.
-
- -- Changes have been made to AIBB's FPU clock rate evaluation.
- Under previous versions, low results could be reported for the FPU
- clock rate when the host system was running a high-clocked FPU
- (~50 MHz) with a moderate to low-clocked CPU (~16 MHz). This
- showed u,p on the A1200 operating with external expansion boards
- equippedwith high-speed FPUs. The changes made here attempt to
- smooth out this difference and give more accurate results for FPU
- clock rate on these systems.
-
- __ AIBB now uses gadgets rather than menu items for CPU cache
- control. The gadgets are located on AIBB's main screen in the
- cache status indicator area.
-
- -- Moving from AIBB's main screen to its system information
- display is now accomplished by clicking on the appropriate
- gadget near the comparison information area corresponding to the
- machine information is desired on. Previously, AIBB used a
- menu arrangement under the "Systems" menu to move to this
- display, and this was complained about as being "clumsy" to
- operate. The new gadgets are located under the "System Comparison
- Information" section of the main screen, and are set up as the
- row headers for that area.
-
- -- AIBB now encorporates gadgets rather than menu items for
- changing code types used in tests and evaluations. Previously,
- menu items under the menu "Test Options" were used to change the
- test code types for both the host system and comparison machines.
- This turned out to be more work for the user than necessary, and
- hence the gadget approach was adopted. The gadgets are located
- next to the evaluation results on the main screen, and allow for
- cycling through the various CPU/FPU code types available for a
- given system.
-
- -- A bug with AIBB's MMU table parsing mechanism has been fixed.
- AIBB normally will parse any active MMU tables in order to find the
- physical location of various system objects. However, a bug was
- discovered in how AIBB parses tables utilizing long (64 bit) table
- descriptors. This was originally thought to be fixed some time
- ago, but recently it became obvious this was still in error. This
- is now fixed and should properly find physical memory locations
- under these MMU setups as well as others.
-
- -- AIBB was inadvertantly making a 2.0+ only OS call within its
- procedures to close a log file being written to. This could lead to
- a failure and crash on systems runing 1.3 or earlier versions of
- AmigaOS. This has been corrected as of this version.
-
-
- Changes to version 5.5
-
- -- The default A3000 internal comparison machine is one using
- AmigaOS 2.x now instead of 3.0 as in the previous 5.0 release
- of AIBB. This is to reflect the fact that AmigaOS 3.0 is not
- openly available for the A500/A2000/A3000 series machines
- presently.
-
- -- AIBB no longer checks for, nor has problems with Enforcer
- running on the system. Therefore, the option to avoid testing
- for it has been removed from the CLI/Icon Tooltypes checking.
- Note that although AIBB coexists fine with Enforcer now, such
- should not really be used when testing as the MMU table lookups
- which Enforcer causes can affect peformance to some degree.
-
- -- A bug with AIBB's cache selection menu items has been corrected.
- In version 5.0, AIBB would not disallow selection of the data
- cache enable/disable menu item on a stock 68000 based machine.
- Selection of this could cause a system failure on a 68000 system
- (which has no caches), and has been fixed in this version.
-
- -- Several test result indicators have changed. The Writepixel
- test no longer gives data in terms of execution time, but rather
- a rating of pixels output per second by the routine. The MemTest
- routine gives its results in megabytes of data transferred per
- second. This change was made to make the results more context
- readable.
-
- -- The TGTest test has been updated. The new version reflects
- effects occuring in a windowed environment for more accurate
- representation of the Amiga under such circumstances. As such,
- AIBB's load file format has -CHANGED- again. Unfortunately, test
- updates do require this action, though I am actively seeking
- a remedy for these inconvieniences.
-
- -- A new test called "EmuTest" has been added in the area of
- "special: tests for AIBB. This test is basically a small
- CPU emulator core running an instruction set simulation
- (basically a small program). The Amiga seems to have gained
- a bit of a precedence in CPU emulation, and I put together this
- test for the purpose of showing various systems' ability to
- perform such emulation efficiently and speedily. The simulated
- CPU is a standard 68000, though the results from this can be
- taken as indicative of other CPU emulators as the basic
- principle is the same. All instructions and internal operations
- are completely software emulated. The results for this test are
- given in Simulated MegaHertz, basically a rating showing how
- fast the emulation is towards an equivalent hardware-based
- CPU.
-
- -- A change was made in how AIBB stores its test timing data.
- Previously, this data was kept (both internally and in the
- load files) in longword (32 bit) integer format. However, due
- to some internal changes, this data is now kept in IEEE double
- precision floating-point format (64 bits). This was done to
- help avoid rounding errors and make internal calculations simpler.
-
- -- By request, standard keyboard shortcuts have been added to
- selected portions of AIBB's menus.
-
- -- Fixed a problem with Parse_MMU_Table(). This function was
- not correctly parsing long-format (double longword) sized
- descriptor tables. This has been corrected and these tables
- and the addresses AIBB attempts to correlate when looking at
- functioning MMU setups should be checked correctly. The bug
- did not show up under any currently used MMU setups on the
- Amiga, but could possibly have shown up in the future. This
- correction assures AIBB will be able to locate physical memory
- addresses from logical ones when reporting the location of
- certain items given in its display.
-
- -- Added some checks in AIBB's System Information Display to
- prevent unnecessary redrawing of parts of the display. This
- enhancement should speed things up a bit for slower machines.
-
- -- AIBB's 68030/68EC030 detection code has been revised again.
- The new method used should provide a somewhat safer determination
- method than the previous way.
- The old method relied to write protecting a page in a
- translation table setup, then writing to the page and checking for
- a bus error situation. Unfortunatly, as it turns out some strange
- interactions can occur in the way this was set up if the
- translation table was located in a 16-bit ported RAM resource.
- The method used now is much safer. Instead of write protecting
- a page, nothing is done whatsoever except for a straight-through
- early-termination one-level setup. Once the MMU is activated,
- a single read is done from a given page, and then the "U" bit
- in the corresponding page descriptor is examined. With an active,
- functional MMU, this bit should be set upon the first access to
- a given descriptor, and will be set in the test case above. On
- 68EC030 based machines, which have no functional MMU, this bit will
- be unaffected.
- An added side-effect of these changes is that AIBB no longer
- needs as large of a translation table as it did with the earlier
- method. A 16 byte table (first level only - upper 2 bits of the
- logical address are used for indexing) is all that is required now,
- as opposed to the 16K byte table used before. As a result, AIBB
- will almost always be able to allocate memory for a table and will
- not be forced to abort the test due to memory constraints.
-
- -- Fixed a minor memory loss situation. AIBB was losing about
- 40 bytes of memory per incarnation due to a port not being deleted
- upon exit. This has been corrected as of this revision.
-
- -- A bug with the internal function Scale_Graph() has been
- corrected. In previous versions, certain odd input circumstances
- could create a worst-case scenario in this function resulting in a
- scaling to infinity. The result of this was usually a garbled
- screen full of strange display artifacts, and assorted memory
- trashing as AIBB overwrote its RastPort boundaries. Additional
- checks have been added to avoid this problem.
-
- -- A bug with AIBB's code type selection for comparison systems
- has been fixed. Earlier, if a module was using 68040 Math code
- and was then replaced by loading a new module incapable of
- using FPU math at all, 68040 Math code would remain selected.
- Normally, AIBB should have stepped the selected type down to
- Standard Math Code. This bug could have caused problems ranging
- from strange results to system failures under these circumstances.
-
- -- An addition was made to AIBB's System Information Display.
- As well as showing memory nodes and expansion devices, AIBB will
- also show information pertaining to various pertinent system
- libraries (location, version/revision, etc...). The only libraries
- included in this are those which may have an effect on performance
- issues where AIBB is concerned. Note that for the memory addresses
- given for each library, the actual node location and memory
- node characteristics can be determined by looking at the various
- system memory nodes and finding the proper one.
-
- -- AIBB now dynamically looks at the system display type in use
- whereas before it only did this on a static at-startup basis.
- This was done to more accurately reflect a systems current true
- state.
-
- -- AIBB's preferences file format has been changed, and thus
- requires the replacement of old preferences files. This was done
- to add an ID field to the file so that invalid preferences could
- not accidentally be loaded. This had occured in several incidents,
- so this action was taken as a preventative measure.
-
- -- Some minor cosmetic changes were made to various areas of the
- program, including requesters and general display characteristics.
-
- Changes to version 5.0
-
- -- AIBB has been recompiled using SAS/C 6.0, resulting in both
- space savings and a general speed up in code.
-
- -- Note that AIBB's load file format has changed. Previous load
- files will NOT work with this version. As of this release, I
- am attempting to freeze the load file format so that further
- inconvieniences do not occur.
-
- -- A bug with AIBB's cache control menu items has been fixed.
- In previous releases, AIBB would request the system CPU type if
- it was not able to determine such by individual means. This
- occured for checks between the 68EC030 and 68030, and also for
- determining the existance of the 68EC040 or 68LC040, if
- warranted. However, AIBB would also erroneously disable the
- cache switching menu items if such a request for CPU identification
- was made. This problem should no longer occur.
-
- -- An expansion board indentification lookup table has been added
- internally to AIBB, allowing various system expansion boards to
- be identified by name. This table is by no means complete, and
- will be added to in the future (unlisted boards are given a
- "No Information Available" entry when referenced). This
- information is found under AIBB's System Information Display when
- viewing system expansion devices.
-
- -- A change has been made in the comparison systems AIBB uses.
- The current default systems AIBB contains are now the A4000,
- A3000, A2000 (with FAST RAM), and A500 (stock, no FAST RAM).
- These systems represent a spread of Amiga models currently
- available.
-
- -- Some of AIBB's CLI/Shell arguments have been changed to
- reflect internal changes to the program. Please note the new
- assignments for CPU/FPU/MMU types (if used) in the main
- documentation file. This is important - using the incorrect
- assignment if these options are necessary may result in
- unexpected program behavior.
-
- Changes to version 4.65
-
- -- AIBB will now request the user to identify whether a 68EC030
- or standard 68030 exists on such systems, or between a 68LC040
- and 68EC040 if conditions warrant. Previous releases simply
- made a processor assumption if situations did not allow for a
- full internal test for the processor type. As of this version,
- the user will be prompted for the correct processor type if this
- situation arises. This was added for accuracy, and some
- safety considerations.
-
- -- The memory port width testing code AIBB uses has been changed.
- The new code used is more accurate, and better able to handle
- a wide variety of memory response configurations.
-
- -- Proper identification of the new custom chips is not done
- within AIBB. Both the new Alice and Lisa devices will be detected
- and shown on the System Information Display portion of AIBB.
-
- -- Under V39 (3.0) of AmigaOS and above, certain CHIP RAM
- characteristics will be recorded and displayed in the System
- Information Display in the memory node information area. These
- include CAS characteristics of CHIP memory, and other related
- bandwidth information.
-
- -- Several "safety measure" improvements have been made internally
- to AIBB to close several holes which could cause user problems.
-
- -- AIBB will now copy the paths of load file modules to the
- load file preferences when they are first called up. This allows
- user selection of available modules from the standard requester
- used when gathering such modules.
-
- Changes to versions 4.58 - 4.61
-
- -- Some display bugs were discovered and corrected in these
- interim releases. Also, some additional work was done on AIBB's
- 68030/68EC030 detection. Version 4.61 corrected a problem with
- 4.60's erroneous display of the system's graphics and display
- chips.
-
- Changes to version 4.57
-
- -- A rather nasty bug cropped up in version 4.56 pertaining to
- the way AIBB tested for an MMU on the system. This led to AIBB
- hanging on startup with certain system configurations. The
- bug is now corrected in this version.
-
- Changes to version 4.56
-
- -- Minor changes made to AIBB's 68EC030 testing to improve
- memory usage. A number of small changes were also made elsewhere
- to this effect as well.
-
- -- Specific time-dependent routines within the interface have been
- downcoded to assembly for speed purposes.
-
- Changes to version 4.55
-
- -- AIBB's system information display has been changed. No longer
- is a simple area used to display memory nodes existing on the
- system. In its place, a similar area exists, which can be used
- to show either memory nodes, or expansion boards contained
- in the system AutoConfig board lists. Selection of one of these
- displays is done dynamically by means of gadgets. Please see
- the main documentation for full information.
-
- -- A new menu item on the main screen, "Show Aggregate Results"
- exists under the "Special" group. This item will allow the
- viewing of aggregate system results after an initial system load
- module is performed on the host. The main documentation includes
- full details on this item's use.
-
- -- AIBB now uses the graphics.library DisplayInfo database under
- V36 and above of the OS (2.0 or higher) rather than other means
- to determine the system display characteristics. This avoids
- unecessary hardware peeking and enhances future compatibility.
-
- -- An annoyance bug with AIBB's startup has been corrected. In
- certain circumstances (especially on single-floppy systems) when
- AIBB is in its initial startup phases, the program may seem to
- suddenly stop on a blank screen. This is because the system
- was requesting a different volume (usually the main system disk)
- to be inserted. However, AIBB's screen was made home to such
- requesters, but too soon - The screen colors were all still black,
- thus rendering the system requester invisible. Now, AIBB waits
- until it is up and running before transfering the system requester
- location to its own screen so that these requesters will be
- visible should the appear (note that in terms of
- "system requesters", this referrs to requesters related to AIBB's
- process only).
-
- -- A bug with the detection of the 68EC030 CPU has been corrected.
- The method used to detect the EC030 is a fairly straightforward one.
- If the MMU ENABLED bit is set in the translation control register
- ( TC ), AIBB assumes that a working MMU exists, and that the CPU
- is a standard 68030. If this bit is not set, a more thorough test
- is performed. This test involves setting up a simple translation
- table, marking a page as 'write protected', and attempting a
- write to that page. If a bus error occurs, this will have been
- caused by the MMU, and thus it must be functional - implying a
- standard 68030. If no bus error is forthcoming, the CPU is thus
- marked as a 68EC030.
- The bug was detected only as a fluke, but could show up in other
- systems in an odd circumstance. Earlier versions of AIBB write
- protected the page in question, turned the MMU on, then installed
- a bus error handler. This order was incorrect...the circumstance
- in question came up when the system exception vector table was
- moved by use of the Vector Base Register ( VBR ). If that table
- happened to reside in the page AIBB write protected, the
- installation of the bus error handler pointer in that table would
- cause a bus error itself -- this would hang the system as the
- proper error handler would not be installed (the write to do so
- would be suspended). This has been corrected. Thus far, it has
- not shown up on other systems, but this will make it more
- bullet-proof in that respect.
-
- -- A rather obscurely discovered Enforcer hit with AIBB has been
- corrected. Under strange circumstances, AIBB could cause a READ
- Enforcer hit during its file-requester procedures. This was
- benign, but nevertheless has been corrected.
-
- Changes to version 4.5
-
- -- PLEASE NOTE THAT AIBB'S LOAD FILE FORMAT HAS CHANGED AS OF THIS
- VERSION! Previous load file formats will no longer be loaded. I
- have frozen the load file format as of this version, so no future
- changes will cause this incompatibility, or some form of conversion
- ability will be given.
-
- -- New routines have been added for 68040 floating point math
- support. The 68040 does not have transcendental function support
- within its built-in FPU, and thus must rely on software emulation
- for such routines. Unfortunately, the method of such emulation
- requires that the FPU jump to a trap routine after encountering such
- a transcendenal function instruction, such as FSIN.<fmt>. The
- 68040 FPU reacts to such instructions by causing an unimplemented
- instruction exception, and fetching the appropriate exception
- routine vector from the system exception vector table. Once jumping
- to the appropriate routine, it is said routine's responsibility
- to determine the instruction which caused the exception, and
- react accordingly. In the case of the FPU instructions not
- implemented, the routine must emulate these instructions and set up
- the return result before returning the CPU/FPU to normal processing.
- The unfortunate part to all this is that although the supported
- instructions in the 68040 FPU are highly optmized, and much faster
- than earlier coprocessor equivalents, the overhead involved with
- the trap routine method of emulation is so much so that it negates
- the gain made by the optimizations. This is where in-line code
- support comes to an advantage with the 68040 FPU, and AIBB attempts
- to do this by making function calls to optimized equivalent math
- routines, rather than allow the trap handling technique to handle
- unimplemented FPU instructions. Hopefully this will show somewhat
- of a performance improvement on transcendenal-intensive routines
- such as the Savage benchmark.
-
- -- AIBB now accepts certain command-line/icon tooltype options.
- Please refer to the documentation for a description of these
- options.
-
- -- A new comparison is now made upon completion of a load module
- or all-tests run. AIBB will open a small requester-like window
- after all tests are completed giving a rundown average comparison
- in both integer/graphic and floating-point categories. The index
- values given represent overall average figures taking into account
- all tests in a given category.
-
- -- The WritePixel test has been updated. It is now longer and
- performs more graphics operations.
-
- -- A new test has been incorporated - InstTest. This test is an
- instruction execution timing setup, and will give results in
- Instructions/Second. It is a special test, and is not affected by
- the individual system code type settings. Please read the
- appropriate section in the documentation for more information.
-
- -- AIBB's primary screen has been reduced from a 4-bitplane
- ( 16 color ) setup to a 3-bitplane ( 8 color ) one. This should
- speed up refresh time and responsiveness of the program to some
- extent.
-
- -- A number of internal routine optimizations have been made to
- increase overall program efficiency.
-
- Changes to version 4.3
-
- -- AIBB can now be made to incorporate load files upon startup
- as the default comparison systems. A new entry under the
- General menu, "Load Module Prefs" allows load modules to be
- selected by path/filename for loading into AIBB upon startup.
- This allows alternate comparison systems to be more easily
- used as manual loading of them is no longer necessary if they
- are frequently used instead of the defaults.
-
- -- Corrected a minor problem with AIBB's data display. Under
- Review Mode, AIBB would not change the system base immediately
- when a new base was selected and there was no test data for
- the host system in reference to any particular test. This
- has been changed so that AIBB handles this condition correctly.
-
- -- Improvement of AIBB's memory bus port width determining code has
- been added. Some 68040 boards with 32-bit memory were being
- incorrectly noted as having 16-bit ports. In addition, a few
- 68030 accelerators without memory were having 16-bit resources
- on the system erroneously reported as 32-bit ported devices.
- This has hopefully been corrected in this release.
-
- Changes to version 4.2
-
- -- The ability to display data in Review Mode, without having to
- perform a given test on the host system itself has been added.
- This allows the viewing of comparison system data without having
- to perform a given test on the host itself. The host system
- will display "N/A" in appropriate locations if no data is
- available for a given test.
-
- -- 68040 systems would display Write Allocation and BURST mode
- operations for cache status incorrectly. Write Allocation is
- not a seperate entity as with the 68030 for the data cache,
- and thus this mode is not displayed for the 68040 now. BURST
- mode operations for both instruction and data caches are hardware
- controlled on the 68040, and always implied. The caches do not
- have a software-controllable setting for this mode as with the
- 68030, therefore this mode is always indicated as ON with a
- 68040 system now.
-
- -- Corrected a bug with AIBB's MMU table parsing code. AIBB would not
- have correctly handled 8-byte descriptor entries in 68851 or 68030
- MMU tables as it was. This has been fixed so that AIBB will
- properly parse these entries as well.
-
- -- Bug pertaining to error output strings for the initialization abort
- routine was fixed. A string was improperly terminated resulting in
- an output error and possible crash for certain startup abort
- conditions.
-
- -- Utility ModInfo was not displaying proper MMU status information for
- 68040 system modules. This has been corrected. ModInfo now stands
- at version 1.2.
-
- -- Documentation improvements and update information added.
-
- -- General code clean up performed and further optimization of
- various routines.
-
- Changes to version 4.1
-
- -- Fixed a bug with certain 68040 system configurations which caused
- AIBB to hang on startup.
-
- Changes to version 4.01:
-
- -- Fixed a bug pertaining to early versions of the kd_freq.library.
- Apparently early versions of this library would crash AIBB during
- startup due to a problem with the library itself. Later library
- versions work fine. AIBB will therefore not open kd_freq.library
- unless the version number is 3 or greater.
-
- -- A bug with the the included AIBB utility ModInfo was discovered.
- Incorrect information was given pertaining to load modules under
- certain circumstances. This has been corrected.
-
- Primary new features to version 4.0 include:
-
- -- Improved CPU/FPU clock speed evaluation code. Earlier versions
- had a great many problems in this area, primarily due to a
- misplaced NOP instruction wreaking havoc with the timings.
-
- -- Enhanced/additional tests. Some tests in earlier versions were
- proven to be non-useful in any real form and were removed.
- The remaining tests were enhanced and refined, and new tests
- were added to further complete the package.
-
- -- Improved system information. More pertinent information is
- given towards evaluation of AIBB's benchmark performance.
-
- -- Module save/load capability. AIBB now incorporates the ability
- to create "load modules" consisting of saved test/machine
- evaluations. These modules may be loaded into AIBB at convienience
- and used within comparisons. This is an effort to allow
- comparisons across many machine types, rather than restricting
- them to in-built figures. A set of internal defaults is included.
-
- -- AIBB has been made more "aware" of the system it is operating
- on and will attempt to keep users informed of situations which
- may prove detrimental to performance analysis.
-
- Further description of these and other features is found in the main
- documentation.
-
-