Further info that I forgot:

This card doesn't have a WB cache compatibility jumper (J5 is unpopulated and not hard jumpered)

I'm using an ATX PSU with an adapter. There's no -5V rail but nothing else in the computer seems to care and presumably I wouldn't have gotten this far if it was needed?

I re-capped the motherboard already when I first got it. The VLB riser has three through hole electrolytics. I replaced 2 out of 3 as that's what I had on hand at the time. I since bought more so on the off chance, I'll change the final cap tomorrow.

I would focus on the parity error first. Have you tried with a different set of RAM sticks? Maybe the VLB BIOS is copied to some RAM address range that remains unused when you run the ISA card.

Could it be the extra vlb slot(s) on the riser and the use of the SCSI card in that extra slot is driving the vl bus too hard?

The vesa bus is connected directly to the processor and it was always a little bit flaky. It was incredibly rare to see a motherboard with more than 3 slots, and even then it was really quite picky. Perhaps there is simply too much loaded on it for that particular implementation in your Dell.

(if you hadn't tested without it) I might have suspected the cache card, but yours seems to have the Dell-approved layout for additional vlb card use.

The 284x does seem quite sensitive though...have you tried anything here - https://storage.microsemi.com/en-us/support/_ … ng_aha-2840.htm

Try lowering the mainboard clock speed from 33 to whatever lowest your mainboard allows to see if that offers any improvement.

Looking at the garbled characters, you see one garbage character per four characters, that is one byte out of 32 bits. Assuming the data buffer used for SCSI identification is aligned, the broken characters appear at the second byte of each 4-byte group. Also, the memory parity error has an address pointing to the second byte of a 32-bit word. This stuff definitely seems related.

Memory parity is calculated by the mainboard. The VLB slot does not have parity information, so when a VL bus master writes into memory, the chipset has to calculate and write the parity as well as the data. In your example, it looks like the data is not written to RAM, and the contents of the byte before the Adapter tried bus-mastering is still present. The patterns don't look like a single bit is flaky, but the entire but is wrong. On the other hand, you are getting parity errors on the affected bytes, so it seems that either some changes do happen to the data byte, or the parity bit at least is written. Possibly, the actual issue is on the RAM side, not on the VL adapter side. VL master cycles and host CPU cycles might have slightly different RAM timings, causing improper writing if something is marginal. Try cleaning the contacts of the RAM, or using a different memory stick.

The oily residue after using DeoxIT is likely a feature, not a bug. It is common for contact deoxidization agents that they leave a thin oily film behind that prevents contact of the contact with oxygen from the air, so the contacts do not corrode as easily as without that film. As corroded contacts are often a consequence of an originally present anti-corrosion coating (like gold plating) being damaged, replacing that layer with the the oil film is not an entirely stupid ideas.

Thanks everyone for the replies. There were a lot of things mentioned here that I didn't consider. Very interesting about every fourth character being corrupt. I hadn't noticed the pattern.
So I've tried a lot more today.

*I swapped the RAM out with some regular non-parity RAM. All known tested and working. - Result: No change
*The SCSI BIOS has a parity option which I tried switching off - Result: No change
*I lowered the FSB down to 25MHz - Result: No change
*The motherboard has an undocumented 20MHz mode but it's unstable. I think the ISA bus goes out of spec or it's actually 40MHz but the BIOS reports 20MHz. It fails to boot even without the VLB card in so I've no way of knowing what's actually going on with it.
*I swapped in a 486DX 33 and ran it at 25MHz - Result: No change
*The motherboard BIOS has the option of setting I/O wait states from 0,1,3,7 (default 0). I tried them all. - Result: No change
*The cache card occupies a VLB slot so I removed it and installed the SCSI card there. - Result: No change. This also rules out the slot as I know it works with the cache card.
*Disabled integrated VLB video, used an ISA Cirrus Logic card as well as removed the cache card and tried the SCSI in both VLB slots (ie. the VLB SCSI card was the only VLB device present) - Result: No change
*Tried worst/slowest case scenario: 25MHz 486DX, wait state 7, ISA video, no cache - Result: No change
*I have an entirely separate identical motherboard and ISA riser (Note: older BIOS version. My main board has the latest). I tried pretty much all of the above tests on it to. - Result: No Change.

Something to note is that the card became increasingly flaky, especially after moving it from one system to another and then back again. 9 out of 10 times it now says host adapter not found so it seems the ISA portion is working no matter what but the VLB connection might not be? Leaving the computer off for a minute and switching it back on usually revives it. I highly doubt anything wrong with either motherboard or the risers. I'm really suspecting something is up with the card (even if it could also simply be incompatible). The capacitors on the card are most likely original but they look/smell fine. I am not going to replace them on the off chance one or more has failed on a card I could then not get my money back on.

b_riera wrote on 2024-03-17, 17:46:

Something to note is that the card became increasingly flaky, especially after moving it from one system to another and then back again. 9 out of 10 times it now says host adapter not found so it seems the ISA portion is working no matter what but the VLB connection might not be?

What do you mean by "moving it from one system to another"? This thread reads like you have just one VLB machine, the Dell Optiplex 486. If you have another system: Does the card show the same symptoms in the other system?

b_riera wrote on 2024-03-17, 17:46:

The capacitors on the card are most likely original but they look/smell fine. I am not going to replace them on the off chance one or more has failed on a card I could then not get my money back on.

This doesn't look like an electrolytic capacitor problem. The small caps next to each chip should be good enough to buffer the chip operating voltage. The primary suspect chip regarding your problem is U22, which is used to send the second byte of a 32-bit-word to the computer (either the CPU or memory). You might want to closely inspect the soldering of that chip, especially the connections in the corners: Pin 1 is used to enable the chip sending the data to the VL bus, Pin 10 is ground, Pin 11 is used to have the chip memorize the data to send to the VL bus and Pin 20 is Vcc. All the other pins of that chip affect only single bits and are very unlikely the cause of your issue. These pins should be interconnected between U20 to U23.

Another signal that might be related to your issue is BE1, which is on the VL slot on the component side on the fifth contact to the right of the break, i.e. very close to the "write-back jumper". I buzzed out on my copy of the card that this pin is connected to U10, Pin 6 and U13, Pin 13. When counting pins on U9..U13, keep in mid that PLCC chips have pin 1 in the center of the wedged edge, and then count counter-clockwise. So pin 1 is in their left edge, the bottom left corner is between pins 4 and 5, and the bottom right corner is between pins 11 and 12.

Your issue may also be a defect on the main board: If some component is errorneously trying to output a byte to data bits 8..15 while VL bus mastering is in progress, this could cause a bus collision. If the problem only surfaces on VL master cycles, you have a hard time diagnosing it without having another VL master card at hand (which you obviously don't...)

mkarcher wrote on 2024-03-17, 18:37:

What do you mean by "moving it from one system to another"? This thread reads like you have just one VLB machine, the Dell Optiplex 486. If you have another system: Does the card show the same symptoms in the other system?

I have three of these Optiplex motherboards and their accompanying risers along with a number of CPUs and plenty of RAM (Two motherboards are identical and one is an older revision that doesn't support the VLB riser so I can't test the VLB SCSI card with that). Different BIOS versions but results are the exact same having tried all the same testing steps with both.

mkarcher wrote on 2024-03-17, 18:37:

Your issue may also be a defect on the main board: If some component is errorneously trying to output a byte to data bits 8..15 while VL bus mastering is in progress, this could cause a bus collision. If the problem only surfaces on VL master cycles, you have a hard time diagnosing it without having another VL master card at hand (which you obviously don't...)

My knowledge doesn't go as far as yours here clearly. In my test with just the SCSI card being the only thing connected via VLB (that is, the VLB video disabled and cache card removed), would this have not ruled that out or are you suggesting something else connected directly to the bus (the chipset itself?). I did all these tests with the sound card and NIC removed as well as the internal IDE disabled as I don't use it.

I might see if I can find something VLB that's cheap enough to test with (not very likely these days). Although, there are a few relatively cheap ($50 or under) no name SCSI cards online that when I look up the controller chip on them, I can determine if they support DMA or not. I'm going to assume this is enough to determine if a card with do bus mastering on the VLB? The stuff I'm reading online is a bit unclear. EIDE cards are very expensive so I'm not willing to buy one of those just to play with without an intention of using it.

Seeing as I have tested this card using two identical motherboards, it's not a perfect test but it does rule out something broken on the motherboard. The one thing I just can't prove right now is that it's not a design defect on the motherboard. If it were then the VLB slots would only useful for a video card or plain controller cards (not necessary on a computer with everything integrated). Not out of the realm of possibility although it would be a rather glaring problem in the design/the chipset to put these motherboards into production.

I also highly doubt a capacitor problem as it doesn't show the usual signs. I'm just not going to test that theory on a card I could return.

b_riera wrote on 2024-03-17, 19:32:

mkarcher wrote on 2024-03-17, 18:37:

Your issue may also be a defect on the main board: If some component is errorneously trying to output a byte to data bits 8..15 while VL bus mastering is in progress, this could cause a bus collision. If the problem only surfaces on VL master cycles, you have a hard time diagnosing it without having another VL master card at hand (which you obviously don't...)

My knowledge doesn't go as far as yours here clearly. In my test with just the SCSI card being the only thing connected via VLB (that is, the VLB video disabled and cache card removed), would this have not ruled that out or are you suggesting something else connected directly to the bus (the chipset itself?).

Exactly. The things connected to the front-side bus include the processor, the L2 cache, the RAM and the chipset, including the ISA bridge that can forward ISA DMA data. Sometimes, the cache and/or the RAM is connected via buffer chips, and there might be issues with the control logic for the buffer chips.

b_riera wrote on 2024-03-17, 19:32:

I might see if I can find something VLB that's cheap enough to test with (not very likely these days). Although, there are a few relatively cheap ($50 or under) no name SCSI cards online that when I look up the controller chip on them, I can determine if they support DMA or not. I'm going to assume this is enough to determine if a card with do bus mastering on the VLB?

That's correct. There is no mainboard-controlled DMA for VL (the same is true for PCI, by the way), so every PCI or VL card that uses DMA to access memory (and it's not just using ISA DMA on a VL card) uses bus mastering.

b_riera wrote on 2024-03-17, 19:32:

The stuff I'm reading online is a bit unclear. EIDE cards are very expensive so I'm not willing to buy one of those just to play with without an intention of using it.

I've had my hands on a lot of EIDE VL adapters. None of them could do busmaster DMA. One of them (IIRC with a Promise 20630 chip) claimed "DMA support", but this only applies to the transfer between the drive and the controller (which looks like IDE DMA to the drive). The data transfer between the controller and the host CPU is still performed using PIO. Buying a VL IDE controller does not help you diagnosing this issue, and in my oppinion, they are overhyped anyway. In the 486 days, we lived with 8MB of RAM, which can be completely filled from disk using ISA PIO controllers in less then 8 seconds. Games were running entirely from RAM, so a slow IDE controller was just prolonging load times a little, but not causing stuttering gameplay.

Things started to get different with full-motion video streaming from a CD or the hard disk. In that case, CPU time spent on transferring data from an IDE device to the CPU started to get importent.

b_riera wrote on 2024-03-17, 19:32:

Seeing as I have tested this card using two identical motherboards, it's not a perfect test but it does rule out something broken on the motherboard. The one thing I just can't prove right now is that it's not a design defect on the motherboard. If it were then the VLB slots would only useful for a video card or plain controller cards (not necessary on a computer with everything integrated).

Very good way of thinking. Indeed, there were VL slots without bus master support, but your slot seems master capable. A target-only slot would never signal "bus granted" to the card, so the controller would just hang, waiting for a bus grant (this claim is backed by experience). I severely doubt there is a design issue on your board affecting only one of the four bytes in the 32 bit memory system, so I agree that a broken card is the most likely cause.

b_riera wrote on 2024-03-17, 17:46:

Thanks everyone for the replies. There were a lot of things mentioned here that I didn't consider. Very interesting about every […]
Show full quote

Thanks everyone for the replies. There were a lot of things mentioned here that I didn't consider. Very interesting about every fourth character being corrupt. I hadn't noticed the pattern.
So I've tried a lot more today.

*I swapped the RAM out with some regular non-parity RAM. All known tested and working. - Result: No change
*The SCSI BIOS has a parity option which I tried switching off - Result: No change
*I lowered the FSB down to 25MHz - Result: No change
*The motherboard has an undocumented 20MHz mode but it's unstable. I think the ISA bus goes out of spec or it's actually 40MHz but the BIOS reports 20MHz. It fails to boot even without the VLB card in so I've no way of knowing what's actually going on with it.
*I swapped in a 486DX 33 and ran it at 25MHz - Result: No change
*The motherboard BIOS has the option of setting I/O wait states from 0,1,3,7 (default 0). I tried them all. - Result: No change
*The cache card occupies a VLB slot so I removed it and installed the SCSI card there. - Result: No change. This also rules out the slot as I know it works with the cache card.
*Disabled integrated VLB video, used an ISA Cirrus Logic card as well as removed the cache card and tried the SCSI in both VLB slots (ie. the VLB SCSI card was the only VLB device present) - Result: No change
*Tried worst/slowest case scenario: 25MHz 486DX, wait state 7, ISA video, no cache - Result: No change
*I have an entirely separate identical motherboard and ISA riser (Note: older BIOS version. My main board has the latest). I tried pretty much all of the above tests on it to. - Result: No Change.

Something to note is that the card became increasingly flaky, especially after moving it from one system to another and then back again. 9 out of 10 times it now says host adapter not found so it seems the ISA portion is working no matter what but the VLB connection might not be? Leaving the computer off for a minute and switching it back on usually revives it. I highly doubt anything wrong with either motherboard or the risers. I'm really suspecting something is up with the card (even if it could also simply be incompatible). The capacitors on the card are most likely original but they look/smell fine. I am not going to replace them on the off chance one or more has failed on a card I could then not get my money back on.

I think the second slot (where the cache card goes in) is NOT a normal Vesa Local Bus slot, it is more likely reserved for only the cache card. I would not expect that any Vesa Local Bus card works in that slot. That is a minor comment, not really important.
Second minor comment, why you wrote in the heading AHA-2840VL, it is clearly a 2842VL, just look on the sticker on the Bios.

OK, but now to the problem.... When you tried already different RAM.
I now guess, that this Vesa Local Bus slot is not a bus master slot. So only passive cards, like VLB graphics card will work in that slot. I had a similar Dell system in the past, but it had only ISA slots on the riser. So it is likely that there are severe limitations on the Vesa Local Bus slot of the riser. Just guessing though.
The only way to to check is indeed to use another Vesa Local Bus mainboard, which has (for sure) bus master capable slots. But I agree just for that test to buy an (probably) expensive board is not really a good option.
EDIT: Some typos corrected.

mkarcher wrote on 2024-03-17, 20:09:

.....
Very good way of thinking. Indeed, there were VL slots without bus master support, but your slot seems master capable. A target-only slot would never signal "bus granted" to the card, so the controller would just hang, waiting for a bus grant (this claim is backed by experience). I severely doubt there is a design issue on your board affecting only one of the four bytes in the 32 bit memory system, so I agree that a broken card is the most likely cause.

I am not 100% convinced. The controller does not hang, but the boot process does not go very far ahead ....
But yes, controller card might be broken.

mkarcher wrote on 2024-03-17, 18:37:

The primary suspect chip regarding your problem is U22, which is used to send the second byte of a 32-bit-word to the computer (either the CPU or memory). You might want to closely inspect the soldering of that chip, especially the connections in the corners: Pin 1 is used to enable the chip sending the data to the VL bus, Pin 10 is ground, Pin 11 is used to have the chip memorize the data to send to the VL bus and Pin 20 is Vcc. All the other pins of that chip affect only single bits and are very unlikely the cause of your issue. These pins should be interconnected between U20 to U23.

Another signal that might be related to your issue is BE1, which is on the VL slot on the component side on the fifth contact to the right of the break, i.e. very close to the "write-back jumper". I buzzed out on my copy of the card that this pin is connected to U10, Pin 6 and U13, Pin 13. When counting pins on U9..U13, keep in mid that PLCC chips have pin 1 in the center of the wedged edge, and then count counter-clockwise. So pin 1 is in their left edge, the bottom left corner is between pins 4 and 5, and the bottom right corner is between pins 11 and 12.

Well I wasn't expecting someone with the same card to be looking at this. This is incredibly helpful.
So I've toned out U20 and it seems like each pin is good. I just toned them out to where I could see the nearest via or connection to another chip. I also checked the BE1 pin on the edge connector. The PLCC chip pinout is certainly confusing but I'm pretty sure I got it. This also checks out ok.

While I had it under my magnifying glass/ring light, I noticed C22 is missing. There definitely was a capacitor here. It's not just a blank pad. Clearly torn off. Any idea of it's value? I've got a lot of through hole ceramics. I probably have it or something close enough I can bodge it with.

edit: forgot image link

CoffeeOne wrote on 2024-03-17, 20:44:

Second minor comment, why you wrote in the heading AHA-2840VL, it is clearly a 2842VL, just look on the sticker on the Bios.

I just looked at the silk screening on the card and never actually looked at the BIOS chip!

CoffeeOne wrote on 2024-03-17, 20:57:

I am not 100% convinced. The controller does not hang, but the boot process does not go very far ahead ....
But yes, controller card might be broken.

The controller is able to write 75% of the SCSI identifiers (the INQUIRY response) into main memory. This means bus mastering is at least kind of working.

b_riera wrote on 2024-03-17, 21:08:

CoffeeOne wrote on 2024-03-17, 20:44:

Second minor comment, why you wrote in the heading AHA-2840VL, it is clearly a 2842VL, just look on the sticker on the Bios.

I just looked at the silk screening on the card and never actually looked at the BIOS chip!

I don't think the 2840VL and the 2842VL use a different BIOS. The sticker on the BIOS does not say anything about the controller type. You likely refer to the sticker on the AIC 7770 next to the BIOS, which indeed says 2842VL. The only difference between those cards is that the 2842VL has an ISA-connected floppy controller, which is not populated on the 2840VL. The floppy controller is handled by the mainboard BIOS, that's why the SCSI BIOS is identical on both variants.

mkarcher wrote on 2024-03-17, 21:14:

b_riera wrote on 2024-03-17, 21:08:

CoffeeOne wrote on 2024-03-17, 20:44:

Second minor comment, why you wrote in the heading AHA-2840VL, it is clearly a 2842VL, just look on the sticker on the Bios.

I just looked at the silk screening on the card and never actually looked at the BIOS chip!

I don't think the 2840VL and the 2842VL use a different BIOS. The sticker on the BIOS does not say anything about the controller type. You likely refer to the sticker on the AIC 7770 next to the BIOS, which indeed says 2842VL. The only difference between those cards is that the 2842VL has an ISA-connected floppy controller, which is not populated on the 2840VL. The floppy controller is handled by the mainboard BIOS, that's why the SCSI BIOS is identical on both variants.

Oops, you are right, I did not look on the Bios, I looked on the controller chip 😁
By the way the writing on the card also says FCC ID:FGT2842VL.

b_riera wrote on 2024-03-17, 21:04:

Well I wasn't expecting someone with the same card to be looking at this. This is incredibly helpful.
So I've toned out U20 and it seems like each pin is good. I just toned them out to where I could see the nearest via or connection to another chip. I also checked the BE1 pin on the edge connector. The PLCC chip pinout is certainly confusing but I'm pretty sure I got it. This also checks out ok.

Your measurements indicate no obvious easy-to-fix fault then. The "booting is unreliable, card is only detected sometimes" thing is a typical symptom for contact issues, like cracked solder joints or traces with a break in them, but both pieces still touching each other most of the time. In your new photo, I don't see any obvious bad joints, though.

b_riera wrote on 2024-03-17, 21:04:

While I had it under my magnifying glass/ring light, I noticed C22 is missing. There definitely was a capacitor here. It's not just a blank pad. Clearly torn off. Any idea of it's value? I've got a lot of through hole ceramics. I probably have it or something close enough I can bodge it with.

You won't do anything wrong by assuming 100nF. These caps are meant to stabilize the voltage on the +5V rail for the IC next to it. One of them missing is likely not causing a malfunction like that, though. There are lots of them on the card, partly marked "A3". I couldn't find a quick reference whether this is a batch number or some vendor code for 100nF.

CoffeeOne wrote on 2024-03-17, 21:21:

Oops, you are right, I did not look on the Bios, I looked on the controller chip 😁
By the way the writing on the card also says FCC ID:FGT2842VL.

That's just because FGT2840/42VL would be an unneccesarily long FCC ID and slash characters are not permitted in FCC IDs anyway. While I couldn't find a photo of an 2840VL on the internet at the moment, https://www.ebay.com/itm/285153104567 shows a 1540CF (no floppy controller present), but has the FCC ID 1542CF printed on it. The sticker that is in the position of the unpopulated FDC seems to say 1540CF. You can barely read it in the last photo, but it is out of focus in all pictures it is present in. So you were doing the correct thing by looking at the sticker (on the SCSI controller chip). Interestingly, the 1540B/1542B had an FCC ID called 154XB.