After all this time, I think I'm actually starting to understand the mysterious (to me anyway) 8237...
Rereading the datasheet, I've realized that the 8237 can be 'forced' to do an xfer by the CPU, by forcing DACK to assert in software (at least 2:00 AM me
thinks that's how it works
- feel free to correct me). Is there any PC hardware that anyone is aware of that by convention uses a 'CPU-initiated' DMA xfer instead of using a DMA request? What happens if the I/O device runs out of data to send or receive? I don't recall there being an ISA control signal to tell the DMA controller of abnormal conditions other than to add DMA wait states.
Logically, I thought the floppy controller DMA would've used this approach (software-initiated DMA), but looking at the BIOS source code, it appears the BIOS programs the DMA controller, programs the NEC floppy controller, and then waits in a loop for an interrupt signifying End-of-DMA... so that would mean the DMA xfer begins when the floppy controller asserts DREQ2. Do I understand this correctly?
And even though I mentioned this in my previous post, I'm questioning it anyway...
How DOES an I/O peripheral know when it's time to increment it's internal buffers to read in or write out another byte for a DMA xfer through an I/O port? Since there's no address placed on the bus for I/O devices, and the IOW/IOR signals must always be qualified by AEN and DACKx (where x is a channel) for the duration of the xfer, I can't see which control signal an I/O device can use to "know" when it's time for the next byte to be read or written via DMA.
Also, reenigne, if you read this, you mentioned a way to do a mem-to-mem xfer on the PC, but only in between 64kB pages... I presume this has to do with DACK0 not being connected to the IC "register file" which holds bits 16-19 of the IBM PC address? Additionally since