• Please review our updated Terms and Rules here

Was there ever any ISA IDE controllers that supported DMA transfers?

tom1000000

Member
Joined
Jul 9, 2013
Messages
19
Location
Australia
Hi,
I would be interested in knowing the best possible IDE controller to use for my 486 computer.
It looks like all ISA IDE controllers only support PIO transfer modes?
Was there any that supported MWDMA-2?
Thanks
Tom
 
I've not heard of any. Even my latest ISA controller with build-in BIOS and 2-channel IDE with LBA 8.4GB support, does not even support PIO MODE 3. I have PIO MODE 3 with VLB controllers only.
 
The slowest ATA DMA mode (DMA Mode 1) is 13.3 MBps, while the 16-bit, 8 MHz ISA bus theoretically tops out at 8 MBps. The best you can ever hope to get with the ISA bus is PIO Mode 1, which is 5.2 MBps.
 
IDE devices can only do bus-master DMA (DMA initiated by the peripheral, not involving the motherboard's DMA chips). ISA bus does not support bus-master DMA, only traditional DMA (using 8237 or equivalent on the motherboard). Therefore, no.
 
Contrary to popular opinion, there were ISA bus-mastering cards. To quote Hardwarebook:

An ISA device may take control of the bus, but this must be done with caution. There are no safety mechanisms involved, and so it is easily possible to crash the entire system by incorrectly taking control of the bus. For example, most systems require bus cycles for DRAM refresh. If the ISA bus master does not relinquish control of the bus or generate its own DRAM refresh cycles every 15 microseconds, the system RAM can become corrupted. The ISA adapter card can generate refresh cycles without relinquishing control of the bus by asserting REFRESH. MRDC can be then monitored to determine when the refresh cycle ends.

To take control of the bus, the device first asserts its DRQ line. The DMAC sends a hold request to the cpu, and when the DMAC receives a hold acknowledge, it asserts the appropriate DAK line corresponding to the DRQ line asserted. The device is now the bus master. AEN is asserted, so if the device wishes to access I/O devices, it must assert MASTER16 to release AEN. Control of the bus is returned to the system board by releasing DRQ.

Wikipedia said:
Designed to connect peripheral cards to the motherboard, ISA allows for bus mastering although only the first 16 MB of main memory are available for direct access.

ISTR that there were some bus-mastering SCSI controllers. It was always a PITA, however.
 
Isn't a common Adaptec 1542 SCSI controller considered an ISA busmaster device, capable of performing DMA with S/G-lists by using a DMA channel in cascade mode?
 
ISA DMA wasn't all that reliable and had compatibility problems. Its one thing Microchannel and EISA fixed. Vendors naturally cheaped out on ISA IDE cards by doing the bare minimum, which is basically making a plug adapter with some TTL address decoders. Even the VLBus IDE adapters I've found don't seem to do IDE DMA properly, they are usually PIO Mode 2. I have no experience with the one EISA IDE card ever made (DTC-2290) to know if it did any DMA (anyone here got one?). Don't know much about the MCA IDE adapters either.

SCSI is still going to be the less CPU intensive choice on vintage machines. Too bad the drives are getting hard to find and flash solutions are pricy.
 
That's a good point--back when ISA was still the reigning champion, SCSI drives were considered as the high-performance champs. IDE drives were merely inexpensive. So it figures that the high-performance controllers were also SCSI. IDE "controllers" were, with few exceptions, merely passive bus interfaces.
 
GSI made some ISA IDE HBAs with DMA capability. I have a Model 4C controller myself (I posted pics of it a while back in another thread). See http://museum.ttrk.ee/th99/c/E-H/20413.htm for what TH99 has to say about it; especially note at the bottom where IDE4 is called out specifically as not supporting DMA (by extension, that means the first three channels (up to six drives) supported DMA). Given the way the docs are written it would seem that that is the ISA DMA using the motherboard's DMA controller.

You will be limited to ISA speeds, of course. Too bad that the bus enhancements made for the higher-speed modes on the PATA interface weren't backported to the ISA bus; after all, the PATA bus is an ISA bus with fewer address lines and some preselection done, and fewer control signals. An 'ISA-133' would have been neat.
 
Thanks for all the info.
It looks like the GSI "MODEL 4C INTELLIGENT IDEA" would be the world's best ISA IDE controller.
If I ever get a chance I will buy one.... assuming its still working ;).
 
ISA bus-mastering has the potential to be considerably faster than 8237 motherboard type DMA. My own experience with 16-bit motherboard/legacy DMA shows that it doesn't really come all that close to the maximum ISA bus bandwidth. The distinction here is that a bus master on ISA uses the 8237 DMAC to obtain control of the bus (via DMARQx), but then conducts DMA directly.

If you can find a bus-mastering ISA PATA controller, so much the better.
 
ISA bus-mastering has the potential to be considerably faster than 8237 motherboard type DMA. My own experience with 16-bit motherboard/legacy DMA shows that it doesn't really come all that close to the maximum ISA bus bandwidth. The distinction here is that a bus master on ISA uses the 8237 DMAC to obtain control of the bus (via DMARQx), but then conducts DMA directly.

If you can find a bus-mastering ISA PATA controller, so much the better.
How do such bus-mastering devices prevent contention with the 8237's control signals- the 8237 doesn't know that it's not performing the xfer.
 
The process is explained in detail in the Mindshare book "ISA System Architecture" - which is available online still:

http://www.mindshare.com/Books/Titles/ISA_System_Architecture_(3rd_Edition)

Basically, the device requests HOLD on the CPU by programming the primary DMA controller for cascade operation, but the card itself becomes the cascade device instead of the second 8237 as would normally be the case. The main issue is that there are absolutely no checks and balances - the CPU is at this point in a hold state until the device releases DRQ.
 
Back
Top