*WimpSlot ignores the -max value

Repro, tested on IOMD and Pi builds:

F12 from desktop
WimpSlot -min 640k -max 2048k
BASIC

This should set the current WimpSlot to 2048KB if available, with BASIC reporting slightly less. Instead it’s always 640KB

WimpSlot only aims to make sure the slot size is between the min and max values. I.e. if the slot size is less than the minimum it will increase it (and error on failure), and if it’s greater than the maximum it will decrease it. So if your next slot is set at the default of 640k then it’s perfectly valid for your repro steps to leave you with a current slot size of 640k.

Ah, in that case I’ve completely misunderstood how *WimpSlot works – possibly along with most game developers going by the amount that use differing -min / -max in their !Run scripts.

Is there a trick you can use to get it to allocate the max?

Is there a trick you can use to get it to allocate the max?

You mean the maximum available regardless of whether it needs it?

No, neither should there be.

I’m not sure if there is a trick, other than using WimpSlot <some_huge_number> and ignoring the error – it still moves as much memory as it can before it gives up with the error. But pre-RiscPC there isn’t a convenient way of ignoring the error, which probably explains why so many games shipped with utilities which mess with DA sizes before they run the main game.

On RiscPC and above you get things like the ‘AppSize’, ‘AppSlot’, ‘X’, etc. commands to make this easier.

Jon,

I could be barking up the wrong tree here, but I seem to recall some old applications having WimpSlot trouble when Acorn switched to 4KB page sizes. Remember the MEMC approach? The page size varied with the amount of RAM, so as machines got more RAM it was easy to be slack and rely on your WimpSlot requests being rounded up to the next 32KB.

So these old games might be making an Archimedes 310 or 440 assumption on a Risc PC or Pi. Maybe?

Mmm, I don’t recall what it was, but about a year ago I ran into something that was crashing with an unaligned address. Turns out, it was making assumptions about the page size which would have worked with a 16 or 32K page, but resulted in unaligned offsets with 4K pages.

I could be barking up the wrong tree here, but I seem to recall some old applications having WimpSlot trouble when Acorn switched to 4KB page sizes.

Indeed and a very good point, I should probably round all memory requests to 32KB boundaries when emulating RO3.11 or lower. Games get tested on all hardware platforms and every major Acorn OS version, so WimpSlot issues usually get picked up fairly quickly.

The only memory allocation issues I’ve seen are around Sprites. They seem to take up more memory on RO5 than previous OS versions, I haven’t looked into why that is, I’ve simply cheated and allocated double what the game requests.

No, the issue I’m having is that I’ve spotted a few games (Carnage Inc for example) that use something along the lines of:

WimpSlot -min 640K -max 2048K

The game then checks the memory via OS_GetEnv and if it has 2MB it will run an enhanced version, with say samples and music. Depending on the Next slot setting in the Wimp, it may end up running the lowest cutdown version in 640K, as its not getting the 2MB its requested.

I’ll code my own version of *WimpSlot which attempts to allocate the max requested, not a big issue now I know it’s expected behaviour.

They seem to take up more memory on RO5 than previous OS versions

My complete guess would be something to do with alpha transparency values.

I wish there was a SpriteOp that I could say “I want a sprite this big, in this resolution, and with this type of mask” and it would tell me how much space I would need to allocate to hold the sprite.
Working it out by hand is….complicated.

Jon,

I remember Saloon Cars Deluxe having something similar. The instructions said you had to manually increase the wimp next slot before running the game, and that would force the ‘2 megabyte mode’. So maybe it was always a manual process?

I suppose coding a replacement WimpSlot command of adding some more complexity to the boot script would do it. With an additional boot script, I guess you could offer easy access to both variants of a game?