Programmer 7500

home *** CD-ROM | disk | FTP | other *** search

/ Programmer 7500 / MAX_PROGRAMMERS.iso / PROGRAMS / UTILS / HARDWARE / RAMIT110.ZIP / RAMIT.DOC < prev next >

Wrap

Text File | 1980-01-01 | 25.0 KB | 859 lines

+-------------+ | RAMIT!!! | +-------------+ If you're running an 8-bit hard disk controller (generally designed for both PCs and ATs) on a 16 bit machine (like an AT or AT&T PC6300) then RAMIT! may be able to help you improve your disk transfer speed. What is RAMIT? RAMIT is a program to run the disk code supplied with an PC type disk controller out of RAM rather than from the disk controller's ROM. What does that do? By running out of RAM rather than ROM, some machines can achieve a real performance gain in disk transfer time. Does this apply to me? RAMIT can make a difference in a number of situations. To see any disk performance improvement, 1. You must be using a hard disk controller which has its own BIOS ROM code. This includes unmodified Western Digital, Mountain, Perstor and Plus [Hardcard] controllers. Undoubtedly there are many others. 2. You must have a machine which runs code faster from RAM than the I/O bus. This includes all 16 bits machines (AT types) and many other compatibles (e.g. AT&T PC6300). 3. You must be willing to reformat your hard disk to get the benefit of this speedup. Naturally, this requires a full backup and restore. Still Interested? Read on. RAMIT! Copyright (c) Hanover Systems, 1987 +-----------------------------------+ | OK, so what does RAMIT! do!!!! | +-----------------------------------+ RAMIT! is a TSR which relocates your disk controller ROM into high-speed RAM and 'fixes up' MSDOS to run the disk code from RAM. RAMIT! operates as follows: 1. RAMIT! verifies that there is a valid ROM BIOS at C800:0000. 2. RAMIT! copies the disk ROM contents to RAM. 3. RAMIT! disassembles the ROM to find out what it had placed in vector locations 4C and 64. These are the primary entry points into the ROM code. If RAMIT! is unable to determine these values, then it aborts with an error message. This is generally attributable to an unusual instruction sequence used to 'steal' the vectors. Contact the author for unusual ROMs. If you'd rather do the disassembly yourself, the original 4C and 64 vector addresses can be specified on the address line. This is the dirty way to support controllers whose initialization sequence is simply too messy for automatic decoding. 4. RAMIT! 'fixes' MSDOS or PCDOS by finding where DOS keeps the vector originally placed by the disk ROM BIOS and redirecting it to the RAM copy. 5. RAMIT! exits, leaving only a copy of the vendor's ROM code. All RAMIT! code is removed. Most unused ROM code is also removed. The amount of memory taken depends on the size and complexity of the disk controller ROM BIOS. In no event will it be more than 8K of code. RAMIT! Copyright (c) Hanover Systems, 1987 +----------------------------+ | Well how do I run RAMIT? | +----------------------------+ Find out your current performance level Before seeing whether RAMIT! can make a difference, you must know how your system performs before RAMIT! is installed. If your disk/PC combination is not explicitly mentioned in the README.RAM file in this archive (and you can't find another PC close enough), then you may have to experiment to find the best interleave factor. SPINTEST is a publicly available utility which computes disk transfer rate. It can be used to see when the optimum interleave has been established. First, run SPINTEST to get the transfer rate and interleave. Testing RAMIT! the first time At first, RAMIT! should be run in TEST mode. This will indicate whether RAMIT! is likely to work on your machine. Type RAMIT /T and examine the output. There should be three messages indicating that 0000:xxxx has been overwritten. Don't worry, in TEST mode the memory is not actually modified. If RAMIT! fails or the messages don't appear, check the README.RAM file in this archive. If your drive and computer isn't on the list, be careful. Things may very well not work. If you get no error messages, RAMIT! will probably work for you. Installing RAMIT! RAMIT! Copyright (c) Hanover Systems, 1987 WARNING: BEFORE INSTALLING RAMIT! MAKE SURE THAT YOU HAVE A FULL BACKUP OF YOUR HARD DISKS. RAMIT! CHANGES THE OPERATION OF YOUR HARD DISK CONTROLLER. WHILE RAMIT! HAS NOT CAUSED ANY PROBLEMS SO FAR, IT HASN'T BEEN RUN ON YOUR MACHINE!!!! TAKE PRECAUTIONS AND MAKE A BACKUP!!!! RAMIT! is installed for normal use by typing RAMIT You should see two messages: the standard RAMIT! version header and an identification for the disk controller ROM BIOS. Continue normal operation with RAMIT! for a while. You should not see any performance change. Just make sure things are still working. RAMIT! should be placed in the AUTOEXEC.BAT file as near the top as possible. The earlier it's executed, the more the AUTOEXEC.BAT programs will benefit from any performance improvement. Tuning up your disk performance To see a real performance difference, you'll probably have to reformat your disk. This requires a low-level format, not just a DOS format (i.e. the FORMAT command). For Western Digital customers, enter DEBUG. Old cards require that AX be set to the interleave. On newer cards, the ROM code prompts for the interleave. Start the format by typing 'G C800:5'. OMTI customers can use the OMTIDISK utility. As part of the low-level format, you get to specify the interleave. Many other manufacturers use a similar scheme. Refer to any documentation from the disk controller manufacturer to figure how to perform a low-level format. Keep lowering the interleave, formatting and running SPINTEST until performance suddenly gets worse. Then do one more format at the best interleave obtained. If you've got a unique computer/controller situation, please drop me a line on how it went. I'll include it in the README.RAM file so the next guy doesn't have to do all this work over again. RAMIT! Copyright (c) Hanover Systems, 1987 RAMIT! Command Format The syntax for RAMIT! is RAMIT [/T] [/V] [/E] [/Wfilename] [/4C:offset] [/64:offset] where /E Specifies EDIT mode. In EDIT mode, any C800 constant value within the ROM area will be changed to the segment where the ROM code gets relocated. Some controllers examine their own CS to determine whether they're strapped for the primary or secondary addresses. For example, the OMTI BIOS-7 (Universal) constantly checks its CS with C800. /V Specifies VERBOSE mode. In VERBOSE mode, RAMIT! will print additional status messages as it analyzes and installs the disk controller ROM BIOS. /T Specifies TEST mode. In TEST mode, RAMIT! will perform its analysis BUT WILL NOT MAKE ANY CHANGES TO DOS, OR INSTALL A RAM COPY OF THE ROM BIOS. TEST mode is provided so that RAMIT! can be checked on new controllers or versions of DOS. TEST mode forces VERBOSE mode. A successful TEST will produce no error messages, and identify THREE overwritten locations; two for vector 1B and another for vector 25. If this is not the case, RAMIT may not work. Contact the author for more instructions. /W Indicates that the disk controller ROM BIOS is to be written out to the file specified. The 'filename' immediately follows the /W; for example '/WDISK.ROM'. This feature is provided so RAMIT! can capture new or updated disk controller ROMs for future support. If you have a non-standard disk controller, and it won't install with RAMIT!, use the /W option to make a disk copy and send it to me. I'll try to extend RAMIT! for your disk controller. RAMIT! Copyright (c) Hanover Systems, 1987 /4C: Explicitly specifies an offset which the BIOS had stuffed into vector location 4C. Rather than disassembling the ROM code, this value can be specified on the command line. /64: Explicitly specifies an offset which the BIOS had stuffed into vector location 64. Rather than disassembling the ROM code, this value can be specified on the command line. RAMIT! Copyright (c) Hanover Systems, 1987 +---------------------------------------------------+ | A Quick Tutorial on hard disk controller software | +---------------------------------------------------+ Getting started. When your computer is started, on-board software in Read Only Memory (ROM) is started. This software, called the ROM BIOS, performs a cursory check of the machine and then initializes all the devices it knows about (CRT, keyboard, floppy etc). If you have the manufacturer's hard disk controller or the manufacturer can support the third party controller in your machine, the ROM BIOS will take control of it. If, however, you're using another board, the original ROM BIOS doesn't know how to handle it. So that you computer doesn't just stare at you, not knowing how to boot from your hard disk, IBM set up a procedure whereby anybody could gain control automatically from the ROM BIOS and provide their own hard disk software. To quote from the IBM Technical Reference, "The ROM BIOS provides a facility to integrate adapter cards with on-board ROM code into the system. During POST [Power On Self Test], interrupt vectors are established for the BIOS calls. After the default vectors are in place, a scan for additional ROM modules takes place. At this point, a ROM routine on the adapter card may gain control The routine may establish or intercept vectors to hook themselves into the system. "The absolute addresses hex C8000 through hex F4000 are scanned in 2K blocks in search of a valid adapter card ROM. A valid ROM is defined as follows: "Byte 0: Hex 55. "Byte 1: Hex AA. "Byte 2: A length indicator representing the number of 512-byte blocks in the ROM (length/512). ... "When the POST identifies a valid ROM, it does a far call to byte 3 of the ROM (which should be executable code). The adapter card may now perform its power-on initialization tasks. The feature ROM should return control to the BIOS routines by executing a far return. All of the cards supported by RAMIT! use this technique to initialize the disk drive itself, and 'steal' vectors in order to gain control when a disk command is required. RAMIT! Copyright (c) Hanover Systems, 1987 Doing Disk I/O. When DOS or a program want to do disk I/O, it loads up some registers with the I/O parameters and executes an 'INT 13h' instruction. The CPU ends up calling whatever routine whose address is in memory for 'vector 13'. At power-on time, the ROM BIOS puts its floppy disk handler's address in this memory location. If external ROM code on the disk controller board is present, at initialization time it will copy the default (ROM BIOS) address to a private location (normally location 100h) and supply its own address for vector 13. The controller's ROM will then receive control after the 'INT 13h' instruction. It will examine the parameters passed in the registers. If the request is not intended for one of its disks, then the controller ROM code will pass the request along to whatever address it found for vector 13 originally. This would normally be the ROM BIOS floppy disk handler. In this way, the disk controller's ROM code gets a chance to process every disk I/O request. This provides a simple way for anyone to make a disk controller which works in nearly all PC-compatibles. Of course, there's no reason why the hard disk controller would be the only piece of code to take over the vector 13! In fact, MSDOS and PCDOS both do this regularly. They provide a handler to scan all disk I/O for errors. The message I/O Error Abort, Retry or Ignore? is a DOS error trapped in this way. Other programs such as disk caches will also trap this vector. The only requirement is that each intercepting program which is unable to service a request fully must pass it along via the vector 13 handler which was in place before the intercepting program took over. This all seems very logical and is, in fact, a very powerful mechanism to handle disk I/O in a device independent fashion. Ok, then where's the problem? RAMIT! Copyright (c) Hanover Systems, 1987 ----------------------------- The speed difference between system RAM and PC-bus ROM. The code which resides on the disk controller card is 'out' on the PC bus. It is as 'reachable' and executable as any code on in RAM or on the mother-board ROMs (where the system ROM BIOS lives). For a 16 bit machine, there is an enormous difference between on-board RAM/ROM and PC bus ROM: each instruction fetched from the on-board RAM/ROM is read in a 16 bit chunk at the machine's maximum speed. Each instruction fetched from the PC bus is fetched in two separate operations because the PC bus is only 8 bits wide. In addition, the PC bus often operates at one half the speed of the main memory, or less. Consequently, it can take anywhere from two to ten times as long to execute code based on the PC bus as on the mother-board. For example, suppose you have a Western Digital PC (not AT) controller on an AT type clone running at 12 Mhz. First, a 16 bit instruction fetch must be converted into two 8 bit PC-bus fetches. This automatically doubles any request. Next, our clone manufacturer tried to be very compatible, so his PC-bus runs at 6MHz, just like the original IBM AT. Add in a few wait states and we will end up taking three times as long to execute a simple instruction from PC-bus ROM than from mother-board ROM or RAM. So what if it's slower, the disk is slower still? ------------------------------------------------- Up to a point this is true. Unfortunately, if the disk controller software cannot get commands out to the disk in time, it may miss a whole revolution. At that point your computer is quite useless, waiting for the disk to come around again. The proper spacing of data around a disk track is determined by the disk 'interleave'. If you don't know what interleaving is or why it's so important, read the next section. The best interleave is determined by the raw transfer rate of the machine and its hardware. You can move data only so fast from disk to memory. It is also determined by the speed of the controlling software which controls the hardware. If you can speed the disk controller's software, you won't need as much time to execute those critical functions and you may be able to run with a smaller interleave. RAMIT! Copyright (c) Hanover Systems, 1987 By way of example, I have a AT&T PC6300. The 'generous' retailer who formatted my disk used the wrong interleave. Consequently, it took 18 revolutions to read a mere 17 sectors from my hard disk!! After reading one sector, I wasn't getting ready to read the next in time, so I had to wait a whole revolution!. (PS. there are 17 sectors per track on most hard disks.) Thanks to a program by Steve Gibson, SPINTEST, I found the ideal interleave was 6. After reformatting my disk, it now took 'only' 6 revolutions to read a track, a three fold improvement which was immediately noticeable when loading large programs. Trying any interleave lower ('better') than 6 put me back to 17 or 18 revolutions to read a track. When I ran the Western Digital controller code from high- speed RAM rather than the slow-speed PC bus, I was able to use an interleave of 4. This allowed a track to be read in only 4 revolutions. Without any additional hardware, I was able to read raw data 50% faster just by running from RAM over ROM. The only trick was getting my machine to run from RAM rather than ROM. That's what RAMIT! does. Great! Give me an example! --------------------------- For WD controllers, with the ROM BIOS still in, and W8 still strapped, I would use: RAMIT This figures everything out for itself and installs the ROM BIOS into RAM. For the OMTI 5527 RLL controller with the universal BIOS, I use RAMIT /E /4c:a79 /64:9a8 The /E (edit) converts C800 constants to whatever-segment- the-ROM-has-been-copied-to; the /4c: and /64: give the original offsets that the BIOS had stuffed into those respective buffers. RAMIT! Copyright (c) Hanover Systems, 1987 +-----------------------------------------+ | A quick tutorial on disk interleaving | +-----------------------------------------+ What is interleaving? Interleaving is the technique where consecutive logical sectors are places several physical sectors apart around the track. The interleave factor is the number of sectors between consecutive logical sectors. For example, a 10 sector track with an interleave of 1 would arrange its sectors 1,2,3,4,5,6,7,8,9,10 while one with an interleave of 3 would be arranged 1,8,5,2,9,6,3,10,7,4 Why bother interleaving? Controllers interleave because they cannot transfer data to memory as fast as they can read it off the disk. Some controllers won't transfer anything unless the error check codes are correct which cannot be determined until after the entire sector is read. If the sectors were placed sequentially on disk, after reading one sector, there would not be enough time to transfer it before the next one came along under the read heads. (Obviously, the disk isn't going to stop spinning just because the controller isn't ready.) By putting sequential sectors the proper distance apart, the desired sector is just about to be read when the controller is ready to process it. What is wrong with having the wrong interleave? With the proper interleave, after reading and transferring sector 'n', sector 'n+1' is just about to come by. If the interleave is too large, we'll have to skip over at least one sector which is not 'n+1'. This will waste whatever time it takes to skip over that sector. If the interleave is too small, we've already missed sector 'n+1'. We must wait a whole revolution of the disk before we get another shot at it. If we were to read all 17 sectors (on a normal disk), we'd require 17 revolutions. What should the PC6300 interleave be? RAMIT! Copyright (c) Hanover Systems, 1987 If you have the standard WD disk controller, an interleave of 6 works best. This is readily verified with a number of public domain disk test programs. An interleave of 6 requires 6 revolutions to read one track. If you have the OMTI RLL controller, an interleave of 4 works best. What should an AT interleave be? If you have the standard WD disk controller, an interleave of 3 works bets. This is the standard low-level format value. How do I change my interleave? Unfortunately, the only way to change this [at the moment] is to perform a low-level reformat of your disk. Instructions vary according to manufacturer. For many, enter debug and jump to location C800:0005. After performing a low-level format, a regular DOS format is required. How do I know how my interleave works? An excellent utility available at bulletin boards across the country is SPINTEST. This program was written by Steve Gibson and reports how many revolutions are required to read a track. Some experimentation is required to determine the optimal interleave value. As I get reports for different controller/computer combinations, I'll put them in the associated README.RAM file. RAMIT! Copyright (c) Hanover Systems, 1987 How is RAMIT! distributed! RAMIT! is still in the development stages as I add support for more controllers. Refer to the attached README.RAM file for the latest list. RAMIT! may be distributed free of charge. RAMIT! remains the copyrighted product of Hanover Systems, Newtown CT. Before sleeping with full confidence, I'd make regular backups for the first few days. I've never seen your machine or disk and therefore can't guarantee anything. I have tested RAMIT! on every machine I have available to me. Further inquiries may be directed to the author Christopher Smith Hanover Systems 19 Tunnell Road Newtown, CT. 06470-1242 (203) 426-0024 RAMIT! Copyright (c) Hanover Systems, 1987