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 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: [DEVICE ] [BUFSIZE ] [MAXN ] [MIN1BUF ] [MIN2BUF ] [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 (default: 16) MIN1BUF (default: 128) MIN2BUF (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 lMAXN*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@vb.franken.de