"Bounce buffer" copyright [was Re: flash (or ide) storage for unibus 11?]

[Warner Losh]

On Sat, Nov 28, 2015 at 7:19 PM, Jerome H. Fine <jhfinedp3k at compsys.to>
wrote:

> >Mouse wrote:
>
> Love that term, "bounce buffer" (I wrote a whole package to support
>>>> them in a packet switch I did) - I'm officially adopting it, right
>>>> now! :-)
>>>>
>>>> Hey - anything that anyone writes is automatically copyrighted.
>>>
>>> I realize you...may have been less than entirely serious.  But what you
>> wrote could easily be taken seriously, especially by someone only
>> partially inside our culture.  So I'm going to be a minor killjoy here.
>>
>> Yes, anything written now is automatically copyrighted in most
>> jursidctions.  But (a) the term "bounce buffer" is small enough and
>> obvious enough it probably cannot be copyrighted on its own (and is not
>> infringing when copied in isolation), (b) was quite possibly published
>> without copyright claim before automatic copyright and is thus in the
>> public domain now, and (c) is of uncertain authorship anyway.  So...
>>
>> So first you need permission to use that!
>>>
>>> ...you actually don't.
>>
>> Thank you for clarifying that aspect.  I just considered
> it so ridiculous that anyone would take the joke seriously
> that I did not even consider the alternative.
>
> For the case of the RX02  DYX.SYS device driver, the
> use of "bounce buffer" was the most descriptive phrase
> that I have ever seen.  During a READ request, the following
> operations take place:
>
> (a)   Set n = 0
> (a)  A request is issued to fill the hardware silo from the floppy media
> with sector a+n
> (b)  The hardware silo is transferred via DMA to the bounce buffer
> (c)  Set n = n+1
> (d)  The next request is made to fill the hardware silo again with sector
> a+n
> (e)  The bounce buffer is copied to the user's buffer one word at a time
>       Repeat (b), (c), (d) and (e) until finished
>
> Normally, during the interleave time, the device driver only needs to
> transfer
> the silo to the user's buffer.  When a bounce buffer is required, the
> device
> driver has the time while the hardware silo is being filled to perform the
> copy from the bounce buffer to the user's buffer.  So the transfer from the
> floppy media is actually bounced off the first data bounce buffer (in a
> location
> in physical memory which is supported by the hardware) to the final
> location
> in physical memory (where the user's buffer is located).   COOOOOOL!!


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

Warner