Date: Thu, 9 Mar 95 00:29:13 PST From: Stefan Ossowski Subject: GURU-ROM V6 #### # # #### # # #### ### # # # # # # # # # # # # # ## ## # ## # # #### # # ### #### # # # # # # # # # # # # # # # # # # # #### ### # # ### # # ### # # omniscsi.device - GVP ROM module by Ralph Babel A new device driver for all Series-II SCSI host adapters and all turbo cards with a GVP SCSI host adapter. Increasing requirements and a larger variety of available SCSI devices made it necessary to rewrite the original GVP device driver. In the previous driver versions, new program portions would be added occasionally to solve problems that existed with a few popular SCSI devices. Also, an ever-increasing number of GVP products needed to be supported in the driver. In time, all of this resulted in considerable space problems, which led to compromises in the development of the driver, but it was nevertheless still possible to support all of the current devices. Unfortunately, because of the price war more and more manufacturers deviate from the SCSI standard in their hardware and firmware or choose to save money in certain areas. An example of this is certain CD-ROM drives that no longer support PARITY. The new OMNISCSI.DEVICE driver is a portable driver for all Amigas and is first being made available for the most widely used SCSI host adapter on the Amiga: the GVP Series-II. It is faster and more reliable than all previous standard SCSI device drivers, but nevertheless fully compatible to all previously supported SCSI devices and then some. With all of these extensions, however, the new device driver no longer fits into the existing ROM area provided by the Series-II. It was therefore combined with a ROM adapter that allows up to four times as much address space as before to be addressed. - Which hardware is actually supported? - Series-II SCSI host adapters with and without RAM option for the A2000/A3000/A4000 - Series-II SCSI host adapter for the A500 - A530 turbo card for the A500 - Combo030 turbo cards for the A2000 - G-Force030 turbo cards for the A2000 - G-Force040 turbo card for the A2000 - A1208 SCSI host adapter for the A1200 - Will my system act exactly the same as before, after I install the ROM module? In essence, there is only a single incompatible change that can be noted in your system: the name of the device driver has changed. In the past, it would show up under the name GVPSCSI.DEVICE; now it is called OMNISCSI.DEVICE. - Is there a new GVPPATCH to prevent modem problems while using DMA transfers? The patch no longer exists in its original form, but has instead been integrated into the control program GVPSCSICTRL. It is actually needed for high-speed transfers only. - Do I get an even greater performance by using the B version of the SCSI chip 33C93? All known bugs in the internal processing of the 33C93 and the 33C93A are worked around by the device driver. Installing a 33C93B chip, which would be difficult in most cases anyway because of the use of SMD mounting on most GVP cards, is unnecessary. One argument often used in favor of using the B version is the support for FAST SCSI, but since the Zorro-II bus is already at capacity with a throughput of 3.5 Mbytes/s, the synchronous transfers of the A version of the 33C93 (max. 4.7 Mbytes/s) is more than sufficient. - I have previously had problems using BRU and AMAX IV. Can these be resolved? BRU and AMAX IV are among the most popular, although not the only programs within which problems occurred with the GVPSCSI.DEVICE. Because the driver adhered strictly to Commodore's "Direct SCSI" standard, it revealed bugs in a few incorrectly written programs. In both cases named above, for example, the problem lay with the fact that a particular flag (SCSIF_READ) was not being set, which is, however, required by the above-mentioned standard. The new OMNISCSI.DEVICE can be configured to work around such problems. - I want to transfer data on my hard disks in synchronous mode. Is that possible? Previously, it was only possible to write the appropriate information into the RDB when a hard disk was prepped, but the mode was not really used. With the new driver, the use of SCSI devices in synchronous mode is finally possible. - In the past, I always had to wait a long time for my machine to start. Is it faster now? The long delays are in part because of the SCSI protocol, but there are ways to achieve a nearly instantaneous boot of the computer from the system hard disk without violating the SCSI specification. This has been taken into consideration in the new driver. - My A4000/040 doesn't support DMA to Chip RAM. Will that present a problem with the use of the host adapter? For this hardware problem of older revisions of the 68040 card used in the A4000, the driver provides an option that prevents all DMA to Chip RAM, but which still permits access to the rest of the Zorro-II area - such as on-board RAM. - Which SCSI peripherals are supported? All SCSI devices we had access to were tested - current and also some from our "museum" - including a number of cartridge drives, CD-ROM drives, and streamers. In spite of exhaustive testing, no problems were noted. - Shouldn't a good SCSI driver support all SCSI devices automatically? Actually yes, but this isn't always "automatically" possible. Each SCSI device includes its own SCSI controller with its own firmware. It would be nice if these were always free of bugs, but that is unfortunately not always the case. This means that - if a problem can't be resolved by switching off certain driver options - sometimes the problem must be programmed around. This, of course, is only then possible when the problem is known, and is one of the reasons why from time to time new revisions of the GVPSCSI.DEVICE were released. All previously noted SCSI device firmware bugs have been taken into consideration in the new driver. - What other improvements does the new driver offer me? - Data transfers have no restrictions, so that the optimum values for the MOUNTLIST/RDB entries MASK, MAXTRANSFER, and BUFMEMTYPE can be used. The driver itself decides what the most efficient way for transferring data is (DMA, buffered DMA, or PIO) and requires no workarounds in the filesystem that would slow down transfers. - Transfer mode and SCSI options like DISCONNECT, SYNCHRONOUS, and PARITY can be configured individually for each board or connected SCSI device, respectively. This results in a much more comfortable configuration of your system. - The rescan command is now required only if a hard disk partition (e.g. on a removable medium) must be mounted after boot-up. - An interesting new function makes it possible to completely write-protect a medium, which blocks even those commands that bypass the filesystem and talk directly to the driver (HD_SCSICMD, CMD_WRITE, TD_FORMAT). In this way for instance, the system drive can be protected from any type of virus. - The I/O Extender integrated in the G-Force040 is now usable even if no SCSI drive is connected. - Which data transfer rates are possible on my system? Due to the multitude of possible GVP host adapters and the virtually unlimited variety of SCSI devices and the resulting combinations it is difficult to provide general benchmarks for all situations. As an example, we have selected a configuration that provides a typical environment: - A2000B revision 4.1 (PAL; the NTSC version is faster) WITHOUT accelerator card or other accelerating components - Kickstart 37.175, Workbench 37.67 - 1 MB Chip RAM - GVP Series-II SCSI host adapter populated with 2 MB of Fast RAM - Maxtor MXT 540 hard disk There are three fundamentally different types of transfer rates, all of which are used in reviews and advertising: - Raw data transfer speed The maximum data transfer rate of the host adapter is limited by the Zorro-II bus only and can be as high as 3.5 Mbytes/s. The program RAWSCSISPEED measures the values for READ BUFFER and WRITE BUFFER and provides a good approximation of that particular maximum transfer rate. In the test system, values of approximately 3.4 Mbytes/s were measured for both reading and writing. - Transfer rate at the device-driver level This transfer speed can be measured with the program SCSISPEED (FF665). Unlike with RAWSCSISPEED, here the time required for the interpretation of the commands, among other things, _is_ taken into account. For a 256-Kbyte buffer, a value of 3.1 Mbytes/s was measured. It dropped to 2.6 Mbytes/s when SCSISPEED also evaluated the amount of available CPU time. This was reported as 79%; thus according to the results of SCSISPEED, the load on the CPU from the driver is only 21%. - Transfer rate at the filesystem level Using the program DISKSPEED (also on FF665), the data transfer rate can be measured at the DOS level. The resulting values are strongly dependent on the filesystem used, the block size, the buffers, fragmentation of the hard disk, and other factors, so that here only limited conclusions can be drawn about the speed of the host adapter and its device driver. In spite of that, measurements were made. On an empty partition that was placed on the outer tracks of the hard disk (with a logical block size of 512 bytes), DISKSPEED showed a result of 2.4 Mbytes/s both during reads and writes of 256-Kbyte blocks in the above configuration. Once again as a reminder: all of the above values apply to a pure 68000-based system in a minimal configuration. - And what about SCSI-2? The new driver completely conforms to SCSI-2. Existing GVP SCSI host adapters, however, do not provide terminator power (TERMPWR), which is optional in SCSI-1 only. All of the differences between SCSI-1, CCS, and SCSI-2 are handled transparently by the driver though, and do not affect normal operation. The SCSI bus itself remains 8 bits wide, of course, and doesn't support FAST or WIDE transfers, two of the new options under SCSI-2, but the new OMNISCSI.DEVICE pushes the Zorro-II bus to its limits anyway. Because of that, the use of SCSI-2 devices in general poses no problem. Price: DEM 99.00 Shipping & Handling: DEM 15.00 All major credit cards are accepted. Release-date(s): 03/25/95 with German manual 04/25/95 with English manual Stefan Ossowski's Schatztruhe Gesellschaft fuer Software mbH Veronikastrasse 33 D-45131 Essen Germany Voice: +49 (201) 788778 Fax: +49 (201) 798447 E-Mail: Copyright (C) 1994, 1995 Ralph Babel. All right reserved.