Ok, here are the credits: (first) I owe many many thanks to MANX, who make the only C compiler that is faster and takes up less memory than an overscan 24 bit raytracing program. Lettuce is rabbit food! (The stuff it leaves all over your disk when you abort it must be rabbit cr*p then) This is freely distributable, assuming that you don't make more than $5 for it, and that you don't attempt to distribute modified versions without asking me first and sending me a copy... And that you leave this notice here... AND and that you distribute the ENTIRE archive, including, yes, THE SOURCE, and THE DOCS. There is nothing worse than a programmer to have to send money that may or may not be needed, a disk, and a letter to somebody way off in CA to convince them to get off the beach and send the source that has been stripped from their copy of something... TO send me your contributions, put them in a crate and send to David Donley (Author of USEFUL programs like IBM and Bounce) 1708 Harkness Manhattan Beach, CA 90266 Feel free to send any interesting non-pirated piece of code, source or not, C or ASM. Don't send me BAS?C unless you think I'll like it enough to translate it to C, I WILL NOT load the MicroCr?d interpreter- Not on MY Amiga. (If I get mad at a sysop, I upload BAS?C programs) If you send me a disk and shipping charges, plus $15, I will try to make a disk with all my programs on it (Yah, FUN, Bounce, BackMouse, 1Button, IntuiKeys, HideFiles, SumBoot, TrapCrash, Plane, FlashBoot, CP, ect.) some of which arn't in the PD. Ok, here are the docs: DSpeed is a program for testing device level raw disk read/write speed. Since it tests raw speed, it does not care if you are using the FastFileSystem or not. It goes through pains to make sure that the disk's seek speed has nothing to do with it's rating. This program also tests your CPU speed at the same time as the disk IO, so you can have an idea how much slower your Amiga runs when it's doing disk access. A good DMA drive will not slow down your Amiga, whereas almost all non-DMA drives will nearly kill your poor Amiga. I think that the HardFrame and the C= 2092 cards are the only DMA ones, the GVP one is not DMA. Even though it's supposed to be a good card, I wouldn't buy it since they lied to everybody and claimed it was DMA. Command Format: DSpeed [] Drive is the AmigaDOS name for the disk, DH0:, df0:, ect. DSpeed will figure out the right device and number for this drive. Cyls is an option that defaults to 1, that tells DSpeed how many times it should read a cylinder of your disk. For some drives, a cylinder can be tested so quickly that the results of the test are not valid. DSpeed will warn you if this is so and recomend another number for Cyls. DSpeed allocates a buffer the size of the cylinder, reads it Cyls times, and then writes it back Cyls times. It does not harm any data, and can be aborted with a CTRL-C (Unlike many other disk speed testers). It uses the hardware CIA timers to time things, and also runs a task that just sits and counts at priority -5. The hardware timer registers are used to calculate the speed of the drive, and the number that the background task counts to is used to measure how well your CPU was working while the drive was accessing. The reason why you can't specify a buffer size is because if it is over about 10K, it has very little to do with anything, and most drives have more than 10K of data per cylinder. ** Please don't run me on fake devices like RAM & PRT... RAD is ok though, but you need something like 1000 cyls ** Output: (For a Sickly Supra 500 controller running through an Adaptek, 5 cyls) ---- Buffer Size: 79872 (78K) Total Length: 399360 (390K) Reads: 73728 (72K) CPU: 0% Acuracy: 1 in 325, +-226 bytes Writes: 71527 (69K) CPU: 0% Acuracy: 1 in 335, +-213 bytes ---- WOW!!!! 72K READS!!! And that's my FAST drive!!! (Supraformance!) Well, that's not so bad, floppies do only 16K reads... But when you use floppies, 87% of the CPU is still there... Ok, lets look at the parts of this output. Buffer Size: This is the size of the buffer, which is the size of one cylinder of that drive. Total Length: This is the buffer size multiplied by the number of cylinders on that track. Reads/Writes: This is the speed of the drive in bytes per second (Don't call it BPS, that also means Bits Per Second- as in baud) CPU: The speed of your computer in percent. If your hard disk takes up zero CPU time, and you have a normal 500/1000/2000, this will be 100. If you have a 2500, and you have a zero CPU time hard disk, this will probably be around 300-500... You get the idea... :-) Acuracy: This is how accurate the test is. The second number (325 for reads, 335 for writes in the example) is the number of hardware ticks the test took. In this example, their are 325 ticks, so I say it has one in 325 acuracy, since there are actually 325 possible numbers for Read speed. There are 60 hardware ticks each second. The third number, +-226 or 213 bytes, is the Read/Write speed divided by the number of hardware ticks, and tells you how far the program would be off if it screwed up one timer tick worth. (Very likly) Since this test writes exactly one cylinder at a time, it does not cause the hard disk to do any head movements during the test. Also, interleave is much more important. Most of the numbers are also in K, and I mean 1024 when I say K. (Not 1000 like certain other hard disk testers... Ahm.. :-) Speed is a program for testing low level proscessor speed. It does two tests: A normal speed test, and a floating point speed test. It runs for a specified amount of time, and counts how many bodgles happened during that time. Command Format: Speed [] Seconds is a special new way of specifying time. There are 60 seconds in one minoote. Seconds defaults to 1. Theoretically, the larger Seconds is, the more accurate the test, but this uses the AmigaDOS Delay function, and I think it gets confused if anything is running at the same time it is. The longer the time, probably the slower your computer is going to look on the results. The task started up to do the testing is -5 again, and I believe if you run this program from a CLI at -5 priority, you will funny (wierd) results. I would suggest using a Seconds value of about five. Since this program runs the same amount of time on all computers, it should either stay the same or get more accurate as your computer gets faster, rather than getting less accurate, like many other speed testers. If you have a cache, the results will look real good on the CPU test. Output: (For an old Amiga 500 with supra drivers mounted, Seconds=5) ---- CPU: 99% FFP: 100% ---- Ok, lets look at the parts of this output. CPU: This is what your speed is in terms of percentage of a normal Amiga. If you have something better than a normal Amiga, the speed should be something better than 100. If you have something less than a normal Amiga, the speed should be something worse than 100. The CPU test is a tight loop that simply increments a 32 bit unsigned long word. FP: This is what your floating point speed is in terms of percentage of a normal Amiga without a floating point processor. The Speed.fp program only run on a lightheaded floating Amiga, and the Speed program is for everything else. Note that those of you with a CMI board got cheated, as it's floater is a fake. To use it, the software must poke and peek registers in ram, or use the 1.3 math library. The problem is, the 1.3 math library is much slower than the other math libraries for people without a floating chip. Therefore, nobody writes software that uses it. Don't be surprised if you get 101% on your Amiga 500/1000/2000, I "Calibrated" this thing with my SupraProblemDrive mounted, and I'm pretty sure the drivers eat the CPU, after all, they eat my data.