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