Deunan wrote on Yesterday, 12:06:

That being said, the left SHIFT must be pressed and held all the time until DOS prompt appears. I don't think it worked properly since on the screen I still see That D instead of \, so MODE and/or DISPLAY.SYS still got loaded.

The display is from an MDA/Hercules card, which does not have software-programmable fonts. The strange D instead of the backslash is part of the character ROM on that card, which obviously does not contain CP-437. Nothing you do during boot will change the font. In the first screen photo, you actually see the error message "Code page operation not supported on this device", which shows that DOS was unable to load a non-standard font. The font in the ROM seems to be "JUS I.B1.002" aka "ISO-IR-141" or "ISO 646-YU", informally called the Latin variant of YUSCII.

If the replacement font were loaded by DOS instead of being in the card ROM, a more modern font would be used instead that would have the backslash from US ASCII at code point 0x5C. Likely MS-DOS 5.0 would try to load Codepage 852 ("Central European") which will have Đ at code point 0xD1.

mkarcher wrote on Yesterday, 12:40:

Deunan wrote on Yesterday, 12:06:

That being said, the left SHIFT must be pressed and held all the time until DOS prompt appears. I don't think it worked properly since on the screen I still see That D instead of \, so MODE and/or DISPLAY.SYS still got loaded.

The display is from an MDA/Hercules card, which does not have software-programmable fonts. The strange D instead of the backslash is part of the character ROM on that card, which obviously does not contain CP-437. Nothing you do during boot will change the font. In the first screen photo, you actually see the error message "Code page operation not supported on this device", which shows that DOS was unable to load a non-standard font. The font in the ROM seems to be "JUS I.B1.002" aka "ISO-IR-141" or "ISO 646-YU", informally called the Latin variant of YUSCII.

If the replacement font were loaded by DOS instead of being in the card ROM, a more modern font would be used instead that would have the backslash from US ASCII at code point 0x5C. Likely MS-DOS 5.0 would try to load Codepage 852 ("Central European") which will have Đ at code point 0xD1.

Yes, i think i have entry 852 in either config or autoexec, but the card has its own characters...
Did You saw the bin file from this card? Has anybody have "BIOS" for this card with "normal" characters, so i can flash it on this ROM, 'cause this is the only MDA card i have....

butjer1010 wrote on Yesterday, 05:04:

2 more pics, back side, and i forgot to tell - first time i had turned this card on, those 2 highest tantalum exploded, but that is pretty normal on such old hardware, right? They couldn't make any significant damage?

When the tantalums burn/explode, they short the power supply rails for a (fraction of a) second. This could damage power traces on the card. Also, while just removing these capacitors will usually work fine, they were there for a purpose: To stabilize the supply voltage. If the BIOS ROM gets insufficiently stabilized supply voltage, it might misbehave, although I have difficulties to imagine how insufficient supply voltage would cause cross-talk between the address and data lines of the ROM. I did not yet get around to trace follow the traces on the EGA card, but assuming that the PEGA2A chip has D0..D7 multiplexed with A0..A7 and the multiplexing happens with buffers like 74LS244 controlled by the PALs, a single misbehaving PAL could cause an address/data conflict locally on that card.

If I understood the OP correctly, the card was first tested in a 486 system where it didn't work and then moved to the 286 system with the Hercules clone card, in which the card doesn't work as well, so I expect the mainboard to not be the primary culprit, but I am quite confident this is an actual fault on the card. Given the 1988 manufacturing date on most of the chips, the card is likely designed to work in Turbo-XTs, so 8MHz ISA clock should not be an issue.

butjer1010 wrote on Yesterday, 04:49:

Could it be that this fault is result of inserting this ega card in 16bit isa slot?

Not at all. The first part of a 16-bit slot behaves exactly the same as an 8-bit slot.

mkarcher wrote on Yesterday, 12:50:

When the tantalums burn/explode, they short the power supply rails for a (fraction of a) second. This could damage power traces […]
Show full quote

butjer1010 wrote on Yesterday, 05:04:

2 more pics, back side, and i forgot to tell - first time i had turned this card on, those 2 highest tantalum exploded, but that is pretty normal on such old hardware, right? They couldn't make any significant damage?

When the tantalums burn/explode, they short the power supply rails for a (fraction of a) second. This could damage power traces on the card. Also, while just removing these capacitors will usually work fine, they were there for a purpose: To stabilize the supply voltage. If the BIOS ROM gets insufficiently stabilized supply voltage, it might misbehave, although I have difficulties to imagine how insufficient supply voltage would cause cross-talk between the address and data lines of the ROM. I did not yet get around to trace follow the traces on the EGA card, but assuming that the PEGA2A chip has D0..D7 multiplexed with A0..A7 and the multiplexing happens with buffers like 74LS244 controlled by the PALs, a single misbehaving PAL could cause an address/data conflict locally on that card.

If I understood the OP correctly, the card was first tested in a 486 system where it didn't work and then moved to the 286 system with the Hercules clone card, in which the card doesn't work as well, so I expect the mainboard to not be the primary culprit, but I am quite confident this is an actual fault on the card. Given the 1988 manufacturing date on most of the chips, the card is likely designed to work in Turbo-XTs, so 8MHz ISA clock should not be an issue.

butjer1010 wrote on Yesterday, 04:49:

Could it be that this fault is result of inserting this ega card in 16bit isa slot?

Not at all. The first part of a 16-bit slot behaves exactly the same as an 8-bit slot.

As Deunan wrote, ISA bus is working on 10MHz 🙁 Doesn't have option for less than 10, only 10 and 20MHz are available in this BIOS

butjer1010 wrote on Yesterday, 12:48:

Has anybody have "BIOS" for this card with "normal" characters, so i can flash it on this ROM, 'cause this is the only MDA card i have....

The chip on that card is not "flash"able. You need a UV lamp to erase the chip before you can reprogram it in an classic EPROM programming device. The standard codepage 437 MDA/Hercules font can be found for examlpe at https://oldcomputer.info/software/fontedit/index.htm, but you might need to re-arrange the data before writing an EPROM. I did not yet look at the "character ROM" (you don't call it a "BIOS") for this card, so I don't know how/whether you need to re-arrange the bytes.

butjer1010 wrote on Yesterday, 12:54:

As Deunan wrote, ISA bus is working on 10MHz 🙁 Doesn't have option for less than 10, only 10 and 20MHz are available in this BIOS

Are you sure it's 10 and 20, and not 5 and 10? 20MHz on the ISA bus is incompatible with most cards, and possibly even too fast for 74LSxxx driver chips on the main board (if it has driver chips). A board targetting at 16 and 20MHz 286 processors should have some option to get below 10MHz ISA clock. While the DMA clock selection is quite clear as "CPUX1/...", which clearly signifies 20MHz, so /2 is 10MHz and /4 is 5MHz, the term "PROCCLK" is ambigous and might either mean 20MHz as well, or it might be "CPUX2", which would be 40MHz.

So just in case: Is the 40MHz oscillator on that board socketed? And if yes, can you replace it by something slower (32MHz at most), possibly a 25MHz crystal stolen from some VGA card? If the EGA starts working, it's really just the ISA bus being too fast.

mkarcher wrote on Yesterday, 13:01:

butjer1010 wrote on Yesterday, 12:48:

Has anybody have "BIOS" for this card with "normal" characters, so i can flash it on this ROM, 'cause this is the only MDA card i have....

The chip on that card is not "flash"able. You need a UV lamp to erase the chip before you can reprogram it in an classic EPROM programming device. The standard codepage 437 MDA/Hercules font can be found for examlpe at https://oldcomputer.info/software/fontedit/index.htm, but you might need to re-arrange the data before writing an EPROM. I did not yet look at the "character ROM" (you don't call it a "BIOS") for this card, so I don't know how/whether you need to re-arrange the bytes.

I have UV Eraser also 😉

mkarcher wrote on Yesterday, 13:10:

butjer1010 wrote on Yesterday, 12:54:

As Deunan wrote, ISA bus is working on 10MHz 🙁 Doesn't have option for less than 10, only 10 and 20MHz are available in this BIOS

Are you sure it's 10 and 20, and not 5 and 10? 20MHz on the ISA bus is incompatible with most cards, and possibly even too fast for 74LSxxx driver chips on the main board (if it has driver chips). A board targetting at 16 and 20MHz 286 processors should have some option to get below 10MHz ISA clock. While the DMA clock selection is quite clear as "CPUX1/...", which clearly signifies 20MHz, so /2 is 10MHz and /4 is 5MHz, the term "PROCCLK" is ambigous and might either mean 20MHz as well, or it might be "CPUX2", which would be 40MHz.

So just in case: Is the 40MHz oscillator on that board socketed? And if yes, can you replace it by something slower (32MHz at most), possibly a 25MHz crystal stolen from some VGA card? If the EGA starts working, it's really just the ISA bus being too fast.

I have 2 other 286 PCs (if i remember 12 and 16MHz). I will bring them down from attic, and try to do debugging on one of them.

mkarcher wrote on Yesterday, 12:50:

I did not yet get around to trace follow the traces on the EGA card, but assuming that the PEGA2A chip has D0..D7 multiplexed with A0..A7 and the multiplexing happens with buffers like 74LS244 controlled by the PALs, a single misbehaving PAL could cause an address/data conflict locally on that card.

OK, so the data lines from the ISA bus are connected to U28 (74LS245) side B. It's not clearly visible whether the traces on the top side of the board "above" U28 going "left" (away from the bracket) are connected there as well, which would continue the unbuffered ISA data lines. Whether those traces are buffered or unbuffered: The top four data bits are connected to the inputs of the 4-bit Flip-Flop U13 (74LS173), and continue to the 8 vias near the "L208801A" label. The traces then continue on the solder side to U18 (another 74LS245), again on the "B" side, where those traces likely end.

U28 pin 19 (/OE) is permanently enabled. Clue: It is connected with a wide trace, so that trace very likely is +5V or GND. Direction control of that chip (pin 1) is not easily traceable from the photos. U18 /OE seems to be connected to pin 10 of U22 (74LS04). That chip is a hex inverter, the corresponding input is pin 11. Pin 11 is connected to a via below U22, which makes tracing that trace on the component side impossible, but it seems likely to be controlled by the PAL U10 next to U22. The direction control pin of U18 (the second 74LS245 possibly connected to the ISA data lines) seems to be connected to some pin of the PEGA2A. Possibly, U28 is a data buffer chip for the parallel port part of the card and U18 is a data buffer chip for the EGA part of the card.

The A side of U28 (the suspected data buffer for the parallel port) is connected to the inputs of U31 (74LS374), an 8-bit flip-flop, likely the data latch for the parallel port. In a classic parallel port implementation, U30 (the 74LS244 2*4-bit unidirectional bus driver above it) would be the chip to read back the data from the pins at the parallel port, the 74LS174 next to it would be the latch for the control pins, one part of U24 (74LS125) is the IRQ7 driver, and one half of U29 (a 74LS240 inverting 2*4-bit unidirectional driver) may be used to read back the status bits. I'm not going to look into that part in more detail.

ISA address lines A0..A19 are routed at the lower edge of the component side of the card. Furthermore A0..A9 (the address bits used for I/O addresses) are tapped near the ISA connector. A8, A10..A13 have vias below U23. After those vias, the block of address lines splits. A0..A13 continue towards the ROM chip (the EGA BIOS is 16K, and 14 address lines are enough to address it), while the higher address lines move towards U11 (but some disappear in a via before reaching U11 on the component side). It seems the address and data bits at the ROM are mostly connected to the address and data bits of the 2K SRAM (which is used for legacy emulation; some CGA/MDA I/O writes like 3D8 are mirrored in hardware into that RAM). As the SRAM is quite close to the ROM, damage in that chip can easily disturb the ROM. You don't need that chip for the BIOS to be readable, so one thing you can try is to remove U15 (the 2K SRAM) and try dumping the BIOS again. If that helps, either the SRAM is broken itself, or it gets bad control signals that cause it to disturb ROM reads.

Meanwhile, I will continue to trace the card to see whether I can find something that is able to "accidentally" short address to data bits.

OK, so the data bits from the ROM and SRAM seem to be routed to U18, the suspected EGA data buffer bridging "local EGA data" to the ISA bus. This makes sense. Some low address lines are obviously connected to input pins of U17, a 74LS244 2*4bit unidirectional driver. As both enable pins are connected together, it is used as single 8-bit unidirectional driver. Given my assumption that possibly something is broken with multiplexing address and data towards the PEGA2A chip, U17 could be an important clue in that loop, as it conditionally forwards address information, and at least one output pin (pin 5) is connected to a pin on the PEGA2A chip is well. So another interesting experiment is how the card behaves with U17 removed.

EDIT: Yeah, indeed. The "local EGA data bus" is actually a multiplexed data/address bus! That bus can be used in different ways:

• If U17 is enabled, it forwards the low 8 ISA address bits to the local EGA bus so that the PEGA chip can read I/O and video memory addresses.
• If U17 is disabled and U18 is enabled to forward data from the local EGA bus to the ISA bus, data can be sent from the PEGA chip or the SRAM or the BIOS ROM to the ISA bus (for reading of I/O ports, emulation RAM, video RAM or BIOS)
• If U17 is disabled and U18 is enabled to forward data from the ISA bus to the local EGA bus, data for SRAM writes, video RAM writes or EGA port writes is transferred from the ISA bus to the EGA local bus.

If, for some reason, U17 is enabled during BIOS reads, the local EGA bus is both driven by U17 (with address information) and the BIOS ROM (with ROM data), causing a conflict that could perfectly explain the symptoms you are seeing. This supports my recommendation to test the card with U17 removed. It clearly will not work without U17, because the PEGA chip will not be able to get full addresses from the ISA bus, but U17 is not required for BIOS reads if I understand the card architecture correctly. So if the problem is indeed in handling the multiplexed address/data bus on the EGA card, removing U17 should make BIOS reads work perfectly.

mkarcher wrote on Yesterday, 14:21:

OK, so the data bits from the ROM and SRAM seem to be routed to U18, the suspected EGA data buffer bridging "local EGA data" to […]
Show full quote

OK, so the data bits from the ROM and SRAM seem to be routed to U18, the suspected EGA data buffer bridging "local EGA data" to the ISA bus. This makes sense. Some low address lines are obviously connected to input pins of U17, a 74LS244 2*4bit unidirectional driver. As both enable pins are connected together, it is used as single 8-bit unidirectional driver. Given my assumption that possibly something is broken with multiplexing address and data towards the PEGA2A chip, U17 could be an important clue in that loop, as it conditionally forwards address information, and at least one output pin (pin 5) is connected to a pin on the PEGA2A chip is well. So another interesting experiment is how the card behaves with U17 removed.

EDIT: Yeah, indeed. The "local EGA data bus" is actually a multiplexed data/address bus! That bus can be used in different ways:

• If U17 is enabled, it forwards the low 8 ISA address bits to the local EGA bus so that the PEGA chip can read I/O and video memory addresses.
• If U17 is disabled and U18 is enabled to forward data from the local EGA bus to the ISA bus, data can be sent from the PEGA chip or the SRAM or the BIOS ROM to the ISA bus (for reading of I/O ports, emulation RAM, video RAM or BIOS)
• If U17 is disabled and U18 is enabled to forward data from the ISA bus to the local EGA bus, data for SRAM writes, video RAM writes or EGA port writes is transferred from the ISA bus to the EGA local bus.

If, for some reason, U17 is enabled during BIOS reads, the local EGA bus is both driven by U17 (with address information) and the BIOS ROM (with ROM data), causing a conflict that could perfectly explain the symptoms you are seeing. This supports my recommendation to test the card with U17 removed. It clearly will not work without U17, because the PEGA chip will not be able to get full addresses from the ISA bus, but U17 is not required for BIOS reads if I understand the card architecture correctly. So if the problem is indeed in handling the multiplexed address/data bus on the EGA card, removing U17 should make BIOS reads work perfectly.

So let me summarize everything You wrote up there - Should i try first without U15, or without U17, or maybe without both chips? Without U17 BIOS should not giving me beep codes, right?

butjer1010 wrote on Yesterday, 19:16:

So let me summarize everything You wrote up there - Should i try first without U15, or without U17, or maybe without both chips? Without U17 BIOS should not giving me beep codes, right?

You should not get beep codes with the broken EGA at all if you have the Hercules card installed at the same time. I still want you to keep the Hercules card around. If my hypothesis that U17 interferes with BIOS reading is correct, the mainboard BIOS should pick up the EGA BIOS, and possibly it will try to initialize the card. Be prepared that you might need to type "MODE MONO" blindly after DOS booted, but likely the MONO/COLOR jumper makes the BIOS do a "MODE MONO" equivalent operation during the POST.

As I think interference via U17 is the most likely cause, try booting without U17 first, and then dump the BIOS again (dc000:0 in debug). If you get the same corrupted contents, also remove U15.

mkarcher wrote on Yesterday, 21:09:

butjer1010 wrote on Yesterday, 19:16:

So let me summarize everything You wrote up there - Should i try first without U15, or without U17, or maybe without both chips? Without U17 BIOS should not giving me beep codes, right?

You should not get beep codes with the broken EGA at all if you have the Hercules card installed at the same time. I still want you to keep the Hercules card around. If my hypothesis that U17 interferes with BIOS reading is correct, the mainboard BIOS should pick up the EGA BIOS, and possibly it will try to initialize the card. Be prepared that you might need to type "MODE MONO" blindly after DOS booted, but likely the MONO/COLOR jumper makes the BIOS do a "MODE MONO" equivalent operation during the POST.

As I think interference via U17 is the most likely cause, try booting without U17 first, and then dump the BIOS again (dc000:0 in debug). If you get the same corrupted contents, also remove U15.

Ok, that was clear, thanks! Will let You know of the outcome...