It seems that ISA pins B8 (NO WAITSTATE*), D1 (MEM CS 16*), D2 (I/O CS 16*) are stuck at 5V. Somehow shortening ALE to ground (what the CF-to-IDE-adapter did) fixes the issue and those are free to work.

All those pins (and also D17 MASTER*, I didn't test it with scope) show 0.3V against GND and 0.5V against +5V when tested with multimeter. I don't know are those voltages what they should be but those pins stuck at +5V indicates that the bus controller inside HT18 is broken and the HT18 should be replaced.

Are there any more ideas or is this board demoted to be a super-turbo-XT since I'd need another motherboard to get another HT18?

0.3 is quite low value for silicon junction but it might be lowered by external pull down or other circuits. If you would manage to isolate the pin e.g. by lift up the pin or break a trace and measure still 0.3V it indicate probably a damaged pin. Try to look at ebay if you can find a replacement chipset but inc. shipping it may cost more that the MB...

arent those signals always pulled high? they are all active low

aitotat wrote on 2023-03-01, 10:01:

It seems that ISA pins B8 (NO WAITSTATE*), D1 (MEM CS 16*), D2 (I/O CS 16*) are stuck at 5V. Somehow shortening ALE to ground (what the CF-to-IDE-adapter did) fixes the issue and those are free to work.

MEM CS16 and IO CS16 are output from an ISA card to the chipset in response to being addressed, that is the card will lower one of these two (depending on the access type and its capability) to signal that it can do 16-bit transfers. So these signals being "stuck" at 5V is normal if there are no cards in the system or the cards are not 16-bit capable (or just not addressed).

ISA card needs to see ALE transition from H to L to know the address is stable and can be decoded - though as I've said some cards will attempt to decode everything to speed things up, and will also work with ALE being L all the time, though that might result in some random glitches now and then. With ALE being high all the time the ISA bus is not properly working, might kinda work in 8-bit mode but ALE H->L is needed to latch the upper bits of the address (these are not latched by the chipset and the card must do it on it's own, without this signal it can never know when the address is valid and stable).

You will need a scope to see ALE transitions but if it's stuck H, and driven from the chipset directly, then (other than some freak shorts to Vcc on the PCB itself) the chip is damaged I'm afraid...

Yes, those signals are always high. For example 16-bit VGA card cannot set MEM CS16 to low unless ALE is shorted. ALE itself does show signal so it works. My guess is that forcing ALE to low does change something inside HT18 that "fixes" the stuck signals allowing card to set them low.

aitotat wrote on 2023-03-01, 15:58:

Yes, those signals are always high. For example 16-bit VGA card cannot set MEM CS16 to low unless ALE is shorted. ALE itself does show signal so it works. My guess is that forcing ALE to low does change something inside HT18 that "fixes" the stuck signals allowing card to set them low.

The chipset should not be driving CS16 lines, these are inputs. I think your theory is incorrect. A multimeter is not enough to properly investigate the signals in question (it will most likely completly miss very short pulses for example).

If I were to guess, based on the fact that you see some mid-level voltages on ALE which would suggest it's toggling, is that the L level is not in spec. Not driving below 0.8V for example or the the driver is weak and the edges are not falling/rising fast enough. That would prevent cards from recognizing the ALE at the correct time (or at all). To be able to tell you need a scope of some sort - but I'm not going to argue this further. I can't be sure either at this point.

Still no fix and I'm more and more sure that the HT18 is the broken part. I've retested everything. There is something to report, however. I had one lucky power on with 16-bit VGA card. Meaning no error beeps but POST OK beep instead. I quickly went into BIOS and this is what I got:

It seems that character attribute bytes are written okay to video memory but characters are not. This is strange since character should be the lower byte and 8-bit ISA cards have worked so far. So if data lines are not working correctly, then high bytes (attribute bytes) would more likely have the errors. And since attributes are where they should be, then address lines are likely to be okay.

I've also tried with different power supply but it did not change anything.

aitotat wrote on 2023-03-08, 10:35:

So if data lines are not working correctly, then high bytes (attribute bytes) would more likely have the errors. And since attributes are where they should be, then address lines are likely to be okay.

That's assuming the data transfer is 16-bit. It could very well be 2 separate writes, 8-bit each, of the character and the attribute, that would only use the lower 8 bits of the bus. And even 16-bit transfer will be split into two 8-bit ones by the chipset if the card does not properly drive the CS16 signals. Or those are not interpreted correctly by chipset - in which case it might even be the chipset thinks it's doing 2x 8-bit transfers and the card is actually accepting 16-bits, twice, but one half is invalid.

So there's a lot of ways this can go wrong if the signals are not passed around properly. It's OK to make some assumptions but unless you can test and verify those assumptions eventually you will only be chasing ghosts. Again, you can't properly diagnose these things without a scope. You sure can try and guess, and experiment, and maybe figure it out at some point, but without a scope you'll need to formulate and somehow test a lot of assumptions... You might run out of patience way before that happens.