Deunan wrote on Yesterday, 19:14:

Well then either that PAL output is broken or, perhaps, there is a problem with the input. If the PAL outputs HSYNC then it must also be getting it from the PEGA2 chip. See if you find a connection between pin 24 of the extension connector and one of the PAL pins. Maybe that is broken and the output is simply stuck at zero all the time.

I agree with this advice.

Deunan wrote on Yesterday, 18:47:

I would not be using this card with direct output of PEGA2 on the connector for anything other than short testing, it might damage the chip.

I mostly agree with this recommendation. The card as it is now exposes a connection to the delicate highly integrated (for that time) PEGA2A chip directly to the monitor connection, with only a low amount of protection circuit. There is a capacitor (the green one) and a 330 ohm resistor that reduces the chance of damage if something happens on the EGA monitor connection, but this is likely not adequate protection against electrostatic discharge hitting the monitor connector. If the PAL turns out to be damaged, this damage may actually be caused by exactly that: Electrostatic charge hitting the HSYNC pin of the EGA port.

A better solution than just bridging pin 24 to pin 30 and exposing the connection to the PEGA2A chip would be to add a non-inverting buffer chip at that location. You have the input to that buffer on pin 24, the output of the buffer needs to be connected to pin 30, and if you want to be fully EGA compatible, accepting all kind of hardware connected to the feature connector, you should take an active-low chip enable signal from pin 27 of the feature connector. +5V/GND can also be tapped from the feature connector, GND is at pin 31 and +5V is at pin 32. Suitable TTL chips that can use this signal to substitute the PAL driving the HSYNC signal are 74LS125, 74LS244 or 74LS245. All of these chips are non-inverting drivers with an active-low chip enable signal. Before you add a dedicated buffer chip, it is a good idea to find how the PAL was supposed to get HSYNC and check whether that trace or that pin in the socket is broken.

butjer1010 wrote on Yesterday, 19:24:

PALs PIN 11 and 13 are connected with PIN24(and 30 of course, wired) of feature connector

OK, so if the wire would not be installed, PAL pin 11 would be connected to pin 24 of the feature connector only and PAL pin 13 would be connected to pin 30 of the feature connector only. So pin 11 is the pin we were looking for. Do you see any corrosion in the PAL socket or at pin 11 of the PAL? A bad contact on that pin would be a possible cause for the missing HSYNC signal you had. Also make sure pin 20 of the PAL is connected to +5v (test connectivity to the "top left" pin of other chips), and pin 10 of the PAL is connected to GND (test connectivity to the "bottom right" pin of other chips).

mkarcher wrote on Yesterday, 19:21:

OK, let's look at your working combinations: All of your pictures show 200-line modes. This might be due to some CGA emulation m […]
Show full quote

butjer1010 wrote on Yesterday, 18:44:

So, only 0001 and 1110 looks normal. Should i play some games to see which combination is better for this monitor?

OK, let's look at your working combinations: All of your pictures show 200-line modes. This might be due to some CGA emulation mode being active in text mode (activated by the upper switches), or it might be that only 200-line modes work. If you limit yourself to the "officially allowed" configurations, you would expect to hit the 80x25 200-line text mode more often than the 40x25 mode. It seem the BIOS doesn't limit the switches to the allowed configurations, though, creating "ghost configurations" that may or may not work sensibly.

From your pictures, I deduce

• 40-character 200-line mode at 0100, 1100, 1001.
• 80-character 200-line mode at 0001 and 1110.

80-character mode at those two combinations makes perfect sense, as those combinations (read with inverted logic and most significant bit on the right) are "EGA primary card with CGA monitor in 80-character mode" (configuration 7), and "EGA primary card with EGA monitor, displaying text as a CGA card would, startup in 80-character mode" (configuration 8 ). If that logic is correct, we can deduce the switch setting that is supposed to yield "EGA primary card with CGA monitor in 40-character mode" (configuration 6), which is 1001, and that's actually also one of the working configuration, so I guess we decoded how the switch settings can be translated to configuration numbers. This allows me to read 0100 as "configuration 13" and 1100 as "configuration 12", which are both unsupported configurations. The BIOS has a 12-entry "switch interpretation table" which is assigned to configurations number 0 to 11. Configurations 12, 13, 14 and 15 accesses data as "switch interpretation" that is not meant to be used that way. Most prominently, configurations 12 and 13 will cause the BIOS to initialize the EGA card for a color monitor, while 14 and 15 will cause the BIOS to initialize the EGA card for a monochrome monitor. So it's not surprising that 12 and 13 cause your card to display an image, while 14 and 15 do not.

Something is still wrong, though. Assuming your monitor actually is an EGA monitor (and not just a CGA monitor), you should be able to get a considerably better text mode at 0110 (configuration 9). If that switch setting does not produce a stable image on an EGA monitor, something is wrong with the 16.257MHz oscillator, the oscillator selection circuit or the vertical sync polarity selection. The vertical sync polarity selection is completely integrated in the PEGA2A chip, so at the moment I consider it unlikely to be broken. Can you please post a photo of the screen contents at 0110, maybe during POST, or at the DOS prompt when AUTOEXEC is finished?

0110 now works?!? It didn't work before pin 13 was disabled.You meant "my" 0110- 1 off,2 on,3 on,4 off?
Here is the picture

butjer1010 wrote on Yesterday, 19:39:

0110 now works?!? It didn't work before pin 13 was disabled.You meant "my" 0110- 1 off,2 on,3 on,4 off?
Here is the picture

Exactly. That's the optimal configuration for an EGA card with an EGA monitor. You should adjust picture height or vertical position on the monitor, if possible. The bottom text line is not supposed to be paritally cut off. And by the way, the brightness setting in your pictures is way too high. Possibly you just did that for taking the pictures, which is OK, but you should turn down brightness such that the background is a solid black instead of that pinkish glow.

mkarcher wrote on Yesterday, 19:37:

butjer1010 wrote on Yesterday, 19:24:

PALs PIN 11 and 13 are connected with PIN24(and 30 of course, wired) of feature connector

OK, so if the wire would not be installed, PAL pin 11 would be connected to pin 24 of the feature connector only and PAL pin 13 would be connected to pin 30 of the feature connector only. So pin 11 is the pin we were looking for. Do you see any corrosion in the PAL socket or at pin 11 of the PAL? A bad contact on that pin would be a possible cause for the missing HSYNC signal you had. Also make sure pin 20 of the PAL is connected to +5v (test connectivity to the "top left" pin of other chips), and pin 10 of the PAL is connected to GND (test connectivity to the "bottom right" pin of other chips).

5.0V on pin 20 😀
No corrosion at all

mkarcher wrote on Yesterday, 19:41:

butjer1010 wrote on Yesterday, 19:39:

0110 now works?!? It didn't work before pin 13 was disabled.You meant "my" 0110- 1 off,2 on,3 on,4 off?
Here is the picture

Exactly. That's the optimal configuration for an EGA card with an EGA monitor.

So, is it safe to use this card without pin 13 lifted up, and connected pin 24 and 30 of feature connector, or it could damage something like Deunan said?
Yes, i have raised brightness up to max 😀
Edit: Sorry, not brightness, contrast is at max. Brightness is the only thing it doesn't work on this monitor. I should find another adjustable resistor, or whatever this is.

butjer1010 wrote on Yesterday, 19:39:

0110 now works?!? It didn't work before pin 13 was disabled.

Yeah, your monitor supports two modes: CGA-like 200 line mode and EGA-like 350 line mode. The monitor likely uses the polarity V-SYNC signal to decide which mode it should operate in. The monitor has its own frequency generator for the horizontal frequency, which is "around 15.6kHz" in CGA mode and "around 21.8kHz" in EGA mode. The monitor needs the HSYNC signal to make sure the horizontal deflection in the monitor is locked to the line frequency of the EGA card. It just happens by pure chance that without any synchronization, the horizontal oscillator in your monitor was very close to the actual horizontal rate, so the image was "kind of OK" even without HSYNC. On the other hand, in the 21.8kHz mode, the oscillator in the monitor did not operate close enough to 21.8kHz on its own to create a nearly stable image. That's why 0110 only started working after you got the HSYNC signal working.

You should check the PAL's socket for oxidation or damage to pin 11, as suggested.

There's ambiguity as to the cause of that PAL's pin11 output error.

It could be any combination of

Pin11 of the PAL has poor contact.
the trace of pin11 of that socket is cut or damaged.
The PAL has suffered damage or failure, and is not driving this pin properly.

You want some other bit of circuitry (that's beefier and much cheaper/easier to replace) to provide this signal on the monitor cable. For diagnostic purposes it's been suggested to test with a direct connection (means crystals are in tolerance, etc), but this is playing with fire, and needs to not be considered a fix.

The root cause of why hsync is not being carried out of the PAL needs to be explored.

Now it is better at the edges, but i cannot adjust the brightness. It is not so pinkish in reality, like on the picture.

So the input is pin 11, and output is pin 13. Therefore pin 11 can't be /OE anyway, although 16L8 can be put into combinatorial mode with individual output enable per pin. But clearly this one is stuck at some level and preventing HSYNC being output.

Best I can tell the right side PAL is I/O address decoder for the built-in LPT port. And I would guess only for that, the PEGA2 chip should handle all the EGA I/O internally. So why is removing it preventing the system from booting properly. Maybe the status bits are then stuck in output mode on the ISA bus? I'm trying to figure out if it is safe to swap the PALs for a test. I would do it, but I don't want to give advice that can break the card even more...

wierd_w wrote on Yesterday, 19:52:

You should check the PAL's socket for oxidation or damage to pin 11, as suggested. […]
Show full quote

You should check the PAL's socket for oxidation or damage to pin 11, as suggested.

There's ambiguity as to the cause of that PAL's pin11 output error.

It could be any combination of

Pin11 of the PAL has poor contact.
the trace of pin11 of that socket is cut or damaged.
The PAL has suffered damage or failure, and is not driving this pin properly.

You want some other bit of circuitry (that's beefier and much cheaper/easier to replace) to provide this signal on the monitor cable. For diagnostic purposes it's been suggested to test with a direct connection (means crystals are in tolerance, etc), but this is playing with fire, and needs to not be considered a fix.

The root cause of why hsync is not being carried out of the PAL needs to be explored.

I can change socket for new one, no problem, but i cannot see any damage to old one. Sprayed with contact cleaner also....

butjer1010 wrote on Yesterday, 19:45:

So, is it safe to use this card without pin 13 lifted up, and connected pin 24 and 30 of feature connector, or it could damage something like Deunan said?

In my oppinion, as long as the monitor is firmly connected to the EGA card, the chance of damage to the PEGA2A chip is very low even with the wire between pin 24 and pin 30. On the other hand, every time you connect a monitor that might have some electrostatic charge stored in it, you risk damage to the PEGA2A chip. Also, if lightning strikes your neighbours house, there might be some induced current spike on the monitor cable (which is long enough to work as an antenna), which can directly damage the PEGA2A chip. If you had a buffer chip in between, only the buffer chip could be damaged by external interference, and the PEGA2A chip will stay safe.

You possibly remember that I was surprised that they connected a PAL output directly (well, nearly directly) to the monitor connector, because that PAL possibly "is not strong enough" to drive the monitor cable, and also I doubt the PAL has perfect protection agains electric spikes. Deunan's fear that the PEGA2A chip is even less robust than the PAL is justified, so a better workaround is recommended in the long run. I don't think you will fry anything if you keep using the card that way for some days, but I don't consider it a good long-term solution.

mkarcher wrote on Yesterday, 19:58:

butjer1010 wrote on Yesterday, 19:45:

So, is it safe to use this card without pin 13 lifted up, and connected pin 24 and 30 of feature connector, or it could damage something like Deunan said?

In my oppinion, as long as the monitor is firmly connected to the EGA card, the chance of damage to the PEGA2A chip is very low even with the wire between pin 24 and pin 30. On the other hand, every time you connect a monitor that might have some electrostatic charge stored in it, you risk damage to the PEGA2A chip. Also, if lightning strikes your neighbours house, there might be some induced current spike on the monitor cable (which is long enough to work as an antenna), which can directly damage the PEGA2A chip. If you had a buffer chip in between, only the buffer chip could be damaged by external interference, and the PEGA2A chip will stay safe.

You possibly remember that I was surprised that they connected a PAL output directly (well, nearly directly) to the monitor connector, because that PAL possibly "is not strong enough" to drive the monitor cable, and also I doubt the PAL has perfect protection agains electric spikes. Deunan's fear that the PEGA2A chip is even less robust than the PAL is justified, so a better workaround is recommended in the long run. I don't think you will fry anything if you keep using the card that way for some days, but I don't consider it a good long-term solution.

What kind of buffer chip do i need to use this card safe? Is it some LS, or something that needs to be programed, like this PAL?

butjer1010 wrote on Yesterday, 19:52:

Now it is better at the edges, but i cannot adjust the brightness. It is not so pinkish in reality, like on the picture.

Nevertheless, the brightness control on the monitor should be fixed some time. You should be able to get both a solid black background and a nice bright white at the same time, which I am afraid you probably can not get without the brightness control fixed. But that's an entirely different issue than the HSYNC issue of your EGA card, and we shouldn't work on both issues at the same time.

butjer1010 wrote on Yesterday, 20:02:

What kind of buffer chip do i need to use this card safe? Is it some LS, or something that needs to be programed, like this PAL?

I already wrote a paragraph about suitable buffer solutions, likely you missed it due to the many posts in this thread:

mkarcher wrote on Yesterday, 19:34:

A better solution than just bridging pin 24 to pin 30 and exposing the connection to the PEGA2A chip would be to add a non-inverting buffer chip at that location. You have the input to that buffer on pin 24, the output of the buffer needs to be connected to pin 30, and if you want to be fully EGA compatible, accepting all kind of hardware connected to the feature connector, you should take an active-low chip enable signal from pin 27 of the feature connector. +5V/GND can also be tapped from the feature connector, GND is at pin 31 and +5V is at pin 32. Suitable TTL chips that can use this signal to substitute the PAL driving the HSYNC signal are 74LS125, 74LS244 or 74LS245. All of these chips are non-inverting drivers with an active-low chip enable signal.

mkarcher wrote on Yesterday, 20:03:

butjer1010 wrote on Yesterday, 19:52:

Now it is better at the edges, but i cannot adjust the brightness. It is not so pinkish in reality, like on the picture.

Nevertheless, the brightness control on the monitor should be fixed some time. You should be able to get both a solid black background and a nice bright white at the same time, which I am afraid you probably can not get without the brightness control fixed. But that's an entirely different issue than the HSYNC issue of your EGA card, and we shouldn't work on both issues at the same time.

Yes of course. That shouldn't be a problem, i need to find some donor monitor for this, cause it is very unlikely i will find it in the store in 2025 😀

mkarcher wrote on Yesterday, 20:04:

butjer1010 wrote on Yesterday, 20:02:

What kind of buffer chip do i need to use this card safe? Is it some LS, or something that needs to be programed, like this PAL?

I already wrote a paragraph about suitable buffer solutions, likely you missed it due to the many posts in this thread:

mkarcher wrote on Yesterday, 19:34:

A better solution than just bridging pin 24 to pin 30 and exposing the connection to the PEGA2A chip would be to add a non-inverting buffer chip at that location. You have the input to that buffer on pin 24, the output of the buffer needs to be connected to pin 30, and if you want to be fully EGA compatible, accepting all kind of hardware connected to the feature connector, you should take an active-low chip enable signal from pin 27 of the feature connector. +5V/GND can also be tapped from the feature connector, GND is at pin 31 and +5V is at pin 32. Suitable TTL chips that can use this signal to substitute the PAL driving the HSYNC signal are 74LS125, 74LS244 or 74LS245. All of these chips are non-inverting drivers with an active-low chip enable signal.

I have few spare 244 and 245, but i'm afraid i don't understand the "procedure" right 😀
I would be very grateful if You can say "on my language",.... if there is a simple solution like solder LS244 pin xx to feature port pin xx,....
If not, i owe You a lot already (and to the other guys here) for fixing this card for me !!!!

Picture too bright, but good colors, might be because somebody bumped the G2 pot on the back of the HV transformer inside the monitor. Some of these are very touchy and you can easily go outside the range of the brightness pot with it.

I would try to read that PAL in a programmer. Could be read protected, but maybe not. If it's not then pin 13, even if broken, should not be needed for reading it properly. In that case it can be cloned into GAL16V8 device with some work (to set the mode fuses properly) and that would fix the issue, and not require direct connection between PEGA2 and the output connector.
But if the PAL is read protected then this path should be fixed with some extra logic chip. There are some SMD single-gate chips with just a couple of pins, something like that could be soldered to the back of the PCB.

Deunan wrote on Yesterday, 20:13:

Picture too bright, but good colors, might be because somebody bumped the G2 pot on the back of the HV transformer inside the monitor. Some of these are very touchy and you can easily go outside the range of the brightness pot with it.

I would try to read that PAL in a programmer. Could be read protected, but maybe not. If it's not then pin 13, even if broken, should not be needed for reading it properly. In that case it can be cloned into GAL16V8 device with some work (to set the mode fuses properly) and that would fix the issue, and not require direct connection between PEGA2 and the output connector.
But if the PAL is read protected then this path should be fixed with some extra logic chip. There are some SMD single-gate chips with just a couple of pins, something like that could be soldered to the back of the PCB.

I will try to read it, but does this chip exist in "database" of T48?
EDIT: no it does not 🙁

There's a few options to read a PAL.

Arduino based dumper
Re: Arduino-based combinatorial PAL dumper

Chip adapter
Re: What's the current status on decoding read-protected registered PAL chips?