exxos's Atari, Amiga & retro forum

Ok this is the only capture I managed to get from that thing. I had to disable the TTRAM xfer test because there is still a sync issue with it. However this should be enough to see that the CT6x results look similar to the DFB1 with the standard GAL logic in place.

Here is the version which runs to completion on this 060 (at 66MHz, since I can't change it for reasons I'm still trying to figure out).

Oh god, sorry @dml!

I didn't mean to trigger such angst. :(

Thank you for the run, though. And it's very interesting. It makes me wonder about ACETracer and Cubase Audio on the CT60 again.

Perhaps they just handle clock domain crossing differently and with such effect that the work is done in the shorter time available?

Anyway, this is in keeping with my understanding of the GALs so the question remains what can I do about it?

Cheers,

BW

So I accidentally did some more work on this last night (was planning to have a week off thinking about timings!)

In the light of the CT60 results I ran Doug's new program on DFB1 in release configuration (at 16MHz mode) just to get a feel.


So broadly similar to the CT60 stats, but actually just a smidge slower on all but one of them. That's probably down to the edge I choose to sync to and perhaps recoverable in firmware.


But then I started playing with GALs again. And then firmware again. And then this happened:


So this is with one GAL changed (to remove that extra delay in 'DMA' mode) and then a bit of a firmware tweaking. The firmware tweaking is light enough that it may be possible to set it from a register so a user could possibly opt for a GAL mod and fast DSP if it were important to them.


However, it's not perfect. I still can't pass the cartridge test:


Which brings me back to the work I was doing on the cartridge and is perhaps the next direction for travel.

There is the additional consideration of what might break with the GAL mod, of course. How does DMA to the DSP work, for example? Is that thrown off? Can anyone suggest something that uses that so I may test it?

Additional good news is that Acetracker seems happy with the new DSP timings, however it will only work relaibly in 16MHz mode as in accelerated mode things seem to break down during screen mode changes (eg. it will start up fine, but when you click load and it reverts to the file selector in the normal GEM desktop, the screen will blank out). So that's probably clock switching related rather than DSP-influenced.

I also ran @dml's 'normal' Badmood for DFB1 and that seems to be very happy. Buttery smooth, I may say. There's also a '56k' build in there, which doesn't work, but I forget what's that's for? Accelerated DSPs? Can't find reference to it in the readme.

I suppose I need to test Cubase Audio somehow now. @exxos, did you get a test case in the end? I presume it'd have to be a hacked version.

BW

Badwolf wrote: 11 Nov 2025 10:44 There's also a '56k' build in there, which doesn't work, but I forget what's that's for? Accelerated DSPs? Can't find reference to it in the readme.

I'm busy today so it will take me a bit longer to absorb your update above - but I can tell you the '56k' DFB1 version uses the DSP for drawing pixels like the vanilla version, whereas the non-56k DFB1 version uses an alternative method with the CPU, relying on a faster CPU and avoiding the hostport bottleneck. That's all.

(If the DSP host port timings have changed so much, the 56k version will probably be broken yes)

I expect ACE tracker must be using DMA to the DSP and therefore probably DMA out of the DSP to the codec also. Acting as a stream processor in the middle. However Mr Hedberg is really the person you want to ask about that - it could be doing something very different :)

Badwolf wrote: 11 Nov 2025 10:44 But then I started playing with GALs again. And then firmware again. And then this happened:

:idea:

Badwolf wrote: 11 Nov 2025 10:44 So this is with one GAL changed (to remove that extra delay in 'DMA' mode) and then a bit of a firmware tweaking. The firmware tweaking is light enough that it may be possible to set it from a register so a user could possibly opt for a GAL mod and fast DSP if it were important to them.

However, it's not perfect. I still can't pass the cartridge test:

It would be interesting to know exactly what that test is trying to do with SRAM and how - especially since SRAM is clearly working ok.

I run a march-test on the external SRAM and most of the internal non-program RAM. The bits that are left are registers and the small program area running the test.

None of the DSP based software you are testing would run anyway if there was a problem with the SRAM.

The 'timeout' part means it has probably boot-loaded some code onto the DSP and is trying / failing to get a response. in fact it is not clear from any of that output if any DSP code has been running during the cart pass, although 'external interrupt' suggests something did...

No idea :) We'd need to study a dump of that code to know what's going on.

Badwolf wrote: 11 Nov 2025 10:44How does DMA to the DSP work, for example? Is that thrown off? Can anyone suggest something that uses that so I may test it?

DMA to the DSP is what the Atari's test tool trying to test / visualise: https://github.com/mikrosk/mikrosk.gith ... 30test.zip.

I think that test works fine and doesn't show any issues..

Badwolf wrote: 11 Nov 2025 10:44 How does DMA to the DSP work, for example? Is that thrown off? Can anyone suggest something that uses that so I may test it?

I do have a vague plan to add some more DSP related tests including this one - but I'm bogged down with work just now and not much time to play. If I make any progress on the changes I'll post them here.

I did wonder if maybe that diag cartridge is using code which assumes a 16MHz Falcon (?) and the breakage might not actually be your GAL/timing changes but incomplete handshaking combined with a speed change. However that problem would also show up with bus speeders - something which could still be tested?

It may not show with other accelerators because they all seem to reduce the DSP hostport speed to 50-75% bandwidth and it might be enough to keep the cart test happy... I mean, if an accelerated CPU is combined with 100% hostport bandwidth - and no change in the DSP's clock speed - problem might start to show up with the cart (?)

Has the diagnostic cart ever been reverse engineered? If it has, maybe you can see what it's actually doing.