ag@elgar.UUCP (Keith Gabryelski) (10/22/88)
Distribution has been limited to comp.unix.questions and comp.sys.ibm.pc. Follow ups to comp.sys.ibm.pc. In article <1279@umbc3.UMD.EDU> brian@umbc3.UMD.EDU (Brian Cuthie) writes: >In article <168@ernie.NECAM.COM> koll@ernie.NECAM.COM (Michael Goldman) writes: >>There are some other problems >>with DMA on the PC. One is that DOS is not re-entrant and so you have >>to VERRRY Carefully save the state with any program that uses interrupts >>which is implicit in any reasonable application with DMA. With all the > >Besides, I know what re-entrant instructions are (and besides, >they're "restartable instructions", but that's a different point), >but what the !%^%@ is a re-entrant operating system. For DOS people, re-entrant operating system, does indeed, mean something. DOS was written without any regards for multi-tasking programs. In DOS, the system routines use the same static buffers. This prevents two routines, say a foreground process and a TSR, from doing DOS calls at the same time. There is infact a flag that is set when a DOS call is initiated that should be checked by all TSRs before attempting any DOS call. So, in the contex in which Micahael was talking, the answer to your question... >Can you name one ?? I bet not. ... is Unix. Pax, Keith -- ag@elgar.CTS.COM Keith Gabryelski ...!{ucsd, jack}!elgar!ag
johne@hpvcla.HP.COM (John Eaton) (10/24/88)
<<<< < < Since NOTHING can interrupt a DMA in progress (including another higher < priority DMA request) burst mode DMA transfers, which would be < significantly faster than CPU transfers could EVER be, would lock out the < channel 0 refresh for too long. Thus DMAs are limited to single byte < transfers. I have seen some graphics cards that use block mode and burst 8 bytes out everytime it gets a DACK*. That doesn't violate memory refresh timing. < Keep in mind that DMA is significantly faster than CPU transfers, even with < caching, because the DMA chip places the memory address on the bus and then < asserts the READ or WRITE line while simultaniously asserting the DMA ACK < line. Since the peripheral requesting DMA is well aware of who he/she is < and knows that if the memory WRITE line is asserted it must be a peripheral < READ (and vice versa) the transfer takes place in exactly ONE memory cycle. The 8237 does a transfer by pulling on IOR* followed one clock later by MW* or (MR* followed one clock later by IOW*). A peripheral only has to look at the DACK line and IO strobes. All IO devices have to decode CPUAEN* so as not to interfere with a DMA transfer when the memory address equals their IO address. The simultanious transfer is not a useful as you might think it would be. A normal CPU write cycle has data valid at the start of the cycle and DRAM's can strobe data in at the start of a cycle. IBM's memory control is designed so that data written into memory must be valid early in the memory cycle rather than at the end. So if you are doing a IO->Memory DMA you must wait almost the entire access time of the peripheral device before starting the memory write cycle. This really get to be a problem when you try and support slow PC cards on a fast AT bus. John Eaton !hpvcla!johne