exxos's Atari, Amiga & retro forum

Maybe add "some of the time" and "to varying degrees" to capture the full picture?

Or just caveat it all with every Falcon is unique... :roll:

On Exxos' suggestion I ran the DMA2DSP.PRG test on the Falcon with the DFB1X enabled and... it passes with flying colours, so it's obviously not a DMA issue but some other timing issue... or the DMA2DSP.PRG test doesn't drive the system in the manner which causes it to fail, which is quite possible seeing that many programs which do use the DSP work.


Anyway, I've got the test set-up on the bench, but I can't really do much more until Tuesday.

Badwolf wrote: 09 Jan 2025 09:53

Steve wrote: 09 Jan 2025 09:51 @Badwolf Please see my post to Stephen above, as mentioned, you probably have sdma delay 'on' too. It's worth turning it on/off to see if the behavior changes. And I appreciate @stephen_usher it might be unlikely, but since testing the theory only takes moving a solder blob, it's worth testing.

Hmm. Interesting I hadn't realised.

I did try changing over my solder blob. No noticiable differences found.

DMA2DSP all green still. Acetracker still a bit hang-y on screen change.

BW

I've given up trying to get Ace Tracker and Joy demo to work. For those I'll just flip the switch as disable the DFB1X :-)

Ace Tracker if it does start works for simple tracks but then half crashes telling me that the CPU can't keep up if it's a highly complex track such as "Natalie 1800".

The Falcon's back in its box so I can move on to other projects.

Have you tried Hextracker? It runs on my 40mhz '030 STacy.

The author was nice enough to work with it until it did run
right there.

I don't know guys... it's just my personal opinion but you are looking at the issues from a wrong angle. True, some people do not see the issues mentioned. On the other hand, the issues are anything but surprising: you overclock CPU to 50 (40) MHz, give it a super-fast TT RAM and keep the rest (the Blitter and DSP most importantly) at the original frequencies.

I mean, what do you expect? Naturally, any software which assumes that DSP is roughtly twice as fast than the CPU is going to fail. Or that the Blitter is roughly 2x as slow as the CPU. It's no coincidence that it is exactly Joy and ACE which are failing, we used to see issues like this with the early CPU/DSP accelerators all the time exactly for that reason - the power up was not balanced.

Only when the Nemesis / Phantom (and CT2 to some extent) arrived, *all* parts were boosted equally, greatly increasing the compatibility.

Just my two cents.

mikro wrote: 20 Jan 2025 20:23 I don't know guys... it's just my personal opinion but you are looking at the issues from a wrong angle. True, some people do not see the issues mentioned. On the other hand, the issues are anything but surprising: you overclock CPU to 50 (40) MHz, give it a super-fast TT RAM and keep the rest (the Blitter and DSP most importantly) at the original frequencies.

I remain unconvinced it's a DSP problem in general, so I'm not looking at it from that angle at all. Unless it's a combination (you access the DSP so this little exception triggers, then you access the videl in *this particular way* and then...), to me it's much more a video issue at the moment.

I'm disregarding issues with Joy at the moment as I don't think anyone else bar Stephen has them and we know his mainboard's a bit of a special case in more than one regard.

The Acetracker issue is more common than not I think, and happens to me even before any DSP heaving lifting occurs.

But I do accept there may be a race condition in Ace during initialisation that's not a problem at 16MHz and just happens to exhibit as a Videl problem.

BW

Can the DFB1X be run from the system clock rather than its own just to see if the issues are clock skew (due to the different clock speeds) which goes in and out of phase or something else?

stephen_usher wrote: 20 Jan 2025 21:36 Can the DFB1X be run from the system clock rather than its own just to see if the issues are clock skew (due to the different clock speeds) which goes in and out of phase or something else?

Sorry, I missed this.

On the original DFB1, the right-most of the four configuration jumpers at the top right disables acceleration, locking the CPU to the bus clock as received at the expansion.

It's only sampled at reset.

I suspect DFB1X behaves the same.

BW