10. The DMAC asserts the memory write command line (MWTC#) and places the address from channel two’s start address register onto the address bus. Normally, the command lines indicate whether the address bus carries a memory or i/o ADDRESS. At this point, however, two command lines (IORC# and MRDC#) are asserted. The asserted IDA bus AEN signal prevents all I/O devices, except for the one that is connected to DACK2#, from responding during this bus cycle.
11. The data on the data bus is written into memory that the address currently on the address bus/
12. The DMAC then increments channel two’s memory address register by one to point to the address in the RAM where it will store the next byte it receives from the disk controller.

13. The DMAC also decrements the byte transfer count. If the transfer count is not exhausted, the data transfer is not complete and the DMAC waits for another DMA Request (DRQ2) from the floppy drive controller, indicating that it has another byte to transfer (step eight).
14. When the transfer count is exhausted, the data transfer is complete. The DMAC will then de-assert the hold request line (HRQ (to tell the microprocessor that it no longer needs the buses. The microprocessor will re-attatch itself to the buses (exit the tri-state condition) and de-assert the Hold Acknowledge line (HLDA) to tell the DMAC it has resume control of the buses. The microprocessor is now bus master again. Logic on the system board de-asserts the ISA bus AEN signal so that I/O devices can resume decoding their addresses.
15. The DMAC also generates EOP (end of process). This supplies the signal TC (terminal count reached) to the disk controller. The disk controller will then generate a device-specific interrupt that request to the 8259 interrupt controller which in turn generates INTR (interrupt request) to the microprocessor to inform it that the transfer operation is complete.

DMA Transfer Types:
Read transfer
Write transfer
Verify transfer

DMA Transfer Modes
Single Transfer Mode
Block Transfer Mode
Demand Transfer Mode
Cascade Mode

按照以上信息，DMA的过程应该是：
1. 板卡数据准备好后置DREQ为有效
2. DMAC收到DREQ后，发HRQ给CPU请求HLDA
3. CPU发HLDA给DMAC并放开总线控制
4. DMAC收到HLDA后，发DACK#给板卡
5. 板卡看到DACK#后，置DREQ为无效，并将数据放到数据总线
6. DMAC控制数据读写，并计数加一
7. 如果总计数值未到预设值，重复1-6过程。

注意一定要板卡与DMAC之间通过DREQ - DACK#的握手过程来控制数据传输。

我的设备是个FIFO，当FIFO半满的时候发DMA请求信号DREQ给总线，8237获得总线控制权后给FIFO发DMA应答信号DACK，怎么来启动DMA的操作？？外设没有什么中断控制寄存器，或者DMA使能寄存器等给我写，我怎么办？？

你的板卡应该在一开始就发DREQ给系统，等系统回DACK#给你时置DREQ为无效，收数据，然后再置DREQ。这样就可以一直把数据发给你的板卡了。
硬件上好象要改动啊，设计上如果已经定死了那就没办法了。

[编辑 -  8/19/03 by  grant]

如果是我的话，为了确定问题，我会采用以下步骤：
1. 回DOS，用C或ASM控制8237，看是否能够发起DMA。
2. 如果可以，回Windows并用示波器监控DREQ与DACK#。
3. 如果不行，就要分析硬件的问题了。

按照以上信息，DMA的过程应该是：
1. 板卡数据准备好后置DREQ为有效
2. DMAC收到DREQ后，发HRQ给CPU请求HLDA
3. CPU发HLDA给DMAC并放开总线控制
4. DMAC收到HLDA后，发DACK#给板卡
5. 板卡看到DACK#后，置DREQ为无效，并将数据放到数据总线
6. DMAC控制数据读写，并计数加一
7. 如果总计数值未到预设值，重复1-6过程。

注意一定要板卡与DMAC之间通过DREQ - DACK#的握手过程来控制数据传输。

非常感谢grant大哥的回答，即使将来我做不出来，我也要多给你点分。
你说的很对，DMA的执行过程正是你说的那样，我理解的也是这样的。但在驱动里面，我看了所有的关于系统DMA驱动的框架，都是这种模式：
1。驱动入口点：DriverEntry例程，完成初始化的一些设置，另外还要获得适配器对象的地址。
2。StartIo例程：  和一般的PIO设备的STARTIO例程不同的是，获得适配器对象的拥有权。
3。AdapterControl例程：执行函数：IoMapTransfer函数来编程系统DMA控制器，然后给设备发送合适的命令来通知设备开始DMA服务请求。
4。ISR：中断处理例程
5。DPC_FORISR :中断延迟处理例程。

令我困惑的是AdapterControl例程里的：给设备发送合适的命令来通知设备开始DMA服务请求。
正象你说的：板卡与DMAC之间通过DREQ - DACK#的握手过程来控制数据传输，我也是这么理解的，但这个和给设备发送合适的命令来启动DMA的传输有什么关系？也就是只要设置好了8237，8237就自动把数据从板卡转移到内存中！

困惑！！！

令我困惑的是AdapterControl例程里的：给设备发送合适的命令来通知设备开始DMA服务请求。
正象你说的：板卡与DMAC之间通过DREQ - DACK#的握手过程来控制数据传输，我也是这么理解的，但这个和给设备发送合适的命令来启动DMA的传输有什么关系？也就是只要设置好了8237，8237就自动把数据从板卡转移到内存中！

我想是这样，板卡是需要驱动发送命令来开始发第一个DREQ的。

虽然设置好了8237，但是要通知板卡发第一个DREQ才能开始传数据。

[编辑 -  8/19/03 by  grant]

[/quote]

我想是这样，板卡是需要驱动发送命令来开始发第一个DREQ的。 [/quote]

你前面说的在DOS下先检查硬件的毛病是对的，应答那样做！
我现在的问题是我的驱动程序里启动DMA的问题。
板子上的FIFO发DREQ的条件是FIFO半满，这个和我的驱动有什么关系，我的驱动怎么来控制使它发第一个DREQ？？

那就变成硬件要改了。
想想你一直没数据发出来，FIFO怎么能半满呢？
而且需要一直有DREQ作为握手信号，FIFO HF也不适合呀。

板子上的FIFO发DREQ的条件是FIFO半满，这个和我的驱动有什么关系，我的驱动怎么来控制使它发第一个DREQ？？

上午忙得没时间过来。
这样我看是没办法完成DMA的。
应该在硬件上利用计数器或别的电路来产生DREQ的时序，
软件只是让这个电路开始运作。
以你的硬件把DIREQ和FIFO HF接在一起，是没办法完成这样的工作的。

那就变成硬件要改了。
想想你一直没数据发出来，FIFO怎么能半满呢？
而且需要一直有DREQ作为握手信号，FIFO HF也不适合呀。

很高兴和你能这么深入的讨论这个问题，我越来越困惑了！板子上的FIFO是和一个单片机了连在一起，单片机从前端接收数据处理后传给FIFO，然后，FIFO的半满标志HF和总线上的DMA请求信号DREQ连接。这个应当是没什么问题吧？？你说没数据发出来。我不懂你的意思，而且HF不合适，我也不理解

板子上的FIFO是和一个单片机了连在一起，单片机从前端接收数据处理后传给FIFO，然后，FIFO的半满标志HF和总线上的DMA请求信号DREQ连接。这个应当是没什么问题吧？？

你说没数据发出来。我不懂你的意思，而且HF不合适，我也不理解

你的意思是，单片机连到ISA总线，控制FIFO的读写？
可是数据从哪儿来呢？要么就是单点读写。
要启动DMA的话，总得有个开始信号发DIREQ才行呀。

FIFO HF --> fifo half full. 是FIFO的几个状态引脚之一。

[/quote]

你的意思是，单片机连到ISA总线，控制FIFO的读写？
可是数据从哪儿来呢？要么就是单点读写。
要启动DMA的话，总得有个开始信号发DIREQ才行呀。

FIFO HF --> fifo half full. 是FIFO的几个状态引脚之一。
 [/quote]

非常地抱歉，我一直把DMA的传送方向给弄反了。我们现在在用PIO方式传输数据给板卡，发现速度很慢（8位的I/O传输），只有25KB/S，打算改成DMA的方式，DMA的传送方向是从主机到板卡：板卡上有FIFO做为缓存和总线相连，FIFO的另一端是单片机，也就是数据的流动方向是：应用层-驱动层-FIFO-单片机。用DMA的话，请大虾分析一下，接口关系怎么设计？？

DMA的传送方向是从主机到板卡：板卡上有FIFO做为缓存和总线相连，FIFO的另一端是单片机，也就是数据的流动方向是：应用层-驱动层-FIFO-单片机。用DMA的话，接口关系怎么设计？？

我从昨天开始知道你的数据流向的。
以你目前的硬件是没办法做DMA了，要重新设计。
板上有单片机，那就好办了。拿它控制时序好了。用单片机的某一位控制DREQ，另一位接收DACK#，当收到ISA总线传来的控制命令后开始握手传输，用FIFO接数据。
具体没仔细想，你画个草图想一下，有问题欢迎讨论。

[/quote]

我从昨天开始知道你的数据流向的。
以你目前的硬件是没办法做DMA了，要重新设计。
板上有单片机，那就好办了。拿它控制时序好了。用单片机的某一位控制DREQ，另一位接收DACK#，当收到ISA总线传来的控制命令后开始握手传输，用FIFO接数据。
具体没仔细想，你画个草图想一下，有问题欢迎讨论。 [/quote]

ISA总线传来的控制命令，我想应该是通过驱动给板子上的寄存器写入特定的数据来实现吧，除了这种方法，也没有其他的办法了！

grant怎么不来了？继续讨论啊

ISA总线传来的控制命令，我想应该是通过驱动给板子上的寄存器写入特定的数据来实现吧，除了这种方法，也没有其他的办法了！

对。建议通过端口发数据给指定的寄存器。
你软硬件都做吗？还是另有人做硬件？

grant怎么不来了？继续讨论啊

昨天后来网络出问题，没办法上来呀。
我回家后就不上网了，看书为主。  :)