3 ms·

> The 8237 is an ISA device and operates at the bus speed (with some overhead, ymmv, yada yada). It's even worse than that -- the 8237 DMA controller is clocke

> The 8237 is an ISA device and operates at the bus speed (with some overhead, ymmv, yada yada). It's even worse than that -- the 8237 DMA controller is clocked at 4.77Mhz for backwards compatability. The normal ISA bus clock is ~8.25Mhz. So ISA DMA is actually half the speed of ISA memory or PIO access. https://wiki.osdev.org/ISA_DMA https://wiki.osdev.org/ISA_DMA is a good reference to the ugly gory details of DMA...

ajross 5y ago
That's correct, but sort of missing context. The original PC bus was synchronous, and everything lived on it. So the idea was you'd fetch an instruction byte from the bus, then another, then another, then spend a cycle interpreting the instruction, then execute the load or whatever it was on the bus, then go back to do it over again. In that world a DMA controller that can do a transfer ever other cycle is much faster than the CPU copy it would be replacing. Modern readers, weened on PCI, see something like "The ISA bus is 16 bits wide at 8 MHz" and think they should be able to stream 16MB/s "across" it "into" main memory. But that's not how it worked with ISA. It's not how it ever worked with ISA. The memory was on the same bus! And the CPU didn't even have a L1 cache!
- kiwidrew 5y ago
  Indeed. Running the DMA at 4.77Mhz made a lot of sense in the context of the original PC and XT, especially since the 8237 was only rated for 5Mhz anyways... [Not to mention that the 8088 took 4 cycles to read a byte from memory and 5 cycles to read a byte from I/O.] The true power of the 8237 was that it never touched the data byte itself: it just manipulated the bus lines, transferring a byte directly from I/O device to memory in just 4 cycles, much faster than the 8088 could ever manage.
- andrewf 5y ago
  https://www.lo-tech.co.uk/xt-cfv3-dma-transfer-mode/ https://www.lo-tech.co.uk/xt-cfv3-dma-transfer-mode/ has some benchmarks for Compact Flash cards on an XT bus. On a V20+/186+, "rep insb" saves a lot of instruction fetch traffic. (The page also talks about breaking up DMA transfers, so a Soundblaster on the same bus can do its own DMA often enough)

ajross 5y ago

That's correct, but sort of missing context. The original PC bus was synchronous, and everything lived on it. So the idea was you'd fetch an instruction byte from the bus, then another, then another, then spend a cycle interpreting the instruction, then execute the load or whatever it was on the bus, then go back to do it over again. In that world a DMA controller that can do a transfer ever other cycle is much faster than the CPU copy it would be replacing. Modern readers, weened on PCI, see something like "The ISA bus is 16 bits wide at 8 MHz" and think they should be able to stream 16MB/s "across" it "into" main memory. But that's not how it worked with ISA. It's not how it ever worked with ISA. The memory was on the same bus! And the CPU didn't even have a L1 cache!

kiwidrew 5y ago
Indeed. Running the DMA at 4.77Mhz made a lot of sense in the context of the original PC and XT, especially since the 8237 was only rated for 5Mhz anyways... [Not to mention that the 8088 took 4 cycles to read a byte from memory and 5 cycles to read a byte from I/O.] The true power of the 8237 was that it never touched the data byte itself: it just manipulated the bus lines, transferring a byte directly from I/O device to memory in just 4 cycles, much faster than the 8088 could ever manage.
andrewf 5y ago
https://www.lo-tech.co.uk/xt-cfv3-dma-transfer-mode/ https://www.lo-tech.co.uk/xt-cfv3-dma-transfer-mode/ has some benchmarks for Compact Flash cards on an XT bus. On a V20+/186+, "rep insb" saves a lot of instruction fetch traffic. (The page also talks about breaking up DMA transfers, so a Soundblaster on the same bus can do its own DMA often enough)