Hi Folks,

I'm trying to repair a battery bombed PAT45PVS (https://theretroweb.com/motherboards/s/tmc-my … at45pvs-ver.2.0). I've rebuilt some traces to the point that the motherboard is kind of posting, it gets to AMI BIOS step code 40 and gives me 8 short beeps (video memory error). On probing the ISA bus (I'm testing mostly with ISA bus video cards), I noticed that there appears to be a bus conflict on the SBHE signal. If I unplug the ISA video card, this signal is being driven properly, but if I plug in a video card, the waveform becomes noisy and clipped, indicating a bus conflict. Also, some of the PALs on my video card get hot (and I sadly burned out an ET4000 card this way). However, my POST card seems to work fine, so whatever ISA bus signals are incorrect, they are not required for the POST card (it's at least able to write data to port x80).

My understanding is that SBHE is a 3 state signal and is supposed to be driven by whatever device is sending the data to indicate that the transfer is 16-bits. I noticed that on the motherboard ISA slot, SBHE is driven by a 74245 along with some other pins on the ISA slot as shown below (excuse my bad handwriting). Basically, many of the IO control signals e.g. IOW#, IOR#, as well as ADDR0/1 and some others.

The ENable signal for the 74245 seems to be hard wired to 0 (so always enabled). However, the DIRection pin does not toggle when the board is running, it just shows a constant VCC (so it seems to be pulled up through a resistor). I'm guessing this is a signal which is supposed to be driven by the chipset but the trace is one of the corroded ones. My question is this: the OPTI 82C571/2 chipset is poorly documented, and there's no datasheet which shows the pins. If I cannot find which signal is supposed to be driving the DIR pin, is there another pin I might be able to use? Also, I don't understand why SBHE (which is supposed to be driven by the device sending data) is driven by the same 74245 for e.g. ADDR1, which is supposed to be always driven by the bus master. Shouldn't those 2 pins share different bidirectional drivers, since they may be driven by different devices? Can someone explain to me why this is the connection on the board?

Thanks!