> From: Anders Magnusson <ragge@ludd.luth.se>
> Subject: Re: asc_vsbus.c: the 64K DMA problem
> To: mouse@Rodents.Montreal.QC.CA (der Mouse)
> Date: Wed, 11 Sep 2002 12:05:56 +0200 (MET DST)
> Cc: port-vax@netbsd.org
> 
> > > By some reasom MAXPHYS has been 63k on VAX since day one (I think it
> > > comes from b_bcount being a short, but I really don't know).
> > 
> > Fuzzy memory, which I think came from reading 4.3 kernel code, says
> > that it comes from 16-bit transfer counts for unibus devices (which
> > impose a limit of 64k, or 64k-1, depending on what the device does when
> > given a transfer count of zero) cropped back a little bit to catch
> > small negative values.  Perhaps someone with 4.3 source online can
> > check this?  IIRC it was commented near the relevant #define, or the
> > code for minphys(), or some suchlike related place.
> > 
> Yeah, I thought of something like that also, but I haven't been able
> to find any device with that problem. The minphys()/MAXPHYS definitions
> don't have any comments.
> 
> Another reason I can think of is that the map registers were handled in
> a resource map, that couldn't use map 0. With 1k pages that would be
> 63k MAXPHYS. But that really do not match how things were implemented.

A quick cruise through old handbooks finds that the only Unibus device
with a 16-bit Byte Count register was the TM11 magtape controller.
Disk and DECtape and newer magtape controllers had Word Count registers,
until they got to the idea of using in-memory command packets.

I have some really ancient TM11 documentation at home, I will try to
see if there is any discussion of what happens if the TM11 is given a
byte count of 0.

    carl
-- 
    carl lowenstein         marine physical lab     u.c. san diego
                                                 clowenst@ucsd.edu