d8b Forum

One of my two d8b consoles went dark while it was running yesterday, and stayed dark when trying to restart or reconnecting the BFC connector.

Since I have two, I tried the power supply from the other unit, and the console lights up normally, so I know the problem is with the CPU/Power Supply from that one unit.

This morning, I was able to boot from the “bad" CPU/Power Supply again and everything initially looked normal, so I thought it was just a fluke or power surge or something (…although I do have it connected to a power conditioner). But again… I walked away for a while, and when I came back, the other console (since I had swapped CPUs/PSUs) was now dark.

The only life sign on the console(s) when this happens, is a faintly pulsing rude solo light.

The computer still boots up, but gives the standard “Error: DSP Control Card not ready. Last Known State:Reset” message, that you get when the console can’t be found.

Logic would tell me, that the power supply can’t provide enough power anymore, to keep the console up and running (or boot it in the first place). But before I open the thing up, and poke around what may be wrong with the power supply… did someone maybe have this kind of issue before? If so, how did you solve it? Replace the whole power supply, or was there an easier solution or lesser component that was the culprit?

I’ll try some electronic cleaner in the BFC connector, too (reseating/wiggling didn't help)… but doubt that that’s the issue, since it seems to work when booting “cold”.

Any tips would be much appreciated!

Nevermind, everyone. Problem solved (or at least I know I'll have it solved shortly).

I found another defective d8b for cheap on Craigslist, that I got to work just fine after a little bit of troubleshooting (bad mainboard battery, and someone connected stuff up wrong on the inside of the CPU - probably while troubleshooting the BIOS error you'd get for an empty battery).

Now I have 3 d8b's, where one of my preexisting ones had a good power supply, but a bad motherboard in the computer. Now I have plenty of parts to swap around, to have 2 fully working ones, and a 3rd one for parts, if anything else should go bad in the future.

Only concern is, that my existing "working" one, where the power supply went bad, is a Celeron 300 (new board), while both other power supplies are from the Pentum 166 version. I hope those are compatible. I'll find out shortly...

Sorry for talking to myself again on this forum (this isn't the first time), but while I made some progress since I posted last, I ran into a new issue that I could use some input for.

First, since I mentioned that I bought another d8b for parts yesterday... I got that one to work completely. It's running the Mackie OS 5.1 hack with all the authorizations now. 256 MB RAM... all good. This means that I won't part it out to fix my main "previously fully working" one.

But this means that if I get my other one to work completely, I could cascade the two units, for an insane number of channels (I already have two Apogee clock cards, and one of them already has the WC termination-off mod).

To avoid that this is getting too confusing, I'll have to explain first what units I have, and establish some sort of shorthand for those:

Unit A: Main unit (300 MHz Celeron). Was fully working until 3 days ago. Then it would still boot cold, but after a few minutes, the console went completely dark. A power supply issue, I assume.

Unit B: My preexisting secondary unit, that I used with a ProBox as a controller. The motherboard on this one is fried (keyboard controller chip isn't recognized), but it was based on a Pentium 166 Mhz. I gave up on resurrecting that one some time back. But it still has a functioning Power Supply, etc. I have Unit A & B sitting next to each other, and mostly use them as a mixer and controller, respectively.

Unit C: This is the "parts" unit I bought for cheap yesterday, that turned out to be fully functional after a little bit of troubleshooting. Based on a Pentium 166MHz.

Knowing that I'm just a step away from being able to cascade two d8b's, I'm of course trying to make one fully working one out of Unit A & Unit B.

I figured it would be easier to move the motherboard from Unit A to Unit B, than moving all the components of the power supply. So I did.

What I get now, is that the combined unit boots up normally at first, and the console shows "Mackie OS 5.1" while it's booting... recognizes all the cards, etc. But when the OS is completely up, it gives the following error:

"Error: DSP Control Card not ready. Last Known State:Reset".

I saw that error before, but usually only when I forgot to connect the console or something. But here, the console goes through the boot process, and then I get this same error on the Monitor, and on the Console as well. So, it's a bit different than if it's not found at all.

I tried a number of things already... including swapping that giant cable between the units, trying if I mixed up the Com1 and Com2 connectors on the board. I even swapped out the Host connector on the CPU with it's ribbon cables, thinking that I don't know if the one in the other case worked. Same result.
I tried the console with the other computer, which works fine, so I know the problem is with the computer.

Knowing that the motherboard worked fine before the other power supply sorta-died, the motherboard should be ok as well, unless I fried something while moving it.

Long story short, unless I damaged something else, the issue should be inside the power supply. And that leads me to the question for you guys:

Does any of you know which portion of the power supply may be responsible for the "DSP card" error? Possibly not supplying the needed power to a connector that powers that board in the console?

I do have a suspicion. There is a tiny cable with only two wires, close to the power switch, that goes from the horizontal board, to the vertical one on the side of the power supply. It was hot-glued on, but for troubleshooting, I removed and re-connected it. In fact, to try, I even left it off at some point, and the error was still the same.

So, back to the question... does anybody know? Could it be the connection I'm talking about, or one of the boards this cable connects?

Sorry... I know this question is pretty specific. But having read some crazy in-depth posts on here, before, I was hoping someone might recognize what I'm talking about.

Sorry about the long post! Thanks in advance to anyone who puts some thought to what the issue might be!

For anyone following this, I found the culprit:

I pulled the MIDI and network cards out of the brain, and now it boots up without an error and works (well, without sync, etc.).

Now that I think about it... I used the MIDI card in a different context at some point, and didn't have it installed in the "working unit" lately. I put it back in to prepare for running the units cascaded, though.

I had changed the jumpers for IRQ and base address. That probably got in the way of the COM ports, and caused this issue. So, basically, I caused my own problem.

Sorry to everyone who wasted time following this thread. It's probably pretty unlikely that anyone else would ever change the jumpers on the MIDI card, so this is a pretty useless thread.

I might send a brief update once the units are running "cascaded" though. Just for closure sake. This will be a few days, though, since I don't have a second parallel port cable for the "Host" connection.

Closure:
The two consoles locked in with each other. Pushing any solo button affects the channels on both consoles (every non-soloed channel muted on both consoles).
- Mic/Line, Tape In, Effects buttons are synched between consoles. Basically, the faders act as if they're part of one big unit.
- Buss channels, linked by interconnecting Alt I/O via ADAT optical (still need to test audio between consoles).

Basically, the two units talk to each other, and so far, everything seems to work. I'm still concerned, since both units use "Hack 1" for the Mackie OS, and the plug-ins. But the code for "Hack 2" never authorized the OS for me, so Hack 1 is all I got for both. Hopefully, they don't check for unit IDs over the network.

More testing to follow, but this is it for this thread.
Sorry for the time-waster.

Thanks for letting us know what solved it

Hey Y-My-R

It's all good! Thanks for the great deal!