Falcon + CUBASE AUDIO + SCSI - Experiences?

[JezC]

@exxos - I should be able to dig out a pukka Cubase dongle; I think I have both black (v2?) & red (v3/Audio) so you might then be able to try the original s/w. Just let me know if that would help and I can brign them with my Falcon to CL4...

Thanks it may help.. But if there's a version which doesn't need the dongle, then I can give that a try first anyway.

I think only certain versions of Cubase work on the Falcon? Possibly v3...

[whomper]

Thanks all for your helpful comments.

I have regular clock delay on on V3 as with no delay and with extra clock delay I get audio crackles.

Please keep in mind that the audio crackles I was getting with V4 and V3-no delay plus V3 extremes delays are different from this issue at hand. Those where small audio crackles like a bad vinyl record however this is digital noise similar to bit rate crushing and digital artifacts.

1. I installed the 100K resistor from GND to SDMA line as advised in V3 instructions, the one that came with the kit.
2. Cubase Audio V2 is the one here. I'm using latest 2.06. We need the audio version of Cubase and I'm using it with a dongle and original Steinberg non-modified code.
3. V4 did not work for me, probably due to missing delay.
4. Original clock patch 1.2 worked for me, probably due to delay on SDMA.
5. Extra delay jumper adds back audio crackles in stock Falcon, so I can only use normal Delay jumper.

One guess I have is that DFB1X changes system bus speed, timing etc and careful clock delay of stock setup get messed up with DFB1X

[mikro]

Please keep in mind that the audio crackles I was getting with V4 and V3-no delay plus V3 extremes delays are different from this issue at hand. Those where small audio crackles like a bad vinyl record however this is digital noise similar to bit rate crushing and digital artifacts.

I think this is key in this whole discussion. It's possible this is completely unrelated to clock patch.

[exxos]

So can you confirm you have the small capacitor in series with the SDMA clock next to the SDMA?

Its strange results. Its like sdma isn't always outputting data. But that would be strange. The fact it drifts from working for a few minutes then not working is also strange. I mean if it was something like gnd bounce it may explain some things but that would mean the whole data bus is corrupted.

Do you have some freezer spray? If you go back to where it works for a short time then gets worse... Then spray chips one at a time, sdma, DSP, DSP ram, gals.. And see if the audio gets better again when some ic is cooled.

[exxos]

Please keep in mind that the audio crackles I was getting with V4 and V3-no delay plus V3 extremes delays are different from this issue at hand. Those where small audio crackles like a bad vinyl record however this is digital noise similar to bit rate crushing and digital artifacts.

I think this is key in this whole discussion. It's possible this is completely unrelated to clock patch.

In one respect it seems like motherboard noise is a factor, the clock can effect the SDMA, or the databus is trashed for some reason, or there is some bug in the falcons gal logic causing the SDMA to screw up.

Its why I suggested freezer spray on DSP and ram etc.. The DSP sdma test programs pass, but I'm guessing cubase uses more DSP ram. And the fact it works for a few minutes hints at a thermal faukt or some timing is drifting out..

Which then leads me why does different clock delays on the SDMA matter.. It shouldn't.. In my v4 tests I had a board to adjust the SDMA clock in 10ns steps but I don't think it made any difference. BUT the DSP test seems flawed if cubase can trigger this fault and test programs don't.

The SDMA should, at least in theory, hold the data on the bus until the cpu reads the data. So delays on the SDMA clock shouldn't even matter.. But seems it does.. But why..

If there was bad ground bounce somewhere it could explain the sensitive nature of timings.. But I'm not really convinced that's the whole story..

The DSP light on his dfb1x seems to die as well for DSP access. I remember BW did fixes for DSP issues. But it's not like they don't work because the sdma DSP test would fail otherwise. But also it's like DSP decoding simpley stops happening which would hint towards some odd issue in the falcons gal logic.

Again it's why I suggested freezer spray on the gals. If something is borderline, finding a chip which changes the issue would at least give us a area of the circuit to concentrate on. Currently we are all guessing at what the fault is and where.

Another layer to the problem is that the stock system works without the DFB1X installed. It does actually delay the CPU clock due to the inherent logic which may have been the start of issues relating to the DSP shenanigans. This suggests some weird fault in the gal logic which does not like the system clock being out of sync.

I could also potentially do a firmware which runs the DFB1X at stock speed all the time to see if that is an issue.. Of course, TT ram will not function in that state, but at least it would give us a clue if speeding up the CPU is a factor in this or not.

I'm not sure if @whomper tried the 40mhz jumper to see if the changes anything?

[whomper]

So can you confirm you have the small capacitor in series with the SDMA clock next to the SDMA?

No, I don't have a cap, only a 100k resistor between U20 pin14 and SDMA line.

Do you have some freezer spray? If you go back to where it works for a short time then gets worse... Then spray chips one at a time, sdma, DSP, DSP ram, gals.. And see if the audio gets better again when some ic is cooled.

When I get that digital bit crush situation, the way to resolve it is to open Cubase audio settings, change sample rate input from FDI (external clock generator) to internal and back again, which basically resets the clock Cubase uses to "slave" to. This cures the issue until a few min or sec later when it comes back again. Its not related to heat probably, but to entering some sort of clock sync issue.

[exxos]

No, I don't have a cap, only a 100k resistor between U20 pin14 and SDMA line.

ah nevermind, the cap is on the V3 board, its hard to remember all the variations.

When I get that digital bit crush situation, the way to resolve it is to open Cubase audio settings, change sample rate input from FDI (external clock generator) to internal and back again, which basically resets the clock Cubase uses to "slave" to. This cures the issue until a few min or sec later when it comes back again. Its not related to heat probably, but to entering some sort of clock sync issue.

Seems like some sort of register corruption if changing settings "resets" the issue.

Try the 40mhz jumper on the DFB1X.

Also try the left side jumper on the top right of the DFB1X (OPTION jumper) This enables 16MHz mode.

Really 16MHz mode should act the same as a stock falcon which works for you.. if it doesn't, then it's possible the delayed CPU clock is causing some issues with maybe the GAL logic.

What is the internal and external clock generator you are referring to exactly ?

[whomper]

Try the 40mhz jumper on the DFB1X.

For some reason when I try it in 40MHz mode, my Cubase hungs while accessing my bluescsi to load the song. Not sure why.

Also try the left side jumper on the top right of the DFB1X (OPTION jumper) This enables 16MHz mode.

Activated the 16MHz (OPTION bridged) and the issue does still happen. This is with TT Ram. Music plays for some time and then digital noise.
When I deactivate maprom in this mode so that I do not get TTRam at all, audio can not play at all as its full of that digital noise.

The only mode that works for me when DFB1X is installed in to jumper the Disable jumper. Then I get the same results as without DFB1X installed.

[exxos]

Activated the 16MHz (OPTION bridged) and the issue does still happen.

So its not down to the speed of the CPU then, it has to be down to clock sync.

The only mode that works for me when DFB1X is installed in to jumper the Disable jumper. Then I get the same results as without DFB1X installed.

Yeah disabled jumper acts the same as DFB1X not installed.

I will have to think how to test the clock sync. I'm thinking along the lines of if I output the 16mhz clock on the DFB1X, then use that clock to feed the SDMA and GAL logic, maybe that will help, but its a bit messy solution, but we need to test the theory anyway first.

[whomper]

A quick update (I edited my previous post). 16MHz worked a bit and then messed the audio. This is with TTRam enabled. When disabled Tram by disabling MAPROM, the digital noise starts right away and the music can not be played at all.

Hope this also helps to narrow down the issue.