🚀 go-pugleaf

        Several people (including myself) have mentioned the specs and
features of the VXL 30 accelerator by Microbotics, but I'll briefly note
the main points once more.

        Speed: 16, 25, 33, 40 or 50 Mhz.
        68EC030 or 68030, 68881 optional. Can be set to boot from 68000
or the '030. Retains 68000. No jumper wires or special software needed
to patch it in during boot. Fits inside the 500 and the 2000. The board
can swap between the 68000 and the '030 using supplied software which
forces a warm boot.

        Optional 32 bit memory board (2 or 8 Mbytes only). Autoconfigs
as Fast ram during boot. DMA compatible. Memory can be used in 68000
mode. Kickstart can be copied to 32 bit ram if the '030 has a working
MMU. 32 bit ram can be mapped past the 68000 memory map limit if needed.
If using the right type of ram chips, the '030 can use it's Fast Page
mode to access the ram at maximum speed.

        I have a 25 Mhz 68EC030 (the MMU is disabled) version. No 68881,
no 32 bit ram. The board is simple to install, provided you are careful
and know how to handle static sensitive devices. It's a snug fit inside
an A500, but everything screws back together in it's proper place. I'm
still using the origional A500 power supply and haven't noticed any
problems I can blame on power consumption. The software I use is as stable
in '030 mode as it is in 68000 mode, except for a few games (I expected
that to happen). Some programs are supplied on a disk, for swapping between
processors and fiddleing with the caches and burst modes.
        Kickstart 1.3 is able to identify the processor type ('000, '020
or '030) and identifies the '030 as an '020, but what do you expect when
you run it through the 68000 socket.

        What sort of benefits does it give? It's most noticeable under
2 situations, prolonged number crunching (ray tracing, mandelbrots, etc)
and if you like to multitask a lot. If you expect the windows to open up
faster, or the disks to read/write faster then forget it. The graphics
still runs at 7 Mhz and the disks still connect to a 16 bit bus. That part
of the Amiga won't change when you use one of these boards. The number
crunching part is obvious. Give the '030 a task that doesn't need to
continually hit disks or 16 bit ram and it will sail along. Heavy
multitasking will also improve, but if you don't have 32 bit ram, it won't
improve as much as you might expect. Constantly having to read/write to
slow 16 bit ram is a significant performance burden.

Benchmarks:

        These benchmarks were derived using AIBB Ver 2.01 (Fish disk 429)
written by LaMonte Koop.

Neither myself nor the author of AIBB can vouch for the accuracy of the
figures provided by AIBB. There are a number of "tricks" that can be
performed to get better results than those listed here.

        The system I used is a Rev 5, PAL Amiga 500 with 512K Chip and
2.5Mb of 16 bit Fast ram. The accelerator is a VXL 30 running a 68EC030
at 25 Mhz, no 68881 and no 32 bit ram.

Note: PAL Amigas are slightly slower (7.03 Mhz) than NTSC Amigas (7.14
Mhz). Keep this in mind when looking at the 68000 benchmarks.

        The figures are arranged in rows with the processor type and
cache state and the results of the 6 tests AIBB performs. All % numbers
are a comparison made by AIBB against known results from a standard NTSC
B2000. 100% is the rating of said B2000 in each test. sec = second(s),
Dcache = Data Cache, Icache = Instruction Cache.

Processor  WritePixel Dhrystone    Sort      Sieve     Savage    Matrix

68000      27.28 sec  661 Dhry/sec 12.20 sec 47.08 sec 91.96 sec 81.50 sec
           100.8%     99.2%        99.2%     102.0%    95.7%     101.5%

68030      35.32 sec  451 Dhry/sec 17.18 sec 70.48 sec 96.84 sec 90.24 sec
Dcache off 77.9%      67.7%        70.4%     68.1%     90.9%     91.7%
Icache off

68030      31.40 sec  571 Dhry/sec 13.22 sec 59.90 sec 90.28 sec 67.30 sec
Dcache on  87.6%      85.7%        91.5%     80.2%     97.5%     123.0%
Icache off

68030      21.46 sec  686 Dhry/sec 6.00 sec  16.60 sec 60.98 sec 34.68 sec
Dcache off 128.1%     103.0%       201.7%    289.3%    144.3%    238.6%
Icache on

68030      17.40 sec  965 Dhry/sec 2.38 sec  7.08 sec  52.64 sec 13.36 sec
Dcache on  158.0%     144.9%       508.4%    678.2%    167.2%    619.5%
Icache on

Best single result:  '030 with both caches on.  Sieve, 7.08 sec, 678.2%
Worst single result: '030 with both caches off. Dhrystone, 451/sec, 67.7%
Best group result:   '030 with both caches on.
Worst group result:  '030 with both caches off.

        What follows are edited notes from the AIBB 2.01 docs. I have
included these to explain what each test does and to point out where
specific results should be viewed with caution. I did not ask Lamonte
Koop for permission to do this, but under the circumstances I don't
think he will mind that much (let me know if you *do* mind LK).

============================================================================

     WritePixel:  This is a derivation of the original SetAPen/WritePixel
                  first introduced by Computer Systems Associates (CSA).
                  It draws a box on the screen one pixel at a time using
                  the OS function call Writepixel(), then erases the box
                  in the same manner.  The test is useful mainly for
                  testing the speed increase of systems which have their
                  KickStart images mapped into a 32-bit RAM environment.

     Sieve:       The Sieve test used here is the basic Sieve of
                  Erathosthenes test for prime numbers.  It searches a
                  set of 8191 numbers for primes in a loop 100 iterations
                  in length.

     Sort:        The Sort test I use here is a simple shell-sort
                  algorithm for sorting integers.  I do not use a random
                  list of numbers to sort, as that would result in different
                  benchmark times depending on the way the list turned out,
                  but rather I use my own 'mixing' method for scrambling
                  the numbers so they are mixed in the same way every time.
                  The test measures the time it takes to order the resultant
                  mess (12000 numbers).

     Savage:      This test is just a loop test of performing a series of
                  nested floating point operations on a number.  This test
                  requires the use of the Amiga's MathTrans.library, which
                  should be in your libs: directory.  NOTE:  The performance
                  figures for the other machines were obtained using the
                  mathtrans.library which comes with the WorkBench on the
                  Amiga.  There are versions of this library around which
                  map those functions and such to a math coprocessor.  If
                  you wish to compare your machine on par with the machines
                  represented internally, you should NOT be using one of
                  these other libraries.  (It would be quite an unfair
                  advantage :-) ).  If the program cannot find the
                  mathtrans.library in your libs: directory, it will inform
                  you of the problem and disable the Savage test gadget.

     Dhrystone:   This one should be fairly familiar to most people.  It is
                  a standard port of the ever-popular Dhrystone benchmark
                  used on so many systems.  It is a close port of the original
                  version written in ADA by Reinhold P. Weicker, and the
                  Modula-2 port by Joergen Thomsen.

     Matrix:      A simple matrix addition/multiplication benchmark on
                  three 40x40 integer matrices. With a loop increment
                  added to smooth out fluxuations.  The time in the loop
                  is factored out of the returned time and percentage
                  calculations.

Now, none of these tests has been 'optimized' in any way.  Thus, you may
notice that, for instance, you get a lower dhrystone/second rating on
your machine than other programs show.  This is not a problem.  Since the
comparisons are done from figures recieved from this program, running this
code, the percentage differences between machines are valid, in that sense.

       5.) The Dhrystone figures should be considered the most touchy.  You
           can surely get a good representation on a medium-grade scale, but
           do not fine-judge anything with just one reading from this test
           (or any for that matter, but this one especially).  The dhrystone
           test is particularly apt to give fluxuations due to cache
           inconsistancies on 020 and 030 machines. (or any cache-utilizing
           machine).  The fluxuations are not astoundingly large, and
           because of that I was able to take a weighted average and use
           it for the internal comparisons between machines. (a weighted
           average was taken for all internal comparison machines.).

                              LaMonte Koop
                        565 Park Meadows Dr. #302
                          Waite Park, MN  56387

==============================================================================

           Bull@vaxc.cc.monash.edu.au  OR  bull@monu1.cc.monash.oz
                      Alias: Gareth Bull, The Opal Dragon
                    DOD# 251  '84 VF 750   Closet Ducatisti
      Disclaimer: " If this was a perfect world, we'd all have Ducatis "

B