Hard to tell. I'd assume it must be something in the RAM interface rather that analogue path or clock, given it forms some sort of regular pattern. I suppose you tried to remove all socketed chips from sockets, clean connector, run it with half of RAM to simplify the problem.

Perhaps you could use a logic probe to identify if there is any stuck data/address bit that remains set/unset all the times. Or try to diagnose those 245 series transceivers. Or try to use multimeter to make sure that DRAM data/address bus is all connected to the controller.

I do have ECS FX-3000 board with ECS slot, but never found a compatible card. So please fix yours as they are rare!

This shuld be a RAM related problem. Reseat the chips and perhaps shuffle them around and see if the artifacts move with that if they still presist. It can help to zone in on the bad chip.

Well, the artifacts in text mode look like local bus data bus bit D8 is broken (stuck high) during font upload. You see broken bright pixel every 4 scan lines, the first one on the second scan line of a character. On the other hand, I don't see any bad text output, which first made me believe that D8 is fine during text output. Thinking more about it, D8 is the "foreground color contains blue" bit, which is set for all characters on screen anyway, so I have no way of knowing whether D8 is broken for character output. To verify my hypothesis that D8 is broken on the path from the CPU to the ET4000AX chip (I'm very confident the issue happens between CPU and ET4000, not between ET4000 and RAM), please run a text mode program that uses blue-less foreground colors. If there is still blue in them (e.g. yellow text looks white, inverted text is darkblue-on-gray instead of black-on-gray) on every second character, this further confirms that hypothesis. At the ET4000AX, D8 and D24 are handled using the same pin, because the ET4000 only has a 16-bit bus interface, so D16-D31 are mapped to D0-D15 using external logic. Furthermore, also A8 (the address bit) is at the same pin of the ET4000 processor. The ET4000 selectes whether it needs to be connected to the address or data bus at any time. A8 and D24 are working, though (otherwise you would get 8 errorneous bright pixels instead of 4 errorneous bright pixels per scan text line (for D24 broken), and blocks of repeated patterns (for A8 broken)). Nevertheless, it might be useful to know that A8/D8/D24 is on pin 56 of the ET4000AX chip. The connection of that ET4000 pin to the bus pins is performed using some of the (74)F244 and (74)F245 chips on the card. I can't fully reverse engineer which chips are used for A8/D8/D24, as I don't have a photo of the back of the card (and I can't look at the traces below the chips). Most likely, pin 2 of U19 is connected to that ET4000 pin. This pin gets forwarded to pin 18 of the same chip in either direction (depending on read/write). So pin 18 of U19 is either local bus D8 or local bus D24 (from the order of the pins at the local bus connector, my bet is on D24). Using a continuity tester, you should be able to find another F245 chip that shares pin 1 with U19, which is supposed to connect the ET4000 to the other data bus pin (which would be D8).

The symptom looks like the trace between D8 on the local bus and the other 74F245 is broken, or that 74F245 itself is broken. Also, you could try a different ECS local bus graphics card to rule out damage on the motherboard (just kidding about having another ECS local bust card at hand, but the issue could indeed be on the motherboard as well as on the card).

EDIT: replaced mistaken "scan line" by "text line" (see strikethrough/italics)

Thanks for the responses guys!

@mkarcher, you seem to be onto something here, I haven't had the time to pull out the card and do any checks, but during a boring work call I ran some tests using VDIAG, the testing software that was included with Tseng cards. And you are in fact correct: yellow text looks white and inverted is dark blue on grey every second character. On graphical modes I get some thin vertical stripes, but the higher the resolution the less noticeable they are.

Later today I will post some more pictures and probe around the card for the connections you mentioned.

Hope it can get fixed, thanks again!

So, here's the connections that I've been able to determine so far:

Looks like U23 would be the chip that handles D8 (at least is connected to the ISA D8 pin, not sure how this works in a local bus configuration), while the ISA A8 is connected to pin 2 of U31. Seems U23 could be a good candidate for removal and testing (and possible replacement) as I don't see any broken traces there...

Also I am attaching a VDIAG screenshot that supports your hypothesis about D8 being stuck.

TheMobRules wrote on 2023-01-06, 22:10:

So, here's the connections that I've been able to determine so far:

VI-811_833_A8D8D24.jpg

Looks like U23 would be the chip that handles D8 (at least is connected to the ISA D8 pin, not sure how this works in a local bus configuration), while the ISA A8 is connected to pin 2 of U31. Seems U23 could be a good candidate for removal and testing (and possible replacement) as I don't see any broken traces there...

I wondered just as you did about the ISA connection, which I first suspected to be used for local bus transfers, too. But then it ocurred to me that possibly that card takes some cycles on ISA, and other cycles on the local bus (e.g. if the ECS local bus can't do I/O cycles): You clearly see two F245 chips handling D16-D31, those are U18 and U19. You also see 16 traces to the local bus connector left to it, all ending on vias near L1. Chances are high these 16 traces are D0 to D15 from the local bus, and connected to the ET4000 through yet another F245, possibly U30 for D8-D15.

Well, I have good news and not-so-good news.

The good news is that the video card is probably fine. First of all, mkarcher you were absolutely right regarding how the data lines are handled. With a multimeter and some patience, I traced all 32 data lines from the ET4000AX chip to the F245 chips and finally to the ECS Local Bus (let's call it ELB) connector: U25/U18 handle D0-D7/D16-D23 while U30/U19 handle D8-D15/D24-D31. All connections were good, so if there was any problem with the card it would be U30.

To confirm these findings and discard issues on the motherboard side, I decided to trace the connections of the data lines from the ELB slot to the 486 CPU socket. And all of them connected directly, just as expected... except for one: D8. There was no continuity between the CPU F-2 pin (D8) to B17 in the ELB slot (which is the pin connected to U30-B0 on the card). So, this is likely the cause of the problem, and again mkarcher you were correct about discarding issues on the motherboard side 😃.

Now, I could have just run a bodge wire between the two pins and called it a day, but I wanted to see exactly where the problem was and try to fix it in a more elegant way. First I tried reflowing the pins on both the CPU socket and the ELB slot, but no change. Then I checked continuity from the D8 pin of the CPU to the 487 socket, and they were connected, so I concluded that the pin and its via were probably OK, no cracked solder joint or anything that would otherwise have isolated it.

So turned my attention to the ELB slot, and noticed there were no traces coming from the B17 pin on the underside, so it had to be on the top side, right? Well, the problem is that the slot itself and a large amount of components were blocking my view. I then decided to desolder the slot and see what was going on there. Luckily, it came out quite cleanly, no torn pads or other damage... but I was disappointed to see that there was no trace on the top side either! Looks like B17 (and a few other data lines) are routed from the slot to the CPU in one of the internal layers! And it looks like the one that connects the D8 line broke at some point.

I've heard stories about boards with VLB or similar long slots would break traces in the inner layers due to the motherboard bending because of the force needed to insert the cards, but it had never happened to me before. Being honest, I only inserted the card a few times and I always make sure the board is properly supported so it doesn't bend. Maybe the trace was already marginal when I got the board from its previous user, so who knows?

In any case, looks like a bodge wire is the only solution (after I resolder the slot), but I am concerned about a couple of things:

• Do I have to keep the wire length limited, considering the board runs at 50MHz FSB? I'm wondering about any possible electrical limitations at that frequency
• Hopefully it's just the trace from the slot to the CPU that broke, and that it doesn't need to go somewhere else (such as a termination resistor or something)

Use thin wire. Do you have motherboard picture posted?

I once had to run long wire bodge to bypass internal broken track on a iphone few years ago to reconnect battery_SWI.

Cheers,

TheMobRules wrote on 2023-01-07, 22:24:

The good news is that the video card is probably fine. First of all, mkarcher you were absolutely right regarding how the data lines are handled. With a multimeter and some patience, I traced all 32 data lines from the ET4000AX chip to the F245 chips and finally to the ECS Local Bus (let's call it ELB) connector: U25/U18 handle D0-D7/D16-D23 while U30/U19 handle D8-D15/D24-D31. All connections were good, so if there was any problem with the card it would be U30.

If you have the pin mapping at hand, I would appreciate a documentation of the ECS local bus pinout, if it is not yet available on the Internet. That's great information to have for diagnosing and fixing further ECS local bus hardware in the future.

TheMobRules wrote on 2023-01-07, 22:24:

First I tried reflowing the pins on both the CPU socket and the ELB slot, but no change.

Good idea! I was about to recommend reflowing the pin on the ELB slot as you mentioned cracks at connections of tracks on inner layers. But as you already did that, this suggestion would be useless.

TheMobRules wrote on 2023-01-07, 22:24:

So turned my attention to the ELB slot, and noticed there were no traces coming from the B17 pin on the underside, so it had to be on the top side, right? Well, the problem is that the slot itself and a large amount of components were blocking my view. I then decided to desolder the slot and see what was going on there. Luckily, it came out quite cleanly, no torn pads or other damage... but I was disappointed to see that there was no trace on the top side either! Looks like B17 (and a few other data lines) are routed from the slot to the CPU in one of the internal layers!

I have an OPTi local bus 486 board, which has 6 or even 8 layers, but on this board, I can see traces on all signal layers, given enough light. On the other hand, I looked at photos of your board on the internet. The second layer from top seems to be a power plane. You clearly see a gap in the plane near the keyboard connector. So it looks like traces in the 2nd and 2nd-to-last plane would be clearly visible on your board. Inner layers would be between the +5V plane and the GND plane, which is atypical. Usually, mainboard manufacturers put GND and VCC as close as possible to get more distributed capacitance. I encourage you to recheck that there is indeed no trace at B17, and you did not accidently mix up pins when turning the board around. At least I sometimes make the mistake of assuming pin positions mirrored to what is correct.

TheMobRules wrote on 2023-01-07, 22:24:

Maybe the trace was already marginal when I got the board from its previous user, so who knows?

That's quite likely. Maybe the copper trace already was cracked, but still making contact just be the two parts touching. Maybe it was a manufacturing defect. I don't think we can find out the root cause with sensible amount of effort.

TheMobRules wrote on 2023-01-07, 22:24:

• Do I have to keep the wire length limited, considering the board runs at 50MHz FSB? I'm wondering about any possible electrical limitations at that frequency
• Hopefully it's just the trace from the slot to the CPU that broke, and that it doesn't need to go somewhere else (such as a termination resistor or something)

The length of the bodge wire is not a problem. Getting the signal from the CPU to the ECS slot takes approximately the same time through a bodge wire as it takes through a trace of the same length. On the other hand, reflections might be an issue. In the worst case, you have two unterminated open-ended trace pieces, one connected to D8 at the ELB slot, and the other one connected to the CPU and chipset. Both of these open end will generate reflections, but at 50MHz with trace length around 6 inch shouldn't be that much of a problem. The 486 local bus is clock synchronous. As long as you get a stable clock signal (reflections would be a disaster on the clock line!), the other signals may ring as much as they like if ringing decays enough before the next rising edge of the clock.

Thinking about it, my theory that I/O cycles might be handled over the ISA bus seems to be true, indeed: D8 is D0 for the bytes at odd addresses. This means that the data values for the CRTC, SEQ and GFX registers would have D0 stuck high. This would yield in an improperly programmed card which would not "work perfectly except for D8". So I/O cycles must be performed through the ISA bus and deliver a proper D8 bit. Furthermore, this means that the FSB/ISA data buffer chip gets a proper D8 bit, so I don't think you have to worry about anything except the ELB slot having no D8. The same is obviously true for memory/cache: If D8 were missing, the system wouldn't boot. Furthermore, after adding the bodge wires, everything that is connected to D8 is again connected to D8, no matter at what side of the break it is. Taking a look at the layout of your board, I expect that running the bodge wire from the CPU socket to the ECS slot will not cause issues.

pentiumspeed wrote on 2023-01-07, 23:57:

Use thin wire. Do you have motherboard picture posted?

The board model was mentioned in the original post. It's https://theretroweb.com/motherboards/s/ecs-sl-486e

Thank you, Wire bodge wire from *nearest* socket or one of nearest chipset pin if you do have datasheet for SiS chipset?

Cheers,

Well, the bodge did the trick! The card is working perfectly again, it passes all VDIAG tests! Kudos to mkarcher for pinpointing the issue with such precision, I tip my hat to you sir.

I still hate having a bodge wire on a board that looks like new but I really can't complain. I'll try and tidy it up later.

mkarcher wrote on 2023-01-08, 00:00:

If you have the pin mapping at hand, I would appreciate a documentation of the ECS local bus pinout, if it is not yet available on the Internet. That's great information to have for diagnosing and fixing further ECS local bus hardware in the future.

Yes, I definitely intend to do this! Currently I have mapped all 32 data pins, plus a few VCC/GND/NC. I still need to work on the address lines and whatever else I can find.

mkarcher wrote on 2023-01-08, 00:00:

I have an OPTi local bus 486 board, which has 6 or even 8 layers, but on this board, I can see traces on all signal layers, given enough light. On the other hand, I looked at photos of your board on the internet. The second layer from top seems to be a power plane. You clearly see a gap in the plane near the keyboard connector. So it looks like traces in the 2nd and 2nd-to-last plane would be clearly visible on your board. Inner layers would be between the +5V plane and the GND plane, which is atypical. Usually, mainboard manufacturers put GND and VCC as close as possible to get more distributed capacitance. I encourage you to recheck that there is indeed no trace at B17, and you did not accidently mix up pins when turning the board around. At least I sometimes make the mistake of assuming pin positions mirrored to what is correct.

I can confirm B17 is indeed the D8 pin and it has no traces on either top or bottom side, tomorrow I will check the board using sunlight to see if I can catch a glimpse of those traces.

I didn't think it was gonna be a connectivity issue on the main bus, very nice catch ~

TheMobRules wrote on 2023-01-08, 00:34:

Yes, I definitely intend to do this! Currently I have mapped all 32 data pins, plus a few VCC/GND/NC. I still need to work on the address lines and whatever else I can find.

Some early local busses only go up to A25 (like the Opti Local Bus) , so don't try for too long to search for high address bits if they appear to be missing. In case of the Opti Local Bus, the EISA connector is used as ISA/Local Bus combination connector, and the lower row if pins just doesnt suffice for all address bits. for the ECS local bus, the add-on MCA-like connector has enough pins for all bits. A simple local bus slot is supposed to have all data bits, a subset of address bits, RDY, ADS, D/C, M/IO, R/W and a pin to claim cycles to the local bus card (called LDEV on VLB). As your chipset doesn't have dedicated local bus support, the LDEV-like signal is most likely connected to the "this is a Weitek 4167 cycle" pin. The 4167 is conceptually just a local bus device like a VL/Opti Local Bus/ECS Local Bus slave, and most early 486 boards provide Weitek support. As I can't find pinouts for the SiS411, I can't give you a hint where to find that pin, though. My Opti Local Bus board has a Weitek socket, and 3 local bus slots, and uses a Quad-AND gate to combine the LDEV outputs of the OLB slots and the Weitek socket, which eases tracing that pin. I'd guess the ELB is not master capable, so no need to find REQ/GNT pins. Also I don't expect that early local bus to have burst / cache support (VLB has, at least technically), so also no need to look for KEN and BRDY.

Thank you for doing this work for the community! And thank you for giving feedback that my troubleshooting hints were helpful.

The last couple of days I've been able to resume the attempt of mapping the ELB pinout. I've been able to identify:

• All data lines (D0-D31)
• All address lines (A2-A31), A20-A23 on the ET4000 chip are grounded and no A24-A31
• Byte enable signals (BE0*-BE3*)
• RDY*
• M/IO*
• ADS*
• D/C*
• W/R*
• +5V, GND, NC

@mkarcher, from your list I still need to find RDY* and the LDEV equivalent, and I have to double check if there are pins in the ELB slot that connect to A20-A31 on the CPU side regardless of only A0-A19 being connected to the ET4000 chip. The pins marked as "NC" are those that are not connected in the card, but I was unable to find whether or not they connect to anything in the motherboard.

By examining the BIOS code, I've determined that this card identifies itself as a Genoa MultimediaVGA. There is apparently an ISA card with the same model name, and the same drivers (both DOS VESA + Win3.1) work perfectly on this one. But I will leave this for a separate post with a more in-depth analysis of the ELB and the performance of this card compared to an ISA equivalent.

Maybe someone can take this and do something fancier than my ASCII ELB slot pinout diagram 😛

1      B    A
2      ------
3  D31 |  1 | GND
4  D30 |  2 | D29
5  GND |  3 | D28
6  D26 |  4 | D27
7  D23 |  5 | GND
8  D21 |  6 | D25
9  +5V |  7 | D24
10 RDY* |  8 | D22
11  D18 |  9 | GND
12  D16 | 10 | D20
13  +5V | 11 | D19
14   NC | 12 | D17
15  D13 | 13 | GND
16   NC | 14 | D15
17  +5V | 15 | D14
18  D11 | 16 | D12
19   D8 | 17 | GND
20   D7 | 18 | D10
21  GND | 19 | D9
22   D4 | 20 | NC
23   D2 | 21 | GND
24   D3 | 22 | D6
25   D1 | 23 | D5
26   D0 | 24 | NC
27  GND | 25 | GND
28  ??? | 26 | NC
29  GND | 27 | GND
30M/IO* | 28 | ADS*
31 D/C* | 29 | GND
32 W/R* | 30 | ???
33  +5V | 31 | ???
34  ??? | 32 | ???
35  ??? | 33 | GND
36  A27 | 34 | A28
37  +5V | 35 | BE1*
38 BE2* | 36 | BE0*
39 BE3* | 37 | GND 
40  A30 | 38 | A31
41  +5V | 39 | A29
42  A25 | 40 | A26
43  A24 | 41 | GND
44  A21 | 42 | A23
45  GND | 43 | A22
46  A19 | 44 | A20
47  A18 | 45 | GND
48      ------
49  +5V | 48 | A17
50  A15 | 49 | A16
51  A14 | 50 | GND
52  A12 | 51 | A13
53  GND | 52 | A11
54   A9 | 53 | A10
55   A8 | 54 | GND
56   A6 | 55 | A7
57  +5V | 56 | A5
58   A3 | 57 | A4
59   A2 | 58 | GND
60      ------

Do you happen to have Tseng 4000AX VLB card by any chance? Finding LDEV should be easy by comparing where pin A49 https://old.pinouts.ru/Slots/VLB_pinout.shtml connects on the VLB card (looking at pictures in https://www.ebay.com/itm/255719525431 it might go to 74LS373 latch and then I lose it) terminates and finding same thing on ECS card. I cant find 4000AX card diagram nor datasheet with documented local bus.

Nice work guys with repairing this card! Sorry for entering this thread with my problem, but i'am unable to solve it myself and it appears you have good knowledge about this Tseng card. I have similar Tseng VLB card with weird problem after resetting PC, please look at my thread on vogons, where is more info. Nobody to this day answered here. Link