Differences between slow & fast ram giving 103 error
 

Not sure if this is the right place to post this query...

Anyway, I have an exe with some code,code_f,data & data_f sections

It is giving a 103 error in WinUAE with 1/2 meg chip and 1 meg fast ram

But it is loading fine with 1/2 meg chip & 1/2 meg slow ram

What could cause this difference of behavour ?

I am not very clued up on AmigaDos stuff really

Hi Dan, this is strange..
You sure there isn't some _c sections?
Can you upload somewhere the exe? (can suffice only the header if you want)

There is no difference between slow(ranger) RAM and real fast RAM
if you use the _f bit on exe header (the memory with the highest priority is used first if there are both).

Why you used? code_f and data_f hunks? code and data is enough. I dont remember exactly but _f hunks will be loaded only in fast mem, and this is problem for Amigas with 2MB chip only.

ah.. my mistake... I use code and data and data_c only

That doesn't really make sense. Are there any other differences in the WinUAE configurations? Or do you really only change the RAM settings?

Ok, then it is possible that it happens.
The reason is that in some configurations the supervisor stack, and/or exec.library and the expansion.library can be located in chip mem (especially configuration with fast ram not autoconfig).
Even with that little difference some exes that require a lot of chip-ram give error 103.

Ok.. that makes sense

I have a 224k chip ram "area" reserved, that I allocate within using my own memory allocator

And there is around 160k for the music module too

so It's about 384k chip ram used.

With KS1.3 512KB chip-ram, Z2 RAM, DF1 online, you've ~420KiB usable (just checked :))
It's the worst situation, you've supervisor stack, exec and expansion in chip ram.

So this is probably it... chip mem usage causing the 103 on fast ram configs

Need to optimise chip mem sections and try to reduce to under 420k

It should be around 385k as noted above, but there could be some stray section in another coders part... I will investigate..

I always prefer to use BSS_C or Data_C hunks/sections than normal memory allocation.At begining you can see if enough memory is available to use. And code is shortest too :)

There is a stray (unaccounted for) 58608 byte chip section that I can't currently locate :D

This is the issue