Check the signal levels with an analogue scope, if you have one. Sometimes the voltages are not decoded right by these chips, if there are poor solder/wire connections or it could be picking up short spikes/glitches along the signal path. The logic analyzer may show the levels differently than the chip sees, if it is marginal.

Unfortunately I don't have any analogue scope at hand to try that out, only a digital one. In any case, its would be hard to figure out anything without knowing that a certain condition is met, for which a multi-channel device is needed, so thats why I used a logic analyzer.

A simple idea that I had overnight is that I should probe the address lines and check if any of them are stuck high or low. This is however not very indicative if the line is supposed to stay in that state, but I'll check them out anyway.

I did check that there's an activity on the DRAM address lines before, but there are also 74LS374 latches that might have something to do with the fault.

Isopodus wrote on 2025-05-21, 09:27:

Unfortunately I don't have any analogue scope at hand to try that out, only a digital one.

A digital scope is fine. I am quite sure Rwolf just meant to suggest a measurement device that is able to resolve the signal at a higher resolution than just "low" and "high", replacing the binary measurement with a more analogue-like measurement.

I carefully verified your measurement setup, and it seems your setup is perfectly correct, so your logic analyzer trace shows indeed some pattern that is wrong. But there is more wrong to it. The width of the pulses seen on the "B" line is just a single sample (20ns = 0.02µs) of your logic analyzer. OTOH, all the timings on the CGA card are derived from the 14.318MHz oscillator crystal, which has a period of around 70ns! So the signal at "B" changes way too fast. It is likely that the signal is at around the switching threshold of your analyzer, and you are just picking up noise. The signal is not supposed to be at the switching threshold, though! It should be driven low to below 0.8V or high to below 2.0V. If "B" is around 1.6V at that time, it is quite possible that the 74LS245 reads this signal as "high", while your analyzer reads it sometimes as high and sometimes as low. That's why the suggestion to look at the scope waveform of D6 makes a lot of sense.

If I guess the meaning of the four red dots on the tape on U66 correctly, you only observed "invalid" patterns on A5/B5 and A6/B6. So it makes sense to check whether the general impression of the data bits 5 and 6 from RAM looks differently on a scope than all the other data bits. My guess is on the two RAM chips being bad that store bit 5 and bit 6, so they don't ouput a proper "low" level.

If "B" is around 1.6V at that time, it is quite possible that the 74LS245 reads this signal as "high", while your analyzer reads it sometimes as high and sometimes as low

Thanks, I did some more measurements and it turns out it's exactly what happens. I'm not sure how normal this is, but here's that B5 pin of that 74245 chip. Sometimes it falls to zero, sometimes it rises to 4v, and it also does sit right on 1.6v for some time:

I have then verified the other data lines and it looks like the majority of them have this similar behaviour, so could it be it's just the idle high-Z state of that transceiver?

Other than that I have continued by simply probing and testing all the possible chips on the board starting from basic gates and moving to the flip-flops. To keep track of my progress I was first marking them with a sticker, then with an additional green marker on the sticker. The ones with blue marker don't have any faults, but they also don't have enough data on the inputs to prove they are fully operational. I tried to combine this approach with wandering through the schematic to seek for any logical faults, but I mostly came to known good chips or to the chips that are too hard to verify (i.e. RAM or CRTC).

My main idea was that if I test all the ICs then I should definitely find some that behaves wrongly by having its input or output always at LOW or HIGH, since all of them are interconnected. However, after now verifying more than the half of them, it feels like the only ICs that could be bad might indeed be RAM or CRTC (i.e. the ones I planned to leave as the least resort of replacement). I will of course verify all of the chips before replacing the last ones, but by looking at the schematic it feels very disappointing to check the ICs that can not affect the basic POST tests in any way.

Speaking of POST, before probing the board I have also tried to use some custom BIOS ROMs to try booting the card no matter what and proving that RAM is working or not by beep sequences for different errors. For that I have even wrote a custom ROM based on ibmxtbios project which worked fine in emulator, but mostly what I achieved was that the motherboard either doesn't boot at all, or the ROM gives a single long beep for a generic error which is impossible to understand without displaying something on the screen. All of that still worked with the known good card.
I was also thinking about finding and using an MDA card to boot the computer and then hot-plugging the faulty CGA card to poke its memory in DOS debug, but I thought of this as being too risky and low chance of success.

I have also thoroughly verified that there are no visible broken traces or shorts, so that type of fault seems to be unlikely, though I have still tested the traces for continuity in some crucial spots.

I will continue on with testing the leftover ICs, but even if I get to replacing RAM or CRTC - I might end up with a non working card anyway, which would be a bummer, since I don't know where to look next.

Isopodus wrote on 2025-05-22, 15:01:

I have then verified the other data lines and it looks like the majority of them have this similar behaviour, so could it be it's just the idle high-Z state of that transceiver?

It doesn't seem to make sense to have the RAM data line in high-Z state and the ISA '245 enabled driving the ISA bus. On the other hand, that might still be intended operation: If the CGA card enables the '245 driving the ISA bus as soon as /MEMR is asserted on the ISA bus, and then waits for the memory system on the CGA to be ready to handle the memory request, there might be high-Z states of the memory system while the CGA card is waiting. It would be interesting to have IORDY on the logic analyzer as well. The output of the '245 only needs to be stable and represent RAM level while IORDY is high. IORDY is pulled low while the CGA card adds wait-states due to the RAM state machine being not yet ready.

On the other hand, the CGA card is (mostly?) TTL technology. Low-Power Schottky is still TTL, not CMOS. TTL inputs behave like pull-ups, and should be able to pull a line in high-Z state to around 4V, although not necessarily very quick. Nevertheless, an undriven TTL signal is not expected to level off at 1.6V, as it does on your card. To me, this looks like a bus conflict with some output driving the data line low while another output drives it high. Thus I recommend to compare the shape of that signal between the broken and the working CGA card you have. If both cards have this 1.6V step on the data lines, it obviously is intended behaviour. On the other hand, if the signal looks quite different on the other card, you should start to investigate what chips can drive the CGA-internal data bus. If all 8 lines look "bad" on you broken card, but look "good" on your working card, it is unlikely that the issue is caused by a chip that is just receiving on the data bus. While inputs may go short to Vcc or GND, it is really unlikely that all 8 inputs break the same way. On the other hand, if for some reasons to drivers to the data bus are enabled at the same time, the issue obviously will affect all 8 lines at the same time.

Isopodus wrote on 2025-05-22, 15:01:

I was also thinking about finding and using an MDA card to boot the computer and then hot-plugging the faulty CGA card to poke its memory in DOS debug, but I thought of this as being too risky and low chance of success.

I think this is actually a very clever idea! You don't need to find an original MDA card, any late-80s Hercules clone will do as well. As long as you set the DIP switches to "MDA" (or, for AT computers, set the video jumper to mono and choose mono in the BIOS SETUP), the POST is not supposed to access the CGA card at all. Unless the CGA card actively disturbs the ISA bus while it is not addressed, you should be able to boot the system without hot-plugging, so there is low risk. You can then test whether the the CGA card responds to memory and/or I/O cycles using DOS DEBUG running on the MDA-type card.

the POST is not supposed to access the CGA card at all

Ah, yes, I have forgot about that! Then it might be somewhat a better solution.

Thanks for the other tips as well, your assumptions seem very logical. I will probe the working card to see if similar thing is present and then investigate the internal D0-D7 bus again.

So far, speaking of direct effect, only a few ICs are actually connected to those data lines:
1. The 74LS245 transceiver that connects the card and the ISA bus (known good)
2. 74LS174 (U39 and U40) latches that are tested being good too, also they do not drive the bus, only listen to data on it
3. 74LS374 (U37) 3-state latch that drives the bus with the output from RAM (MD0-MD7 bus) (known good)
4. 74LS244 (U36) 3-state buffer that I have somehow skipped in my IC list table (!) and it is not yet tested. It drives the bus when the !WE signal for writing data to RAM is LOW.
5. MC6845 CRTC itself

I'll give it another round of testing and will let you know how it goes. Thanks!

Isopodus wrote on 2025-05-22, 16:03:

3. 74LS374 (U37) 3-state latch that drives the bus with the output from RAM (MD0-MD7 bus) (known good)

You could also add that the output enable signal of that chip to the Logic Analyzer trace (or as a second channel to your scope trace). You shouldn't get into the 1.6V region if the output is enabled on that chip. You could actually try to get the control signals that enable outputting the to CGA internal data bus onto your 16-channel logic analyzer, and check for conflicting control signals. Assuming the theory of a bus conflict is correct, the reason may both be broken chips driving the bus when they are not supposed to or broken control logic enabling two outputs at the same time. I suspect that verifying the shape of the data line signal on the working card is a very sensible first step to establish what way to continue the investigation.

74LS244 (U36) 3-state buffer that I have somehow skipped in my IC list table

I have tested this IC and it turned out working just fine. More than that, I misunderstood how it is wired, and it actually can not drive the bus. Instead it is used to write data to RAM from the internal card bus.

You shouldn't get into the 1.6V region if the output is enabled on that chip

I verified that this is not the case. Also, the working card has same 1.6v resting bus state, so I assume it is completely normal.

You could actually try to get the control signals that enable outputting the to CGA internal data bus onto your 16-channel logic analyzer
I suspect that verifying the shape of the data line signal on the working card is a very sensible first step

That was what I did next. I wrote down all the pins that are in charge of enabling the chips to drive the internal card bus, but here it is a bit unclear as what should the normal state be. Here's a snapshot of this analysis on the working card:

This plot seemed very strange for me, since I expected that only a single IC would be enabled to output data onto the bus at the same time, but looks like its not the case. You can see that 245 is enabled and the direction pin is LOW, meaning the data from the card is coming out to ISA bus. At that time the 374 latch is getting enabled and drives the bus as well as the 6845 R/!W pin is high and !CS is low, meaning the 6845 is selected and is also reading data from its internal registers onto the internal card bus? This seems to be conflicting by itself, unless I don't understand some of the intended logic over there - again, this is a known good CGA card so its intended behaviour. It makes it even harder to understand what is the unintended one...

I have also captured the Enable pin of 6845, which is most likely derived from the clock. Through the datasheet if wasn't exactly clear if it should be used together with !CS. I did a basic test by setting a trigger condition of the logic analyzer and it did not find any case where EN is getting high while !CS is low, so I assume they are unrelated. It looks like EN is instead used when the R/!W pin is being low, meaning when the data is written to internal registers.

Thanks for the suggestions and please let me know if you have any other ideas on that topic.

Best regards

Isopodus wrote on 2025-05-25, 20:25:

74LS244 (U36) 3-state buffer that I have somehow skipped in my IC list table

I have tested this IC and it turned out working just fine. More than that, I misunderstood how it is wired, and it actually can not drive the bus. Instead it is used to write data to RAM from the internal card bus.

Yeah, if you read the original IBM schematic, that one is tricky, because it violates the "left-to-right flow" conventions. U36 is drawn with the outputs left and the input right. I just checked the "redrawn" schematics: They use exactly the same layout as the original IBM ones, it's just better quality than the scan. So it contains the same trap.

Isopodus wrote on 2025-05-25, 20:25:

This plot seemed very strange for me, since I expected that only a single IC would be enabled to output data onto the bus at the same time, but looks like its not the case. You can see that 245 is enabled and the direction pin is LOW, meaning the data from the card is coming out to ISA bus.

This is expected for a read cycle from the card targetting the ISA bus.

Isopodus wrote on 2025-05-25, 20:25:

At that time the 374 latch is getting enabled and drives the bus

Which is expected during ISA reads from video memory.

Isopodus wrote on 2025-05-25, 20:25:

as well as the 6845 R/!W pin is high and !CS is low, meaning the 6845 is selected and is also reading data from its internal registers onto the internal card bus?

[...]

I have also captured the Enable pin of 6845, which is most likely derived from the clock. Through the datasheet if wasn't exactly clear if it should be used together with !CS. I did a basic test by setting a trigger condition of the logic analyzer and it did not find any case where EN is getting high while !CS is low, so I assume they are unrelated.

That assumption is wrong. Maybe your measurement did not include any 6845 I/O access? You should have regular port write access to the 6845 if the cursor moves in text mode, so I don't know what went wrong here. The datasheet at https://bitsavers.trailing-edge.com/component … Sheets/6845.pdf tries to indicate in figure 2 that for a read or write to happen, E needs to be high, and !CS needs to be low the whole time E is high. !CS requires a setup time before the rising edge of E, and must stay constant (i.e. low) until some hold time after the falling edge of E. If there is no pulse on E, there is no bus cycle the 6845 may respond to.

So all in all, this looks like a valid read from CGA video memory. You might be wondering why the 6845 is selected at all. This is because the address decoder (U18 and U30A) just decodes the address lines, not the cycle type. Every address ending in 3D0..3D7, 7D0..7D7, BD0..BD7 or FD0..FD7 will assert the chip select signal to the 6845. The qualification for I/O cycles is performed using the E signal. The "this is I/O" signal is generated by U15C, which is then synchronized to the IO clock (whatever that is) using U11B.

So let's recap where we currently stand at: We know that the 1.6V level on the data bus is likely not a defect. Your interpretation of the chip enable situation during a CGA memory read to a memory address that looks similar to the I/O address of the CRTC was wrong, your logic diagram does not show an invalid state. Furthermore, as the 1.6V level is "normal", we don't have an indication of a bus conflict on the CGA at all, so basically we have to start from scratch. While "modern" BIOSes (AMI/Award 286-like ones) just check for basic CRTC and video memory read/write, the IBM 5150 POST is more intricate. See page 202 of https://bitsavers.org/pdf/ibm/pc/pc/6025008_P … rence_Aug81.pdf (TEST.08): This code does the following things:

• It sets mode 1 for CGA 40x25, and mode 3 for CGA 80x25. It sets "mode 0" for MDA, but in MDA mode, the IBM INT10 handler just ignores the mode number.
• It then blanks video by setting the mode control register to 0 (CGA) or 1 (MDA) (out at E392)
• It performs a RAM test on 4K of MDA RAM or 16K of CGA RAM, and beeps if it fails.
• It then tests the status register, bits 3 and 0 (bit 3 first). On CGA, that's the "video enable" and the "horizontal sync" bit, while on MDA, it's the "video output monitor" and the "horizontal sync" bit. To produce a video output level thats visible (for the MDA that monitors the video output signal), some inverted spaces are put into the text mode buffer. Both bits needs to be toggling, otherwise label E17 will call the beep procedure.
• The DIP-selected video mode gets re-initialized.

There actually is no CRTC read test, like on later BIOSes. If we get beeps, either the video card fails the RAM test, or it fails the status register test. The status bits are transferred via U24E..H, and its enable pin (19) is fully decoded, i.e. it does no false triggers on similar memory addresses. You should be able to see the status register polling with the working card (if a 5150 POST is executed), and you can use the status register polling as indication for the broken card: If you see that polling before the beep, the status register test fails; if you see that polling after the beep, the memory test fails.

That assumption is wrong. Maybe your measurement did not include any 6845 I/O access?

I did set the analyzer trigger for this condition: on 6845 EN rising edge while R/!W = HIGH and !CS = LOW. No trigger occurred during boot with a working card - as if BIOS didn't try to read anything from 6845.
I have only seen EN being high with !CS low when R/!W is LOW, meaning on a write cycle to 6845.

The IBM 5150 POST is more intricate

I dug pretty deep into the BIOS POST procedure before even trying to test any chips. First of all, this is an IBM5155, not 5150, so I used a different brochure, even though the approaches are all the same: https://minuszerodegrees.net/manuals/IBM/IBM_ … 80089_MAR86.pdf.
The video test routine takes place on page 267, the BIOS version installed in my machine is the 1982 revision.

It first checks the video RAM (line 693) and then (as far as I understand) displays a horizontal bar of blanks on the screen to check if video enable and hsync signals are present when the card is displaying something. I did probe VSYNC and HSYNC lines and they aren't toggling at all for the broken card, so I knew it either fails to initialize CRTC or the RAM test fails even earlier.

It then tests the status register, bits 3 and 0 (bit 3 first)

Here is becomes a little confusing to me as of what to check and where. If you say U24 is transferring the status bits 3 and 0, then I should see VSYNC_DLY changing on U24E input. In reality - it never does that on the bad card, because that signal is derived from VSYNC coming from 6845 - and that pin stays silent all the time. I don't remember if DE pin has any activity, but I'd expect both of them to be active to display something. I'll verify the DE again, but if it is silent as well - probably the CRTC is never initialized.

As I understand, the E17 routine is beeping out the error code, after which the initialization is not continued, so it never gets to later CRTC tests if RAM fails. Knowing this, it seems like the problem lies somewhere in the RAM circuitry, similarly to what I was assuming from the very start.

Except for CRTC, RAM and ROM only a few ICs are not tested yet:
1. 273 (U34, U35) - used for character ROM control, so most likely unrelated
2. 166 (U7, U8, U32) - same characters control area
3. 153 (U9, U 10) - same
4 164 (U62) - used as part of final stage of image generation, so probably unrelated as well
5. 151 (U45) - same, final stage
6. 374 (U58-61) - RAM addressing

So all in all, only last 4 374 chips or the RAM ICs could be bad here (in case the RAM test is the one that's failing). Gonna test the latches, then I'll probably need to desolder RAM's one by one and use some simple Arduino setup to test all the bits. If all of that is good - I don't even know that may be bad except for PCB traces.

Thanks again for the suggestions, I will check everything and write back how it went.

Best regards

Isopodus wrote on 2025-05-26, 11:38:

I did set the analyzer trigger for this condition: on 6845 EN rising edge while R/!W = HIGH and !CS = LOW. No trigger occurred during boot with a working card - as if BIOS didn't try to read anything from 6845.
I have only seen EN being high with !CS low when R/!W is LOW, meaning on a write cycle to 6845.

This is fine. I didn't read the INT 10 code again, but AFAIK the only CRTC reads in the INT 10 code are in the lightpen code path, which is not triggered during the POST. Furthermore, the POST itself also only reads 3DA, which is not in the 3D0..3D7 range, so it is not supposed to generate a read cycle to the CRTC. So far, everything seems to behave as intended.

Isopodus wrote on 2025-05-26, 11:38:

It first checks the video RAM (line 693)

Even before that, it initializes the CRTC. While the PC BIOS I referred to only initializes the CRTC indicated by the DIP switches, the XT BIOS you refer to blindly initializes both the MDA/Hercules CRTC in line 650 and then the CGA CRTC in line 654. The DIP selected initialization then follows in line 673.

Isopodus wrote on 2025-05-26, 11:38:

and then (as far as I understand) displays a horizontal bar of blanks on the screen to check if video enable and hsync signals are present when the card is displaying something.

Black-on-gray (inverse) spaces, to be exact. This causes normal intensity pixels to be generated for 40 character clocks per frame by the MDA card. The MDA card mirrors the video signal pin in 3BA, bit 3. For the CGA, these characters are irrelevant, as 3DA, bit 3 is generated from the VSYNC signal instead. So for either card, bit 3 is set for some time of the frame and clear for the remaining time.

Isopodus wrote on 2025-05-26, 11:38:

I did probe VSYNC and HSYNC lines and they aren't toggling at all for the broken card, so I knew it either fails to initialize CRTC or the RAM test fails even earlier.

That must not happen. The CRTC is initialized twice, in line 654 and in line 673. This is even before the RAM test. This means the CRTC does not respond as it is supposed to do, which can have multiple reasons: The CRTC might not get a valid clock. You can check that with a scope or the logic analyzer. It should run at the character clock, which is 14.318MHz/8 if in 80*25 mode or 14.318MHz/16 if in any other mode, eg. 40*25 text. Or the CRTC does not receive its initialization writes, because the decoding logic is faulty. You might want to look at all CRTC writes with the logic analyzer (trigger on E falling edge, !CS low, W/!R high), sample D0..D7 and RS. The third possibility is that the CRTC is broken.

Isopodus wrote on 2025-05-26, 11:38:

As I understand, the E17 routine is beeping out the error code, after which the initialization is not continued, so it never gets to later CRTC tests if RAM fails.

While this is true, the CRTC is already supposed to be initialized even if the jump in line 694 is taken, so "no sync signals" means something around the CRTC fails...

Isopodus wrote on 2025-05-26, 11:38:

Knowing this, it seems like the problem lies somewhere in the RAM circuitry, similarly to what I was assuming from the very start.

... thus I don't think this is the correct conclusion.

Yesterday, before you wrote your message I went down the path of testing all the remaining ICs that could be introducing issues around the RAM, and didn't find anything so I went onto testing the RAM chips themselves. I carefully desoldered the ICs one by one and as I did that I used a simple Arduino sketch for testing the DRAMs. It checks for the data in/out working fine, then looks for any address aliasing and also does a sort of March-C test for all the bits (I have attached the code if anyone ever needs a similar thing). When I almost finished testing all the ICs and the despair was kicking in - turned out the very last 2 RAMs were not working properly! Looks like some of their address lines are damaged and are not pointing to the address they should. I have then verified all the chips one more time to confirm that only the last 2 were bad.

... thus I don't think this is the correct conclusion.

Then I read this and understood that something more might still be wrong with this card. I have tested the VSYNC, HSYNC and DISP_EN pins of 6845 and still didn't see anything while RAM was uninstalled. I have then decided to try fixing the RAM issue first - installed the DIP sockets and put 6 working RAM chips into them. Instead of 2 broken ones I took the 64kb D2164 RAMs from an AST SixPackPlus board and tied the normally disconnected pin 9 of the socket to GND for each - this way grounding the A7 address pin of D2164 and only using 1/4 of the capacity, since thats what I need (I have also tested the new RAM's with the tester and they were good). After turning the machine ON - I still heard the same error beeps and no activity on 6845, as suggested by you, mkarcher.

The CRTC might not get a valid clock. It should run at the character clock, which is 14.318MHz/8 if in 80*25 mode or 14.318MHz/16 if in any other mode, eg. 40*25 text

I hooked up the scope to the CLK pin and measured the frequencies - it first runs at ~895 kHz during startup (probably 40*25 mode by default) and then switches to 1.79 MHz (80*25), after reading the DIP switches state - so the clock signal should be fine.

Or the CRTC does not receive its initialization writes, because the decoding logic is faulty.

This is unlikely, since all the logic ICs that might be used in that area are now tested good. Here's the list of what it looks like at the moment (green are good, blue are not bad, but not enough data to be tested good, pink are unrelated to the problem):

You might want to look at all CRTC writes with the logic analyzer

I can do that, but I'm not sure what to look for - unless I dig into the datasheet really hard to see a sequence that's needed to enable the thing and start generating sync pulses.

At this point - I can see 2 main reasons for a failure - something that uses VSYNC/HSYNC/DISPEN signals as an input is holding them LOW because that something is bad, or the CRTC is bad. Speaking of V/HSYNC - only the U21 174 can be an issue.

Thanks for the tips, I'll do some more investigation.

Best regards

Isopodus wrote on 2025-05-27, 13:45:

I hooked up the scope to the CLK pin and measured the frequencies - it first runs at ~895 kHz during startup (probably 40*25 mode by default) and then switches to 1.79 MHz (80*25), after reading the DIP switches state - so the clock signal should be fine.

I agree. This also confirms that mode register writes likely work correctly. At least the high-resolution bit D0 correctly ends up in the mode register.

Isopodus wrote on 2025-05-27, 13:45:

Or the CRTC does not receive its initialization writes, because the decoding logic is faulty.

This is unlikely, since all the logic ICs that might be used in that area are now tested good.

You should be aware that not only ICs can be faulty, but you can also have broken traces, so a signal gets lost before it reaches the target IC.

Isopodus wrote on 2025-05-27, 13:45:

You might want to look at all CRTC writes with the logic analyzer

I can do that, but I'm not sure what to look for - unless I dig into the datasheet really hard to see a sequence that's needed to enable the thing and start generating sync pulses.

Basically, you should see the BIOS write the values from the video mode parameter table into the CRTC registers. So you expect a sequence like

• RS=0, data = 0x00, then RS=1, data = 0x38
• RS=0, data = 0x01, then RS=1, data = 0x28
• RS=0, data = 0x02, then RS=1, data = 0x2D
• RS=0, data = 0x03, then RS=1, data = 0x0A
• RS=0, data = 0x04, then RS=1, data = 0x1F
• RS=0, data = 0x05, then RS=1, data = 0x06
• RS=0, data = 0x06, then RS=1, data = 0x19
• RS=0, data = 0x07, then RS=1, data = 0x1C
• RS=0, data = 0x08, then RS=1, data = 0x02
• RS=0, data = 0x09, then RS=1, data = 0x07
• RS=0, data = 0x0A, then RS=1, data = 0x06
• RS=0, data = 0x0B, then RS=1, data = 0x07
• RS=0, data = 0x0C, then RS=1, data = 0x00
• RS=0, data = 0x0D, then RS=1, data = 0x00
• RS=0, data = 0x0E, then RS=1, data = 0x00
• RS=0, data = 0x0F, then RS=1, data = 0x00

for the initialization of the 40x25 text mode. For the 80x25 text mode, just the first three values differ, they are supposed to be 0x71, 0x50, 0x5A instead.

Isopodus wrote on 2025-05-27, 13:45:

At this point - I can see 2 main reasons for a failure - something that uses VSYNC/HSYNC/DISPEN signals as an input is holding them LOW because that something is bad, or the CRTC is bad. Speaking of V/HSYNC - only the U21 174 can be an issue.

Do you get anything from the CRTC? The CRTC is also supposed to generate video memory addresses, that are buffered by U58/U59. If the CRTC is not initialized, the "SYNC" position might exceed the "TOTAL" number of characters / text lines, which might prevent generation of SYNC pulses. Furthermore the datasheet claims that DISPEN is only valid after "the first frame has been displayed". I'm unsure whether an uninitialized CRTC that has SYNC > TOTAL ever finishes the first frame for this purpose.

So until you verified that sensible CRTC intialization data arrives at the CRTC pins, both "bad/missing initialization" and "CRTC bad" are still possible, in my oppinion.

So you expect a sequence like

Thanks a ton, thats very useful! First of all I did a small test and found out that there's absolutely no output from the 6845 address lines. Only MD0 stays high all the time, all the other ones are LOW, as well as RA0-RA3. Basically all the outputs are not doing anything.

I hooked up the logic analyzer to the internal data bus and then also verified that there are no broken traces from the point where I measure up to the 6845. I enabled the "Simple Parallel" analyzer extension and used R/W, CS and RS as part of my measurement (since there were no default way to filter data) (see config screenshot). I then did a capture up to the error beep and searched for 0x0000 data i.e. all lines LOW on E rising edge and found 3 places where the address register zero is set. You can see 3 markers where the 0x0000 happens time wise.

I then followed the initialization sequences and wrote down the data I saw being written to 6845:

Here I colored them green where matching your sequence, and yellow where not matching. This is the 80*25 mode.

Speaking of control logic, it seems that R/W, CS, RS and E pins are activated as intended, more than that - we can see that the very last sequence is exactly what you wrote, so I'd assume that everything should work.
Also, keep in mind that with this many channels I can only run the analyzer at 25 MS/s, so 40ns is the smallest pulse it can capture, i.e. read mistakes might be present. I did run the test again and for second sequence the faulty 0x3F at address 0x02 was properly read as 0x5A, making sequences 2 and 3 identical - as would be expected for initializing the CRTC before and after POST. I'm not sure about sequence 1, but I can't say I'm concerned about it since there may be some more initialization steps beforehand.

Now to the most interesting test: how does that look on the working card? Short answer - absolutely the same! All 3 sequences are identical, meaning the very first one is also something to be expected.
Overall we can see that the data is coming into the CRTC but does not come out of it in any way - being address or sync pulses. I have compared the MA0 line of the working card, and it shows activity almost from the very start, while for the broken card it is always in high state. All the other MA lines are held LOW. Knowing that the in and out traces from CRTC are good, we either have the bad CRTC or bad 374 at U58 and U59 that are holding the lines in constant states.

Starting from here it seems like it doesn't make much sense to check that both 374 were bad, but just to be sure I have desoldered U59 and confirmed that MA0 is still held HIGH all the time. Also the 374 was tested being good with a logic tester.

Speaking of other inputs to 6845 - RESET is held HIGH as it should, CLK is known good and LPSTB should be unrelated here. Can we conclude that CRTC is bad, or is there something else that might be unknown, such as excess writes after initialization that are breaking the config and not letting the memory addresses to be generated properly?

Thanks!

Best regards

Isopodus wrote on 2025-05-28, 13:38:

Here I colored them green where matching your sequence, and yellow where not matching. This is the 80*25 mode.

Speaking of control logic, it seems that R/W, CS, RS and E pins are activated as intended, more than that - we can see that the very last sequence is exactly what you wrote, so I'd assume that everything should work.
Also, keep in mind that with this many channels I can only run the analyzer at 25 MS/s, so 40ns is the smallest pulse it can capture, i.e. read mistakes might be present. I did run the test again and for second sequence the faulty 0x3F at address 0x02 was properly read as 0x5A, making sequences 2 and 3 identical - as would be expected for initializing the CRTC before and after POST. I'm not sure about sequence 1, but I can't say I'm concerned about it since there may be some more initialization steps beforehand.

The first sequence is the initialization sequence for the CRTC on an MDA card! Assuming the BIOS isn't buggy, that sequence is supposed to be sent to I/O ports 3B4/3B5, not 3D4/3D5. U18 is supposed to not drive its output O7 low if 3B4/3B5 is accessed, so you shouldn't get /6845_CS asserted during the MDA initialization sequence. Practically, it doesn't matter, because even if the MDA initialization ends up in the CGA CRTC, it is promptly overwritten by the correct CGA initialization.

Isopodus wrote on 2025-05-28, 13:38:

Now to the most interesting test: how does that look on the working card? Short answer - absolutely the same! All 3 sequences are identical, meaning the very first one is also something to be expected.

Which might point to a BIOS bug. If I remember correctly, the link you shared contained the listing of the IBM XT 5160 BIOS, while you are using a 5155. I'm unsure whether the BIOSes are identical, but I expect at least the model byte near the end to be different between the 5155 and the 5160. The idea of the primary video initialization looks fine: They set the configuration byte (which is usually a copy of the DIP switches) to indicate "MDA installed" first, then use INT 10 to reset/initialize the video system, then set the configuration byte to "CGA in 80 character mode installed" and again use INT 10 to reset/initialize the video system. I skipped checking the BIOS, but AFAIK the BIOS is supposed to update the CRTC base address in the BIOS data area to 3B4 or 3D4 depending on the configuration byte, making sure that the MDA initialization sequence is sent to 3B4 instead of 3D4.

Isopodus wrote on 2025-05-28, 13:38:

Overall we can see that the data is coming into the CRTC but does not come out of it in any way - being address or sync pulses. I have compared the MA0 line of the working card, and it shows activity almost from the very start, while for the broken card it is always in high state. All the other MA lines are held LOW. Knowing that the in and out traces from CRTC are good, we either have the bad CRTC or bad 374 at U58 and U59 that are holding the lines in constant states.

Starting from here it seems like it doesn't make much sense to check that both 374 were bad, but just to be sure I have desoldered U59 and confirmed that MA0 is still held HIGH all the time. Also the 374 was tested being good with a logic tester.

Speaking of other inputs to 6845 - RESET is held HIGH as it should, CLK is known good and LPSTB should be unrelated here. Can we conclude that CRTC is bad?

I tend to agree that it looks very much like the issue is narrowed down to a non-functional CRTC chip. I recommend to check that the power supply pins of the CRTC are actually connected to +5V and GND before concluding that the CRTC is bad, but after that final check, I don't see how anything except a broken CRTC chip is able to cause the issue. The CRTC is supposed to count all the time if it receives a clock and RESET is high. Maybe it's counting in strange ways if the register setup is bad, but it still should count. If the CRTC doesn't count (which is visible on the addres output pins), something is clearly wrong.