james@bigtex.cactus.org (James Van Artsdalen) (02/20/91)
In <8345@davidsys.com>, douglass@davidsys.com wrote: > In article <1991Feb12.010248.7563@cs.mcgill.ca>, phil@cs.mcgill.ca (Philip LOCONG) writes: | As earlier posts suggested it, the ISA bus specifications force the bus | to run each 128k section of RAM entirely in 8-bit mode or entirely in | 16-bit mode, that means the A-B section has to be either 8 or 16-bit. This is exactly correct. > Excuse me, but you're *WRONG*. > I've already run a test that indicates otherwise. Design considerations are not done by running one test and declaring victory. There are things called "specifications". From the IBM AT Technical Reference Manual description of MEMCS16 (page 1-27 in mine): '-MEM 16 Chip Select' signals the system board if the present data transfer is a 1 wait-state, 16-bit, memory cycle. It must be derived from the decode of LA17 through LA23. Description of the SA address lines (page 1-22): SA0 through SA19 are gated onto the system bus when 'BALE' is high and are latched on the falling edge of 'BALE'. Description of the LA address lines (also page 1-22): These signals are valid when 'BALE' is high. LA17 through LA23 are not latched during microprocessor cycles and therefore do not stay valid for the whole cycle. Their purpose is to generate memory decodes for 1 wait-state memory cycles. These decodes should be latched by I/O adapters on the falling edge of 'BALE'. > To put it simply, if the card responds quickly enough, there is NO > PROBLEM. No. Notice above that MEMCS16 must be valid on the falling edge of BALE. But the SA addresses aren't valid until the falling edge of BALE. Therefore, "quick enough" could mean zero time, and you can't guarantee that. Often, the addresses will be valid before BALE falls. But sometimes they might not be (and in fact sometimes aren't in IBM designs), so you have to live by the rules if you want to be reliable. -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" Dell Computer Co 9505 Arboretum Blvd Austin TX 78759 512-338-8789
ejy@cbnewsi.att.com (eugene.yurek) (02/21/91)
From article <54860@bigtex.cactus.org>, by james@bigtex.cactus.org (James Van Artsdalen): > In <8345@davidsys.com>, douglass@davidsys.com wrote: > >> In article <1991Feb12.010248.7563@cs.mcgill.ca>, phil@cs.mcgill.ca > (Philip LOCONG) writes: > > | As earlier posts suggested it, the ISA bus specifications force the bus > | to run each 128k section of RAM entirely in 8-bit mode or entirely in > | 16-bit mode, that means the A-B section has to be either 8 or 16-bit. > > This is exactly correct. I side with James. Having designed several PC cards in the past, I can attest to the fact that everything he has said is correct. There really is a 128k block problem for ISA bus memory accesses above the 1MB address. This has been a source of endless problems for an uncounted number of people. Think about this scenario: There are two cards in a system, both of which reside in the same 128kbyte block of ISA bus memory addressing, and one is a 16 bit card where the other is an 8 bit card. Since you can only use the LA[23:17] address lines to activate MEMCS16, every access to this block becomes a 16 bit one. If a user program or the ROM BIOS tries to access the 8 bit card, a 16 bit memory cycle will be initiated. This won't have much effect on even address accesses since this is the low byte on the bus anyway. ALL odd address byte access cycles will fail miserably because, thinking its doing a 16 bit access, the processor (or AT chipset) will put the odd address databyte on the high 8 bits of the data bus (D[15:8]). The 8 bit card doesn't (and can't) look at these upper data bus lines, and junk gets read from the 8 bit card. On writes, the data falls off the end of the earth. I needn't say what kind of wierd problems this causes. If you move the base address of a card, and your problems go away, you've most probably been bitten by the 128k block problem. -- Eugene J. Yurek Internet: ejy@honasa.att.com AT&T Bell Laboratories UUCP: ...!att!honasa!ejy Holmdel, NJ Voice: (201) 949-3753