Try memsize=31, which I often do with heavier games from the late 90's.

Running out of cache blocks can be avoided with core=normal, but then you will probably need more cycles, so perhaps cycles=auto (which translates to cycles=max for protected mode games).

thanks - i thought core on auto did usually just go to normal, but thats not the case clearly.

i just found another thread here about AF2 and that person found they had issues mounting an iso, and instead just copied the contents to a folder, so i have tried that and i ran through a whole mission with no ctd and no ctd on the map screens, so i wonder if that has somehow fixed things?

With a "typical" install of AF2, I'm seeing myriad file searches (FindFirst) during gameplay that are left hanging (FindNext never called), which can consume a lot of host memory but not sure it causes crashes... I haven't seen any crash yet.

Based on this finding, I suggest trying the helper program here in DOSBox.

thanks again for the help - did you run it by making a folder to put the cd contents in mounting that folder as d drive instead of an ISO? i do have the actual AF2 disk somewhere in my game collection, i havent tried it with that yet

I installed from a disc image as normal.

If you haven't tried it already, I suggest using a build of straight SVN source, as many improvements have been made to the dynamic core. However, as I mentioned before, running out of cache blocks can be avoided by using normal core, though depending on the host system it might be kind of slow for AF2.

update - looks like it still crashes even with teh cd contents in a "d" folder, i tried it also not with the program you suggested justyet, but i will. i was just trying it firstly with another suggestion i got - slowread.com which i think you also created. - Sadly it still crashed with the out of cache error, but i do have the core on auto still. i tried normal but the game unplayably slow,

i just doesnt seem fair that its either stable and too slow to play, or fast and smooth to play but prone to crash after about 5-10 minutes.

where can i get "straight SVN source" ?

The maintainer of the ECE build also provides builds of straight SVN source. There's a link to the website in the maintainer's signature: DOSBox ECE (for Windows & Linux)

The builds not labeled as "ECE" are the straight SVN builds.

okay although the game still crashes out with the core set to auto in the SVN build r4465, if i run the game with normal core and cycles at 100000 it actually is not too bad, it is faster than standard dosbox . the only thing is the sound gets a bit choppy, but no crashes which is good. I applied the ffclose program too not sure if that helps or not

oddly if i run it at auto then it plays at max cycles and is actually running with poorer frames but the sound is good

I've been using memsize=31, and no problems with cache blocks so far.

BTW, AF2's last patch is v1.03, in case you don't already have that version.

and is your core set to auto? yes my version is patched to 1.03

Yes, default settings except memsize, so DOSBox is switching to dynamic core due to core=auto and AF2 running in protected mode.

Which host CPU and OS are you running DOSBox on?

i am running dosbox on my windows 10 64bit system

i had my memsize still on 63 - i had on that from some earlier tests, i changed it to 31 and ran it on auto and no crash for the whole Rollout mission in the Provide Relief campaign - i hope this means the problem might be gone with the memsize on 31 - so memsize 31 can make all the difference? why not 63, which is a setting that i have seen as a default on a few dosbox games online that have dosbox packaged with them?

Well, wait and see how it goes after playing awhile, as there may be only a reduced frequency of the cache block problem.

Anyway, more memory is not always better in DOS games, because too much can and does cause issues in some cases.

if its less frequent i will be happy with that also

As a test of last resort for the use of the dynamic x86 core, it is possible to change a cache block setting from 32 to another value. I have not tested it, but a value of 16 may work. Here is one of the locations of the setting in core_dyn_x86.cpp:
block=CreateCacheBlock(chandler,ip_point,32)

If building dosbox on your machine, then it should be possible to select either the x86 or x64 dynamic core. The choice of dynamic core may affect the appearance of the cache block error.

I believe dosbox-x has a configuration setting for the above cache block setting value which does not require a code edit. However, it uses a different variant of the dosbox dynamic core and may produce different results.

thanks- i have dosbox-x and see in its conf settings that there is the entry
dynamic core cache block size=32

i did see this in teh SVN daum dosbox also - another version i was trying AF2 with, i was thinking i had to make the amount larger, but this had no effect on the crashing, - are suggesting it be smaller?

Lowering the max instructions per block would likely make things worse if you're hitting the max cache blocks limit (less instructions per block = more overall blocks).

oh okay, well maybe then make the dynamic core cache block size=1024? or some other much larger number?

ripsaw8080 wrote on 2021-09-15, 03:10:

Well, wait and see how it goes after playing awhile, as there may be only a reduced frequency of the cache block problem.

Anyway, more memory is not always better in DOS games, because too much can and does cause issues in some cases.

i have tried AF2 again and again no crash - completed the 2nd mission in the provide relief campaign, certainly it is looking good so far!