There was a bug in A4091PATCH Version 39.1. Some Forbid()s and Permit()s were commented out. Now they have been reactivated. If you find somewhere versions 39.1 please replace with version 39.2 !!! Thank You
The entire risk as to the use of this program is assumed by the user. In no event will the author be liable for any direct, indirect, incidental, or consequential damages derived from the use of this program. This program is not authorized for use in medical applications, including but not limited to, use in life support devices. This application hasn't been tested too much but it should work properly.
This program was written by Giuliano C. Peritore. All rights reserved. It may be distributed in any form, but not for commercial purposes. Donations are highly welcomed. Explicit permission is given to Fred Fish and Hyper Media Concpets to include this work in their disks. Commodore is also authorized to use it whenever it may be useful. Source code is available upon request.
This program was developed on a stock A4000 with 4MB of Fast RAM, 2 MB of Chip RAM, IDE 120MB HD, A2088 XT board not binded (with binddrivers), an A2091 SCSI interface populated with 512 K of Fast RAM, 7.0 ROMS, and a Quantum LP52s hard drive. A Toshiba 3301B CDROM was connected but turned off. The program worked fine with this configuration, but I think it will work on A3000s and or A2091s with 6.6 ROMs. Amiga OS 3.0 is required.
When I plugged an A2091 SCSI board in my A4000 I noticed that transfer speeds between Zorro III memory (outside the 24bit range) and A2091 HD were astonishingly low and used all CPU time. I had this problem also with my CD ROM, using CDROM File System from Canadian Prototype Replicas.
I thought that it was a problem with A2091's 6.6 ROMs, since someone told me that they used processor polled I/O on A4000. So I got 7.0 ROMs and also 512K of fast RAM to install in my A2091 in order to provide newer ROMs and some 24bit DMAble memory. But this didn't work.
When I noticed that transfers to Chip RAM were fast and used not much CPU time I tried to move HD and CD buffers to 24bit memory. First I modified the mountlist of the CDROM, setting BufMemType=512 (MEMF_24BITDMA). This speeded up the CD and freed some CPU time. But I wasn't able to make the FastFileSystem put his buffers in 24bit DMAble memory. I tried making a mountlist and/or changing the BufMemType field in the Environment structure in hard disk's Rigid Disk Block. But it had no effect.
Bothered with this fact,that I had correct DMA fast transfers in CHIP and A2091's FAST RAMs and processor polled very very slow I/O to Zorro III memory, plus sometimes strange errors with CPU polled I/O, I decided to make an OS patch. The errors that I was getting sometimes were not R/W, nor 'bad block checksum' errors. It was the data coming from HD that was missing some bytes here and there.
My idea was that DMA transfer towards a DMAble memory buffer, followed by CPU copy from that buffer to Zorro III memory, was surely faster than CPU polled I/O, and should eat less CPU time. I was right. Through some testing with DiskSpeed I noticed that my patch provided in Longword aligned transfers to A2091 memory ten times the old transfer rate plus eight time less CPU time used.
Now I had a working beta release, and I had only to make it a bit more usable and to find a name for it. So I added Shell and WB support and a meaningful name. The formula from which I got the name is: A+((4000&0xff00)|(2091&0x00ff))+patch. ;-)
To use this patch you need an A4000 (A3000 may suffice I think) with AmigaOS 3.0, A2091 with 7.0 ROMs (6.6 should suffice I think), and possibly at least 512K on your A2091 (If you haven't it Chip RAM will be used). Of course you need a SCSI device connected to your A2091.
You can invoke this program via the Shell, via the Workbench and obviously through WBStartup. If invoked from the Shell it needs two parameters.
The first is the buffer size, the second the partition name, without the colon. If instead you use the Workbench it accepts two tooltypes:
BUFSIZE=xxxx, and PARTITION=xxxxx, without the colon. When the program is invoked the first time it will install itself. When it is invoked a second time it will remove itself. Please read subsequent documentation!
The bufsize parameter tells the program how big should be the buffer. The greater the buffer, the better the performance. If you have Fast RAM on the A2091 you should set bufsize to anything you desire, but a bit less than A2091's RAM size. If you exceed this size the buffer will be put in Chip memory and things may slow down a bit. If you have no RAM on the A2091 there are no problems, chip RAM will be used.
This program is able to patch only one partition. I regret but I didn't want to spend time making it more usable. So I suggest to install only one partition on your A2091's HD. The partition is indicated with its Task name. It is the partition name (i.e. QDH0, not MyHardDisk) without the terminating colon. Letter casing is important (QDh0 is different from QDH0). Generally an A2091 Hard Disk is called with the first letter of the producer of the HD plus 'HD0'. For instance a Quantum HD will be called QDH0, while a Seagate will be called SDH0. Avoid to set buffers too small. Acceptable sizes are generally in the range 65536-262144.
A4091patch SetFunction()s the Read() and Write() routines of dos.library.
When it is called a second time it will remove the patches. Beware, because if someone else patched Read() or Write() your system will go in a confused state. Probably it will hang. So decide if you want to use A4091patch and avoid removing it.
The idea behind A4091patch is very simple. I will describe how Read() is patched, since Write() is almost equal, except the relative positions of CopyMem() and Write(). When an application issues a Read() on a patched system it will fall into A4091patch's read(). If the transfer is direc ted towards 24 bit DMAble memory read() will call directly Read(). So we leave DMAble transfers to the dos.library. Now remain only Zorro III transfers. If the drive towards which the command is issued isn't the patched drive read() will fall into Read(). Now remain only Zorro III transfers from the patched drive. So if the length of the transfer fits into the buffer a single Read() will be issued from the HD to the buffer, and then data will be moved via CopyMem() from the buffer to the correct Zorro III destination. If the length exceeds the size of the buffer the transfer will be broken into chunks fitting the buffer and data will be alternatively Read()ed to the buffer and CopyMem()ed to the destination.
Errors will be correctly managed, registers are preserved, and the setpatched Read() and Write() seem indistinguishable from the originals to the general application and to the OS. The Amiga OS modularity allows this. Thank you Amiga.
In the file Speed.doc you can observe the DiskSpeed reports for the A2091 HD, the RAM disk and the internal IDE drive of the A4000, on patched and unpatched systems. I include here only the most important values regarding read transferring rates:
| Hard Disk | Unpatched | CPU | Patched | CPU |
| A4000 IDE | 504123 | 62% | 677958 | 50% |
| A2091 SCSI | 47788 | 1% | 461142 | 49% |
| RAM Disk | 3772792 | 0% | 3768116 | 0% |
Notice the tremendous increment on A2091 speed and the drop in CPU usage, the slight slowdown of RAM disk, and the sluggish increment on IDE speed, togheter with a small drop in CPU usage of the IDE drive. The IDE results don't make much sense, since the disk was higly fragmented and since I am not properly sure of DiskSpeed's accuracy with IDE drives.
I wish to thank Ettore Caurla for his phone support as Italian developers support manager and Randell Jesup for his attention. Mike Sinz is also included as the author of DiskSpeed. I wish also include the Amiga for being the best computer.