🚀 go-pugleaf

I've been trying to make pseudo-dma work for scsi device drivers for
mach.

I have had limited success. I find that I can do reads in small chunks
mostly successfully, but with reads of over 3k, I loose the (3k + 1)th
byte. This looks very much like it arises from an interrupt occuring
and a re-read occuring from the dma buffer.

It is odd that this seems to be repeatably (at least with the same
command) the (3k + 1)th byte, I wouldn't have expected this degree of
synchronization (of clock interrupts?)!  Anyway, all comes good if I
raise spl before the read. Which tends to point the finger pretty
definitely at the pre-fetched operands being discarded on interrupt
problem.

However, this is not an adequate final solution since disabling
interrupts does not allow the correct determination of the number of
bytes copied (needed for disconnect support).

I am currently using "movsb". The string instructions support "partial
completion". A pending interrupt is only serviced when the instruction
is at a point where r0, r1 and r2 have been adjusted and the
instruction can be restarted. However, I can't find any documentation
to say whether the next operand might have been fetched. Can anyone
with intimate knowledge of 32532 internals (Dave? George?) comment?

I can go to an unrolled loop of "movb"s but it is more difficult to
work out how many bytes have been copied.

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).

The aic chip has dma count registers on it which may 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. If this is indeed the case, then a) one could just
disable interrupts and re-enable them momentarilly after every
blocksize bytes have been transferred and b) use movd or movsd instead
of movb or movsb.

It seems like this must have all been solved before for minix (unless
the minix drivers are as simple as the current mach drivers and don't
support disconnection) and I would just as sooner not re-invent the
wheel.

Ian

* Technically, the number of bytes isn't needed if the target abruptly
  disconnects. If the target wants to reconnect, is should send a
  save-pointers message, so the interrupt which is actually relevant is
  the phase change interrupt.