CompuServe Messages

Hard Disk Drive

    15-Dec-86 00:07:04
Sb: #43502-Hard Disk Drive
Fm: E. J. Lippert II 71330,2365
Joergen: (Again) RE: DMA and the C Ltd. SCSI Controller. I will try to clear the air once and for all on DMA for Hard Disk Access, why we chose not to use DMA and the net effect on the end user. First, we built our own DMA drive before we built the non- DMA unit we are marketing. True DMA (ala Atari ST) is not possible on the Amiga, even though a HD is "DMA" doesn't mean that is fast. Our production non-DMA drive ranged from 'about as fast' (+/- 15%) on opreations like loading Dpaint, Modula compilations from disk, Database operations and opening windows full of icons; to 'half as fast' on operations like loading some long files. In many cases, like loading V.I.P. and Analyze! files, where the loading is done from the program while computation was going on, the non-DMA drive was actually faster. (Has something to do with DMA Interrupts, which I don't understand, even after our techies tried to explain it to me.) – So, overal speed of a DMA HD is faster, but not all that much. Second, the DMA version cost 50% more that the non-DMA unit. Which would have meant the retail would have been well over our 'under a thousand dollars' target price. Last, the DMA unit would not have been as easy to adapt to our upcoming SCSI Local Area Network as our non-DMA unit. The DMA activity, it seems, does at times preclude (over-ride?) the multi- tasking ability of the Amiga, a situation which would be very very difficult to deal with when your network is designed to run as a high-priority task in one window of the machine. Your analysis was mostly correct, we are using a pseudo- DMA 'cashe' scheme. We are grabbing 5K hunks (optimal by our tests) and dropping them into memory using the DMA channel. This allows us to set our task priortiy down far enough to allow higher priority (multi-) tasks to over-ride us. E.J. Lippert II C Ltd. Wichita, KS (316) 267-6321