douglar wrote on Yesterday, 03:13:

jakethompson1 wrote on 2026-09-10, 21:42:

I believe the single and multi-word DMA modes on IDE are inspired directly by modes of operation on the 8237 in the PC, so they should be compatible.

Where did you get that idea? I thought that the mwdma spec from 1994 was specifically designed to work with the PCI from the previous year, not the 8237 which was much much older.

edit: after all, multi word sort of implies a burst mode, no?

In these drafts https://www.os2museum.com/wp/historical-ata-standard-drafts/
rev. 1 does not mention DMA at all.
rev. 2.1-3.0 mention DMA but do not break it down into single word vs. multi word
rev. 3.2 adds multiword DMA but is still from Oct. 1992.

The wording throughout 2.1-3.2 about programming a 16-bit slave DMA channel sounds a lot like ISA DMA
In this post Re: How to get and validate DMA mode for disks in Windows 3.1? mkarcher explained how single word and multi word correspond to different 8237 modes

jakethompson1 wrote on Yesterday, 06:48:

In these drafts https://www.os2museum.com/wp/historical-ata-standard-drafts/ rev. 1 does not mention DMA at all. rev. 2.1-3.0 me […]
Show full quote

douglar wrote on Yesterday, 03:13:

jakethompson1 wrote on 2026-09-10, 21:42:

I believe the single and multi-word DMA modes on IDE are inspired directly by modes of operation on the 8237 in the PC, so they should be compatible.

Where did you get that idea? I thought that the mwdma spec from 1994 was specifically designed to work with the PCI from the previous year, not the 8237 which was much much older.

edit: after all, multi word sort of implies a burst mode, no?

In these drafts https://www.os2museum.com/wp/historical-ata-standard-drafts/
rev. 1 does not mention DMA at all.
rev. 2.1-3.0 mention DMA but do not break it down into single word vs. multi word
rev. 3.2 adds multiword DMA but is still from Oct. 1992.

The wording throughout 2.1-3.2 about programming a 16-bit slave DMA channel sounds a lot like ISA DMA
In this post Re: How to get and validate DMA mode for disks in Windows 3.1? mkarcher explained how single word and multi word correspond to different 8237 modes

I could see the designers trying to make single word DMA devices would with ISA DMA, sure. Third party DMA and all. The dates match up.

MWDMA? Maybe MWDMA-0 was built with ISA DMA somewhere in the realm of possibility if you had a 10mhz bus. But MWDMA-1 & -2 ? They were way too fast to work with the 8237. They were going to need a first party DMA of some sort. So that still smells like they had PCI in mind for those modes. The first revisions of the PCI spec came out in July 1992, no?

Here's an interesting patent from IBM in 1994. Looks like it's for a VLB IDE controller that can switch between fast PIO and slow ISA DMA .
Local bus-ISA bridge for supporting PIO and third party DMA data transfers to IDE drives

Anyway, I have an old quantum drive that says it can do single mode DMA in its ATA identify. Any idea how I might get it to do DMA over ISA?

douglar wrote on Today, 00:12:

Anyway, I have an old quantum drive that says it can do single mode DMA in its ATA identify. Any idea how I might get it to do DMA over ISA?

Perhaps with a card like the one earlier in the thread that connects the DMARQ and DMACK lines, presumably to DRQ5 and DACK5 on the ISA slot, but with a custom disk BIOS.

MWDMA0 is the only one defined in the original ATA. MWDMA1 and MWDMA2 come in ATA-2. So it's possible that MWDMA0 was intended to be possible directly over the ISA bus. And when extending it to more modes, the mindset was "the same protocol as 8237 ISA DMA, but faster than any real ISA bus could do." That seems like the same spirit of what faster PIO mode are, too.

I've wondered if it's no accident that the minimum de-assertion times for DIOR# for PIO 0, 1, 2, and 3, which are 165 ns, 120 ns, 100 ns, and 80 ns, correspond to a cycle for a 6 MHz, 8 MHz, 10 MHz, and 12.5 MHz clock, respectively. The original 286-6 AT is 6 MHz, the updated 286-8 AT is 8 MHz (which became canonical ISA speed), some turbo XTs are 10 MHz, and perhaps a few 286es without an ISA divider were 12.5 MHz.

jakethompson1 wrote on Today, 01:42:

Perhaps with a card like the one earlier in the thread that connects the DMARQ and DMACK lines, presumably to DRQ5 and DACK5 on the ISA slot, but with a custom disk BIOS.

Well , maybe some day I can retire from the day job and spend a week making a hacked up ISA card, a month learning to program a 8237, and then a year writing a Win 3.1 device driver for a small multi tasking gain.

Here is what I got from Claude. The task looks pretty sickeningly hard. Maybe start from an open source floppy driver and twist it into a VxD. Maybe I'd work on some other projects first. Like writing a util to test disk transfers under load for data corruption, because I'd almost certainly corrupt the file system 1000 times before getting it right.

1. Confirm the drive supports it.
Issue IDENTIFY DEVICE (ATA command 0xEC) and check word 62 — the field reporting which single word DMA modes (0/1/2) the drive supports and which is currently active. This is a read-only query, standard on any ATA-1+ drive.

2. Negotiate the mode with the drive
Issue SET FEATURES (command 0xEF) with feature register 0x03 ("Set Transfer Mode") and the sector count register loaded with the mode value (0x00-0x02 for SDMA 0-2, per the ATA-1 encoding). The drive acknowledges by updating its status register.

3. Program the 8237 for this specific channel. This is the real firmware work, and it's a fixed sequence:

Write the mode register (I/O port 0x0B for DMA channels 0-3, 0xD6 for channels 4-7) selecting: this channel, single-transfer mode (not block or demand mode — SDMA maps to single-transfer specifically), and read or write direction matching the ATA command about to be issued.
Write the address registers: the low byte and high byte of the starting memory address to the channel's address port (e.g., port 0x00 for channel 0), plus the page register (port 0x87 for channel 0) for the upper address bits, since the 8237 only handles 16 bits of address itself.
Write the count register: transfer count minus one, to the channel's word-count port.
Clear the channel's mask bit (port 0x0A, or 0xD4 for the second controller) so it can respond to DREQ.

4. Issue the actual ATA DMA command
Send READ DMA (0xC8) or WRITE DMA (0xCA) to the drive's command register. The drive then asserts DREQ when its buffer has data ready (or is ready to accept it).

5. Let single-transfer mode do its thing, one word at a time
Because SDMA maps to the 8237's single-transfer mode: the DMA controller responds to DREQ, does one fly-by word transfer, then releases HOLD back to the CPU — and the drive must re-assert DREQ for every subsequent word. Critically, this means the 8237 doesn't run the whole sector autonomously; BIOS/firmware code has to sit in a loop watching for either the terminal count (TC) signal or the drive's completion status, since control bounces back to the CPU after every single word.

6. Handle the 64KB constraints
The 8237's word-count register maxes at 64KB, and — this one's easy to trip over — a transfer cannot cross a 64KB physical page boundary, since the page register doesn't auto-increment when the low 16 bits wrap. For anything beyond one page, firmware has to split the transfer into page-aligned chunks and reprogram the 8237 between chunks.

7. Detect completion and errors
Poll (or take an interrupt on) the drive's status register for DRQ clearing and BSY dropping, and separately watch the 8237's status register (port 0x08 or 0xD0) for the TC bit on this channel, to confirm the DMA side finished cleanly.

Why this is the hard part relative to bus-master DMA: in the PCI bus-master case, you build one PRD table describing the whole transfer's scatter-gather layout and let the controller run autonomously to completion, interrupting once at the end. Here, because single-transfer mode releases the bus after every word, your firmware loop is far more exposed to timing — and depending on how tightly your DREQ-servicing loop is written, it's plausible you'd bottleneck well below even 2.1MB/s (SDMA-0's nominal max) if the code polling for the next transfer isn't tight. That's a real engineering risk, not just busywork, and part of why period BIOS/firmware teams apparently decided it wasn't worth building.