DFB1 BadMooD issues

[dml]

Bizarre! Utterly bizarre!

There are too many moving parts in the C version. While the C part 'does the same thing' as the 68k version, the binary is 99% GCC libs and an executable packer loader on the front (which probably clears the i-cache to depack the program - no idea what else it decides to do if it sees TTRam for example).

I should have been less lazy and just did it in 68k in the first place :)

[Badwolf]

There are too many moving parts in the C version. While the C part 'does the same thing' as the 68k version, the binary is 99% GCC libs and an executable packer loader on the front (which probably clears the i-cache to depack the program - no idea what else it decides to do if it sees TTRam for example).

I should have been less lazy and just did it in 68k in the first place :)

Yes, very odd. TT-RAM oughtn't be to blame as none was declared in any of these tests, but something is different, clearly!

Anyway, to cut a long story short, TOS (4.04 at least) seems to re-enable caches and burst after every program termination.

Cheers,

BW

[dml]

It might be worth giving the new release of BadMooD (v1.01) another try, using new test binaries and config file for DFB1.

Here is the full initial release:

https://www.dropbox.com/s/1p71rrw85wnkx ... a.zip?dl=1


Here are the new binaries made for DFB1/CT2 class of 68030+FastRAM boards.

https://www.dropbox.com/s/vdquawh5n6jya ... s.zip?dl=1

You will also find a new config file 'default_dfb1.cfg'. Please replace the existing 'default.cfg' with this (i.e. rename it to 'default.cfg' and replace the one from the full release zip).

If in doubt, there is a SETUP section on the BM wiki here: https://bitbucket.org/d_m_l/badmood/wiki/Home



There are 4 experimental DFB1 binaries in the .zip. I'm trying to cut down on the turnaround/attempts since there are timing issues involved.

BM03XA.TTP - minimal DSP handshaking (fastest, least likely to run without ingame hangs)
BM03XB.TTP - moderate DSP handshaking
BM03XC.TTP - increased DSP handshaking
BM03XD.TTP - pedantic DSP handshaking (slowest, most likely to run without ingame hangs)

I'm hoping the 'B' build will cover it - but lets see what happens, if anything. There are still some tweaks I can do to improve compatibility or speed e.g. using the CPU to draw floor/ceiling textures instead of DSP, which is the current setting for the 060 builds (the 060 is quick at it).


Some extra info:

These binaries are all built to use FastRAM if found. They also avoid touching the blitter and the PMMU.

They don't cap the framerate to 12Hz as is the case for a stock Falcon (upper limit is 35Hz), but I don't know what sort of framerate we can expect from accelerated 030s as the game AI will also be trying to run 35Hz catchups and that is quite expensive. I expect running it in high detail mode will not be a great choice - even the CT60 struggles with direct drawing in fullscreen over the STRam bus. The current settings should be ideal for 50MHz 030, if it works at all.

The default_dfb1.cfg just disables the VGA tweaks (which can cause no-sync display on some monitors) and increases the audio quality/polyphony a bit for the accelerated system. 3D positional sound etc.

If anyone has success with this, please let me know. I don't have a DFB1 (or CT2) to test it myself :)

[Badwolf]

If anyone has success with this, please let me know. I don't have a DFB1 (or CT2) to test it myself :)

Cool! Will endeavour to give these a go this evening. :-)

And damn. I just gave away my last card. ;)

BW

[Badwolf]

Tests carried out in VGA mode using TT-RAM from plain TOS.

BM03XA.TTP - minimal DSP handshaking (fastest, least likely to run without ingame hangs)

Runs to intro screen. Music seems to be in slow motion. Keyboard works but unresponsive. Crashed when trying to start game. Eye flash on skulls not visible (frame rate).

BM03XB.TTP - moderate DSP handshaking

As above but didn't crash on trying to start, just froze although slow-mo music continued this time.

BM03XC.TTP - increased DSP handshaking

Music in slow mo, skull eyes changing slowly (one frame per 3-4 seconds?). Got to 'Hurt Me Plenty' option. Music continues, but nothing happens.

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

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

These binaries are all built to use FastRAM if found. They also avoid touching the blitter and the PMMU.

Running without TT-RAM freezes after 'change in statusbar: 0->1'.

Setting aud_quality 0, no change.

Sorry it's not better news.

BW

[dml]

Sorry it's not better news.

Well thanks for trying, but it doesn't leave me with many clues as to what is going on. In fact there are issues here I have never had reported before and don't really make much sense either. (Music in slow-mo? o_O)

The closest thing I have to DFB1 is a 68040 card, which I will test as soon as it is back in action - but TBH these issues don't sound exactly like what I would expect from a system compat. or timing issue of any kind. Something is off.

The game is running on base 030, in Hatari (various configs) and on 060 now (I tested these latest builds too in Hatari before linking them) and while there have been some minor issues on 060 which could cause hangs going into the game or ingame, those have been resolved. I have seen nothing like this combination of effects.

If there were similar hangs on DFB1 ingame I would probably have submitted a new build with the floor rendering switched to CPU, as with the 060. But reading this report, I doubt that will help at all if the music replay is already broken.

I'll mull it over for now. Will post if I have any other ideas. Again, thanks for taking the time to try.

[exxos]

The sound playing slow sounds odd. Does the sound run on the DSP then @dml ?

I wonder if there is some other DSP sound tests which come be done?. Or maybe just compile the sound routine to loop a sample to see if it still acts up ?

[Badwolf]

The sound playing slow sounds odd. Does the sound run on the DSP then @dml ?

I wonder if there is some other DSP sound tests which come be done?. Or maybe just compile the sound routine to loop a sample to see if it still acts up ?

TBH, it *sounds* slow. I don't actually know what it's meant to sound like. Ties in with slow frame rate, mind.

Let me toggle off DFB1 and try it...

EDIT: *gah*. I forgot I have a 4MB card in! That's why it hung with TT-RAM undeclared :oops:

@dml I don't suppose it needs 14MB ST-RAM even with TT-RAM present does it? Could that cause the effects I saw?

BW

[dml]

The sound playing slow sounds odd. Does the sound run on the DSP then @dml ?

I wonder if there is some other DSP sound tests which come be done?. Or maybe just compile the sound routine to loop a sample to see if it still acts up ?

The DSP is heavily used for rendering and 3D but the audio is handled entirely by the CPU and TimerA / DMA frames. I can't think of a reason it should run slow. But it sounds like it might be connected with DMA or Codec or MFP in some way... it is very weird.

TBH, it *sounds* slow. I don't actually know what it's meant to sound like. Ties in with slow frame rate, mind.

i just tried it a few minutes ago on the stock 16MHz Falcon and I do see very slow menu refresh - this is mainly because the Doom game is trying to run the game stuff at a constant 35Hz and the menus can't keep up. So perhaps that part is me making a bad choice re: the 35Hz ticrate (which is what I use in the 060 builds).

But still, the audio runs correctly here even on the stock machine, with the supplied config (stereo + quality=1). And it loads the game and runs (slow for that build on that machine config, but it runs).

.
EDIT: *gah*. I forgot I have a 4MB card in! That's why it hung with TT-RAM undeclared :oops:

@dml I don't suppose it needs 14MB ST-RAM even with TT-RAM present does it? Could that cause the effects I saw?

I don't think so. I run the 060 tests with a 4MB card.

However.... if it for some reason can't claim the TTRam and falls back to 4mb... then yes it will struggle and will probably die.

When the game boots, in the first few lines of console text it shows how much RAM has been claimed in total. On a 14MB machine its normally around 11000-12000k (12mb). On the 060 it claims about 260MB. Would be interesting to see what it is claiming on DFB1, I didn't think of that.....

[Badwolf]

The DSP is heavily used for rendering and 3D but the audio is handled entirely by the CPU and TimerA / DMA frames. I can't think of a reason it should run slow. But it sounds like it might be connected with DMA or Codec or MFP in some way... it is very weird.

Perhaps slow is the wrong word and 'stuttering' is better?

It's like the tempo is up and down with some notes playing multiple times.

When the game boots, in the first few lines of console text it shows how much RAM has been claimed in total. On a 14MB machine its normally around 11000-12000k (12mb). On the 060 it claims about 260MB. Would be interesting to see what it is claiming on DFB1, I didn't think of that.....

13157K, so definitely using TT-RAM in this case.

BW