OS_DynamicArea,0 API incompatibility

Can somebody explain why it was decided to make OS_DynamicArea,0 incompatible with RO4/6 as late as 2015?

No scrub that. Can someone explain why it is necessary to have the cache policy in area flags 12-14 and DMA in 15 when RO4/6 already had DMA in 12 and other useful things in 13-15? Why could cache policy not have been put in some unused bits in the area flags?

What is the proposed solution to the incompatibility – is there one? It is trivial to move the flag bits around – I added OS32_DynamicArea some time ago so the RO4/6 API can continue to be used on RO5, and its flag remap is eight instructions, putting cache policy in bits 21-23.

OS32 was created back in 2001 to allow programs to be easily patched to avoid the infamous 26bit APIs, which is fair enough for hardware incompatibility, but I didn’t intend to use it to get around wilful API destruction.

For reference, cache policy in bits 12-14 was introduced sometime between February and October 2002, making it a feature in the first version of RISC OS 5 to ship with the Iyonix in October. Meanwhile ROL’s documentation indicates that bit 12 was a RISC OS 4.04 feature, dating it to January 2001

So the answers to some of your questions will likely depend on what the situation was like between ROL and Castle/Pace/Tematic at that point in time.

Ah, thanks for the clarification. Seventeen years of divergence on this one. Does that mean nobody (outside OS developers) ever used Heaped DAs and next to nobody ever sets Cache Policy?

Missing functionality can be provided, but divergent bit usage is infuriating. Are we clear that that this an OS-version API variation, rather than a processor mode variation (as the ReadLineV API is)? If there’s no plan to unify this API I’d like to strictly define what the API selector is.

Does that mean nobody (outside OS developers) ever used Heaped DAs and next to nobody ever sets Cache Policy?

Probably.

Also, in traditional Acorn style, OS_DynamicArea 0 is very light on parameter validation, with unknown flags not raising an error. So any code that wants to use post-3.5 features should contain at least some form of capability check, which will help to reduce the risk of malfunction.

Are we clear that that this an OS-version API variation, rather than a processor mode variation (as the ReadLineV API is)?

Yes, I think OS version is the correct determinant.

Thanks Jeffrey.