Paul said “But the DZ doesn't do DMA.” 
I apologize. I used DZ in responses when i meant DH. 
  

Sent from my iPhone

> On Nov 1, 2022, at 11:56, Paul Koning via cctalk <cctalk@classiccmp.org> 
> wrote:
> 
> 
> 
>> On Nov 1, 2022, at 2:32 PM, ben via cctalk <cctalk@classiccmp.org> wrote:
>> 
>> On 2022-11-01 11:20 a.m., Paul Koning via cctalk wrote:
>> tents.  The result is that the OS only has to deal with the device every 30 
>> characters or so (RSTS case) or even less often if the buffer size is larger.
>>> Consider disk for another example.  With very rare exceptions, disks do 
>>> DMA: the OS points to the place where the data lives, supplies a transfer 
>>> length and starting disk position, and says "go do it and tell me when it's 
>>> finished".  Newer devices like the MSCP controllers support a queue of 
>>> requests, but even simple devices like the RK05 will do a full transfer 
>>> without CPU involvement.
>> How mqny old systems required partial transfer for disk io, for swapping 
>> overlays in and out?
> 
> Arbitrary size reads are common; as you said overlay loads require that.  
> Partial block writes are not so common.  In RSTS, the base OS write operation 
> does not allow that.  But I found out early that RT11 does, and depends on 
> it.  In RT11, if you do a partial block write, the rule is that the rest of 
> the block is zero-filled.  In some disks the controller takes care of that.  
> In the RF11, the driver does because the device does any word count, so the 
> driver sets up a separate transfer for the rest of the block using a word 
> containing zero as the source buffer, and "inhibit bus address increment" set 
> so all the DMA cycles use that same word.  In the RC11, the sector size is 64 
> bytes, so the device zero-fills to the end of the sector but the driver has 
> to do the same sort of stuff as the RF11 driver if there are any additional 
> 64-byte sectors left before the 512-byte block boundary.
> 
> It turns out RT11 Fortran depends on this, though I don't remember the 
> details.
> 
>    paul
> 

Reply via email to