Deunan wrote on 2025-07-19, 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 2025-07-19, 12:40:

Deunan wrote on 2025-07-19, 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 2025-07-19, 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 2025-07-19, 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 2025-07-19, 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 2025-07-19, 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 2025-07-19, 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 2025-07-19, 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 2025-07-19, 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 2025-07-19, 13:01:

butjer1010 wrote on 2025-07-19, 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 2025-07-19, 13:10:

butjer1010 wrote on 2025-07-19, 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 2025-07-19, 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 2025-07-19, 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 2025-07-19, 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 2025-07-19, 21:09:

butjer1010 wrote on 2025-07-19, 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...

mkarcher wrote on 2025-07-19, 21:09:

butjer1010 wrote on 2025-07-19, 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.

So You were right, there is different debug message after removing U17, look at the picture...
This U17 i checked with a T48 programmer, and it passed test...

When i remove also U15, the PC wont show picture, only few lines and dots are showing

Now the good part maybe starts 😀
There is no more beep sound when i left only EGA card in this 286 (didn't try on this 486 i first tried this card on), and when i put another LS 244N instead of U15 old 244N, here is the picture i get on EGA screen. Maybe now it is the time to work again on DIP switch?

Definitely the card works now with new 244N in U17!!!!! You are all geniuses, but You already knew that 😉
Now i need DIP switch settings, because i can see the letters, but it is out of frequency!
From first 4 switches, it works most stable with only switch 2 ON, but work with SW1 on, but the pic is more out of freq....Faster the letters are "spinning"
Now i need to guess the combination of other 4 SW, if this is the SW setting on this EGA card (as everybody said here in first messages: 1-4 for graphics mode EGA, CGA, MDA,..., 5-8 for freqs i guess)

butjer1010 wrote on 2025-07-20, 15:12:

here is the picture i get on EGA screen. Maybe now it is the time to work again on DIP switch?

That's actually great news. Given the symptoms I was not surprised that removing U17 fixed the broken BIOS, but I was afraid that not U17 itself was broken, but the PAL controlling U17. Replacing a PAL with an unknown program in it is way harder than replacing a standard logic chip. So now the interface between the computer and the EGA, including video memory, seems to work perfectly.

butjer1010 wrote on 2025-07-20, 15:57:

Definitely the card works now with new 244N in U17!!!!! You are all geniuses, but You already knew that 😉
Now i need DIP switch settings, because i can see the letters, but it is out of frequency!

The horizontal frequency is only slightly off. I wonder whether the HSYNC signal is missing and the monitor is oscillating unsynchronized and nearly hits the standard frequency. Your last photo (with the boot text from DOS) seems to be in CGA-compatible 80-column text mode with 200 scan lines and an 8x8 font. This doesn't really match standard EGA switch settings, though.

butjer1010 wrote on 2025-07-20, 15:57:

Definitely the card works now with new 244N in U17!!!!! You are all geniuses, but You already knew that 😉
From first 4 switches, it works most stable with only switch 2 ON, but work with SW1 on, but the pic is more out of freq....Faster the letters are "spinning"
Now i need to guess the combination of other 4 SW, if this is the SW setting on this EGA card (as everybody said here in first messages: 1-4 for graphics mode EGA, CGA, MDA,..., 5-8 for freqs i guess)

I don't think you can separate "frequency" from "mode". You also can't fine-tune the frequencies of that card. The card has just 4 frequencies: 14.318MHz taken straight from the ISA bus, and 16.257, 25.000 and 27.256 MHz from the three crystal oscillators on the card. The BIOS of your card contains code that reads 4 switches just as you would do on a standard EGA card, so 4 of those eight switches are very likely identical to the IBM switches. The IBM switches are not about selecting "graphics modes" like EGA, CGA or MDA, but their primary purpose is to select the monitor type, so the EGA card can output the required frequency. The IBM EGA card does not behave exactly like an CGA or MDA card, so programs that do direct low-level programming to those cards, e.g. to set custom modes, will fail on a standard EGA card. That's where the extra functionality of your card kicks in: You card is supposed to emulate CGA, Hercules and MDA on a register level well enough that most programs that manually set up CGA modes work perfectly with it. As there is no BIOS support for Hercules at all, every Hercules graphics program also manually programs the Hercules registers, which will fail on standard IBM-compatible EGA cards.

If I understand it correctly, your card can emulate MDA and Hercules on a register level, at least with an MDA-type monitor (~18kHz) connected. It also can emulate CGA, and the extended Plantronics CGA variant, at least if a CGA monitor (15.6kHz) or an EGA monitor (15.6kHz / ~21kHz dual frequency) is connected. Furthermore, the key feature of the Paradise AutoSwitch EGA card is that it can switch to CGA register level emulation automatically if a CGA-like mode is selected and switch back to native EGA mode as soon as an EGA 16-color graphics mode is selected. "AutoSwitch" likely is an optional feature, so the extra switches need to set up whether the EGA card should autoswitch, if it should boot in CGA emulation mode (for color monitors) or MDA/Hercules emulation mode (for MDA-type monitors), and possibly also whether it is allowed to leave emulation mode, or if it stays "locked" in emulation mode.

As your monitor worked well with a EGA/VGA card in EGA mode, I assume your monitor is able to synchronize both 21kHz and 15.6kHz. The monitor can deduce whether it should operate in 21kHz (350 line) or 15.6kHz (200 line) mode by looking at the wave form of some sync signal, IIRC the vertical one. Even without a sync input, the monitor will oscillate at around 21kHz or 15.6kHz, so that's why I suppose that the real issue is that this card does not output any horizontal sync signal at all. Vertical sync seems to be fine. You can try to follow the traces from pin 8 of the monitor jack to see where HSYNC is supposed to come from. I suppose it is either U32 or U34 via RP1. HSYNC is supposed to be "active high" in all modes supported by an EGA monitor, which means that the signal is normally low with short high pulses at the end of each line. If you attach a digital voltmeter to that signal, I would expect an average voltage of 0.7V to 1.2V, probably lower while the RESET button is pushed. If the voltage at the HSYNC output is below 0.3V or above 3V, HSYNC likely is broken and needs troubleshooting next.

mkarcher wrote on 2025-07-20, 17:28:

That's actually great news. Given the symptoms I was not surprised that removing U17 fixed the broken BIOS, but I was afraid tha […]
Show full quote

butjer1010 wrote on 2025-07-20, 15:12:

here is the picture i get on EGA screen. Maybe now it is the time to work again on DIP switch?

That's actually great news. Given the symptoms I was not surprised that removing U17 fixed the broken BIOS, but I was afraid that not U17 itself was broken, but the PAL controlling U17. Replacing a PAL with an unknown program in it is way harder than replacing a standard logic chip. So now the interface between the computer and the EGA, including video memory, seems to work perfectly.

butjer1010 wrote on 2025-07-20, 15:57:

Definitely the card works now with new 244N in U17!!!!! You are all geniuses, but You already knew that 😉
Now i need DIP switch settings, because i can see the letters, but it is out of frequency!

The horizontal frequency is only slightly off. I wonder whether the HSYNC signal is missing and the monitor is oscillating unsynchronized and nearly hits the standard frequency. Your last photo (with the boot text from DOS) seems to be in CGA-compatible 80-column text mode with 200 scan lines and an 8x8 font. This doesn't really match standard EGA switch settings, though.

butjer1010 wrote on 2025-07-20, 15:57:

Definitely the card works now with new 244N in U17!!!!! You are all geniuses, but You already knew that 😉
From first 4 switches, it works most stable with only switch 2 ON, but work with SW1 on, but the pic is more out of freq....Faster the letters are "spinning"
Now i need to guess the combination of other 4 SW, if this is the SW setting on this EGA card (as everybody said here in first messages: 1-4 for graphics mode EGA, CGA, MDA,..., 5-8 for freqs i guess)

I don't think you can separate "frequency" from "mode". You also can't fine-tune the frequencies of that card. The card has just 4 frequencies: 14.318MHz taken straight from the ISA bus, and 16.257, 25.000 and 27.256 MHz from the three crystal oscillators on the card. The BIOS of your card contains code that reads 4 switches just as you would do on a standard EGA card, so 4 of those eight switches are very likely identical to the IBM switches. The IBM switches are not about selecting "graphics modes" like EGA, CGA or MDA, but their primary purpose is to select the monitor type, so the EGA card can output the required frequency. The IBM EGA card does not behave exactly like an CGA or MDA card, so programs that do direct low-level programming to those cards, e.g. to set custom modes, will fail on a standard EGA card. That's where the extra functionality of your card kicks in: You card is supposed to emulate CGA, Hercules and MDA on a register level well enough that most programs that manually set up CGA modes work perfectly with it. As there is no BIOS support for Hercules at all, every Hercules graphics program also manually programs the Hercules registers, which will fail on standard IBM-compatible EGA cards.

If I understand it correctly, your card can emulate MDA and Hercules on a register level, at least with an MDA-type monitor (~18kHz) connected. It also can emulate CGA, and the extended Plantronics CGA variant, at least if a CGA monitor (15.6kHz) or an EGA monitor (15.6kHz / ~21kHz dual frequency) is connected. Furthermore, the key feature of the Paradise AutoSwitch EGA card is that it can switch to CGA register level emulation automatically if a CGA-like mode is selected and switch back to native EGA mode as soon as an EGA 16-color graphics mode is selected. "AutoSwitch" likely is an optional feature, so the extra switches need to set up whether the EGA card should autoswitch, if it should boot in CGA emulation mode (for color monitors) or MDA/Hercules emulation mode (for MDA-type monitors), and possibly also whether it is allowed to leave emulation mode, or if it stays "locked" in emulation mode.

As your monitor worked well with a EGA/VGA card in EGA mode, I assume your monitor is able to synchronize both 21kHz and 15.6kHz. The monitor can deduce whether it should operate in 21kHz (350 line) or 15.6kHz (200 line) mode by looking at the wave form of some sync signal, IIRC the vertical one. Even without a sync input, the monitor will oscillate at around 21kHz or 15.6kHz, so that's why I suppose that the real issue is that this card does not output any horizontal sync signal at all. Vertical sync seems to be fine. You can try to follow the traces from pin 8 of the monitor jack to see where HSYNC is supposed to come from. I suppose it is either U32 or U34 via RP1. HSYNC is supposed to be "active high" in all modes supported by an EGA monitor, which means that the signal is normally low with short high pulses at the end of each line. If you attach a digital voltmeter to that signal, I would expect an average voltage of 0.7V to 1.2V, probably lower while the RESET button is pushed. If the voltage at the HSYNC output is below 0.3V or above 3V, HSYNC likely is broken and needs troubleshooting next.

Sorry, but i don't know anything about the thing You are master at 🙁
I tried to play with switches for last hour and a half... First 4 switches gives me picture (with Hsync broken as You stated) in combination of : 0-0-0-0, 0-0-0-1, 0-1-0-0, 1-1-1-0, 1-0-0-1 and 1-1-0-0. In other combination, there is a blank screen. So i tried all 16 combination with this 6 ( 96 all together 🙁 ), but hsync is always broken. So next thing as You stated is pin 8 of EGA connector, and see where it goes!
Thanks again, this is really great school to me 😉

Need to desolder oscillator 16.257, and maybe 25.000 also, well see.... This is the trace from pin 8 of ega connector. It goes to resistor 330 first leg, first leg have resistance of 330 with 2nd leg of this resistor array, then it goes to this green capacitor, and trace from positive leg of capacitor goes under oscillator....
EDIT: Of course it went under all 3 oscillators, and it ends on upper 3rd from right leg on PAL16L8!