DFB1 BadMooD issues

[exxos]

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.

Video it ;)

[dml]

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.

It sounds like audio frame overruns, where the CPU can't paint the audio buffer fast enough (every 20ms) and it misses a DMA frame interrupt, so you get cuts, stutters, jumps and overall the tempo is lower.

This can be reproduced by increasing all the audio settings to max on a 16MHz system (49khz, 9 channel stereo), it will occasionally drop audio frames. But it takes a few seconds before it is noticed, and then repeats a few seconds later.

For it to happen obviously and continuously with normal settings.... hard to explain.


Something which could cause this is the CPU being denied timely interrupts due to some other effect going on, e.g. as a result of large blocks of writes constantly across the STRam bus (which the menus will do).

This is actually what happens if the blitter is used in HOG mode for significant spans of time - interrupts get delayed or lost because the CPU is locked out of the bus. This shouldn't happen normally though for CPU writes (as is the case here). Unless 'burst mode' suddenly started working across the STRam bus. But that's very unlikely to happen by accident :)

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

Yes that looks normal.

[dml]

.... burst mode.

I recently enabled burst mode for 030 builds, because - it has no effect on a normal Falcon, its basically ignored by the Falcon memory interface.

I enabled it for the benefit of the DFB1 mainly. That was back around the time that test builds seemed to be somewhat semi-working (if not stable, and with no-sync video issues). I don't think it has ever worked since.

I wonder if enabling that was actually not such a good idea here? It seems an unlikely source of problems, but DFB1 does actually have logic for burst mode and I have no experience seeing what it does in this context, transferring pixels from TTRam to STRam in huge blocks without a break.

[Badwolf]

.... burst mode.

I recently enabled burst mode for 030 builds, because - it has no effect on a normal Falcon, its basically ignored by the Falcon memory interface.

I enabled it for the benefit of the DFB1 mainly. That was back around the time that test builds seemed to be somewhat semi-working (if not stable, and with no-sync video issues). I don't think it has ever worked since.

I wonder if enabling that was actually not such a good idea here? It seems an unlikely source of problems, but DFB1 does actually have logic for burst mode and I have no experience seeing what it does in this context, transferring pixels from TTRam to STRam in huge blocks without a break.

Have subbed out my 4MB card for my 14MB one and at least it runs when in ST-RAM only mode (just tried 'D' so far). I still have that burst toggle program around here somewhere -- I can give that a go later (probably tomorrow or Wednesday now).

Music is good. Frame rate in menus much better.

Will run a few more combination tests too.

BW

EDIT: 'A' works in ST-RAM only mode too.

EDIT: Burst off makes no difference.

EDIT: 16MHz mode + TT-RAM. No change.

EDIT: changing the flags of the program to run from and allocate from TT-RAM (they were all cleared previously) caused the menu and music to work beautifully in the 'D' variant right up until the point it hung with the music stuck on game launch :lol:

[dml]

Have subbed out my 4MB card for my 14MB one and at least it runs when in ST-RAM only mode (just tried 'D' so far). I still have that burst toggle program around here somewhere -- I can give that a go later (probably tomorrow or Wednesday now).

Music is good. Frame rate in menus much better.

Ok, thanks for the extra tests.

EDIT: 'A' works in ST-RAM only mode too.

EDIT: Burst off makes no difference.

EDIT: 16MHz mode + TT-RAM. No change.

I don't think you'll be able to disable burst because the game enables it after taking exclusive control over CPU. For a toggle I'd need to put it in the .cfg or just leave those CACR bits as-is. I'll consider either disabling it or putting it on a switch.

But it is strange that things work when run from STRam.

Could there be something funny/special going on with the DFB1 bus when source=TTRam, dest=STRam and the transfer is aligned? Could it be trying to burst-control across the STRam bus, because the source is TTRam?

[dml]

FWIW, here's a build with safe-as-possible settings. I'll check in tomorrow in case anything changed.

https://www.dropbox.com/s/b49klsaqczr24 ... E.ttp?dl=1

Like the plain 030 version
- 12Hz game timebase (not 35Hz as with the experimental builds)
- cache burst mode off

Like the hatari version:
- avoids MMU
- cooperates with TTRam

Like the 060 version:
- avoids DSP for texturing
- adds DSP handshaking
- avoids blitter

[Badwolf]

I don't think you'll be able to disable burst because the game enables it after taking exclusive control over CPU. For a toggle I'd need to put it in the .cfg or just leave those CACR bits as-is. I'll consider either disabling it or putting it on a switch.

Ah, fair enough.

But it is strange that things work when run from STRam.

Yes, that’s the real head scratcher. You’d think perhaps it’s speed related, but then slowing down TT-RAM made no difference.

Could there be something funny/special going on with the DFB1 bus when source=TTRam, dest=STRam and the transfer is aligned? Could it be trying to burst-control across the STRam bus, because the source is TTRam?

Burst is only ever about cache filling and it can only ever happen when STERM is used to terminate a cycle. Impossible on a 16 or 8 bit bus, so definitely not affecting either writes or any ST-RAM access.

The only thing i could think of is a strange corner case interaction between TT-RAM accesses and DSP accesses. The DSP handling code was the last thing to work on DFB1 on account of the DSP being peculiar in latching data on a rising chip select edge and the Falcon’s expansion port lacking the A0 line, necessitating it to be derived by the GALs which would normally stop deriving it on the rising edge of the chip select signal… you see the problem.

So, long story short, DSP access is an odd special case. The result is it’s a slower access with DFB1 at 50MHz than the stock Falcon at 16. We seem to get away with it for the most part, but perhaps interlacing lots of DSP writes (slower than normal, chip at 16) with TTRAM (fast, up to 50MHz) is messing with the effective throughput?

Dunno, clutching at straws now!

BW

[exxos]

Have you tried running ACE TRACKER @Badwolf As I think it uses the DSP.

[Badwolf]

Have you tried running ACE TRACKER @Badwolf As I think it uses the DSP.

Using the DSP is fine. I spent months getting it to be fine. ;)

I was wondering if a cycle counting/timing critical DSP<-->TT-RAM interaction was fouling up, that's all.

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.

BW

[exxos]

Using the DSP is fine. I spent months getting it to be fine. ;)

Tried running it from alt-ram as well ? Not sure if it supports alt-ram but may help rule some stuff out :shrug: