VOGONS


First post, by Zuofu

User metadata
Rank Newbie
Rank
Newbie

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 attachment 20260724_181646.jpg is no longer available

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!

Reply 1 of 6, by majestyk

User metadata
Rank Oldbie
Rank
Oldbie

I have one of these, too and it didn´t suffer the VARTA pest.
I can try to measure what chipset pin the T/R*-input of the 245 is connected to if you tell me which 245 it is...

Reply 2 of 6, by Zuofu

User metadata
Rank Newbie
Rank
Newbie
majestyk wrote on 2026-07-25, 05:45:

I have one of these, too and it didn´t suffer the VARTA pest.
I can try to measure what chipset pin the T/R*-input of the 245 is connected to if you tell me which 245 it is...

Thank you very much for the offer. Here is the photo of the board with the DIRection pin (pin 1) which appears to be 'stuck'. If you can figure out where it's supposed to go I would appreciate it greatly. Also, if you have an oscilloscope, can you verify that it is indeed supposed to be switching during POST (rather than just fixed to VCC, like it is on my board).

The attachment 20260725_121712.jpg is no longer available

Thank you again!

Reply 3 of 6, by rasz_pl

User metadata
Rank l33t
Rank
l33t
Zuofu wrote on 2026-07-24, 23:28:

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.

Driven by Bus Master at the moment of transaction.
When Low its used in conjunction with SA0 to indicate if transfer is 16bit or just upper 8bits on SD[15:8].
When High transfer is always 8bit. Pulled high by resistor by default.

Bus Master = chipset when CPU is doing reading/writing, DMA (two 8237 emulated inside chipset) when performing programmed ISA DMA transfers (floppy, sound card), something in ISA card when its a Bus Mastering device (example: Adaptec 154x scsi controller).

Zuofu wrote on 2026-07-24, 23:28:

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

yep

Zuofu wrote on 2026-07-24, 23:28:

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.

hmm, that would only be a problem when using DMA, and maybe only when using external bus master (something like Adapted ISA SCSI controller) as ISA DMA engine sits in the chipset so no need to flip directions.
We would need someone much smarted than me, like mkarcher, to confirm this 😀

Zuofu wrote on 2026-07-24, 23:28:

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?

Bus Master can both read and write data. The pin you are thinking of would be MEMCS16# <- this one is owned by the device (like video card) and used to tell Bus Masters if a 16bit transfer is possible at this address.

Zuofu wrote on 2026-07-25, 17:22:

can you verify that it is indeed supposed to be switching during POST (rather than just fixed to VCC, like it is on my board).

it isnt, it will only switch direction if you plug Bus Mastering card into ISA slot, and that card performs full Bus takeover dance involving:
1 driving DRQ
2 waiting for DACK from the chipset
3 driving MASTER#
Only after all this the card owns pin SBHE# and MEMR#, MEMW#, IOR#, IOW#, BALE, SA0, Ref (ram Refresh). Thats 8. Are you sure that Addr1 you found isnt a MEMR# pin?

TLDR this buffer doesnt seem to be your problem 🙁

https://github.com/raszpl/sigrok-disk FM/MFM/RLL decoder
https://github.com/raszpl/FIC-486-GAC-2-Cache-Module (AT&T Globalyst)
https://github.com/raszpl/386RC-16 ram board
https://github.com/raszpl/Zenith_ZBIOS Zenith Z-386 MFM-300 ZBIOS disassembly

Reply 4 of 6, by Zuofu

User metadata
Rank Newbie
Rank
Newbie
rasz_pl wrote on 2026-07-26, 02:09:

TLDR this buffer doesnt seem to be your problem 🙁

I think you might be right, the BIOS beeps with 8 beeps (indicating a video memory failure), but the actual POST card indicates state 36 -> state 40, when it hangs, which is usually the A20 control state. The battery damage is in the keyboard connector / RTC area, so let me check the A20 line as well.

Reply 5 of 6, by rasz_pl

User metadata
Rank l33t
Rank
l33t

that would mean you have corrosion going half way under sim slots? all the vias in that are will need plugging with wires.

https://github.com/raszpl/sigrok-disk FM/MFM/RLL decoder
https://github.com/raszpl/FIC-486-GAC-2-Cache-Module (AT&T Globalyst)
https://github.com/raszpl/386RC-16 ram board
https://github.com/raszpl/Zenith_ZBIOS Zenith Z-386 MFM-300 ZBIOS disassembly

Reply 6 of 6, by Zuofu

User metadata
Rank Newbie
Rank
Newbie
rasz_pl wrote on 2026-07-27, 01:57:

that would mean you have corrosion going half way under sim slots? all the vias in that are will need plugging with wires.

The corrosion doesn't look like it extends to under the SIMM sockets, but it does extend under the first ISA/VLB slot, so I will have to remove that as well as the keyboard connector to check fully. I suppose that is the next step.