oolidjr@hubcap.UUCP (Joe Moll) (11/16/88)
What is the deal with the usuable I/O address range on the IBM PC bus??
I read in a manual that the addresses above 0x0400 were unusable? Is
this true?? I don't see how this could be, since all the address lines
and control signals off the 8088 are available on the bus.
Could someone shed some light on this please??? I was about to wire
a project into I/O address 0x0400 and it needs to be done soon.
Thanx Much ...
Joe
/=----------+^ jlmoll@clemson.bitnet
Joe Moll --------=\ Internet | oolidjr@hubcap.clemson.edu
Clemson University \ UUCP | {pick a hub}!hubcap!oolidjr
Clemson, SC \ |\=--------+--------/`seeger@beach.cis.ufl.edu (F. L. Charles Seeger III) (11/16/88)
In article <3552@hubcap.UUCP> oolidjr@hubcap.UUCP (Joe Moll) writes: |What is the deal with the usuable I/O address range on the IBM PC bus?? | |I read in a manual that the addresses above 0x0400 were unusable? Is |this true?? I don't see how this could be, since all the address lines |and control signals off the 8088 are available on the bus. | |Could someone shed some light on this please??? I was about to wire |a project into I/O address 0x0400 and it needs to be done soon. | |Thanx Much ... |Joe Only the first ten bits of the address are decoded on the motherboard. Hence, any addresses that the motherboard responds to will be shadowed into the upper regions of the address range. You can make use of higher addresses on IO cards, but you must be certain that the lower ten bits of the addresses do not conflict with any devices on the motherboard. Choose whatever address range is appropriate in the ten bit range, then make sure that all your addresses, both above and below 0400, are within that range for the lower ten bits. The conventions of IO addresses are published, and you should consult them. They're not within a few feet of my keyboard, but I can provide references or the info, if needed. I suggest using PALs for address decoding, if possible, because they're so easy to change. Be aware that some IO cards may not decode all address bits, either. Good luck, Chuck
phil@diablo.amd.com (Phil Ngai) (11/16/88)
In article <3552@hubcap.UUCP> oolidjr@hubcap.UUCP (Joe Moll) writes: |I read in a manual that the addresses above 0x0400 were unusable? Is |this true?? I don't see how this could be, since all the address lines |and control signals off the 8088 are available on the bus. This is not true. What is true is that the motherboard and most plug-ins only decode (the low) 10 address bits. So if you use address 4f0, it will collide with the motherboard's 0f0. This seems to be very inconvenient but there is a nice trick to get lots of IO address space. Every byte that you pick is equivalent to 64 bytes. If you pick byte 200, you can also use 600, A00, etc. No other hardware can possibly be broken by this since it is the same as if you only decoded the low 10 address bits. You know all the address bits are there as 20 or more bits are needed for memory addressing. In theory this method should work. In practice, this is the method Lotus, Intel, and Microsoft use for expanded (not extended) memory, so you know it has to work. I strongly recommend you grab the least number of bytes possible out of the range 0-3ff. It's a very limited resource that has to be shared with all the plug-ins in the world. -- Phil Ngai, phil@diablo.amd.com {uunet,decwrl,ucbvax}!amdcad!phil
mguyott@mirror.TMC.COM (Marc Guyott) (11/17/88)
In article <3552@hubcap.UUCP> oolidjr@hubcap.UUCP (Joe Moll) writes: > >Could someone shed some light on this please??? I was about to wire >a project into I/O address 0x0400 and it needs to be done soon. > I believe that the reason I/O addresses only go up to 0x03FF is because I/O port addressing only uses the least significant 10 bits of the specified address. This is the way the hardware works, no other reason. I also thought you might find the following listing of interest: The following is from "The Peter Norton Programmer's Guide to the IBM PC": Figure 2-9. The ports and port addresses used in the PCjr, the PC/XT, and the AT computers. Description Range PCjr PC/XT AT DMA Controller (8237) n/a 000-00F 000-01F Interrupt controller (8259) 020-027 020-021 020-03F Timer (8253;8254.2 in AT) 040-047 040-043 040-05F PPI (8255) 060-067 060-063 n/a Keyboard (8042) n/a n/a 060-06F DMA page register (74LS612) n/a 080-083 080-09F NMI mask register 0A0-0A7 0A 070-07F Interrupt controller 2 (8259) n/a n/a 0A0-0BF Sound generator (SN76496N) 0C0-0C7 n/a n/a DMA controller 2 (8237) n/a n/a 0C0-0DF Clear/reset math coprocessor n/a n/a 0F0-0F1 Math coprocessor n/a n/a 0F8-0FF Joystick (game controller) 200-207 200-20F 200-207 Expansion unit n/a 210-217 n/a Parallel printer (secondary) n/a n/a 278-27F Serial port (primary) 2F8-2FF 3F8-3FF 3F8-3FF Serial port (secondary) n/a 2F8-2FF 2F8-2FF Prototype card n/a 300-31F 300-31F Fixed disk n/a 320-32F 1F0-1F8 Parallel printer (primary) n/a 378-37F 378-37F SDLC (secondary BISYNC in AT only) n/a 380-38F 380-38F BISYNC (primary) n/a n/a 3A0-3AF Monochrome adapter/printer n/a 3B0-3BF 3B0-3BF Color/graphics adapter n/a 3D0-3DF 3D0-3DF Diskette controller 0F0-0FF 3F0-3F7 3F0-3F7 ---- "All my life I always wanted to BE somebody. I see now I should have been more specific." Jane Wagner (but I agree 8-) Marc Guyott mguyott@mirror.TMC.COM {mit-eddie, pyramid, harvard!wjh12, xait, datacube}!mirror!mguyott Mirror Systems Cambridge, MA 02140 617/661-0777
jmbj@whuts.ATT.COM (BITTMAN) (11/17/88)
> |I read in a manual that the addresses above 0x0400 were unusable? Base I/O addresses above this range cannot be used without claiming the address equal to the lower 10 bits. > This is not true. What is true is that the motherboard and most > plug-ins only decode (the low) 10 address bits. So if you use address > 4f0, it will collide with the motherboard's 0f0. > Every byte that you pick is equivalent to 64 bytes. If you pick byte ^^^^ ^^^^^^^^ > 200, you can also use 600, A00, etc. No other hardware can possibly be > broken by this since it is the same as if you only decoded the low 10 > address bits. You know all the address bits are there as 20 or more > bits are needed for memory addressing. In theory this method should work. Assuming a "byte" here is an I/O address, there are at least 1024 addresses available for each I/O address claimed, the 8-bit PC XT bus has 10 "extra" address lines (1024) and the AT has 14 "extra" for a total of (16384). Just use the lower 10 address bits like high-order bits on any other system, to select your board. Then use the upper bits as decodes or direct ram addressing, etc. > I strongly recommend you grab the least number of bytes possible out > of the range 0-3ff. It's a very limited resource that has to be shared > with all the plug-ins in the world. Agreed.
Ralf.Brown@B.GP.CS.CMU.EDU (11/18/88)
In article <5065@whuts.ATT.COM>, jmbj@whuts.ATT.COM (BITTMAN) writes: }Assuming a "byte" here is an I/O address, there are at least 1024 }addresses available for each I/O address claimed, the 8-bit PC XT bus has }10 "extra" address lines (1024) and the AT has 14 "extra" for a I/O addresses only have 16 bits, on both PC and AT, thus there are 64 I/O addresses for each value of the lower ten bits. -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=-=-=- Voice: (412) 268-3053 (school) ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/31 Disclaimer? I |Ducharm's Axiom: If you view your problem closely enough claimed something?| you will recognize yourself as part of the problem.
corbin@pinocchio.Encore.COM (Steve Corbin) (11/19/88)
In article <5065@whuts.ATT.COM> jmbj@whuts.ATT.COM (BITTMAN) writes: >> |I read in a manual that the addresses above 0x0400 were unusable? > >Base I/O addresses above this range cannot be used without claiming >the address equal to the lower 10 bits. > >> This is not true. What is true is that the motherboard and most >> plug-ins only decode (the low) 10 address bits. So if you use address >> 4f0, it will collide with the motherboard's 0f0. > >> Every byte that you pick is equivalent to 64 bytes. If you pick byte > ^^^^ ^^^^^^^^ >> 200, you can also use 600, A00, etc. No other hardware can possibly be >> broken by this since it is the same as if you only decoded the low 10 >> address bits. You know all the address bits are there as 20 or more >> bits are needed for memory addressing. In theory this method should work. > >Assuming a "byte" here is an I/O address, there are at least 1024 >addresses available for each I/O address claimed, the 8-bit PC XT bus has >10 "extra" address lines (1024) and the AT has 14 "extra" for a >total of (16384). Just use the lower 10 address bits like high-order >bits on any other system, to select your board. Then use the upper >bits as decodes or direct ram addressing, etc. The original poster was correct. 64 bytes are available at each I/O address if you decode the extra address lines. There 20 address lines for memory on the 8088/8086 but only 16 lines are used for I/O. Stephen Corbin UUCP: {bu-cs,decvax,necntc,talcott}!encore!corbin Internet: corbin@multimax.ARPA
phil@diablo.amd.com (Phil Ngai) (11/19/88)
In article <5065@whuts.ATT.COM> jmbj@whuts.ATT.COM (BITTMAN) writes: |> Every byte that you pick is equivalent to 64 bytes. If you pick byte | ^^^^ ^^^^^^^^ |> 200, you can also use 600, A00, etc. No other hardware can possibly be | |Assuming a "byte" here is an I/O address, there are at least 1024 |addresses available for each I/O address claimed, the 8-bit PC XT bus has |10 "extra" address lines (1024) and the AT has 14 "extra" for a You seem to have forgotten that IO addresses are either 8 or 16 bits, but not 20 or 24. My number of 64 is correct, your 1024 is wrong. -- Phil Ngai, phil@diablo.amd.com {uunet,decwrl,ucbvax}!amdcad!phil
ward@cfa.harvard.EDU (Steve Ward) (11/20/88)
In article <4229@encore.UUCP>, corbin@pinocchio.Encore.COM (Steve Corbin) writes: > ...there are 64 bytes at each I/O > address if you decode the extra address lines. There 20 address lines > for memory on the 8088/8086 but only 16 lines are used for I/O. > > Just to prevent misunderstanding, there are 64 images, or "copies" of each of the 1024 I/O byte-addressable registers, or I/O byte locations. This means any I/O addressing done to any of these 64 "imaged, copied, ghosted, etc" address locations will result in an access to the same I/O byte location. There are only 1024 I/O byte locations available due to the partial (10-bits out of the possible 16-bit I/O address space) I/O address decoding inflicted on us by IBM. This 1024 byte I/O address space repeats itself 64 times within the 64K I/O address space. Said another way, there are 64 distinct I/O addresses you can use to access exactly the same I/O byte. As has been pointed out, for purposes of I/O instructions on Intel 8088/86/286 micros (probably 386, too) only 16 address lines are used. The memory address space is larger, being 20 address lines for the XT/AT's. I believe that Mr. Corbin is saying what I just said, but the spate of several postings needed at least one more followup :-) Steve W. ward@cfa.harvard.edu
ralf@b.gp.cs.cmu.edu (Ralf Brown) (11/20/88)
In article <1275@cfa.cfa.harvard.EDU> ward@cfa.harvard.EDU (Steve Ward) writes: }In article <4229@encore.UUCP>, corbin@pinocchio.Encore.COM (Steve Corbin) writes: }> ...there are 64 bytes at each I/O }> address if you decode the extra address lines. There 20 address lines }> for memory on the 8088/8086 but only 16 lines are used for I/O. }> } Just to prevent misunderstanding, there are 64 images, or "copies" } of each of the 1024 I/O byte-addressable registers, or I/O byte } locations. This means any I/O addressing done to any of these } 64 "imaged, copied, ghosted, etc" address locations will result } in an access to the same I/O byte location. There are 64 copies of each I/O address used by the motherboard. All 16 I/O address lines are available on the bus, and a board can choose to decode all 16 if it so desires (though many, if not most, don't). -- {harvard,uunet,ucbvax}!b.gp.cs.cmu.edu!ralf -=-=- AT&T: (412)268-3053 (school) ARPA: RALF@B.GP.CS.CMU.EDU |"Tolerance means excusing the mistakes others make. FIDO: Ralf Brown at 129/31 | Tact means not noticing them." --Arthur Schnitzler BITnet: RALF%B.GP.CS.CMU.EDU@CMUCCVMA -=-=- DISCLAIMER? I claimed something? --
ward@cfa.harvard.EDU (Steve Ward) (11/21/88)
In article <3626@pt.cs.cmu.edu>, ralf@b.gp.cs.cmu.edu (Ralf Brown) writes: > In article <1275@cfa.cfa.harvard.EDU> ward@cfa.harvard.EDU (Steve Ward) writes: > }In article <4229@encore.UUCP>, corbin@pinocchio.Encore.COM (Steve Corbin) writes: > }> ...there are 64 bytes at each I/O > }> address if you decode the extra address lines. There 20 address lines > }> for memory on the 8088/8086 but only 16 lines are used for I/O. > }> > } Just to prevent misunderstanding, there are 64 images, or "copies" > } of each of the 1024 I/O byte-addressable registers, or I/O byte > } locations. This means any I/O addressing done to any of these > } 64 "imaged, copied, ghosted, etc" address locations will result > } in an access to the same I/O byte location. > > There are 64 copies of each I/O address used by the motherboard. All 16 > I/O address lines are available on the bus, and a board can choose to decode > all 16 if it so desires (though many, if not most, don't) I think I said that?!!! Again, since somebody might get confused, sure, you can decode all 16 address lines for I/O, but because of the partial address decoding on the motherboard and on plug-in cards, you better 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 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 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 on dip switches so you can switch to somewhere in the first 1k :-) Given the dozens of boards out there, all using 10-bit decoding, it doesn't promise much return for decoding all 16 address lines for I/O, though I have described a desperation method for garnering I/O addresses. ward@cfa.harvard.edu .
bkliewer@iuvax.cs.indiana.edu (Bradley Dyck Kliewer) (11/22/88)
Select a 10 bit address and then use 16 bit addresses created from that base
giving you lots of ports off one IBM-style port.
Perhaps it worth mentioning that the Micro Channel decodes the full 16 bit
address, and the EISA specification will probably do the same.
Bradley Dyck Kliewer Hacking...
bkliewer@iuvax.cs.indiana.edu It's not just an adventure
It's my job!phil@diablo.amd.com (Phil Ngai) (11/22/88)
In article <1275@cfa.cfa.harvard.EDU> ward@cfa.harvard.EDU (Steve Ward) writes: | Just to prevent misunderstanding, there are 64 images, or "copies" | of each of the 1024 I/O byte-addressable registers, or I/O byte | locations. This means any I/O addressing done to any of these | 64 "imaged, copied, ghosted, etc" address locations will result | in an access to the same I/O byte location. This is true of the motherboard and many plug-in cards you can buy. You are not bound by this restriction if you design your own hardware. Also, LIM EMS memory boards are a notable exception to this rule as well. -- Phil Ngai, phil@diablo.amd.com {uunet,decwrl,ucbvax}!amdcad!phil
phil@diablo.amd.com (Phil Ngai) (11/22/88)
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
phil@diablo.amd.com (Phil Ngai) (11/22/88)
In article <15225@iuvax.cs.indiana.edu> bkliewer@iuvax.UUCP (Bradley Dyck Kliewer) writes: |Select a 10 bit address and then use 16 bit addresses created from that base |giving you lots of ports off one IBM-style port. That's correct. 64 addresses, to be exact. |Perhaps it worth mentioning that the Micro Channel decodes the full 16 bit |address, and the EISA specification will probably do the same. This is totally irrelevant. You're not going to plug your XT bus board into a micro channel. As for EISA, since it must work with old boards (or what's the point) and old boards claim all 10-bit aliases, there is nothing wrong with the LIM technique, even in a post-EISA world. -- Phil Ngai, phil@diablo.amd.com {uunet,decwrl,ucbvax}!amdcad!phil
ward@cfa.harvard.EDU (Steve Ward) (11/22/88)
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 "
ward@cfa.harvard.EDU (Steve Ward) (11/22/88)
Aha! I finally understand what Phil has been saying. Correct me if I am wrong, but what you are saying is that using 16-bit I/O address decoding, garner a set of (up to 64) I/O bytes by using I/O bytes spaced 1024 (1K) byte addresses apart. By mapping the lowest address into the bottom 1K address space, you guarantee that the upper (normally 10-bit decoding "ghosted" addresses) addresses on 1K increments are available for 16-bit decoding. Why didn't you just say that? :-) :-) (now that I have the cotton out my ears, I can hear just fine! :-) ) This will work just fine. I guess I just had my mind set on a block of contiguous addresses. However, the real problem remains: lots of 10-bit decoded boards really crowding the bottom 1K I/O space (and hence crowding the whole 64K). However, your suggested method stretches the I/O ports as far as they can go, under the circumstances. ward@harvard.edu
phil@diablo.amd.com (Phil Ngai) (11/23/88)
In article <1278@cfa.cfa.harvard.EDU> ward@cfa.harvard.EDU (Steve Ward) writes: |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 Oh, that's what you're talking about! The concept of using a forever fixed address is so repugnant to me that it never occurred to me that anyone might think of using it. I assumed that you would allow the byte in the range 0-400 to be selectable. |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 I mean you have to pick a byte on the range 0-400 and make sure it does not clash with anyone else in the system. Then you can claim that byte and all its aliases for your own use. |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 :-) From what I have seen, there's plenty of IO addresses compared to the amount of free space within the 1 MB range. -- Phil Ngai, phil@diablo.amd.com {uunet,decwrl,ucbvax}!amdcad!phil
cdold@starfish.Convergent.COM (Clarence Dold) (11/23/88)
From article <23617@amdcad.AMD.COM>, by phil@diablo.amd.com (Phil Ngai): > In article <1278@cfa.cfa.harvard.EDU> ward@cfa.harvard.EDU (Steve Ward) writes: > |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 Of course, what someone might do, in the case of an 80386 machine rated for ~30 UNIX users, is to have intelligent serial cards, five of them, perhaps, that all address to the same '10 bit' address, but are unique amongst themselves with respect to the remaining addresses. -- Clarence A Dold - cdold@starfish.Convergent.COM (408) 434-2083 ...pyramid!ctnews!professo!dold MailStop 18-011 P.O.Box 6685, San Jose, CA 95150-6685
matthew@sunpix.UUCP ( Sun NCAA) (11/24/88)
You've got to think of it this way. Use the address bits A0 thru A9 to
select where in the 1K of IBM PC/XT/AT I/O space where you want your
board to be mapped to. Then use the address bits A10 thru A15 to decode
to one of 64 "ghosted" addresses.
A15 A14 A13 A12 A11 A10 A9 A8 A7 A6 A5 A4 A3 A2 A1 A0
\__________ ___________/ \_____________ ______________/
\/ \/
Used to decode 64 Used to assign PC/XT/AT
"ghosted" addresses compatible address.
(could be switch selectable)
--
Matthew Lee Stier (919) 469-8300|
Sun Microsystems --- RTP, NC 27560| "Wisconsin Escapee"
uucp: {sun, rti}!sunpix!matthew |