Re: Seeking enlightenment regarding Bus Adapter Purges on Unibus VAXen (and their ilk)
On Fri, Sep 6, 2019 at 4:32 AM Matt Burke via cctalk wrote: > I'm not sure if the adapter needs to request the purge at the end of > each block transfer. The driver may do this anyway but I'll have to > check the source listings. I would definitely check source listings. Also, check BSD/Ultrix _and_ VMS. I guarantee they don't do everything the same way (case in point RB730 controller initialization) but both will be insightful. My own Unibus (and Qbus and VAXBI) experience is with comm drivers not storage drivers so I don't have any insights on block transfers and purges, unfortunately. I'm excited for the results of this. -ethan
Re: Seeking enlightenment regarding Bus Adapter Purges on Unibus VAXen (and their ilk)
On 9/5/19 9:22 PM, Josh Dersch via cctalk wrote: > I have a pretty good grasp of > Unibus mechanics these days but I'm not quite understanding the reasoning > behind this. Here's what the Storage System Unibus Port Description > (AA-L621A-TK) document says: you might also want to ask on the simh developers list
Re: Seeking enlightenment regarding Bus Adapter Purges on Unibus VAXen (and their ilk)
On 06/09/2019 05:22, Josh Dersch via cctalk wrote: > What I do not understand is (a) why such purges are necessary, and (b) how > the MSCP controller knows when one should occur. The Port Description doc > hints that it has to do with repeated access to a given area of memory. > The DW780 documentation hints that it needs to happen after *any* block > transfer. (See pg. 2-58 of the document linked above.) > > I think point 3 and 4 on page 2-59 are critical here. The memory accesses via the buffered data path must be to consecutive increasing addresses. If a non-consecutive access is required (transfer restart, compare etc) then the data path must be purged first. In the case of a write this will flush any residual bytes to memory and for a read it will ensure that fresh data is loaded to the buffer on the next access. At least that's my interpretation from reading 2.6.2.2 I'm not sure if the adapter needs to request the purge at the end of each block transfer. The driver may do this anyway but I'll have to check the source listings. Matt
Seeking enlightenment regarding Bus Adapter Purges on Unibus VAXen (and their ilk)
Hi all -- Been working on an MSCP implementation for Joerg Hoppe's Unibone project, and it's working well on PDP-11 systems; less well as of late on the VAX. I've been looking to tidy up a few dark corners in the MSCP spec and one thing that's left is bus adapter purges -- I have a pretty good grasp of Unibus mechanics these days but I'm not quite understanding the reasoning behind this. Here's what the Storage System Unibus Port Description (AA-L621A-TK) document says: "To support such higher-level protocol functions as transfer restarts, compares, etc., the host memory interface must allow repeated access to a given host memory location for both reads and writes. On purely Unibus systems such as 11/44, this requirement is trivially met with no participation by the host CPU. On systems with bus adapters such as the 11/780, the repeated access requirement means that the relevant adapter channel may have to be purged, requiring the active cooperation of the host CPU. The port signals its desire for an adapter channel purge by interrupting the host. The host writes zeroes to the SA register to indicate purge completion." This is also discussed, from the bus adapter point of view, in the technical documentation for the bus adapter itself. (See http://www.vaxhaven.com/images/2/29/EK-DW780-TD-001.pdf) It hasn't been particularly enlightening to me, but I will admit to not having read every page of this and the DW780 doc -- maybe I missed something :). I understand the mechanism here; in essence it's: 1) MSCP controller decides a purge is necessary after a DMA transfer and requests one by setting a value in a reserved slot in the communications area 2) Host system (MSCP driver) sees the special value, and issues a purge command to the bus adapter. 3) Host system then clears the value in the communications area 4) MSCP controller continues on its merry way. What I do not understand is (a) why such purges are necessary, and (b) how the MSCP controller knows when one should occur. The Port Description doc hints that it has to do with repeated access to a given area of memory. The DW780 documentation hints that it needs to happen after *any* block transfer. (See pg. 2-58 of the document linked above.) Anyone have any experience with this? Thanks! Josh
