DFB1 BadMooD issues

[dml]

Oh teh noes! I thought. I've broken the firmware! This may be still be true, but then I considered the second half of the program name and it occurred to me perhaps the DMA part of that program means it doesn't like to be loaded into TT-RAM.

Yes it's possible the DMA buffer is allocated in the BSS section of the program (which would be bad, and shouldn't be the case) but you don't have an easy well to tell without diassembling the thing - so it's probably a moot test until this is clarified or some other kind of test is available. -_-

[Badwolf]

OK, so just done a half hour soak on DMA2DSP in 50MHz mode and no failures reported*.

Can't remember, but can you run it in other video modes like true-colour for example ?

I think it changes the screen res on startup. Could disassemble it over lunch, I suppose.

BW

[dml]

Can't remember, but can you run it in other video modes like true-colour for example ?

Not a bad idea - bus competition is highest in VGA mode in truecolour. Although ACE doesn't run in TC so it's not a common factor to BM & ACE acting strangely.

[Badwolf]

DSPBENCH is happy enough running from TT-RAM at full (CPU) speed. Reports 100% on the three tests.

The DSP mode of FRAC working nicely in true colour with TT-RAM too.

Anyone have any other obvious DSP + TT_RAM candidates to try?

BW

[dml]

DSPBENCH is happy enough running from TT-RAM at full (CPU) speed. Reports 100% on the three tests.

DSPBENCH unfortunately is quite limited in terms of a fidelity/reliability test. IIRC it does request a CRC from the DSP but 99.9% of the time, it is just the DSP doing its thing until the result is ready. It is primarily a performance test. Which is probably always going to work, unless the DSP itself is flaky or overclocked. There are very few actual exchanges between CPU/DSP involved.

However I've been considering making another test which is more exchange/transfer oriented.

The trouble with the DSP is there are so many ways to communicate with it, an exhaustive test is difficult to do.

OTOH, the type of failure that occurs in BM only involves one kind of transfer/negotiation. So I should probably just focus on that for now and ignore the other complexity. That will keep things simple.

[exxos]

@Badwolf What was that DSP fix you did a while ago again ? Something about a problem with one of the GALs or something ? Could that be related ?

[Badwolf]

Hi @dml, going back to the original post and running back in VGA mode:-

BM03XD.TTP - pedantic DSP handshaking (slowest, most likely to run without ingame hangs)

As above. Freeze on 'Hurt me plenty' option, music stalls.

I've removed set music_replay_mode 0 in the config.

'D' with load/Run from TT-RAM: now runs nicely!

'C' with load/Run from TT-RAM: still doesn't work -- menu is fine, but game doesn't launch.
'C' with load only from TT-RAM: as above
'C' with allocate only from TT-RAM: menu much less responsive, but then as above.

'B' with load/Run from TT-RAM: nice and smooth.

'A' with load/Run from TT-RAM: exquisite!



So it looks like my previous problems were with music rather than DSP and the slowness in the menus was because the programs were running from ST-RAM (even if allocing from TT-RAM internally).

I'm not sure what's going on with the 'C' build, mind! That's a strange one.

BW

[Badwolf]

Tried 'D' with MIDI sound turned on.

I'm sitting here grooving away to the distortion guitar which is still playing the tune nicely. Unfortunately the game itself has frozen whilst I was trying to blow up a barrel. ;)

EDIT: 'A' seemed to carry on fine when I shot/made noise.

EDIT AGAIN: no, none seem stable with MIDI or Falcon music on, alas.

BW

[dml]

Hi @dml, going back to the original post and running back in VGA mode:-

Thanks for giving that another spin. I need to digest it now...

...perhaps the DSP is not involved then, because these results are somewhat sensible. Not sure about the 'C' build, but really I would have expected the 'A' build to fail and the other 3 to work (albeit, increasingly slowly from B..C..D). But still, it is working without music so that's news.

Still not sure what to make of this yet (working with music off), or the previous report that music was running slowly. That's really bizarre. Really, very bizarre.

The sound FX use the same audio replay mixer/mechanism as the music. All the music player does is inject events into the mixer, as does the game for SFX. So for sound FX to work and music not.....

It is almost as if the music files themselves are corrupted? Maybe the files did not transfer intact? That could explain some things perhaps?

[Badwolf]

It is almost as if the music files themselves are corrupted? Maybe the files did not transfer intact? That could explain some things perhaps?

It all works with TT-RAM disabled, music included and the base game (same game files) works with DFB1 disabled. The odd slowness only seemed to happen when:-

1) TT-RAM was available and being allocated to;
2) The game was not set to load itself into TT-RAM (the files as extracted).

The breakthrough was disabling music when TT-RAM was available and then allowing the program to run from TT-RAM.

I don't suppose allocating from TT-RAM is causing an overhead copying sounds to ST-RAM for DMA or something convoluted like that?

The only difference I can see with music and SFX would be the frequency at which they happen, perhaps increasing the chances of seeing a deadlock somewhere?

BW