DFB1 BadMooD issues

[dml]

I'm thinking of making a CPU/DSP interaction test program, to see if anything interesting shows up.

Normal builds of BM for 030/Hatari use minimal DSP handshaking for performance. However the test builds I have been providing are different.

One of the builds (D) uses handshaking everywhere. So no timing/sync issues - both sides negotiate every transfer (which has a performance hit but prevents any exchange-related freezes due to dropped data).

In all builds, DSP always negotiates because it is generally in front of the exchange, so nothing to lose. CPU only negotiates if configured to, for each type of transfer - unless it is 'always on', which was the case for test build 'D'.

The DSP is not used at all in the menus. It is initialized once on startup and a program is transmitted via XBIOS but that's all. The tricky stuff only happens later when the game window opens.

As mentioned yesterday, DSP is not involved in music/sound at all. Blitter is used on 030/Hatari builds, but not in these 0x0 builds.

So this is all very strange. But i'll see what I can come up with re: small independent tests to narrow down which 'thing' is going awry.

@exxos - yes BM program can be run from AltRAM. Even if it is forced to run from STRam, it will query AltRAM and prefer it for most things when available, except for display and audio DMA, which is requested always from STRam only.

[dml]

That said, Ace Tracker *doesn't* work in VGA mode on DFB1, probably for the same reasons BadMood037 didn't which I think was something related to clock switching confusing the precise Videl timings.

Does it work in RGB mode? I mean the DSP synth functions as expected, VGA issues aside?

[exxos]

That said, Ace Tracker *doesn't* work in VGA mode on DFB1, probably for the same reasons BadMood037 didn't which I think was something related to clock switching confusing the precise Videl timings.

Could you use the Falcons 32mhz master clock ? Aside from it being slower than 50mhz, it should sync without glitching errors better.

[Badwolf]

That said, Ace Tracker *doesn't* work in VGA mode on DFB1, probably for the same reasons BadMood037 didn't which I think was something related to clock switching confusing the precise Videl timings.

Does it work in RGB mode? I mean the DSP synth functions as expected, VGA issues aside?

I don't recall, to be honest. Will have to check.

That said, Ace Tracker *doesn't* work in VGA mode on DFB1, probably for the same reasons BadMood037 didn't which I think was something related to clock switching confusing the precise Videl timings.

Could you use the Falcons 32mhz master clock ? Aside from it being slower than 50mhz, it should sync without glitching errors better.

I have no reason to believe it's glitching, I suspect it the switching itself that's the problem, although I could easily check that with OPTION2 set (block acceleration).

Not at home until much later today.

The DSP is not used at all in the menus. It is initialized once on startup and a program is transmitted via XBIOS but that's all. The tricky stuff only happens later when the game window opens.

As mentioned yesterday, DSP is not involved in music/sound at all. Blitter is used on 030/Hatari builds, but not in these 0x0 builds.

This would seem to rule out DSP/TT-RAM interaction, then.


BW

[Badwolf]

Does it work in RGB mode? I mean the DSP synth functions as expected, VGA issues aside?

Screen snaps in and out of garbled in RGB mode too.

image0.jpg

image1.jpg

Playback is unstable, stopping after a time with a message about the CPU not keeping up (which is ironic).

Screen stabilises with 16MHz switch, but music still aborts with the CPU message.

I don't think any of this is particularly surprising. Programs that use Videl tricks may not like the non-constant cycle time per scanline and anything that has critical DSP timing will probably fall foul of the slightly slower individual DSP accesses that the external interface causes.

DSP processes that aren't *that* synchronised work fine though (BM037 under RGB, for example).

BW

[dml]

Screen snaps in and out of garbled in RGB mode too.

Thanks for trying this.

Playback is unstable, stopping after a time with a mesasge about the CPU not keeping up (which is ironic).
Screen stabilises with 16MHz switch, but music still aborts with the CPU message.

Strange.

I don't think any of this is particularly surprising. Programs that use Videl tricks may not like the non-constant cycle time per scanline and anything that has critical DSP timing will probably fall foul of the slightly slower individual DSP accesses that the external interface causes.

Maybe - but it is interesting that we have two independent failures involving DSP exchanges, and ACE uses very different methods for interacting with DSP. BM uses 'manual' hostport negotiation. ACE very probably uses interrupt-driven DMA streaming, possibly in hardware negotiation mode. I know for a fact that he makes more channels available on systems with a faster DSP so its hard to imagine non-negotiated exchanges in a context where different machine performance is expected, especially with a high channel count and time critical events (no dropping of audio frames).


Display trickery of the kind used on the ST (timing-sensitive shifter/raster tricks) are generally avoided on the Falcon because the 030 cycle timings and the Falcon bus do not have a fixed relationship. Things vary constantly, so most tricks which are synchronous in nature are out of the window from the start. Most things are coded to expect asynchronous behaviour between devices.

I tried using a time-sensitive Videl event for the status bar in BM for a simple screen split on VGA - and even that is a nightmare and jumps around under acceleration. So it is turned off for all but the base 16MHz machine.

There are some more common Falcon tricks re: partially-negotiated exchanges with DSP as used in BM (e.g. negotiate at block start, but not for each individual word), which can be expected to fail on faster machines, especially bus-boosted machines - but it is easy to avoid doing that (for BM it is build-configurable) and I expect ACE does not do this at all since it is working at audio DMA bandwidths not video bandwidths, so too much to lose, not enough to gain IMO. I expect Thomas set it up to use reliable transfers always, likely using the 'handshaking', interrupt-driven DMA mode. In that case, even competition between DMA and Videl access to the bus would be handled by the hardware DMA handshaking/negotiation mode (scenario is mentioned in the Atari docs).


So while none of this is conclusive whatsoever - it might still be worth investigating to see if DSP/CPU exchanges are in some way being impacted in a manner other than speed/timing.

I won't have time to do much about this for a few days but will continue thinking about it. If I can come up with some kind of simplified direct test it might be worth giving that approach a try before trying to speculatively fix anything else. If it had been a straightforward thing based on experience on the other accelerator boads i would probably have iterated it out by now. I don't think its worth trying any more builds until the problem is a bit better understood.

[Badwolf]

I won't have time to do much about this for a few days but will continue thinking about it. If I can come up with some kind of simplified direct test it might be worth giving that approach a try before trying to speculatively fix anything else. If it had been a straightforward thing based on experience on the other accelerator boads i would probably have iterated it out by now. I don't think its worth trying any more builds until the problem is a bit better understood.

I didn't have time last night, but I need to get around to checking if TT-RAM is in play during these tests and disable it if it is. That would be another data point.

I think there's DSP test program kicking around somewhere. I can run that on an extended soak. I think that was looking for DMA audio issues rather than stress-testing the DSP itself, however, so may not show up everything.

Cheers,

BW

[exxos]

@Badwolf viewtopic.php?f=25&t=4575

[Badwolf]

@Badwolf viewtopic.php?f=25&t=4575

That's the one, ta.

BW

[stephen_usher]

Note that in VGA mode ACE Tracker has display glitches now and again on a stock machine, which is a known issue that New Beat has said he'd look at sometime.