OS_Module 19 behaviout

I was looking at some old code that uses OS_Module 19 to enumerate the ROM modules.
Under RO 4 and below it works but functionality of OS_Module 19 has changed in OS 5.
What used to happen is that R1 (which returns the ID of the next module in the list) would return a number less than the asked for ID if that module number did not exist. Now what happens is that the ID of the next module (which does not exist) is returned and the error “No more modules” is generated. Example code is below.

   10r1%=0
   20REPEAT
   30id%=r1%
   40PRINT id%;" ";
   50SYS "OS_Module",19,id%,-1 TO r0%,r1%,r2%,r3%,r4%
   60PRINT r0%,r1%,r2%,r3%,r4%
   70UNTIL (r1%<=id%)

Is this a known change to functionality? If so, what is the correct way to enumerate ROM modules now?

Thanks,

Michael.

Are you sure it wasn’t calling XOS_Module? That old code shouldn’t have worked…

PRM 1-253 (DDE PDF version) states:

The call returns the error ‘No more modules’ (error number &107) if there are no more modules from the point specified in the ordering.

The existing code is assembler and I’ve noticed that the compare was only doing a < and not <= which is why it was going into an infinite loop. Didn’t spot that before but I can change that to fix it.

Yes, the old code was calling XOS_Module, but because the behaviour has changed between RO4 and RO5, it highlighted the issue. The example above still produces different results between RO4 and RO5.

Using XOS_Module on RO5 causes R0 to become corrupted and R1 stays the same (ie. does not get incremented) when the end of the module list is hit. Under RISC OS 3 and 4, R0 would stay at 19 and R1 would reset and return a value less than the current module number (usually 0 or 1).

https://www.riscosopen.org/wiki/documentation/show/OS_Module%2019 states:

If there are insufficient modules in the ROM section then the search continues with the next section; so the fifth module in a four module section would in fact be the first module of the next section.

indicating that when the module id hits the end of the list, the section is incremented and the module id should be reset to 0 but maybe because there are no more sections and no more modules, it does not do this now?

I think the source of your problems is a bug in your code, rather than a change in the OS (CVS doesn’t show our implementation of OS_Module 19 as having any significant changes made to it since RISC OS 3.6 – which is as far back as the history goes for the kernel).

OS_Module 19 essentially enumerates modules in the following way:

while(true) {
  find module section R2
  if (R1 < number of modules in section) then
  {
    get details of module R1
    R1 += 1
    return
  }
  if (R2 was the last section containing any modules) then
    return
  R2 = next section
  R1 = 0
}

I’m guessing your RISC OS 3/4 machines have podules or network cards fitted. In which case your loop will enumerate all the main ROM modules, enumerate the first podule/NIC module, and then terminate (with R1=1). But on a machine without podules (traditional RO 5) R1 will never get reset and so you’ll hit the ‘no more modules’ error instead.

Using XOS_Module on RO5 causes R0 to become corrupted and R1 stays the same (ie. does not get incremented) when the end of the module list is hit.

Are you sure the “corrupted” R0 isn’t actually a pointer to the error block? (i.e. V flag should be set)

Hi Jeffrey,

Thanks for the clarification. You are right on both counts. On RO 3/4 machines it does skip to the podule sections, but these don’t exist on the RO5 machine, so it terminates. The “corrupted” R0 is in fact a pointer to the error block so my bad for not spotting that.

Cheers,

Mike.