JGROVER@MAINE (10/03/89)
I'd appreciate tapping into the cumulative knowledge out there concerning the proper methods for doing DMA from a peripheral board. I need to know how to set up the channel for both reads and writes. I know how to get my board to do the read or write once the channel is set. John Grover University of Maine Computing Center
chasm@attctc.Dallas.TX.US (Charles Marslett) (10/05/89)
In article <JGROVER.891002160902@MAINE.MAINE.EDU>, JGROVER@MAINE writes: > I'd appreciate tapping into the cumulative knowledge out there concerning > the proper methods for doing DMA from a peripheral board. I need to know > how to set up the channel for both reads and writes. I know how to get > my board to do the read or write once the channel is set. > > John Grover After a long series of hassles with MSDOS and its demented attitude toward device drivers, I would strongly reccommend you avoid writing a device driver and making your access to the device "clean." It hurts to say that (I have even implemented IBM's bisync protocol as a Unix line discipline, so I have properly encapsulated I/O tasks in the past). MSDOS just does not understand any kind of block device that is not part of the file system! Otherwise, either put the DMA on the board (I think this is called first-party-DMA), or plan to learn about all the idiosynchracies of the 8237 and those of the almost compatible C&T, WD, etc., motherboard chip sets. May you live in interesting times (;^). Charles > University of Maine Computing Center =========================================================================== Charles Marslett STB Systems, Inc. <== Apply all standard disclaimers Wordmark Systems <== No disclaimers required -- that's just me chasm@attctc.dallas.tx.us
cgs@umd5.umd.edu (Chris G. Sylvain) (10/06/89)
In article <9577@attctc.Dallas.TX.US> chasm@attctc.Dallas.TX.US (Charles Marslett) writes: >After a long series of hassles with MSDOS and its demented attitude toward >device drivers, I would strongly reccommend you avoid writing a device >driver and making your access to the device "clean." [...] MSDOS just does >not understand any kind of block device that is not part of the file system! Much as I respect the poster and the great volumes of very informative technical information he has posted in the past, I submit that the above is a false assertion. Please check with the folks at IOtech in Cleveland, Ohio. Their IEEE-488 interface card for the PC's is shipped with a device driver that installs itself as "\DEV\IEEEIN" and "\DEV\IEEEOUT". Both DMA and non-DMA transfers are supported. Please excuse me if I have misunderstood the technical details of the assertion. I have used their product with success. -- --==---==---==-- Borogove: A thin, shabby-looking bird something like a live mop -- ARPA: cgs@umd5.UMD.EDU BITNET: cgs%umd5@umd2 -- -- UUCP: ..!uunet!umd5.umd.edu!cgs --
chasm@attctc.Dallas.TX.US (Charles Marslett) (10/08/89)
In article <5421@umd5.umd.edu>, cgs@umd5.umd.edu (Chris G. Sylvain) writes: > In article <9577@attctc.Dallas.TX.US> chasm@attctc.Dallas.TX.US (Charles Marslett) writes: > >After a long series of hassles with MSDOS and its demented attitude toward > >device drivers, I would strongly reccommend you avoid writing a device > >driver and making your access to the device "clean." [...] MSDOS just does > >not understand any kind of block device that is not part of the file system! > > Much as I respect the poster and the great volumes of very informative > technical information he has posted in the past, I submit that the above is > a false assertion. Actually I did not assert anything -- just made a sugguestion. But I should explain why: MSDOS handles errors pretty much in two ways: character devices are assumed to work or not work, and nothing need be done to fix an error (no character went out to the paper tape punch or whatever, or it did go out, and DOS returns no error code). Block devices are disks: if an error occurs, we redo the whole operation from the top, rewriting the whole sector, or rereading the whole sector -- and for a sector oriented device that supports reads, writes, and positioning commands, this works quite well. If you have a block device that does full duplex transfers, and perhaps has structure to its operations (say, headers, data, and check information) -- it is very hard to make a DOS device driver work. Even a relatively simple device driver (say for a printer) that should not be invoked for each character, but rather for blocks of characters (pages) to increase transfer speed, DOS can't hack it. HP Laserjets can run about twice as fast if you bypass the byte-at-a-time DOS/BIOS bottleneck, but the code becomes a nightmare if you want to use an MSDOS driver. (You have to remember the contents of the last buffer you were sent, for example, if the printer is taken off line, so you can strip off the characters actually sent from the next buffer (if they match those sent in the last buffer), because DOS doesn't tell the application all it needs to know, and many DOS programs (COMMAND.COM's COPY for example) don't care what they get sent anyway). > Please check with the folks at IOtech in Cleveland, Ohio. Their IEEE-488 > interface card for the PC's is shipped with a device driver that installs > itself as "\DEV\IEEEIN" and "\DEV\IEEEOUT". Both DMA and non-DMA transfers > are supported. Please excuse me if I have misunderstood the technical details > of the assertion. I don't know much about the IEEE bus, but I would guess that the device driver needs to do a lot of what I mentioned above. Simple block transfers (maybe, START-INSTRUMENT or SET-SCALE that transfer a chunk of data and at most get a simple acknowledgement) might not require much effort, but I seem to recall there are IEEE commands that transfer arbitrary sequences of stuff (such as TELL-ME-YOUR-SETTINGS or SEND-ME-A-READING-EVERY-SECOND-TIL-I-STOP-YOU). Those can be handled, but if you don't have to be a general purpose device driver, you should skip the hassles, and use funny IOCTLs or non-DOS I/O functions in the program itself or in TSRs. > I have used their product with success. > -- > --==---==---==-- > Borogove: A thin, shabby-looking bird something like a live mop > -- ARPA: cgs@umd5.UMD.EDU BITNET: cgs%umd5@umd2 -- > -- UUCP: ..!uunet!umd5.umd.edu!cgs -- =========================================================================== Charles Marslett STB Systems, Inc. <== Apply all standard disclaimers Wordmark Systems <== No disclaimers required -- that's just me chasm@attctc.dallas.tx.us