DFB1 BadMooD issues

[dml]

If the program is running from STRam, performing say, 1-3x 16bit memory fetches for every instruction, but most of those instructions are reading uncached data samples from FastRAM... it will be switching down constantly (or will be continuously locked at 16mhz, not sure?) but still trying to access FastRAM. If the instructions are reading individual bytes from FastRAM (like a string, or worse - a sound sample which can involve address skips) could something weird be happening which causes it all to run slower than it normally would from STRam only?

I don't really see how/why this would be the case, but if running instructions out of STRam causes some kind of weird additional bottleneck for FastRAM access it might cause the audio mixer to paint very slowly and produce frame overruns. But it would need to be a *lot* slower, at least 3-4x slower than normal for this to occur I think. There's plenty of CPU free normally at 16MHz for the mixer with current settings (because it has to be low-impact during gameplay).

Anyway I'll set up the 040 and see if I reproduce any of this. It does not switch down like DFB1 - but STRam is a bit slower than normal and the 040 doesn't like the way the STRam bus works in terms of cache filling and writes and so on.

[stephen_usher]

HDDriver 10+ does seem to do a lot of things in the background. It's probably setting up timers and all sorts of things which can cause problems for non-GEM/TOS programs. I've seen slow-downs to one key press actioned every minute with some of PP's game conversions on the TT which supposedly work with PP's driver.

I'm seriously thinking about switching to another driver at some point.

[Badwolf]

If the program is running from STRam, performing say, 1-3x 16bit memory fetches for every instruction, but most of those instructions are reading uncached data samples from FastRAM... it will be switching down constantly (or will be continuously locked at 16mhz, not sure?) but still trying to access FastRAM. If the instructions are reading individual bytes from FastRAM (like a string, or worse - a sound sample which can involve address skips) could something weird be happening which causes it all to run slower than it normally would from STRam only?

Yes, I think there could be a performance hit for infrequent TT-RAM access.

Let me think this through: The worst possible case is a solid block of ST-RAM accesses with a (byte) TT-RAM access right in the middle to an item that has no cacheable value but falls on a 16-byte boundary. The following would happen:

* The first read to TT-RAM would start slowly as there's a deliberate delay in switching up.
* The transaction would be marked as burstable.
* Burst mode would carry out four reads from TT-RAM (128 bits).
* I'd have to reaquaint myself with the logic, but I think that would be 17 clock cycles, the first two of which would be at 16MHz
* If there were no cachable value to the remainder of the read, or that cache line were overwritten by ST-RAM access later, 15 of those 16 bytes would be wasted.
* The bus would then switch back down to 16MHz, this does lose a cycle, but this is normally during a wait-state anyway, so should be cost neutral.

So I think the total TT-RAM diversion would take around 425ns, equivalent to 7 16MHz cycles. That's three cycles more than doing the same byte-read to ST-RAM.

So a slow down to 60% effective access speed with 100% burstable addresses and 100% cache miss. Worst case, therefore.

Looking at this, I think I've identified a few lost cycles in the burst logic (a result of this being based on Terriblefire's 330 controller, which uses a 100MHz clock) which I should optimise out, but that's for another day.

Disabling burst would, of course, change this worst case quite a bit. But it's a big assumption that everything is hitting burstable addresses and then the cache is being missed as well, so I doubt it woud be that big an effect.

Since I'm doing firmware work ATM, I can always disable burst in the firmware and see how she rides.

I don't really see how/why this would be the case, but if running instructions out of STRam causes some kind of weird additional bottleneck for FastRAM access it might cause the audio mixer to paint very slowly and produce frame overruns. But it would need to be a *lot* slower, at least 3-4x slower than normal for this to occur I think. There's plenty of CPU free normally at 16MHz for the mixer with current settings (because it has to be low-impact during gameplay).

Anyway I'll set up the 040 and see if I reproduce any of this. It does not switch down like DFB1 - but STRam is a bit slower than normal and the 040 doesn't like the way the STRam bus works in terms of cache filling and writes and so on.

Yeah, I dont' think we're into 0.33x territory, even at worst.

Cheers,

BW

[Badwolf]

HDDriver 10+ does seem to do a lot of things in the background. It's probably setting up timers and all sorts of things which can cause problems for non-GEM/TOS programs. I've seen slow-downs to one key press actioned every minute with some of PP's game conversions on the TT which supposedly work with PP's driver.
I'm seriously thinking about switching to another driver at some point.

There are a couple of things I don't much like about HDDriver 11, I have to say. If I can find my software and license I may go back to v8.3.

I own PP's driver, but it doesn't do XHDI, which is a must for me.

BW

[dml]

Yeah, I dont' think we're into 0.33x territory, even at worst.

That all ties with what I'd expect. It would need to be something more to cause the audio problems described.

Thinking of making some more specific test that simplifies what is going on in the game - but still knee deep in things this week. Maybe tomorrow or weekend I can do something here.

[Badwolf]

Thinking of making some more specific test that simplifies what is going on in the game - but still knee deep in things this week. Maybe tomorrow or weekend I can do something here.

No drama. It's a 'nice to know' item really. Setting the flags to run from TT-RAM seems to fix the problem. The music under HDDriver business is somethign I can research at my end.

BW

[dml]

I had a very brief opportunity to test a recent BM build on 040 - and while it does run, I do see some odd stuff going on...

The framerate is not consistent. It skips and stalls in a way that I did not see before on the vanilla machine or on the 060 machine. It is not super obvious, but I noticed it very quickly. It *might* be due to the 12Hz cap I enabled for 16MHz systems and trying to outrun that - but the BM0X0.TTP build should not have that cap in place. And the cap shouldn't behave like that anyway even if it is in enabled. So it is a bit strange IMO.

I can't check the audio unfortunately because that machine is in a CLAB case with 1/4" jacks on the back and my leads for it are not handy. Just looking at the strange frame skipping effect, I'm wondering if the audio has the same overrun problems you reported from DFB1...

I'm pretty sure it is running out of STRam at the moment (I did not check or change any prg flags yet).

Anyway nothing conclusive - just a bit suspect. I won't get time to look at it closely until later today or tomorrow. I'm kinda hoping it is the same issue as seen on DFB1 - it means I can probably fix it and may be one less thing for you to worry about too.

[Badwolf]

Anyway nothing conclusive - just a bit suspect. I won't get time to look at it closely until later today or tomorrow. I'm kinda hoping it is the same issue as seen on DFB1 - it means I can probably fix it and may be one less thing for you to worry about too.

Cool. Well not cool you have a problem, but you know what I mean.

I need to figure out a way to capture my VGA output then I can send you meaningful video. Or hook out by RGB capture setup.

BW

[dml]

So I have figured out what was causing the weird behaviour with the music enabled / running from STRam when allocating from FastRAM.

Short story - it is a bug in the code. And it has been fixed. (-_-)

It wasn't so much a bug as a build config fault - it was building with audio error prints enabled (warnings downwards disabled) and trying to print errors relating to sample addresses being outside STRam :-/ (which of course they are, for super Falcons). This debug stuff should normally have been compiled out but due to the broken build config, it was still spamming calls to vsnprintf which were not being caught by anything. And from an interrupt no less.

Anyway I'm still looking at other things ATM but at some point I'll roll a new build and hopefully it will work better this time!

[Badwolf]

So I have figured out what was causing the weird behaviour with the music enabled / running from STRam when allocating from FastRAM.

Short story - it is a bug in the code. And it has been fixed. (-_-)

The old printf()-induced slowdown, eh?

Been there & done that

Anyway, fantastic -- thanks for keeping on looking at it. I look forward to more trials as and when.

EDIT: actually, genuine question. If the PRG flags are set to not alloc from AltRAM, ought you honour that, do you think? I know you're bending the hardware to its absolute limit, but it does seem counter-intuitive to a bear with very little brain.

BW