DFB1 BadMooD issues

[dml]

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

Oh ok, yes I remember now you said the same data works in a different configuration.

So....

PRG=STRam, Alloc=STRam, music=on, result=ok
PRG=STRam, Alloc=TTRam, music=on, result=bad!
PRG=TTRam, Alloc=TTRam, music=off, result=good?
PRG=TTRam, Alloc=TTRam, music=on, result=???

Just trying to keep track

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 DMA frame buffer is in STRam, dynamically allocated via MXAlloc. This is the only part that needs to be in STRam because its the only part the hardware is looking at.

The samples themselves could be in TTRam or STRam - the CPU mixes them into the DMA frame (STRam) regardless. It should just take less time when they are coming from TTRam.

Although... samples are bytes. It would be reading bytes from TTRam during the mixing step, maybe not always consecutive bytes either. But I can't see a problem with that. And it does this from STRam normally - which is slow - without issues.

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?

There will be more events injected for sure, but the Codec DMA frame 'rate' will remain at 1 per 84ms. It just means there are more channels to mix down (by the CPU) to prepare the buffer for each one. So yes, there is more to do, it will take longer and maybe more chance of a deadlock, but I've never seen a deadlock occur in the sound system for any reason (it doesn't wait for anything, although I think it has a bypass condition where it can bail on an overrun condition, i.e. if a new frame interrupts itself before completing the old one) and it's still not clear how TTRam would play a part in this situation too.

[Badwolf]

Oh ok, yes I remember now you said the same data works in a different configuration.

So....

PRG=STRam, Alloc=STRam, music=on, result=ok
PRG=STRam, Alloc=TTRam, music=on, result=bad!
PRG=TTRam, Alloc=TTRam, music=off, result=good? -- Yes, for all but 'C'.
PRG=TTRam, Alloc=TTRam, music=on, result=???

The last one is what I was trying to get workign with the various config tweaks. I've set all the music preference to the performance option and whilst it sometimes starts up, mostly it'll hang after the menu selection is made.

Using MIDI it will normally start to run, but the game has a habit of simply freezing whilst the MIDI music carries on playing properly.

it's still not clear how TTRam would play a part in this situation too.

This is the kicker.

Thinking about the second line of the results above, this could be caused by the way I switch clock speed after an ST-RAM access. There is a delay before the clock is allowed to go back to 'fast' mode to not incur switching delays on back-to-back 16 bit ST-RAM reads.

I wonder, is it possible with the program running from ST-RAM that the calls to ST-RAM are the overwhelming majority of bus cycles with the occasional TT-RAM access dropped into that ST-RAM sea? TT-RAM at 16MHz can be slower than ST-RAM at 16 MHz... Could this actually be a significant enough performance penalty to have this effect?

Hmm.

EDIT: if you have time it might be nice to test a build that doesn't change the CACR such that I can experiment with caches and burst mode with the same build. My thinking is that a word or byte read to a 16-byte-aligned address in 16MHz is potentially much slower (because of the burst cache fill) than a word read from ST-RAM.

BW

[dml]

EDIT: if you have time it might be nice to test a build that doesn't change the CACR such that I can experiment with caches and burst mode with the same build. My thinking is that a word or byte read to a 16-byte-aligned address in 16MHz is potentially much slower (because of the burst cache fill) than a word read from ST-RAM.

I had wondered about this too so the last builds had burst disabled. However it was a few days ago now and I have made so many builds to test different things (currently looking into a weird keyboard/midi thing under Hatari, over on AF).

So I'll make a new build with CACR changes disabled.

There are 3 classes of CACR change in the game, 2 of which I can disable. One I probably need to keep.

- setting new CACR defaults for the whole program on start
- changing CACR defaults temporarily, for specific tasks (like block copying)
- invalidating I/D caches for some reason e.g. setting up SMC for floor rendering.

I can switch the first two off but the 3rd is required for correctness.

[Badwolf]

There are 3 classes of CACR change in the game, 2 of which I can disable. One I probably need to keep.

- setting new CACR defaults for the whole program on start
- changing CACR defaults temporarily, for specific tasks (like block copying)
- invalidating I/D caches for some reason e.g. setting up SMC for floor rendering.

I can switch the first two off but the 3rd is required for correctness.

That sounds fair enough. Maybe just mask the burst bits for now?

No rush, obviously. Glad it's working at all!

BW

[dml]

In other news, my 68040-accelerated Falcon is finally working again so I should be able to gather a bit more compatibility data for the territory between 16MHz/030 machines and CT60 machines (which is quite big gap!).

It runs at 32 or 40MHz (bus at 16 or 20MHz) so there is some room to check a few things.

I am also reminded that this 040 card seems to have very slow access to STRam. It was always the case but really stood out again in a benchmark just now. Probably some compromise in there to keep the 040 happy with its 'assumed' fastram design with burst mode and writebuffer behaviour.

[Badwolf]

In other news, my 68040-accelerated Falcon is finally working again so I should be able to gather a bit more compatibility data for the territory between 16MHz/030 machines and CT60 machines (which is quite big gap!).

It runs at 32 or 40MHz (bus at 16 or 20MHz) so there is some room to check a few things.

Nice!

I was given a couple of (sadly beaten up) LC040s by Steve. Not been brave enough to try to do anything with them yet, but it's getting tempting.

I am also reminded that this 040 card seems to have very slow access to STRam. It was always the case but really stood out again in a benchmark just now. Probably some compromise in there to keep the 040 happy with its 'assumed' fastram design with burst mode and writebuffer behaviour.

That would make me twitch. And now I'm intruigued.

Does the introduction to Frontier work well or are their graphics glitches as the palette changes mess up? It's my go-to test for ropey ST-RAM (and by extension motherboard register) access speeds.

Actually ignore me. You've enough on your plate ATM!

BW

[dml]

Here are some '040 results for comparison with DFB1 (taken in 640x480x2col VGA - video mode affects STRam access competition with Videl)

32MHz CPU, 16MHz bus:

68040-16-32.jpg (119.28 KiB) Viewed 1589 times

40MHz CPU, 20MHz bus:

68040-20-40.jpg (122.07 KiB) Viewed 1589 times

Note the STRam access times - particularly writes - are slower.

[Badwolf]

Here are some '040 results for comparison with DFB1 (taken in 640x480x2col VGA - video mode affects STRam access competition with Videl)
32MHz CPU, 16MHz bus:
...
Note the STRam access times - particularly writes - are slower.

Wow, look at those cache and floating point scores! That's the difference between the 030 and 040 right there.

Is the ST-RAM figure relative to 640x480x1bit VGA or is the VGA aspect of that sucking out some performance?

Anyway the noticable things there to me are that FastRAM read performance is better than DFB1 but write is slower. Which is odd as it's normally faster to write to SDRAM -- but this card might predate SDRAM?

Perhaps there's an inherant write limitation with this card that you're seeing in both ST and Fast RAM.

Still, very cool and I should like to have one.

BW

[dml]

Wow, look at those cache and floating point scores! That's the difference between the 030 and 040 right there.

It is pretty quick on some scores yes.

Is the ST-RAM figure relative to 640x480x1bit VGA or is the VGA aspect of that sucking out some performance?

I think the baseline is either 640x400x1bit or 640x480x1bit - I forget now, would need to try it on the 030 to see which one produces 100% for STRam. But the difference will be small. It's definitely a 1-bit mode for the reference measurements.

At the higher colour depths things begin to drag - it is even noticeable at 16colours in VGA.

Anyway the noticable things there to me are that FastRAM read performance is better than DFB1 but write is slower. Which is odd as it's normally faster to write to SDRAM -- but this card might predate SDRAM?

Not sure what kind of ram is installed - will be 60ns SIMMs but I need to check what kind. It is an old board though.

Perhaps there's an inherant write limitation with this card that you're seeing in both ST and Fast RAM.
Still, very cool and I should like to have one.

Probably there are some limitations yes, I think there was only one revision of the card and not many were made. I don't think it is flashable either.

[Badwolf]

I think the baseline is either 640x400x1bit or 640x480x1bit - I forget now, would need to try it on the 030 to see which one produces 100% for STRam. But the difference will be small. It's definitely a 1-bit mode for the reference measurements.

At the higher colour depths things begin to drag - it is even noticeable at 16colours in VGA.

Yeah, I've seen ST-RAM scores up at 6MB/s in some modes.

Not sure what kind of ram is installed - will be 60ns SIMMs but I need to check what kind. It is an old board though.

Ah yeah, that'll be DRAMs, then. Never worked with them so don't know their foibles. I think it was the SIMM to DIMM transition that saw the move from DRAM to SDRAM, wasn't it? I think that's when specs changed from nanoseconds to megahertz.

BW