🚀 go-pugleaf

This is actually intended for Des Young, but the mailer at NSC keeps bouncing
it back to me. I'm sorta forced to send it to the group.


Hi Des;

I'm currently working on a driver for the AIC6250 chip and have run into
problems with pseudo-DMA. I sent George the message below and he thought
that you might be working on a driver too and recommended that I contact
you.

>> I'm trying to write a driver for the 6250 SCSI chip (as you've probably
>> noticed from other mail). Everything works fine (read/write) when I use
>> polled mode. However, when I try to use the pseudo-DMA the chip thinks that
>> fewer bytes have been transferred than my software does, i.e., there's usually
>> a residue in the DMA count registers after I come out of the transfer loop.
>> Note that this loop uses byte accesses rather than movsd.
>> 
>> I'm pretty sure that I'm programming the chip correctly because, if I loop
>> until the chip thinks there are no more bytes, the disk is happy and the
>> chip is happy. Unfortunately, the data actually transferred to/from the
>> disk is wrong.
>> 
>> I'm just a poor software guy but one of the hardware people here looked at
>> various signals with a logic analyzer. We examined the behavior with both the
>> 8490 and the 6250 for comparison.
>> 
>> We looked at the following signals:
>> 	drqs0/1 into the scsi pal
>> 	/rd from the wait pal
>> 	A27 from the decoder pal\__ we triggered on these two
>> 	/scsi into the scsi pal /
>> 	/dack from the wait pal
>> 	/nrdy from the wait pal
>> 	/dack0/1 from the scsi pal
>> 
>> For the 8490 (which works) we noticed that drqs1 was asserted about every
>> 800ns with /dack1 coming shortly after. For the 6250 we noticed that drqs0
>> was asserted 4 times in a row (about 760ns all told for 4 drqs0's). /dack0
>> appeared on the heels of drqs0. /scsi remained asserted the whole time. After
>> this "burst" there was a delay of about 2600ns until the next "burst".
>> I assume that drqs0 comes so quickly in bursts because of the on-chip FIFO
>> and that the 2600ns delay corresponds to the time needed to read 4 more
>> bytes into the FIFO.
>> 
>> It looked sort of like this for the 6250: (for a read)
>> 
>>         __________________________  __  __  __
>> A27: ___|                         |_| |_| |_| |________
>> 
>>      ___                           _   _   _   ________
>> /scsi:  |_________________________| |_| |_| |_|
>> 
>>     ________   ___   ___   ___    __________________________
>> drqs0:      |__|  |__|  |__|  |___|
>> 
>>      ______   ___    __    __    __________________________
>> /dack0:    |__|  |__|  |__|  |___|
>> 
>> I don't think that the CPU transferred a byte each time drqs0 was asserted.
>> I suspect that the cycle was extended by the logic in the pals and that only
>> one byte was really transferred. However, I don't know which signals to look
>> at to verify this.
>
>No, the /dack0 signal is asserted by the wait/scsi pal combination. The /dack
>signal from the wait pal is generated only for a iord or iowr to/from the
>scsi pseudo dma address. Therefore, since you show a /dack for each drqs this
>can only occur if the cpu performs a read or write. So, I don't know why
>you appear to be losing data - but the waveforms that you show are correct.
>
>> I'm wondering if the bursty way that drqs0 comes isn't leading to a problem.
>> Did you and Dave ever test out the 6250 with pseudo-DMA? Do you think that
>> there could be a problem with the scsi and/or wait pals?
>
>It shouldn't be a problem, since the aic6250 can only de-assert drq when it
>receives a /dack and that can only happen when the cpu does a read or write
>as explained above.
>
>We haven't really looked at the aci6250 since we only had the old DL rev
>which was very broken (which rev do you have - we shipped EL's to everyone
>but I think that some of the kits from Steve Ligget had some DL's). When we
>got the EL rev we checked transfers very quickly and then went on with the
>8490 which we had drivers for and which Bruce supported in Minix. I think
>that Des Young has been working with the aic6250, maybe you should check
>with him and see if he has had problems.
>
>> Can you suggest any other signals to look at to confirm whether the CPU is
>> transferring a byte every time drqs0 is asserted?
>
>As I've said - the cpu must be transferring data - else /dack wouldn't
>transition.
>
>> Any leads you can give me will be greatly appreciated.
>
>Good luck, keep me posted,
>
>best regards,
>
>-- 
>George Scolaro
>george@wombat.bungi.com                [37 20 51 N / 122 03 07 W]
>

ARE you working on a driver and, if so, have you seen anything like this?
Am I doing something wrong/stupid here?

As I wrote to George, any leads you can give me will be greatly appreciated.

Gary