exxos's Atari, Amiga & retro forum

It may be the case that all the clock changes I've made just makes sure the clock works, however the issue with Cubase Audio may be related to a different race condition of DMA buffer issues, perhaps in combination with SCSI activities, which DFB1X triggers.

Fundamentally, what changes does DFB1X introduce to the system that could trigger this? As it also happens in 16MHz mode, it might not be the CPU, rather something around it.

whomper wrote: 20 Sep 2025 15:06 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.

I had similar capacitor there in my original clock patch install guide somewhere. But others found the cap made problems worse. Some people scoped the clock and looked more like a triangle. So removing the cap gave better waveform.

The capacitor basically does the same as 66R resistor. Czuba said 47R. But he didn't really understand the problem either.

I sent my falcon to czuba originally and he used 47R there. But my falcon didn't boot. I measured the sdma clock and saw only 0.5v there. I also noticed really bad undershoot which was likely been seen as logic low. Not proper logic low. It also crowbared the voltage reducing the DC offset. This is what started my original clock patch investigation.

Currently my falcon works with any clock patch with joy demo and ace tracker. But yesterday I find that odd SCSI file copying problem. Where files over 6mb lockup the computer. This seems like similar issue you have.. Where at best audio works for some time then dies. So I wonder if both issues are part of the same problem.

When I fit V3 to my falcon, i will experiment with SCSI file copying and see if I can prove there is something more going on.. SCSI malfunctions on stock machine and I need to know why.

Currently the only thing which solved the problem is using a 4MB STram card... But why..

So I need to diagnose those issues even before trying DFB1X issues.. But also it could be linked to your problem as to why delaying the sdma clock works better.. But then more delay works worse..

Maybe the sdma clock has a PLL input and a tiny bit of noise either on signal or ground causes some internal sdma issues. It would explain why so many variations of clock patches...

But as your saw, about 30mv of noise isn't much.. But is it enough... Don't know.. Atari said the cause was disturbances on the clock and even they kept changing the solution.

Its why I suggest you try direct buffer on sdma clock using V4.. If that doesn't change anything, then it's reasonable to assume its not a sdma clock problem. It's something else.

whomper wrote: 20 Sep 2025 15:18 It may be the case that all the clock changes I've made just makes sure the clock works, however the issue with Cubase Audio may be related to a different race condition of DMA buffer issues, perhaps in combination with SCSI activities, which DFB1X triggers.

Fundamentally, what changes does DFB1X introduce to the system that could trigger this? As it also happens in 16MHz mode, it might not be the CPU, rather something around it.

@Badwolf hypothesis is bus grant timing issues.. This is not really fixable as a hardware issue. This is also why he wanted to know if CT60 worked.. And it seems it does.. So more tests need to be done.

16mhz cpu clock on DFB1X doesn't change the delays on bus grant hand offs. We tried syncing the clocks to run out clock sync issues. So there isn't much left.

But I also see screen corruption in my tests with cubase.. So somehow SCSI activity is causing STram corruption.. That's another stance thing I have no idea about yet..

There are a lot of issues and tests needed to be done to gather as much information as possible. I'm currently wanting to try stock machine to see if SCSI issues remain.. I will fit v3 and retest.

Posible there may be some OS bug.. Maybe some cache related issue somewhere. It could be anything..

exxos wrote: 20 Sep 2025 15:34 Posible there may be some OS bug.. Maybe some cache related issue somewhere. It could be anything..

Did you see Zippys quote on AF when I mentioned about the Cubase crack and accelerators?

https://www.atari-forum.com/viewtopic.p ... &start=525

viking272 wrote: 20 Sep 2025 15:41

exxos wrote: 20 Sep 2025 15:34 Posible there may be some OS bug.. Maybe some cache related issue somewhere. It could be anything..

Did you see Zippys quote on AF when I mentioned about the Cubase crack and accelerators?

I have now. I don't look at other forums anymore..

But yes @whomper should also try that.. But he doesn't have issues with a stock machine..

I use a spinning rust SCSI drive and seem to have more issues than @whomper currently... And that's a issue with stock machine...

For me there's no point looking more at booster issues when the stock system isn't even stable.

What I'm looking at is..

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

Which mentions audio issues only..

But then later fixes do mention large file copying issues with SCSI..


So this is what I need to investigate more first..

Annoyingly Atari didn't go into specific details on the issue or fixes.

exxos wrote: 20 Sep 2025 15:34

whomper wrote: 20 Sep 2025 15:18 Fundamentally, what changes does DFB1X introduce to the system that could trigger this? As it also happens in 16MHz mode, it might not be the CPU, rather something around it.

@Badwolf hypothesis is bus grant timing issues.. This is not really fixable as a hardware issue. This is also why he wanted to know if CT60 worked.. And it seems it does.. So more tests need to be done.

Thing is there's a patch for CT60 which, among other things, purportedly tinkers with the DSP handshaking. Could be a factor if handshaking is needed when accelerated and potentially it's not getting polled enough when running at 16MHz (because of fewer available cycles on a bus arb exchange).

16mhz cpu clock on DFB1X doesn't change the delays on bus grant hand offs. We tried syncing the clocks to run out clock sync issues. So there isn't much left.

If you mean 16MHz mode doesn't change delays from the 50MHz version -- it's possible it could make things worse, actually. Both CPUs have to issue a grant and at 16MHz that takes one longer than it normally does.

EDIT: also, I don't recall off the top of my head which clock the bus arb state machine runs to.

I can't quite get over the bus arb LED going dark for human-scale time. I wonder if that's the same in stock mode? Anyone with a working Cubase Audio got a logic probe or fancy fitting a transistor, an LED and a 330Ohm resistor between XBGK on the expansion port and ground?



BW

whomper wrote: 18 Sep 2025 15:31

Badwolf wrote: 18 Sep 2025 15:29 @whomper the original title of the thread involces SCSI. Is that still a factor? Does the problem occur with IDE?

Cubase Audio only works with SCSI drives as they have some sort of SCSI optimized code as part of Cubase's Direct to Disk behavior.

Just coming back to this.

1) How does Cubase know it's talking to a SCSI disc? Does it issue its own SCSI commands?
2) Is a hard disc driver actually needed at all in that case?
3) What happens under EmuTOS (different driver)

These may be starkly obvious questions to long-time Cubase users, but I've never actually even seen the software, so apologies. :P

In the back of my mind I'm pondering if Cubase can be tricked (or hacked) into running to/from IDE to take the SCSI bus side of things out of the equation.

BW

Badwolf wrote: 20 Sep 2025 16:53 Thing is there's a patch for CT60 which, among other things, purportedly tinkers with the DSP handshaking. Could be a factor if handshaking is needed when accelerated and potentially it's not getting polled enough when running at 16MHz (because of fewer available cycles on a bus arb exchange).

Possible yeah. More DSP weirdness..

If you mean 16MHz mode doesn't change delays from the 50MHz version -- it's possible it could make things worse, actually. Both CPUs have to issue a grant and at 16MHz that takes one longer than it normally does.

IIRC there was no difference between 50mhz and 16mhz.. BUT we both found 40mhz is worse.

Maybe @whomper could scope the bus grant signals to see if there's any relation to working or not working..

EDIT: also, I don't recall off the top of my head which clock the bus arb state machine runs to.

I was messing with that last night.. Might have been system 16mhz or CPU clock.. You had it inverted, I tried various changes and different clocks.. If anything I made it worse.

I also tried messing around with the arb logic itself.. Trying to make sure no glitches etc could happen.. But in the end didn't seem to make any odds.

I can't quite get over the bus arb LED going dark for human-scale time. I wonder if that's the same in stock mode?

On my stock machine SCSI dies copying over about 6mb... Now it's possible that as the audio files are almost 300mb that there may be a correlation there when DFB1X is used. For me it took about half an hour before SCSI timed out.. But if cubase has its own SCSI driver.. It may timeout after a couple seconds...

Badwolf wrote: 20 Sep 2025 17:08 Just coming back to this.

1) How does Cubase know it's talking to a SCSI disc? Does it issue its own SCSI commands?
2) Is a hard disc driver actually needed at all in that case?
3) What happens under EmuTOS (different driver)

1. Before I had SCSI, I had an internal 4GB IDE drive that Cubase refused to work with. It said something (can't remember exactly) that it can not read or something along those lines. I had to move to bluescsi to get Cubase Audio to accept the drive. I guess it operates SCSI commands itself, but this is just my guess.
2. I did not try without HDDriver as I need it to have a drive entity in TOS to work with or for Cubase Audio to recognize.
3. Tried EmuTos 1.4, Cubase Audio crashes. My guess it relies on specific TOS 4.x instructions or memory addresses. EmuTOS did not recognize all my SCSI drives, only the last one, it did recognize all my IDE ones.