ISA interfacing.

[prime]

Hi all,

Am I correct in assuming that only *ONE* of the the memory or I/O write strobes may be active at one time e.g. nMEMR, nMEMW, nIOR, nIOW ?

The reason I ask is because I have a RAM / Clock card (I have been developing on and off for a couple of years), this has an 74ALS245 buffer between the internal and external data lines.
The internal data lines have two AS6C4008 512Kx8 SRAM chips and a DS12887 RTC chip on them.
The logic for the chip enables and buffer enable/direction is controlled by an XC9572XL CPLD, this completely decodes the RAM and the RTC. The RTC I/O is only enabled if AEN is low.

So the buffer obviously need to be enabled when either the RAM or RTC is being accessed.

I'm having seemingly problems with switching the buffer direction, if I just use nMEMW everything works fine and the memory remains intact. If I switch on nIOW as well then it seems certain accesses to the clock will bork the RAM.

Cheers.

Phill.

 

[Eudimorphodon]

So, the short answer is I'm pretty sure that, yes, MEMW and IOW (and MEMR/IOR) should be mutually exclusive *unless* a DMA cycle is happening, in which case a cross-pair could be up? (MEMR + IOW, or vice-versa.)

In your design do you just have MEMW/MEMR connected directly to the RAM chips, or are you trying to synthesize those somehow with the logic on the CPLD depending on chip enable or decoding state? I've built several RAM boards for Tandy 1000s, which have RAM starting at 00000h (which I think would mean their chip enable would be enabled if I/O was being touched, since I *think* the 8088 drives the high address lines zero when you're doing an I/O cycle) and I've never observed a "clobbering" problem. Basically I'm wondering if you are driving the MEMW/IOW lines with the CPLD instead of directly from the bus (because you have them running to the CPLD anyway for the buffer logic) if there's an error somewhere that's causing MEMW to be driven when IOW is; IE, the problem isn't with the buffer, it's the driver line to the RAM chip.

 

[prime]

So, the short answer is I'm pretty sure that, yes, MEMW and IOW (and MEMR/IOR) should be mutually exclusive *unless* a DMA cycle is happening, in which case a cross-pair could be up? (MEMR + IOW, or vice-versa.)

That's good to know, I'd pretty much implied it and it seemed logical that only one would be active at once. In the case of DMA, AEN would be active and I gate my I/O with that being low anyway.

In your design do you just have MEMW/MEMR connected directly to the RAM chips, or are you trying to synthesize those somehow with the logic on the CPLD depending on chip enable or decoding state? I've built several RAM boards for Tandy 1000s, which have RAM starting at 00000h (which I think would mean their chip enable would be enabled if I/O was being touched, since I *think* the 8088 drives the high address lines zero when you're doing an I/O cycle) and I've never observed a "clobbering" problem. Basically I'm wondering if you are driving the MEMW/IOW lines with the CPLD instead of directly from the bus (because you have them running to the CPLD anyway for the buffer logic) if there's an error somewhere that's causing MEMW to be driven when IOW is; IE, the problem isn't with the buffer, it's the driver line to the RAM chip.

MEMW and MEMR are connected direct to the RAM chips, it's just chip select that is gated with address and selection jumpers.

I *THINK* I have figured out what my problem was, I had the DS12887A in Motorola mode and was wiggling DS/R/W according to the Intel spec. This was leaving DS high at the end of a write to the RTC, but then setting R/W high also. This caused the RTC to constantly output data, which of course clashed with the data output by the RAM and so the CPU get's corrupted data.

I've since adjusted the DS/R/W to properly use Motorola signaling and it all seems to be working now. I did try using Intel signaling for the RTC but could not get this to work at all, which is odd, because the other XT RTC designs I have seen use Intel signaling, and I assume work. Though they connect the RTC direct to the ISA databus rather than trough a buffer.

Cheers.

Phill.

 

[Eudimorphodon]

I *THINK* I have figured out what my problem was, I had the DS12887A in Motorola mode and was wiggling DS/R/W according to the Intel spec. This was leaving DS high at the end of a write to the RTC, but then setting R/W high also. This caused the RTC to constantly output data, which of course clashed with the data output by the RAM and so the CPU get's corrupted data.

Ah, interesting.

Yeah, I haven't built anything yet for something that uses Motorola's schemes, and I have to say they kind of give me a headache. (Did help someone with the GAL programming to fix a Mac memory card once, so I *sort* of get it, but...)

I've since adjusted the DS/R/W to properly use Motorola signaling and it all seems to be working now. I did try using Intel signaling for the RTC but could not get this to work at all, which is odd, because the other XT RTC designs I have seen use Intel signaling, and I assume work. Though they connect the RTC direct to the ISA databus rather than trough a buffer.

I ran into some mysterious issues when I put a 16552 Dual UART behind a buffer instead of directly on the bus with a prototype card I made a while back. (It was a card that combined a 16552 and an XT-CF port. You *should* have a '245 in front of a CF port because there's part of the drive detection standard that relies on a pull-up, and I figured it should be fine to drop the UART behind the same one.) Was weird, almost *everything* worked except for DOS Kermit. I have no idea what it did differently but it'd hard fail on that card while it works fine on earlier and later revisions of the same card where I just put the UART straight on the bus. Every other serial-utilizing program worked fine. I think it *must* have been some sort of signal delay/propagation issue but it made no sense.

(I could physically swap UART chips between boards and the problem followed the buffered board.)