AminetAminet
Search:
84451 packages online
About
Recent
Browse
Search
Upload
Setup
Services

driver/media/vbak2091.lha

Mirror:Random
Showing:m68k-amigaosppc-amigaosppc-morphosi386-arosi386-amithlonppc-warpupppc-powerupgeneric
No screenshot available
Short:A2091 driver patch - V1.5 (19.12.2007)
Author:Volker Barthelmann, Andreas R. Kleinert
Uploader:info ar-kleinert de
Type:driver/media
Architecture:m68k-amigaos
Date:2007-12-20
Download:http://aminet.net/driver/media/vbak2091.lha - View contents
Readme:http://aminet.net/driver/media/vbak2091.readme
Downloads:2015

    vb2091 (vbak2091) V1.5 (19.12.2007)

    (c) in 1994 by Volker Barthelmann,
    modified 1996-97 by Andreas R. Kleinert,
    re-uploaded 2007 with updated documentation.

    USAGE AT YOUR OWN RISK. NOBODY CAN BE HELD RESPONSIBLE FOR ANY DAMAGES.

    THERE IS NO FUNCTIONAL CHANGE IN THIS RELEASE - THE MAIN REASON TO MAKE
    AN UPDATE AGAIN AFTER 10 YEARS WAS TO EMPHASIZE AGAIN THAT ALL A2091
    ROMS FROM COMMODORE ARE SEVERELY BROKEN AND THAT IT DOES _NOT_ MAKE
    SENSE TO RUN AN A2091 IN AN A4000 WITHOUT GURU-ROM.

PREFACE
                 This is a slightly reworked version of vb2091 by Volker
Barthelmann.

                 When running vbak2091 it may make sense to install
                 the following programs (in this order), too:

                    C:FastExec NOEXEC FASTSSP FASTVBR FASTEXP FASTMEM FASTINT
REBOOT
                    C:LoadV43Module c:a1000.ld.strip REBOOT
                    C:SetPatch QUIET
                    Run C:MapBoard A2091
                    Run C:vbak2091 [OPTIONS]
                    C:NSDPatch PCF DEVS:NSDPatch.cfg QUIET

                 Note the following:

                  - all programs should be called as "[command] >NIL: <NIL:"
                    or "Run >NIL: <NIL: [command]" (has been shortened above).
                  - FastExec is recommended (Aminet).
                  - LoadV43Module (and the scsi.device V43 patch strip) can
                    be found on ftp.amiga.de (Beta).
                  - SetPatch V43 is recommended. Can be found on ftp.amiga.de
(Beta)
                  - you have to supply additional options for "vbak2091" (see
below)
                  - MapBoard can be found on Aminet. It will drastically
increase
                    the speed that can be reached in conjunction with vbak2091
                  - NSDPatch turns the old A2091 scsi.device V37.x into a 'new
style'
                    device and thus should be installed *after* vbak2091.
                    Can be found on ftp.amiga.de (Unsupported).
                  - you may also wish to install the newest FastFileSystem V43
beta
                    version on the related hard disk partitions.
                    Can be found on ftp.amiga.de (Beta)

                 The above configuration basically worked for me - you have to
                 test for yourself whether the newest versions of the concerned
                 tools will work as well with your system configuration.

                 Included you find the compiled SAS/C version (vbak2091),
                 the SAS/C, GCC and VBCC-aware source code (vbak2091.c)
                 and the original source code of the last public Aminet
                 release (vb2091.c).

                 So you can easily see, what the program is doing.

                 Feel free to modify and improve the source code,
                 but tell us before releasing it !

                 Neither me nor Volker will take any responsibility
                 for any results out of the usage of this program;
                 neither for any damages nor any loss of data, nor
                 anything else. It's your own risk!

                 Following is the original documentation (note, that
                 the remark on ixemul.library is obsolete - see also
                 history.txt).

INTRODUCTION

    ZorroII boards can only reach the lower 16MB of address space. So DMA
    SCSI controllers must find another way to transfer data to expansion
    RAM. Some of them (especially the A2091) do a very bad job in this
    situation. In an A4000/40 transfer rates may drop to 50KB/s.
    This program patches the (2nd.)scsi.device to use MEMF_24BITDMA
    RAM as a buffer followed (in case of CMD_READ) by CopyMem().
    It was developed with the A4000/A2091 combinbation in mind, but
    should work with other configurations, too (see REQUIREMENTS). Some
    people reported good results with GVP controllers.

    There have been some bugfixes, additional options and changes of the
    commandline options since the last public release. So I am afraid all
    users of previous versions will have to read this manual again
    (especially the USAGE section).


FEATURES

    There are already some PD utilities floating around that do a similar
    job. So why may this one be better?

    - It patches the device instead of the Read() & Write() DOS-functions,
      giving the following advantages:

      o Programs accessing the device directly (e.g. SysInfo, SCSI-Speed
        or tape-handlers) are patched, too.
      o Patching Read() doesn't seem to have any influence on LoadSeg(), so
        those patches don't speedup loading of programs whereas vb2091 does.
      o It is possible to use double-buffering and load into one buffer
        while copying the contents of the other one to fastram. This makes
        higher transfer rates possible. I wasn't able to get more than
        800KB/s with DOS-level-patches, but could get over 1MB/s with
        vb2091.

    - Some early A4000s (including mine :-( ) can't do DMA to onboard ram.
      On such A4000s every transfer to/from chipmem will cause the
      computer to hang. vb2091 can be told to redirect those transfers too.

WARNING

    FIRST: READ THIS ENTIRE FILE BEFORE TRYING OUT vb2091 !!
    (This is meant seriously - I know this is a very badly written manual,
    but it mentions some very important points.)

    This program is still beta and I can't give any warranty about anything.
    I have tested it for some time and have not encountered serious
    problems, but had no opportunity to test vb2091 on other configs,
    so there may still be many bugs.
    It seems to work fine with my system (A4000/40, broken DMA, A2091/7.0
    ROMs, Quantum LPS270S+LT730, Tandberg streamer) in conjunction with
    MapBoard, however there may be problems with the serial port.

REQUIREMENTS

    vb2091 has been compiled with gcc, so it needs ixemul.library in libs:
    and ENV: assigned. Keep this in mind when placing it in Your startup-
    sequence. There will probably be a version that has been compiled with SAS
    in this distribution. This version doesn't have these requirements.

    As it uses the exec-functions CopyMem()/CacheControl(), it doesn't work
    with early versions of Kickstart (sorry, I don't know since when these
    functions are present - probably since 2.0).
    vb2091 does not check for a correct version at the moment (sorry).

    You must have some MEMF_24BITDMA RAM (e.g. RAM on the controller or
    chipmem) to be used as a buffer.

    I hope I haven't forgotten anything (of course a controller and some
    expansion RAM would be quite useful).


USAGE

    [run] vb2091 UNIT <unitlist> [DEVICE <device>] [BUFSIZE <bufsize>]
                 [MAXN <number>] [MIN1BUF <size>] [MIN2BUF <size>]
                 [BROKEN] [SINGLE] [NOCACHE] [NOWRITE]

    All the keywords must be uppercase! (sorry)

    UNIT    List of unitnumbers of devices to be patched, not separated by
            spaces or commas, e.g. 014 for device 0, 1 and 4.
            (default: no default - this MUST be specified)

    DEVICE  Name of the device to be patched.
            (default: 2nd.scsi.device)

    BUFSIZE Size of buffer in kilobytes.
            (default: 256)

    BROKEN  Use this if You have got an A4000 that cannot DMA the chipmem.
            You MUST have some 24Bit fastmem (e.g. on the controller)
            then - vb2091 will only accept MEMF_FAST|MEMF_24BITDMA RAM
            as buffer then.

    SINGLE  Normally vb2091 uses double-buffering to get slightly higher
            transfer rates; use SINGLE, if free processor time is more
            important to You. Currently only CMD_READ is double-buffered,
            CMD_WRITE is not.

    NOWRITE If You specify this option, only CMD_READ ist patched, whereas
            CMD_WRITE will be unchanged. Use this if You don't trust
            vb2091.

    NOCACHE If this option is specified, the DataCache will be disabled
            before CopyMem() and enabled after finishing; this will speedup
            CopyMem() (at least on a 040). This has not been tested very
            well, so be careful with this option.

    MAXN    <number> (default: 16)
    MIN1BUF <size in kilobytes> (default: 128)
    MIN2BUF <size in kilobytes> (default: 64)
            These options can be used to adjust some parameters which are
            used with double buffering. If a block of size l is to be read
            then vb2091 will probably split the transfer into smaller blocks
            for better use of double buffering. If l<MIN1BUF then vb2091
            will use one transfer of l bytes (i.e. no double buffering), if
            possible. If l>MAXN*MIN2BUF then the transfer will be split into
            MAXN parts. If none of those conditions is true then the transfer
            will be split into blocks of size MIN2BUF.
            I thought about a rather simple method to let the user adjust the
            buffers in different situations without having to specify one
            BUFSIZE for almost every single transfer size. The method I used is
            just heuristic and the default values were chosen rather arbitrary
            and optimal values may be quite different (especially on different
            systems). MIN2BUF shall be set to the smallest size which achieves
            good transfer speeds with little cpu usage. So MIN2BUF is the value
            which should usually be used as buffer size (yielding high rates
            and as many chunks, i.e. best use of double buffering, as possible).
            But if the transfer size is a little larger than MIN2BUF, it
            wouldn't be a good idea to usee double buffering with those chunks.
            E.g. with MIN2BUF=64k a 65k transfer would be split up in a 64k
            transfer and a 1k transfer. Although I haven't tested it, one 65k
            transfer should be better. Because of this You can prevent double
            buffering for any transfers less than MIN1BUF. I set
            MIN1BUF=2*MIN2BUF for default, but this may be too large.
            Now if You have very large transfers (e.g. 4MB), then it would be
            split up into 64 64k chunks. But from a certain number of chunks it
            should be better not to raise the number of chunks but the size of
            the chunks (especially as MIN2BUF should be set as small as
            possible). This is what MAXN is for - however this is rather
            theoretical, because I doubt that transfers that large will occur
            often (if at all).
            As said before this method can be argued (especially as I almost
            haven't tested if my thoughts are true in reality) and the default
            values may be far from optimal. So everybody who wants almost
            optimal performance has to find out his personal values (they also
            depend on the applications You use, because You can configure
            vb2091 for best speed or least cpu usage or something inbetween).


    Example:
        run >NIL: vb2091 DEVICE scsi.device BUFSIZE 128 MAXN 8 UNIT 046


    You can remove the patch by sending vb2091 a CTRL-C/break - but don't
    do this while any program is using the device.


SOURCE

    I decided to distribute the source in order to raise chances of finding
    bugs. You should be able to compile it using gcc (I used 2.3.3) or SAS.
    It is NOT meant to be an example of good programming and I am not liable
    for anyone turning into stone after looking at it.


CREDITS

    This program would not exist without the help of Olaf Seibert (another
    poor fellow with a broken A4000) who encouraged me to write it and
    provided me with helpful information. Thank You, Olaf!
    Thomas Boerkel did the changes for SAS and compiled it.
    Several testers helped to remove some bugs of the older versions and made
    suggestions for improvement.

LEGAL

    vb2091 may be freely distributed as long as no part of the distribution
    is changed.

    This program is Bearware: If You like it, You can send me something
                              with a bear on it.

    But more important:

        If You try it, please send me Your experiences, bugreports,
        suggestions etc.




Volker Barthelmann
Kennedy-Ring 39
91301 Forchheim
Germany

I should be reachable per eMail via:

volker at vb.franken.de




Contents of driver/media/vbak2091.lha
 PERMSSN    UID  GID    PACKED    SIZE  RATIO METHOD CRC     STAMP          NAME
---------- ----------- ------- ------- ------ ---------- ------------ -------------
[generic]                 1234    3809  32.4% -lh5- aeb2 Aug 13  1997 vbak2091/compiler.h
[generic]                  367     773  47.5% -lh5- a5af Dec 19 17:19 vbak2091/history.txt
[generic]                  143     206  69.4% -lh5- f21b Sep 14  1997 vbak2091/scoptions
[generic]                   87     177  49.2% -lh5- dfe4 Sep 14  1997 vbak2091/smakefile
[generic]                   73      79  92.4% -lh5- 8713 Sep 14  1997 vbak2091/smakefile.wth
[generic]                  102     194  52.6% -lh5- c26c Sep 14  1997 vbak2091/smakefile040
[generic]                   78      86  90.7% -lh5- 10c6 Sep 14  1997 vbak2091/smakefile040.wth
[generic]                 2497    9131  27.3% -lh5- 8296 Aug 13  1997 vbak2091/vb2091.c
[generic]                 3711    5816  63.8% -lh5- 8106 Dec 19 17:19 vbak2091/vbak2091
[generic]                 3711    5816  63.8% -lh5- 8106 Dec 19 17:20 vbak2091/vbak2091.040
[generic]                 3970   15849  25.0% -lh5- 4553 Sep 14  1997 vbak2091/vbak2091.c
[generic]                 5273   12665  41.6% -lh5- b669 Dec 19 17:28 vbak2091/vbak2091.readme
---------- ----------- ------- ------- ------ ---------- ------------ -------------
 Total        12 files   21246   54601  38.9%            Dec 20 09:09

Aminet © 1992-2024 Urban Müller and the Aminet team. Aminet contact address: <aminetaminet net>