What is ChkKernelVersion, and how does it work?

I don’t see how it stops modules working on RO2, since it calls the X form of the SWI and ignores the results. Even if the SWI was unavailable, didn’t it just return with V set? (Of course, this is from my initial confusion of: why does a filing system support module need to know the screen mode?)

    ; ****************************************************
    ; ***  ChkKernelVersion - Call OS_ReadSysInfo (1)  ***
    ; ***  Stops modules from working on 2.00 kernel   ***
    ; ****************************************************
            MACRO
    $label  ChkKernelVersion
    $label  Push    "r0-r3"
            MOV     r0,#1
            SWI     XOS_ReadSysInfo
            Pull    "r0-r3"
            MEND

Why is it pushing and pulling r0-r3 ? Only r0 is used and returned by the SWI, and the return value is lost making it both useless and crashy, by potentially setting V with no valid error block.

Examples of usage.

RiscOS.Sources.FileSys.FileCore.s.InitDieSvc

 InitEntry ROUT          ; NO REENTRANCY CHECK NEEDED
        Push    "R7-R11,LR"

        ; Macro to disallow rip-off RAM loaded version (te he ;-)
        ChkKernelVersion

        ; Check if we're the base incarnation and return if we are
        CMPS    R11, #&3000000
        RSBLOS  LR, R11, #0
        BHS     %FT70

RiscOS.Sources.FileSys.FileSwitch.s.FileSwBody

  FileSwitch_Init Entry "r7"

        ; Macro to disallow rip-off RAM loaded version (te he ;-)
        ChkKernelVersion

        LDR     r2, [r12]               ; Is this a hard initialisation ?
        CMP     r2, #0                  ; r2 = 0 -> hard. VClear
        BEQ     %FT01

        MOV     wp, r2                  ; SoftInit
 [ debuginit
 DLINE "Soft Init"
 ]
        B       %FT40

RiscOS.Sources.FileSys.ResourceFS.ResourceFS.s.ResourceFS

ROMFS_Init Entry

        LDR     R2, [R12]               ; have we got workspace yet ?
        TEQ     R2, #0
        BNE     %FT05

        MOV     R0, #ModHandReason_Claim
        MOV     R3, #ROMFS_WorkspaceSize
        SWI     XOS_Module
        EXIT    VS
        ChkKernelVersion
        STR     R2, [R12]               ; save address in my workspace pointer,
                                        ; so Tutu can free it for me when I die
05      MOV     R12, R2

So, does it “work”? (And will anyone ever try to softload an RO5 module on an Archimedes, anyway?)

I think it’s probably outlived its usefulness.

A quick peek inside a RISC OS 3.11 ROM suggests that the same version of the macro is in use there – so the only explanations I can think of is that the 2.00 kernel either outright crashes, or ignores the X bit and raises the error, or someone broke the macro shortly after it was added.

So, does it “work”? (And will anyone ever try to softload an RO5 module on an Archimedes, anyway?)

RO5 won’t work on anything pre-RiscPC anyway will it? ARM2/250/3 were 26-bit only.

A lot of the modules can be built as 26-bit friendly (the disc image & !System download contains many modules that will run as far back as RISC OS 3.1)

From the PRM, “This call is not available under RISC OS 2.”

With the idiotic comment, I’d say it’s a throwback to early Acorn days and can probably now be removed from the source.

It appears to date to just prior to RISC OS 3 release when someone had the bright idea of stopping the module being loaded on RISC OS 2 for whatever reason. Kill it at source.

I seem to recall hacking out some unknown SWIs when softloading later versions of RISC OS 3 modules on RO2. The pre-release RO3 stuff softloaded fine for beta testing, so maybe Acorn wanted to put a stop to that.