On Sat, Nov 28, 2015 at 7:19 PM, Jerome H. Fine <jhfined...@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
