🚀 go-pugleaf

[In the message entitled "Pseudo dma." on Aug 27, 22:46, idall@eleceng.adelaide.edu.au writes:]
> 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.

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

The move may or may not have read the byte from the peripheral, when the
interrupt is asserted. When we did the design, it was thought that:

1) SCSI devices will always transfer in block unit sizes (usually 512 bytes)
before requiring service via an interrupt. Even during disconnect/reconnect,
it *seems* that this is the case, but is not required by the standard. A
duff's device, with size of 32 (128 bytes), seems to offer the best
compromise between i-cache usage and speed. Your results may vary. Void
where prohibited.  Up to 512 could be used, but results are uncertain.

2) SCSI devices may not change phase (disconnect) until the ACK has occured
for pending data.

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.

4) The AIC chip is slightly more complex (due to the FIFO) but the same
logic applies.

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

I don't *think* that we missed the boat here. New pals/logic should not
be required - but see below.

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

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. For
block devices, I *THINK* that they will only disconnect on a block boundary.

Yes, you do have to use a gross hack to get them (count-PC-start_of_loop),
but the count is available. The p-dma approach gives *much* better peak
bandwidth than any real-dma chip available on the market, that could
interface to the 532.

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.
Read the count in the ISR if the EOF flag is not set (disconnect) from 
the hardware. Should fit in two chips, in the spare area.

-- 
Dave Rand
{pyramid|mips|bct|vsi1}!daver!dlr	Internet: dlr@daver.bungi.com