🚀 go-pugleaf

Dave Rand writes:
 > 
 > [In the message entitled "Pseudo dma." on Aug 27, 22:46, idall@eleceng.adelaide.edu.au writes:]
 > > interrupt occurs. There is no way to tell the difference between an
 > > instruction that completed because it read real data and an
 > > instruction which completed because a scsi interrupt occured. Merely
 > 
 > This is correct.
 > 
 > > I think what is really needed, from the hardware point of view, is to
 > > abort the bus cyle (and thereby the instruction) if (and only if) an
 > > interrupt occurs from a scsi device when a read/write cyle to/from the
 > > pseudo-dma area is in progress.
 > 
 > This is what is done. But you didn't really mean abort. The INT pin is
 > only examined at the completion of each instruction (or start, one of
 > the two). If the instruction is completed due to a read, you want the
 > PC to point to the NEXT instruction. If the instruction is completed due
 > to an interrupt, you want it to point to the CURRENT instruction. I don't
 > know of a way to do this on the 532. So...

Actually I did mean abort. I guess I was thinking asserting BER would
do the trick, but the data sheet says that the PC is undefined(!)
after a BER so I suppose it wouldn't do the trick after all.

 > 3) The 8490 can be polled (bit 6 HA 5) to determine the true state of DRQ.
 > A proper ISR will poll this bit, and read the last byte if required.

I am not too sure about this one. The enhanced mode is supposed to
only give an end-of-dma interrupt after the last byte has been
transferred. I am using enhanced mode, I am not doing this polling,
and I am not (at least so far) losing any bytes. But then, I
haven't tried disconnects yet.

The chip spec says that phase mismatch doesn't reset DRQ (section 3.0)
and it also says (section 4.11.2) that the easi will stop driving the
bus on a phase mismatch. It doesn't say that the situation arises, but
I suppose that DRQ active means there is still a byte in the 8490 chip
to be read. It is hard to see how this could arise on a write (if the
scsi bus is already "not being driven" sending more data from the CPU
to the 8490 can't do much good. Should that final read be done with
EOP?

 > Again, for writes you could over-estimate if you use MOVD. If you use MOVB,
 > and poll the DRQ bit, you *know* how many bytes were transferred.

How does this work? What I am concerned about is not the normal
end-of-dma, which the enhanced mode seems to signal correctly, but the
abnormal end-of-dma due to phase change etc.

Also, do you recommend movb's or movd's? I am not sure if there is an
appreciable difference in speed when the source or destination
operands are the pseudo-dma buffer. I am getting 4.25 MB/sec using a
loop of 32 movb's (DRAM to DRAM). I am sure a loop of movd's would go
faster DRAM to DRAM, but since 4MB per sec nearly saturates a normal 8
bit SCSI bus anyway, is there any benefit in going to movd's?  On the
other hand, if the byte count is to be uncertain anyway due to the
factors discussed, I suppose there is not much *disadvantage* in going
to movd's.

 > For
 > block devices, I *THINK* that they will only disconnect on a block boundary.

I guess this is what it comes down to. You have to make that
assumption.  I suppose it is true for most block devices, but I
imagine that SCSI printers and SCSI comms devices might be two cases
where it is not true. Admittedly, both of these are as scarce as
rocking horse shit.

 > If worse comes to worse, one approach might be to use a small counter
 > (say, equal to the duff's device loop size in bytes). Preload it on the
 > top of each loop, and decrement/increment on the DRQ from the SCSI.

Or even simpler, from a hardware point of view, leave off the
pre-load.  Just count DRQ's and read at the beginning of the transfer
and in the isr. Work out the difference, unwrapping if necessary. Work
out the nominal bytes transferred the way we do now and use the
counter difference result to set the low bits. An 8 bit counter should
be heaps.

I might try this one day, but for now, I suppose I will do the driver
development using the "disconnects only happen of block boundaries"
assumption.

Ian