🚀 go-pugleaf

I wrote:
 > I've been trying to make pseudo-dma work for scsi device drivers for
 > mach.
 > 
 > [movsb doesn't protect against prefetching of operands...]
 > 
 > I can go to an unrolled loop of "movb"s but it is more difficult to
 > work out how many bytes have been copied.

I've done this now and it works better. I figure out how far into the
unrolled loop it is by examining what the pc was at the time of
interrupt.

If I read an 8k chunk from a tape which hits eof after 4k, the
residual is underestimated by one byte (or equivalently, the no of
bytes tranferred is over estimated by 1). This doesn't matter for
hitting a true end of file since the residual is read from the target
using a scsi (request-sense ?) command. But in the event of a
"save-pointers" message, in preparation for a disconnect, I believe
the number needs to be correct.

I believe the discrepency is explained as follows. The 532 is faster
than the peripheral. When the last byte of the tape file is read, the
532 goes on to the next instruction. The way the pal logic seems to
be, the next instruction completes when the byte is ready *or* an
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
incrementing the residual is not correct because a) the 532 mightn't
always be faster than the peripheral, and b) the 532 could have ducked
off to service, say, a clock interrupt which would give the peripheral
time to generate its interrupt, before the next movb instruction is
issued.

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.

I haven't had a good look at this, but I suspect it would need more
than just new pals.

 > A second problem with this "pseudo dma" business is on writes? In the
 > presence of the 532 write buffer, how does one know how many bytes
 > have successfully been copied to the dma buffer at the point where a
 > scsi interrupt (for disconnection (*)) occurs. It seems the number of
 > bytes could be over-estimated by up to two (or 8 if doing movd/movsd
 > rather than movb/movsb).

No progress on this one. Until I put in disconnect support, it is harder
to get a scsi interrupt in the middle of a pseudo dma transfer while
writing than reading.

 > The aic chip has dma count registers on it which should solve the
 > problem.  With the dp chip, however, one seems forced to rely on the
 > cpu to know how many bytes have been transferred.
 > 
 > The obvious kludge which comes to mind is to say that it is most
 > unlikely for a target to start disconnecting except on a block
 > boundary and round the estimated number of bytes transferred
 > accordingly.

Any better ideas?

Ian