Unite wrote on 2020-12-03, 19:42:

After last nights panic with the VLB 486 (don't ask) I decided tonight to take a look at a VLB controller I picked up from eBay […]
Show full quote

After last nights panic with the VLB 486 (don't ask) I decided tonight to take a look at a VLB controller I picked up from eBay a while back, in particular this is the Tekram DC-680T.

Its possibly dead though as on boot it gives a looping single flash on the LED and an error message "Controller Failure! ERROR CODE = 1"

Looking at the manual

http://www.minuszerodegrees.net/manuals/Tekra … 80%20DC-690.pdf

Page 46 would suggest this means 1 of 4 things

Controller is not functional
No Cache DRAM is installed
TAG SRAM test failure
Parity error on cache DRAM

Ram is installed (it came with 4x 256kb simms but I have also tried others and tried bank 0 only). What does it means by TAG SRAM test failure or Parity error on cache DRAM? Assuming this means a fault with the memory modules I know at least that the simms I tried from my own hoard do work fine so its not that.

Any ideas before I settle on controller is not functional with a sad face 🙁

Which version of the EPROM do you use? Do you use the common 1.50, or the modern 2.02? I can take a look into the firmware to help you find possible causes for the failure. "TAG SRAM" means the 64KiB of static RAM soldered onto the controller board, and "Parity error on cache DRAM" would indicate broken or parity-less SIMMs. On the other hand, I am unsure whether the DC680 hardware actually supports parity checking...

EDIT: Obviously, you are using Version 1.50. Version 2.02 does not support "Error code 1". Error code 1 means that the controller firmware does not respond on either port 1F0 or 170 (primary or secondary IDE). This is of no surprise, because a blinking LED indicates that the Firmware of the DC680 failed its own self-test. When the firmware blinks the LED, it's in a state where it can not respond to commands.

There is a known issue that the DC680T Firmware (AFAIK this did not change between V1.50 and V2.02) fails its selftest when the VL bus clock is lower than 12MHz. I have a VL board that drops the front side bus clock (so obviously also the VLB clock) to 8MHz in deturbo mode. This causes the issue you describe even without any hardware failure. The Version 1.50 firmware seems to encode the kind of failure in the duty cycle of the blinking LED. If I understand the firmware correctly, the following table applies:

1  6%  80186 internal timer failed (or VL clock too slow)
2 25%  No cache RAM detected
3 50%  80186 register failed (broken chip)
4 75%  On-Board SRAM failed

25% duty cycle means that the LED is lighting up 25% of the time, and being dark 75% of the time.

mkarcher wrote on 2020-12-03, 21:38:

Which version of the EPROM do you use? Do you use the common 1.50, or the modern 2.02? I can take a look into the firmware to he […]
Show full quote

Which version of the EPROM do you use? Do you use the common 1.50, or the modern 2.02? I can take a look into the firmware to help you find possible causes for the failure. "TAG SRAM" means the 64KiB of static RAM soldered onto the controller board, and "Parity error on cache DRAM" would indicate broken or parity-less SIMMs. On the other hand, I am unsure whether the DC680 hardware actually supports parity checking...

EDIT: Obviously, you are using Version 1.50. Version 2.02 does not support "Error code 1". Error code 1 means that the controller firmware does not respond on either port 1F0 or 170 (primary or secondary IDE). This is of no surprise, because a blinking LED indicates that the Firmware of the DC680 failed its own self-test. When the firmware blinks the LED, it's in a state where it can not respond to commands.

There is a known issue that the DC680T Firmware (AFAIK this did not change between V1.50 and V2.02) fails its selftest when the VL bus clock is lower than 12MHz. I have a VL board that drops the front side bus clock (so obviously also the VLB clock) to 8MHz in deturbo mode. This causes the issue you describe even without any hardware failure. The Version 1.50 firmware seems to encode the kind of failure in the duty cycle of the blinking LED. If I understand the firmware correctly, the following table applies:

Copy code to clipboard

1  6%  80186 internal timer failed (or VL clock too slow)
2 25%  No cache RAM detected
3 50%  80186 register failed (broken chip)
4 75%  On-Board SRAM failed

25% duty cycle means that the LED is lighting up 25% of the time, and being dark 75% of the time.

The below is a link to an image of the card, it appears to be using 1.4 roms.

https://imgur.com/IlX7WRw

Going on the list above for LED duty cycle its hard to tell if its at 25% or 50%. Here's a quick video of the led- https://youtu.be/auRpjIH901g

It looks to me as if its 25% so that would suggest bad ram. I've tried it with only 2 of the modules in bank 0 and tried swapping out between the 4 of them but its no different.

I'm not sure I can test the clock speed of the VLB bus, the system is certainly setup to power on at full speed. FSB is set to 33mhz.

Unite wrote on 2020-12-04, 09:14:

The below is a link to an image of the card, it appears to be using 1.4 roms. […]
Show full quote

mkarcher wrote on 2020-12-03, 21:38:

25% duty cycle means that the LED is lighting up 25% of the time, and being dark 75% of the time. […]
Show full quote

Copy code to clipboard

1  6%  80186 internal timer failed (or VL clock too slow)
2 25%  No cache RAM detected
3 50%  80186 register failed (broken chip)
4 75%  On-Board SRAM failed

25% duty cycle means that the LED is lighting up 25% of the time, and being dark 75% of the time.

The below is a link to an image of the card, it appears to be using 1.4 roms.

https://imgur.com/IlX7WRw

Going on the list above for LED duty cycle its hard to tell if its at 25% or 50%. Here's a quick video of the led- https://youtu.be/auRpjIH901g

It looks to me as if its 25% so that would suggest bad ram. I've tried it with only 2 of the modules in bank 0 and tried swapping out between the 4 of them but its no different.

I'm not sure I can test the clock speed of the VLB bus, the system is certainly setup to power on at full speed. FSB is set to 33mhz.

If it powers up at FSB33, you don't have any issue with the VL clock.

You can step YouTube videos frame-by-frame using the dot and comma key while the video is paused. I am counting around 10 frames on-time on 36 frames cycle time. This is a duty cycle of 28%, so it sureley is 25% duty. This means that the 80186 is unable to detect the Cache RAM. This need not be a defective or incompatible cache RAM module, it could also be a broken trace on the controller. If the card was improperly stored in a "bucket of cards", scratches can happen. Consider that the cache RAM is on one end of the card, whereas the ST300ALI interface chip is near the other end, so if traces are broken, it is quite likely to affect the RAM interface.

The architecture of your card is like this: The ST300ALI chip is the main hub, and it connects the firmware ROMs (ROM #2 and ROM #3), as well as the "Tag SRAM" directly to the front-side bus of the 80186 (and this seems to work properly, because checking for cache RAM and setting up the management data is the last step in the 80186 boot process). Furthermore, the ST300ALI manages the cache RAM and allows whole-sector transfers between the cache RAM and one of the following peers: Either one of the IDE connector, or the 80186 processor, or the VL bus. Furthermore, the ST300ALI presents the content of the host ROM (ROM #1) to the VL bus. This also works, because the message "Controller Failure, Error Code = 1" is printed by code in that ROM. This means the VL interface seems to be working, too.

Looking at Firmware 1.5, it does not seem like the statement is true that you need to have Cache RAM installed in the first bank - either of the two banks should work. If cache RAM is installed in both banks, and one of the banks is broken, it still should detect the other bank. The 80186 firmware does *no* actual test of the cache RAMs on its own, this is done under control of the host ROM during PC post. The 80186 just probes whether some specific addresses on that RAM can be read and written, and which address bits are actually used by the RAM (to detect the size). No detection of cache RAM is thus unlikely to be caused by degraded memory chips on your SIMMs (which might have some bad bits), and more likely to be caused by either completely broken chips or SIMMs, or (as I suggested) by a broken data trace that impacts all read/write cycles, irrespective of address. I tend to suggest the board to be at fault, because you already tried different sets and types of SIMMs.

mkarcher wrote on 2020-12-04, 17:25:

If it powers up at FSB33, you don't have any issue with the VL clock. […]
Show full quote

If it powers up at FSB33, you don't have any issue with the VL clock.

You can step YouTube videos frame-by-frame using the dot and comma key while the video is paused. I am counting around 10 frames on-time on 36 frames cycle time. This is a duty cycle of 28%, so it sureley is 25% duty. This means that the 80186 is unable to detect the Cache RAM. This need not be a defective or incompatible cache RAM module, it could also be a broken trace on the controller. If the card was improperly stored in a "bucket of cards", scratches can happen. Consider that the cache RAM is on one end of the card, whereas the ST300ALI interface chip is near the other end, so if traces are broken, it is quite likely to affect the RAM interface.

The architecture of your card is like this: The ST300ALI chip is the main hub, and it connects the firmware ROMs (ROM #2 and ROM #3), as well as the "Tag SRAM" directly to the front-side bus of the 80186 (and this seems to work properly, because checking for cache RAM and setting up the management data is the last step in the 80186 boot process). Furthermore, the ST300ALI manages the cache RAM and allows whole-sector transfers between the cache RAM and one of the following peers: Either one of the IDE connector, or the 80186 processor, or the VL bus. Furthermore, the ST300ALI presents the content of the host ROM (ROM #1) to the VL bus. This also works, because the message "Controller Failure, Error Code = 1" is printed by code in that ROM. This means the VL interface seems to be working, too.

Looking at Firmware 1.5, it does not seem like the statement is true that you need to have Cache RAM installed in the first bank - either of the two banks should work. If cache RAM is installed in both banks, and one of the banks is broken, it still should detect the other bank. The 80186 firmware does *no* actual test of the cache RAMs on its own, this is done under control of the host ROM during PC post. The 80186 just probes whether some specific addresses on that RAM can be read and written, and which address bits are actually used by the RAM (to detect the size). No detection of cache RAM is thus unlikely to be caused by degraded memory chips on your SIMMs (which might have some bad bits), and more likely to be caused by either completely broken chips or SIMMs, or (as I suggested) by a broken data trace that impacts all read/write cycles, irrespective of address. I tend to suggest the board to be at fault, because you already tried different sets and types of SIMMs.

Thanks for the detailed reply. I'll take a close look over the card and try to bell out traces to ensure nothing is broken. The card is very clean and it has been well stored, in my ownership anyway. Hopefully it is just something simply like this and I can fix it.

I've been over the card with a fine toothcomb and cannot find any broken traces, cracked soldier joints etc.

The data lines are routed through the 2 74logic ICs between the simm sockets, from there it appears as if they are directly linked to the main ST300ALI and possibly ROM3. If I had a logic probe I suppose I could check to see if the datalines are active or if any are stuck which might indicate a fault on those logic chips.

One thing I found interesting with some further testing is that if I connect a floppy drive, at boot you get the floppy seek but the light on the floppy drive stays lit afterwards, it doesn't go out. Could that be some indication as to were the fault lies. Its almost as if the card crashes and the motor off signal never comes from the floppy controller.

Unite wrote on 2020-12-07, 16:56:

One thing I found interesting with some further testing is that if I connect a floppy drive, at boot you get the floppy seek but the light on the floppy drive stays lit afterwards, it doesn't go out. Could that be some indication as to were the fault lies. Its almost as if the card crashes and the motor off signal never comes from the floppy controller.

The floppy controller is a completely separate chip on that card: It's the PLCC chip in the upper right corner (typical orientation of the card: bus connector to the bottom, slot cover to the right), in my copy of the DC-680T, it's manufactured by GoldStar. Access to the floppy controller might still be gated through the ST300ALI, but this is supposed to be "state-less", i.e. the chip does not know what happened before, so if it is configured to pass through addresses 3F0-3F7 to the FDC, it will always do so, with no chance of crashing.

The motor has to be turned on and off by the host processor of the PC. Usually, the timer interrupt (IRQ0) decrements a variable in the BIOS data area, and if it reaches zero, it turns off the floppy motor. If for some reason during POST IRQ0 is hooked and not chained through to the original BIOS handler, or interrupts are masked, the floppy drive will keep running indefinitely without there being any fault on the floppy controller.

I was wrong to claim that the BIOS is read through the VESA local bus - only IDE I/O, possibly even only port 1F0, the data port, is performed on the local bus; the BIOS is connected to the ISA bus as 8-bit device.

I'm sorry that I can't point you into further directions to find the fault of your card, but I might suggest to you to test your 30-pin SIMMs in some other device, like a Sound Blaster AWE32 or a 286-class mother board (486-class boards might not support 256k SIMMs). While it is unlikely that all off your SIMMs are broken, it's not impossible.