Falcon + CUBASE AUDIO + SCSI - Experiences?

[whomper]

Did you try the extra delay jumper as well?

I think the clock patch isn't just buffering the clocks. The inversion is needed to fix some timing problem with SDMA transfer. I just assume it's outputting data to early and causing some odd bus conflict or something.

I tried it a few days ago when I first installed the patch. It did not work well in stock Falcon so I focused on either no delay or regular one.

[whomper]

If I can have a copy of the song and a guide @whomper then I might also be able to run some tests next week with my Falcon and a DFB1X (it arrived today, thanks Exxos!).

Sure, I'll send you a download link. @exxos is probably running it at the base 33KHz sample rate as Cubase Audio needs a C.A.C or FDI hardware devices to get to 44.1 or 48 KHz. This is "slow" down the audio tracks and generate weird music but should exhibit the issues. I see from your video you have an FDI, so that's great.

[frank.lukas]

I haven't read everything, but have you tried the original CT60 clock patch?

ct60clockpatch.jpg (52.99 KiB) Viewed 174 times

https://mikrosk.github.io/clockpatch/

[viking272]

If I can have a copy of the song and a guide @whomper then I might also be able to run some tests next week with my Falcon and a DFB1X (it arrived today, thanks Exxos!).

Sure, I'll send you a download link. @exxos is probably running it at the base 33KHz sample rate as Cubase Audio needs a C.A.C or FDI hardware devices to get to 44.1 or 48 KHz. This is "slow" down the audio tracks and generate weird music but should exhibit the issues. I see from your video you have an FDI, so that's great.

Great! I do have an FDI so can use 44.1/48 but the video wasnt mine, it was a general one from YouTube! Thanks

[exxos]

Did you try the extra delay jumper as well?

I think the clock patch isn't just buffering the clocks. The inversion is needed to fix some timing problem with SDMA transfer. I just assume it's outputting data to early and causing some odd bus conflict or something.

I tried it a few days ago when I first installed the patch. It did not work well in stock Falcon so I focused on either no delay or regular one.

So strange it only works with a particular delay. It's difficult to know if the SDMA sees the clock as advance or delay..

If it's a delay, then maybe it's holding data a tiny bit longer on the bus so it's latched correctly. But this brings me back to things like bus pullups. If the data isn't reaching logic high fast enough then delaying SDMA until data has settled could be possible.

It probably isn't that simple but you could monitor the 16bit data bus on the DFB1X header. I don't have time to look for pinout, but it's in the falcon schematics.. Just measure the 16bit data bus during SCSI failure and watch carefully if there are any data lines which take very long time to transition to high state. They would all be like 20-40ns. If any take like 100ns or longer, in particular randomly then it could be an issue.

I think though as CT60 patch hints to dsp mode then that might be a clue. But it currently hints to bus grant issues but if CT60 works then it's possibly not.

I also wonder if you tried a later version of cubase? Like 3.10? we can't rule out this issue was fixed in later versions.

My current clock patch is a PLL prototype. I need to look into the SCSI issues next and see if V3 patch fixes the copying problem and cubase works better or not for me.

By what's been said so far, it seems to be the clock inversion which is solving clock issues not just buffering the signals.

Wasn't there the falcon gerbers in the wild somewhere? I wonder if it would give some hints as to what the gnd connections are like and what signals are close to the SDMA and FPU clock..

Problem is, Atari only said there was "disturbances" on the clock and didn't say what from..

Its also maybe another test you could do @whomper is break the SDMA clock next to sdma, remove the wire from the V3 board.. I think it's middle output.. The run a new short as possible wire from V3 output to SDMA clock directly.. Note the track has to be cut to isolate the original motherboard clock line..

Then retest everything. See if delay on off behaves differently or not. This will give us huge data to see is interference is a factor on the clock even with buffering..

It may also help if you ground your scope on the large cap next to PSU,, then scope a ground pin like ground on Ajax where yo soldered that 100k and see what ground noise is like.

[whomper]

It may also help if you ground your scope on the large cap next to PSU,, then scope a ground pin like ground on Ajax where yo soldered that 100k and see what ground noise is like.

I've connected my scope between large cap - pin and U20 pin14 (the one connected via resistor) and saw an interesting behavior the second digital bit crushing started. You can see that in the two images. First one is normal operation with about 30mV of busy noice. Once the bit crushing starts, noise almost flat lines for a very short burst and then continues normal. The bit crushing from that point just happens.

Normal

Normal.png (311.02 KiB) Viewed 142 times

Bit crushing

Bit Crushing.png (247.54 KiB) Viewed 142 times

Here is a download link for the 6 seconds file. You can see the issue at around second 3 for a very brief moment. Sorry there is no sound as it is a screen capture.
Bit crushing scoped on GND

[exxos]

Its likely the " bit crushing" is missing data which would lead to less bus activity and less noise. It is good information to have as it suggests we are not dealing with simple data corruption but totally missing data. Like the sdma stops outputting data for some reason..

[whomper]

Its also maybe another test you could do @whomper is break the SDMA clock next to sdma, remove the wire from the V3 board.. I think it's middle output.. The run a new short as possible wire from V3 output to SDMA clock directly.. Note the track has to be cut to isolate the original motherboard clock line..

Then retest everything. See if delay on off behaves differently or not. This will give us huge data to see is interference is a factor on the clock even with buffering..

Disconnected R221T from main board and connected it directly to SDMA with a short wire. Run test with 0 delay and with normal one. With and without the U20 pin 14 resistor. The system is not stable at all and generates that digital big crushing sound on music playing or close thereafter.

[exxos]

Disconnected R221T from main board and connected it directly to SDMA with a short wire. Run test with 0 delay and with normal one. With and without the U20 pin 14 resistor. The system is not stable at all and generates that digital big crushing sound on music playing or close thereafter.

Strange using a wire is worse..

Can you please take images of v3 and sdma area for future reference.

That 100k should still be in place.

Please scope sdma clock across the 100k resistor...

Possible the series resistance may need adjusting...

Its strange such a small change has such significant impact. During v4 tests I buffered the clock direct at sdma end.. But didn't find any reason to do that.. Possible we could try your V4 to buffer directly the clock..

[whomper]

I scoped the clock signal at SDMA during audio playback and digital bit crushing occurrence and the clock was stable, did not detect any glitch.

Referencing this link's version 2.2, it suggests placing a 150pF where I have a 100K resistor. It still uses an increased delayed signal compared to the regular delayed CPU/FPU/EXP ones, so it may seem SDMA still needs a delay.