"Bounce buffer" copyright [was Re: flash (or ide) storage for unibus 11?]
paulkoning at comcast.net
Sun Nov 29 12:33:54 CST 2015
> On Nov 29, 2015, at 1:13 PM, Warner Losh <imp at bsdimp.com> wrote:
> A similar thing was implemented on the old DEC Rainbow 100 (though
> I'm sure others). To give the software a chance to do some minor things
> while processing, it physically laid out the 10 sectors as 0 2 3 4 6 8 1 3
> 5 7 9
> so that when reading sequentially, you had half a disk rotation to get your
> together to read the next sector. This turned out to be only a small
> performance win, and was a pita for interoperability, so was done only in
> the earliest versions. Since these were RX50 disks, I suspected its origins
> were in the PDP-11s and VAXen that the drives were also attached to.
I didn't know Rainbow did this, but it's familar from the PRO floppy controller. Those use a primitive controller (in fact, *all* PRO controllers are horribly primitive) where the CPU has to pull data from the device, with program I/O. So you'd likely have to use interleaving for decent performance. In any case, it does so. And the track start is offset by 3 sectors per track. And, last but not least, for some strange reason sector 0 is in physical track 1, while physical track 0 contains the highest 10 sectors.
Presumably later devices used the same layout for compatibility.
The PRO hard drive controller was also programmed I/O, but did't use interleave. And the Ethernet controller had a chip that did DMA (somewhat reliably) but only to on-card memory, so you either had to use that memory for network buffer space, or copy from the card to host memory.
More information about the cctalk