Are you sure about the absolute memory addresses? That would be very strange, and poor programming on the part of the game developers. Changing CONFIG.SYS settings, loading a TSR in low memory, or adding environment variables would cause programs to load higher in memory; and if what you say is true then the saves would become broken on real DOS systems as well. If saves made in 0.73 cause problems in 0.74, I suspect there is a different issue. In cases where games are sensitive to load address, LOADFIX will often work around the problem; so I suggest trying various allocation amounts.

I could be wrong but I doubt the DOSBox devs support saved\installed games between DOSBox versions anyway.....

Memory start won't be user-configurable. Finish the game in the older dosbox or re-start all the fun in a newer one.

I installed Blood & Magic 1.01 in DOSBox 0.72, made several game saves from different campaigns in 0.72 and 0.73, and I can load them all in 0.74 with no problem. Didn't reinstall, just used the same installation; and default settings in all the DOSBox versions.

@ripsaw8080
With regard to your first post, I didn't change any of the things you listed. The problem happens deterministically in a stock 0.74 install with the unmodified B&M folder that I mounted in 0.73 as well. Will try your loadfix suggestion. As for your second post, that is pretty much the same test I performed as well, but every load of an old save game dies with:

Illegal read from 9dbb10e8, CS:IP 160: 2124a8

Illegal write to 9dbb10e8, CS:IP 160: 2124a8

Exit to error: INT:Gate Selector points to illegal descriptor with type 0

But I guess I have my answer from wd, even if it's not what I wanted to hear.

The things I listed were to illustrate why game developers would never use absolute addresses, because they are unreliable with changes in the environment. Protected mode descriptors would seem to make sensitivity to real memory start even less likely.

It is possible to change the memory start in 0.74 to be the same as earlier versions by editing the MCB chain in official 0.74, or changing the 0.74 source and compiling. That would be an interesting test to see if the saves load without error afterwards, but I cannot reproduce the problem.

nantoka can you enclose your savegames here?

I tried using loadfix with various amounts (32k increments up to 1M) but it didn't make a difference.
I compiled 0.74 with DOS_MEM_START set to the value from 0.73 and... it still dies. I'm not sure though whether that's all that needs to be changed to get the old behavior.
While playing around I also found that saves made under (the stock) 0.74 don't load in 0.73, so it goes both ways. I should have tested this earlier.
Here are two saves, 3.SAV and 4.SAV. The numbers correspond to the version in which they do not load, having been saved under the other one.

And finally, I realize that wd has already spoken and I don't mean to spam. Just hoping somebody can help me out.

Well it certainly won't be user-configurable if it doesn't even help 😉

How did you determine that it has to do with the dos memory start address?
There are a lot of other changes related to dos structure placements that may or
may not have an effect similar to the changed start address (and as ripsaw already
pointed out the start address is nothing that games would use for their save files).

@wd
Sorry, I didn't determine it with the granularity required to differentiate it from "other changes related to dos structure placements that may or may not have an effect similar to the changed start address". That's why I said that "I'm not sure though whether that's all that needs to be changed to get the old behavior".

As for "the start address is nothing that games would use for their save files", I don't mean that they use it directly, just that they seem to contain absolute addresses (encoded in whatever form), or in any case information that leads the game to such an address When loading a save game the game tries to access a memory location that only seems to depend on which save file I choose. It didn't change with the loadfix attempts or with changing (only) DOS_MEM_START, so it seemed to me that a location (presumably derived from the save file) was previously valid, but is now illegal because things have been moved around.

I put the save files in my BAM directory, but they do not show up in the list of saves that can be loaded. All the saves I made myself are still there, but slots 3 and 4 are empty like missing teeth. I checked with the DOSBox debugger, and the game is definitely opening all of the save files, including the ones you posted, but it is apparently refusing to recognize yours as valid. I guess this is happening because the saves are from a different version of the game.

I'm using the 1.00 US version on CD patched to version 1.01, which version are you using?

I'm using plain vanilla 1.0 US. I didn't experience any of the (two) problems the patch apparently fixes, and it also makes previous save games unusable... which seems to cause our current mastication issue.

You can try to see if the problem persists with saves created after patching. If you're not interested in doing that, I'll try an unpatched installation to see if I can reproduce the crashes.

I downloaded the patch from analogbit, replaced the exe as instructed, and now the game dies after the intro movie before the menu shows up with:

Can't find squib 7010 - 300
at line 138, file TEXT.CPP

So I can't even get to testing saves with the patch. Maybe there's something wrong with the version I have since I would have expected it to work with the patch, but I've used it for many years and never had any problem before this save game thing.