Path: utzoo!attcan!uunet!husc6!mailrus!ames!amdahl!amdcad!diablo!phil From: phil@diablo.amd.com (Phil Ngai) 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: <23608@amdcad.AMD.COM> Date: 22 Nov 88 01:04:53 GMT References: <5065@whuts.ATT.COM> <4229@encore.UUCP> <1275@cfa.cfa.harvard.EDU> <3626@pt.cs.cmu.edu> <1276@cfa.cfa.harvard.EDU> Sender: news@amdcad.AMD.COM Reply-To: phil@diablo.AMD.COM (Phil Ngai) Organization: Advanced Micro Devices, Inc. Sunnyvale CA Lines: 34 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. |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. -- Phil Ngai, phil@diablo.amd.com {uunet,decwrl,ucbvax}!amdcad!phil