Falcon + CUBASE AUDIO + SCSI - Experiences?

[whomper]

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).

I tried that patch (patching Cubase and installing a .PRG in the AUTO folder) and also just installing a handshaking patch I found elsewhere, same results.

If CT60 works and DFB1/X does not, can it be rectified via firmware once we understand the issue? My system is very stable with V3 patch and also with DFB1X apart from DSP audio. I am working in DFB1X mode on a normal basis and just have to switch to Stock Falcon when I use Cubase.

[exxos]

Been doing a few more tests with DFB1X.

So far, CUBASE doesn't even load with NVDI,MAPROM_C,WDIALOG in the auto folder. I have been trying to find if it's just one of those but Cubase only seems to load with all three disabled in the auto folder.

I don't know if it's coincidence but even the floppy drive goes nuts when loading Cubase with stuff in the AUTO folder.. I had floppy malfunction once in GEM, but not sure if that's related or not.

I'm getting somewhat confused with all the combinations of stuff now So will just not use anything but HD12 for now. But I can't really do much because of the issues in my other thread.
viewtopic.php?f=23&t=7983

OK so cubase was just sat doing nothing now the Falcon has locked up. But mostly I don't get as far as it drawing the main sequencer window with items in AUTO.

I noticed I had cops.acc and xcontrol loaded. So removed those. Rebooted, Cubase now saying it cannot find 2 files, but still drew the main window. I left it for a few seconds and locked up again.

Next test with DFB1X DISABLED.

It seems to play fine, but not sure if the clicking sounds are supposed to be there or not...

Of course it is a bit difficult to tell because of the clicking with the SCSI drive itself

[exxos]

I've been playing around with all sorts all day but not really getting anywhere

Cubase tends to lockup just after the first clock popup box.

I have tried keeping the CPU & Combel in sync. Inverting SDMA. Tried various delays. If anything the extra delay on the V3 worked best. But as its unstable anyway, cant conclude that. Tried more resistors on the clocks.. but I don't think its a clock patch problem.

I tried forcing 16Mhz in DFB1X code, no real change. Tried playing around with various timing changes in bus-arb module. no luck. There does seem to be some oscillation on XBGK, but extra pullup and 47pf did not change anything.

The only small observation is that when the program does tend to load a bit more that I get a buzzing sound which seems to change page each time the SCSI drive is accessed. In Cubase, it looks like voices are outputting with no audio playing. So its like SCSI access is corrupting the audio system somehow. Mostly it just locks up, sometimes with row of bombs.

All tests are done with simple stock system with DFB1X. No MAPROM, or TTram used etc. Keep things simple as possible.

EMUTOS was a little more helpful this time..

IMG_3705.JPG (258.19 KiB) Viewed 282 times

IMG_3706.JPG (297.83 KiB) Viewed 282 times

But I am out of ideas now anyway

EDIT:
Tried running from IDE. It seems to crash as it starts drawing the main score window. But still locks up the same was really as running from SCSI. So I think we can rule out clock patches and SCSI devices now.

[exxos]

Tried like 100 different code variations on the bus arbitration and basically giving up with that route now. Nothing I do really makes any odds other than making things worse

Played with The system clocks on the clock patch to no avail either.

Did see some oscillations on the rise and fall of XBGK but caps and pullups didn't help.

50mhz seems to let me load and play the music more than 40mhz.

Slow slew on the PLD seems to make things worse.

The screen corruption is consistent after loading the module. Clicking fast forward which hammers the SCSI drive more generally causes instant crash with row of bombs. Its like hard drive access is somehow corrupting STram.

So dunno. @Badwolfs turn now

[stephen_usher]

I guess that there's no way of running at 32MHz?

Clocks going in and out of phase could cause issues I s'pose.

If the DFB1X is at a harmonic frequency to the rest of the system then could this help?

[exxos]

@stephen_usher it doesn't work any better running with the system clock either. I've also tried inverted and non inverted clocks. Makes no odds.

Its odd that only cubase causes the issue as well. Its like hard drive activity is corrupting ram. Which then causes Cubase to crash.. But it will pass STram tests.. I can copy files fine. So what's the connection..

Its also odd that sometimes SCSI activity causes a buzzing sound to change in pitch. Like DMA sound is planing back corrupted ram.. And each SCSI access changes the ram and the noises. It's like a address error on data. But acetracker works fine.. So cubase must be doing something really odd I think.. But no idea what.

[whomper]

I did some tests with the diagnostics card and a loopback DSP plug I have.
Without DFB1X everything passes, with it I get these messages on a few runs. This is without Cubase or SCSI, just diag cart running Digital Audio test.

IMG_0039.jpeg (608.63 KiB) Viewed 207 times

IMG_0040.jpeg (618.74 KiB) Viewed 207 times

IMG_0041.jpeg (603.78 KiB) Viewed 207 times

[exxos]

That is very strange...

The problem there is I don't believe myself or @Badwolf has the interface harness to test that out

[Badwolf]

Aha. That’s very interesting.

You know, I’ve not run that test very often as I don’t have the loop back harness.

But I did run it when debugging my roasted DSP board and saw those messages. Perhaps I wrongly assumed that was a sign of the problems on the board.

I should like to look into that further as if there is a as-yet undiagnosed DSP compatibility problem, unrelated to DMA sound (which is where I assume Acetracker and Cubase are falling down), it may actually better compatibility in general.

Does anyone know, or have schematics for, the test connections for this test at all?

BW

[don_apple]

Does anyone know, or have schematics for, the test connections for this test at all?

Take a look at the PDF posted in https://www.atari-forum.com/viewtopic.p ... 39#p476939