dyer@spdcc.COM (Steve Dyer) (12/04/88)
How compatible are the AT-style 16-bit bus slots with most
16-bit cards sold for the PC/AT and its clones? Can one
say reliably that any card which works on an AT bus should
also work (with appropriate driver support) on an RT?
Are there any "gotchas"?
--
Steve Dyer
dyer@harvard.harvard.edu
dyer@spdcc.COM aka {harvard,husc6,linus,ima,bbn,m2c,mipseast}!spdcc!dyerbernerus@ce.chalmers.se (Christer Bernerus) (12/14/88)
In article <2211@spdcc.COM> dyer@spdcc.COM (Steve Dyer) writes: >How compatible are the AT-style 16-bit bus slots with most >16-bit cards sold for the PC/AT and its clones? Can one >say reliably that any card which works on an AT bus should >also work (with appropriate driver support) on an RT? The answer is unfortunately NO! (at least not reliably) I've spent quite some time now writing device drivers for SCSI tapes and disks using the Adaptec AHA-1540 SCSI host adapter. The problem I went into was that the Adaptec card didn't honor the IOCHRDY signal. It seems to be quite common that cards for the AT doesn't look at this signal. (Even if they should according to the specifications of the AT bus.) Using such cards on an RT is a true nightmare. We patched our Adaptec card so that the clock on the card was stopped when IOCHRDY indicated that there wasnt any data present yet. The patch made the card work just about as much as neccessary for development work. During the period I've been looking for other SCSI cards to put into our RT's without having to patch them. At least the Western Digital WD 7000-ASC shouldn't be considered, since the OEM manual says: 4.1.11 I/O CHANNEL READY This input to the IBM AT bus is pulled low by a memory or an I/O device to lengthen I/O or memory cycles by an internal number of clock cycles (167 nS). **This signal is not used by the WD7000-ASC controller.** The AT connector table says: Pin A10, IOCHRDY*, N/C. (BTW They probably meant integral, not internal) Unfortunately the RT uses this signal quite a lot since the main memory isn't on the AT-bus. Another problem I ran into concerns the use of alternate controllers (3:rd party DMA). When naive controllers (or controller programmers) update things running as a bus master, they think that all memory updates are atomic. On the AT they are, since the memory, the controller and the processor are on the same bus. However, on the RT, the controller is on another bus than the processor and memory, and being an AT bus master doesn't lock out the processor from its memory, so the processor can reach the memory even if there is a controller that is using the AT-bus as a bus master. This causes problems wehn device drivers sometimes read partially updated data. NOTE: I've recently received a new version of the host adapter card from Adaptec (AHA-1542) and indeed, contrary to earlier indications, they seem to have fixed at least the IOCHRDY problem.
pgc+@andrew.cmu.edu (Paul G. Crumley) (12/17/88)
Christer, I guess it's obvious that the card that didn't work (the Adaptec AHA-1540 SCSI host adapter) in the RT/PC doesn't really work in the AT either. (just try DMAing onto a video adapter or some other slow memory that inserts wait states) This board is clearly broken by design. (the IBM PC/AT Technical Reference Manual is very clear about the use of this signal) As for the problem with non-atomic reads and writes from system memory, try setting the DMA channel to use "buffered" mode. (this is described in the RT/PC Tehcnical Reference Manual) This mode will force updates to be atomic and will usually provide better performance too! BTW: How about using the IBM RT/PC SCSI adapter? We use them here and they work fine. They have plenty of buffers so the performance is quite good. Best Regards, Paul