OS_Memory 9

This is a bit of a retroactive request. When I checked in my IOMD ROM fixes, I decided that rather than hard-coding the 82C710 address as being an offset from the IOMD address, it would make sense to add it as a new controller type to HAL_ControllerAddress. However a couple of days ago while looking through the kernel sources I spotted that OS_Memory 9 internally calls HAL_ControllerAddress, so something that I thought was just a private change is suddenly a public one (i.e. could be subject to clashes with ROL’s changes). And indeed, it looks like controller #6 is already in use for the tube ULA (presumably used by ROL, although the select docs only seem to list controllers 0-3).

So, how do we go about reserving new controller numbers for use with OS_Memory 9? And for that matter, other things like OS_ReadSysInfo reason codes?

how do we go about reserving new controller numbers for use with OS_Memory 9?

I think the comments in the Kernel are the allocation scheme, certainly when I grabbed 6 for use in my ARM7TDMI Coprocessor all I did was submit that comment.
I think that 4 was allocated when the Podule manager was abstracted, and probably 5 at the same time since it’s handled by the same module.

I’ve just spotted something I missed in ROL’s docs – they’ve added a OS_Memory 25 call which is basically the same as OS_Memory 9 except it returns the physical address instead of the logical address. This lists a few more of the controllers that our OS_Memory 9 supports, but it also lists all the spare ones up to 31 as being reserved (“for Pace OS variants”). It looks like they’re using 32 and above for their own allocations. So it doesn’t look like we have to worry about clashing with their allocations.

I’ve now checked in some changes to switch the IOMD HAL (and related modules) from using controller #6 for the 82C710/SuperIO/SMC37C665/whatever over to using controller #34 (i.e. the same ID that ROL are using with their OS_Memory 25). This should sort out all the allocation clash issues.