"Bounce buffer" copyright [was Re: flash (or ide) storage for unibus 11?]
imp at bsdimp.com
Sun Nov 29 12:13:19 CST 2015
On Sat, Nov 28, 2015 at 7:19 PM, Jerome H. Fine <jhfinedp3k at compsys.to>
> >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
> (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
> the silo to the user's buffer. When a bounce buffer is required, the
> 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
> in physical memory which is supported by the hardware) to the final
> 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
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.
More information about the cctalk