Path: utzoo!attcan!uunet!husc6!cfa!ward
From: ward@cfa.harvard.EDU (Steve Ward)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Usable I/O Address range on the PC bus ...
Keywords: Limited to addresses up to 0x0400 only??
Message-ID: <1278@cfa.cfa.harvard.EDU>
Date: 22 Nov 88 15:09:48 GMT
References: <5065@whuts.ATT.COM> <4229@encore.UUCP> <1275@cfa.cfa.harvard.EDU> <23608@amdcad.AMD.COM>
Organization: Harvard-Smithsonian Ctr. for Astrophysics
Lines: 79

In article <23608@amdcad.AMD.COM>, phil@diablo.amd.com (Phil Ngai) writes:
> In article <1276@cfa.cfa.harvard.EDU> ward@cfa.harvard.EDU (Steve Ward) writes:
> |decode them carefully!  It buys you nothing to decode the extra lines
> |since the I/O addresses above 0x400 are not available except to the
> |extent that there is a "hole" in the first 1k addresses.  Sure, for
> 
> Steve, I think you have a very dangerous thing, i.e., a partial
> understanding of the situation. My suggested method is not a
> desperation technique, does not have any problems, and is also
> approved by Lotus, Intel, and Microsoft as embodied in EMS. 
> 
> |the very hard up, you can leave a hole in the first 1k (never ever use
> |10-bit decoding in the hole, 16-bit decoding is ok) and then you can
> 
> This is a meaningless statement.

    No, it isn't, except that you have broken two sentences away from
    from the paragraph which explains what I mean, taken together.  See
    next three sentences below.
> 
> |use 16-bit decoding in the 64 different (1k apart) slots within the
> |64kb I/O space.  The disadvantage is potential I/O address clashing
> |due to the non (IBM) standard decoding.  Of course, you always put
> 
> No, there is no potential for clashing. Using 16-bit decoding is no
> different from 10-bit decoding in terms of clashes. I think your
> problem is that you think of 16-bit decoding as using something above
> 1K. The way that 16-bit decoding really works is that you pick a byte
> WITHIN 1K. Then you distinguish all the addresses that would be
> considered aliases of that address with 10-bit decoding. For example,
> you distinguish between 240 and 640 and respond to both. But no one
> else cares because when you use 10-bit decoding, you also claim both
> 240 and 640 and respond to both. 
> 

  Well, now you are talking!  You have said exactly what I said.  No,
  I don't have a "dangerous misunderstanding", I know exactly what's
  up.  When I said you have to leave a "hole" in the first 1k where
  no 10-bit address decoding (hole is one or more adjacent I/O
addresses) will be allowed, it was because all 10-bit decoding repeats
up through the entire 16-bit (64K) I/O address space.  Clearly, if
any I/O addresses in the first 1K range are either left unused or
used with 16-bit decoding only, all the other 63 spots in the rest
of the 16-bit I/O address space that would have otherwise been
overlapped with 10-bit "ghosted" addresses, can be safely used for
16-bit address decoding.  This is what I originally said, what you
said, etc.

Where we disasgree is in the meaningfulness, hazards, etc. of 16-bit
decoding.  I say, if you do 16-bit decoding, you make it selectable
to be able to choose several different address locations, and preferably
many alternate locations.  My reason for this is because all it takes
is one 10-bit address I/O card "below" (in a spot that "ghosts" up
into your pristine 16-bit address) to ruin your day.  99% of I/O
cards out there only use 10-bit I/O addressing, making this a very
likely event.  I agree that using 16-bit address decoding is the
proper method, but the reality is quite different.  Therefore, I
advise a "mobile" 16-bit address decoding if you want some assurance
you can buy most any I/O card and be confident they will not have
address clashes.

There is one point in your statement that I am a little unclear about.
You seem to be saying "use 16-bit address decoding, but the decoded
address(es) should be in the first 1K byte range of the 64K I/O
address space."  If this is a correct understanding, what's the
point of using 16-bit address decoding if the intent is to always
decode into the first 1K, ie, you seem to be limiting yourself
by definition to 1K addresses, so why use more than 10 address
lines?  It seems to me that the whole point of using 16-bit address
decoding is to try to utilize some of the entire 64K I/O space,
and I have pointed out this is possible, though perilous, in my
opinion.

Of course, the REAL solution is to say the heck with I/O address
space decoding entirely, and memory map everything somewhere in
the upper area of the 1MB memory address space  :-)

Steve W.   ward@cfa.harvard.edu
"