DFB1 BadMooD issues

[dml]

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.

That flag just changes default behaviour of Malloc. BM use MXAlloc to claim STRam and FastRAM to its own chunk allocator on startup and it decides itself from that point onwards which type it prefers for different jobs. So the alloc-from-AltRam flag is more or less ignored.

The run-from FastRAM flag however is observed, because it happens before the program gets to decide anything itself.

[dml]

@Badwolf

Here is a new build with the music/fastram bug fixed and some minor changes. The archive is executables only - just replace the existing binaries from BM v102 package.

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

These are the standard binaries (bm03x is the closest 'standard' build for DFB1 but I suspect it will not be stable without additional DSP handshaking)


And these are some additional builds - variations on bm03x binary with increasing levels of DSP handshaking (bm033 = full handshaking, but also the slowest as a result).

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

I have no idea which one is best to begin with but at a guess I suspect bm031 or bm032 is going to be the safe territory for that config.


If any of these work properly, I can spin another version with the framerate cap lifted - but there's not much point until we have a stable version to work with.

All of the builds allow FPS counter to be enabled with F9 key to help you make some comparisons, if any difference is noticed. But make sure you have a working FPU before doing that - the builtin profiler and framecounter use that. Main reason I ship builds with that disabled now!

(Real performance comparisons are best done with music off since the cost of the music varies a little with time and with the track)


I have set the music/sound config to standard in the default.cfg, except that stereo is enabled. I think you can probably also increase audio quality to at least '1' but lets not change too many things at once initially

No hurry for testing these - whenever you find the time!

[Rustynutt]

Here are some '040 results for comparison with DFB1 (taken in 640x480x2col VGA - video mode affects STRam access competition with Videl)

32MHz CPU, 16MHz bus:


68040-16-32.jpg


40MHz CPU, 20MHz bus:


68040-20-40.jpg


Note the STRam access times - particularly writes - are slower.

At 46MHz, ST RAM performance is at F030 bench

[dml]

At 46MHz, ST RAM performance is at F030 bench

It's annoying, isn't it Not sure what is causing the slow writing but its either baked into the MACH chips or maybe the way I marked pages for STRam, which should be marked cacheable, non-serialized. The HW regs need to be non-cacheable, serialized. I'll check it at some point but no idea where the source for it is now.

[Badwolf]

No hurry for testing these - whenever you find the time!

Just done some very basic initial testing as I only had 1.01u and I was scratching my head about the WAD not found message for a while before then spending ages extracting the new one

So far:

• BM030 does work under RGB mode, but won't sync in VGA when tries to switch to the splash screen. prgflags unchanged;
• BM03x seems great in both RGB and VGA configurations and with flags as default then with everything set (fast load, load into tt-ram, alloc from tt-ram);
• BM0x0 never gets to the splash screen in any video configuration, haven't changed prgflags;
• Music working as expected.

Not done any proper benchmarks yet although the FPS counter works well when tested. Could hit the frame rate limit in F5 mode (wide pix), but not in high def.

Fuller tests with numbers & additional builds to come as and when

BW

[dml]

[*]BM030 does work under RGB mode, but won't sync in VGA when tries to switch to the splash screen. prgflags unchanged;

It may have just died. There is no difference between BM030 and BM03X in terms of VGA stuff. Any VGA tweaks are set by the config file only and the tweaks should be off.

It can just randomly freeze on a black screen going into the game though, due to DSP sync issues.

[*]BM03x seems great in both RGB and VGA configurations and with flags as default then with everything set (fast load, load into tt-ram, alloc from tt-ram);

Ok that's promising. I wasn't sure if the first attempt at this one would work.

[*]BM0x0 never gets to the splash screen in any video configuration, haven't changed prgflags;

This one won't work because it uses 040/060 instructions.

The only one I expected to work from the 'standard' binaries zip is the BM03X build. If that failed, then some stricter handshaking variations on it were in the other zip to try. But perhaps they are not needed.

Not done any proper benchmarks yet although the FPS counter works well when tested. Could hit the frame rate limit in F5 mode (wide pix), but not in high def.

Ok that sounds sensible so far. Thanks for the feedback!

[Rustynutt]

At 46MHz, ST RAM performance is at F030 bench

It's annoying, isn't it Not sure what is causing the slow writing but its either baked into the MACH chips or maybe the way I marked pages for STRam, which should be marked cacheable, non-serialized. The HW regs need to be non-cacheable, serialized. I'll check it at some point but no idea where the source for it is now.

Have a copy of the ToolKit Source. I'm not sure "which version" it is.
There was a point where John Klockens was integrating it to be more NOVA aware, maybe including the driver's in the tool kit.
I'll find it, it's still an attachment via email. I can send it to the one on your laser page if still valid.

[dml]

So I posted an update to BadMooD v1.02 over on AF, but the d/l links are here:

The 'essential files':

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

The optional, pre-build cache dir, for those with really fast transfer/unzip capability (otherwise, don't bother - let the Falcon build the cache for you)

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


This release includes a binary for DFB1/CT2 machines (called BM03X.TTP).

At this point I think (hope) the big data files are settled. Any compat/stability fixes needed should affect the TTP files only, which I would provide as updates. If this doesn't work for you with DFB1 I can iterate further but this build is based on recent tests with BW's DFB1 and should work for the most part, without additional updates. Just keep in mind I don't have access to one of these boards so fixes are made with cooperation, or based on some comparisons/estimates from AB40 or CT60.


Extra details on changes over on the AF post but most of these are MIDI related. Will update the repo/wiki when the dust settles.

[Badwolf]

So I posted an update to BadMooD v1.02 over on AF, but the d/l links are here:

Thanks, Doug.

Really sorry, not had any chance to benchmark all the test builds yet.

BW

[dml]

Really sorry, not had any chance to benchmark all the test builds yet.

No need to worry about that - it's not holding anything up. The main thing is to ensure its working properly before I write it up as 'supported' on the wiki. And no hurry for that either!