DFB1 BadMooD issues

[dml]

EmuTOS declares its own TT-RAM, hence neither FASTRAM or MAPROM needed & it has software blitting available so it doesn't need NVDI either.

However I've just run it with NVDI too and that's also good.

Ok that's a handy feature.

Trying to figure out what the common factor in all this is. So far, not seeing it.

Some combination of TOS+NVDI and FastRAM, for reasons that are not clear. Maybe it does have to do with NVDI in some way. I normally test on clean boots on the stock machine and the CT60 has its own blitter hacks.

Still not clear why the FastRAM+NVDI combo would specifically annoy BM, specifically when loading music vs no music o___O.

[EDIT]

I think the next step for me here is to review use of sys vectors used and look for potential conflicts, put more stuff under build config switches and see if that helps.

[Badwolf]

I can boot into a command prompt and run from there (no NVDI needed). I wonder if it’s my HDDriver config? EmuTOS bypasses HDDriver and MiNT does its own thing with file systems.

BW

[dml]

I can boot into a command prompt and run from there (no NVDI needed). I wonder if it’s my HDDriver config? EmuTOS bypasses HDDriver and MiNT does its own thing with file systems.

I kind of ignored HDDriver in the mix because I use it myself - although I have an older version (8.x or something, need to check)

[EDIT]

If there is an issue between BM and HDDriver (recent or any version) it is odd that it would appear to load some files but not others, particularly music files. And odd that it would be fine without FastRAM mapped. Still weird.

[Steve]

I can boot into a command prompt and run from there (no NVDI needed). I wonder if it’s my HDDriver config? EmuTOS bypasses HDDriver and MiNT does its own thing with file systems.

I kind of ignored HDDriver in the mix because I use it myself - although I have an older version (8.x or something, need to check)

Dml, later versions (after 10x) of hd driver added interesting performance features like 'load hd driver into TT ram' and 'enable blitter for disk transfer speed increase', two potential performance features that could potentially conflict with BadMood.

I have a feeling that I tried BadMood with the blitter transfer feature enables once and it didn't work.

[dml]

Dml, later versions (after 10x) of hd driver added interesting performance features like 'load hd driver into TT ram' and 'enable blitter for disk transfer speed increase', two potential performance features that could potentially conflict with BadMood.

Interesting...

I have a feeling that I tried BadMood with the blitter transfer feature enables once and it didn't work.

I can imagine that being the case, especially if disk events occur during a cooperative blit.

[Badwolf]

I'll have a think if I can side-load an older HDDriver version.

So many options in the later versions I don't know what half of them do.

BW

[Badwolf]

I'll have a think if I can side-load an older HDDriver version.

Didn't have an old HDDriver, but loading AHDI from floppy, then running FASTRAM then running BM 'D' works well.

Next test (probably Wednesday now) will be how that configuration works with BM 'D' set to run from ST-RAM (which caused massive slow down previously).

BW

[Steve]

@Badwolf might be worth checking those two options I mentioned. I think the blitter transfer is under the performance menu, alt ram option is under general preferences.

[Badwolf]

Cheers, @Steve. Will give them a go once I've tested these other combinations.

@dml: with AHDI side-loaded. FASTRAM declared after boot and program flags removed (so it loads to ST-RAM but has TT-RAM present for you to do your worst with) it does run but I get that stuttering music and terribly bursty frame rate again.

So the crashing does appear to be HDDriver related, but the stuttering seems to be when TT-RAM is available but the PRG flags aren't set to load into it.

BW

[dml]

So the crashing does appear to be HDDriver related, but the stuttering seems to be when TT-RAM is available but the PRG flags aren't set to load into it.

Thanks for digging deeper. More bizarre results, but at least a consistent picture is forming sort of!

I can try the same experiment here on the 040 to see what happens - run from STRam but allow allocs from FastRAM.

The music/sound uses the following hardware/resources:

- 16bit/2ch DMA playback (routed from STRAM to Codec, the framebuffer is MXAlloc'd from STRam only)
- MFP TimerA triggered on DMA frame end/loop

There isn't really anything else going on there. All blitter use is disabled in the 'D' build so it can't be contributing in any way.

I scanned through the sources again earlier looking for badness and the only item I came up with is messing with sys vector $176/TT-clock as short address register, but as far as I can tell it is unused by TOS on F030 (unless HDDriver decides to do the same, albeit very very unlikely). I could make another build which avoids that but I'm not confident its going to change much. Better to to hold off until something more likely shows up and i can roll it in then.