DFB1 BadMooD issues

[dml]

The memory sticks look like this:

ab40-ramstick.jpg

[Badwolf]

The memory sticks look like this:

Yeah, old school DRAMs. Probably 4 bits per chip. Similar to the ones causing Exxos all that grief over on his Falcon memory board thread. :-)

I think easier to work with in many respects than SDRAM (probably need less logic), but going the way of the dodo, alas.

BW

[Badwolf]

A thought struck me yesterday: when the music-enabled DFB-BM hangs (normally on loading the game after selecting a difficulty setting) it does so with no hard disc activity on the LED.

Recalling how TOS and MiNT (and EmuTOS for that matter) handle hard disc access differently, I thought I'd try to launch the game from MiNT.

So far it's worked every time from MiNT. Of course MiNT is then very unhappy when I reboot as the EXT2 partition is dirty after reset-to-quit, but that's an interesting data point.

Could point to disc/IO issues rather than sound per se?

Will try EmuTOS later.

BW

[dml]

Could point to disc/IO issues rather than sound per se?

Mmm. Maybe - what software are you using for the harddisk driver?

In fact, what software do you generally have loaded from AUTO when you test BM from TOS and see issues?

[EDIT]

But there is still something very weird happening because the 'music' is essentially always running, even when the music player is switched to MIDI mode, or even when it is turned off. The thing that runs on interrupts and does the work is the mixer and that is shared between the music player and the sound FX. So when music is off, it is still mixing to serve the SFX.

The difference is that it will not be injecting as many events into the mixer (callbacks to the music pattern seeker from the mixer) and so the mixing time is less per audio frame. I can't think of anything special about the playing of the music that would affect anything, except the mixer takes a bit longer.

Although, with music on there is an extra load event to actually load the music track. If that failed it might crash or do something bad. But again, not clear why it would fail to load the music in accelerated mode but work happily at 16mhz. It's the same code that loads everything else.

But if it works from MiNT... it is interesting. Even if it still doesn't make a lot of sense :)

[Badwolf]

Could point to disc/IO issues rather than sound per se?

Mmm. Maybe - what software are you using for the harddisk driver?

In fact, what software do you generally have loaded from AUTO when you test BM from TOS and see issues?

• HDDRIVER 11
• MAPROM2.2
• NVDI
• FALCDATE*

NVDI needed for TT-RAM on Falcon.

BW


*Small program of mine that sets NVRAM [and tries to set the date/time if a network is present].

[dml]

What does maprom do? Copies TOS into RAM?

[Badwolf]

What does maprom do? Copies TOS into RAM?

Declares TT-RAM and PMMU's it into RAM.

Have tried with FASTRAM2.2 too (the same program but without messing with ROM & PMMU) which made no difference.

BW

[Badwolf]

What does maprom do? Copies TOS into RAM?

Declares TT-RAM and PMMU's it into RAM.

Have tried with FASTRAM2.2 too (the same program but without messing with ROM & PMMU) which made no difference.

BW

Just tried with EmuTOS (no MAPROM/FASTRAM or NVDI needed) and it's a sample size of one, but it's worked well here. Just completed first level with lots of gratuitous shooting to make more noise. :P

EDIT: tests done with 'D' program for best chance of running, I figured.

BW

[dml]

Just tried with EmuTOS (no MAPROM/FASTRAM or NVDI needed) and it's a sample size of one, but it's worked well here. Just completed first level with lots of gratuitous shooting to make more noise. :P

EDIT: tests done with 'D' program for best chance of running, I figured.

Presumably this successful test is not using FastRAM though, if it hasn't been declared by your other programs?

[Badwolf]

Just tried with EmuTOS (no MAPROM/FASTRAM or NVDI needed) and it's a sample size of one, but it's worked well here. Just completed first level with lots of gratuitous shooting to make more noise. :P

EDIT: tests done with 'D' program for best chance of running, I figured.

Presumably this successful test is not using FastRAM though, if it hasn't been declared by your other programs?

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.

BW

EDIT: put MAPROM in as well (so same configuration as TOS4 -- although MAPROM doesn't declare TT-RAM now it still fiddles the PMMU) and it still fires up and runs well.Very slow to load, but I think that's because the EmuTOS buffers are quite small (see previous discussion surrounding Basilisk II under EmuTOS).