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(a)classiccmp.org> wrote:
On Nov 1, 2022, at 2:32 PM, ben via cctalk
<cctalk(a)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