From owner-freebsd-commit  Fri Dec 15 16:31:42 1995
Return-Path: owner-commit
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id QAA00300
          for freebsd-commit-outgoing; Fri, 15 Dec 1995 16:31:42 -0800 (PST)
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id QAA00263
          for cvs-all-outgoing; Fri, 15 Dec 1995 16:30:12 -0800 (PST)
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id QAA00253
          for cvs-sys-outgoing; Fri, 15 Dec 1995 16:30:09 -0800 (PST)
Received: from Root.COM (implode.Root.COM [198.145.90.17])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA00248
          Fri, 15 Dec 1995 16:30:05 -0800 (PST)
Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id QAA01981; Fri, 15 Dec 1995 16:30:04 -0800
Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id QAA02036; Fri, 15 Dec 1995 16:30:14 -0800
Message-Id: <199512160030.QAA02036@corbin.Root.COM>
To: Bruce Evans <bde@zeta.org.au>
cc: CVS-committers@freefall.freebsd.org, cvs-sys@freefall.freebsd.org
Subject: Re: cvs commit: src/sys/i386/isa if_ed.c 
In-reply-to: Your message of "Sat, 16 Dec 95 10:43:56 +1100."
             <199512152343.KAA04105@godzilla.zeta.org.au> 
From: David Greenman <davidg@Root.COM>
Reply-To: davidg@Root.COM
Date: Fri, 15 Dec 1995 16:30:14 -0800
Sender: owner-commit@FreeBSD.ORG
Precedence: bulk

>>>In this case, I think the casts only work because the hardware ignores
>>>some bits in the address (bits 14-15 of 0-31 for 16K cards and bits
>>>13-15 for 8K cards?).  Conversions of the form
>>>
>>>	(int)(buf - base)
>>>	((int)buf) & 0x3fff
>>>
>>>would be more obviously correct, but might be slower.
>
>>   That's not quite correct. The offset within the NIC memory segment is a 16
>>bit number but is written out a byte at a time. The fact that only the lower
>>two bytes are written out *implies* a masking of the upper bits. This is both
>>intended and correct. I chose to fix the problem the way I did to avoid
>
>Yes, the top 16 bits are masked by not writing out the bytes for them.
>Bits 14-15 aren't masked.  Consider a board with 16K of memory address
>0xd4000.  Then address 0xd4000 corresponds to offset 0 but offset 0x4000
>is written out.  This apparently works because bits 14-15 are ignored by
>the h/w.  It wouldn't work for a board with 32K of memory at address
>0xd4000 but this is unlikely to be supported since it would take a gate
>or two more to decode.  It wouldn't work if the board used bits 14-15
>for something else.  To determine the correctnes of the cast, you have
>to look at the manuals for all supported boards (a growing list :-) and
>and see if those bits are specified as "don't care".

   No, you apparantly don't understand what's happening in there. In the PIO
case, the "base" is 0 and the offset is just an offset relative to zero. The
upper bits will never be non-zero.

-DG