Machine specific

Is there a call to identify an ARMini/Beagleboard specifically?

The code

a9%=TRUE

ON ERROR a9%=FALSE

IF a9% THEN SYS “XOS_ReadSysInfo”,8 TO a9% ;flags: IF a9%<>7 OR (flags AND 1) THEN a9%=FALSE

IF a9%=FALSE THEN ERROR 0,“This version runs on A9 only”

ON ERROR (next test)

serves to identify the A9home.

Is there a similar call to identify the ARMini and/or the Beagleboard?

Maybe HAL_MachineID (in Miscellaneous HAL/kernel improvements)?

Is there a call to identify an ARMini/Beagleboard specifically?

No. Adding one was discussed, but hasn’t happened yet, primarily because of ROOL’s reservations ("history has shown that programmers often end up comparing them against a list of specific platforms whose attributes are known at authoring time, when they should be using a specific API to test for that attribute instead"). Personally I’m torn between the two viewpoints – I know that looking for a specific machine type is a bad thing in terms of future proofing, but it would be nice if things like system information utilities were able to easily determine what machine is in use.

So, I guess the question is, why do you need to identify if the machine is an ARMini/Beagleboard? If it’s specific hardware features which your code relies upon then we can add new APIs to allow you to test for those instead.

Maybe HAL_MachineID (in Miscellaneous HAL/kernel improvements)?

I don’t think that’ll help you find out what type of machine you’re running on, unless I’ve got it wrong.

Is there a similar call to identify the ARMini and/or the Beagleboard?

I think you can only identify whether you’re running on a HAL-based (RISC OS 5) machine, but not the specific type within that. I believe Jeffrey was thinking of adding some more SysInfo calls to return a bit more info, but I don’t think that’s done yet.

You can check the processor you’re running on – see !CMPTmpMon or Jeffrey’s BASIC program to change the CPU clock speed (Sorry, I can’t remember the name).

Really, we should all be using HAL interfaces to avoid having to probe the machine, I guess – Checking for the presence or absence of particular features rather than a particular board. But sometimes it’s much quicker just to check the machine! What are you trying to do?

So, I guess the question is, why do you need to identify if the machine is an ARMini/Beagleboard?

So that I can offer some free software that will only run on ARMini (or Beagleboard if ARMini is too difficult)

Ah, OK. In that case:

• If it’s software that’s going to be distributed on the ARMini disc image and you’re serious about locking it down to just ARMinis, you could ask R-Comp to change their disc image setup procedure slightly so that after setting up the base image they boot the machine and run a program which will save out the machine ID (via OS_ReadSysInfo 12) in an encrypted form. Your program can then load that file to check that it’s still running on the same machine it was first installed on.
• However since it sounds like you’ve found a pretty good reason to know the machine type, I’ll try approaching ROOL again on the subject and direct them towards this thread.
• But note that even though it’s trivial for me to write some code to tell the difference between different OMAP3 machines (BeagleBoard, BeagleBoard-xM, IGEP, TouchBook, etc.), there’s currently no way to tell the difference between a BB-xM and an ARMini. R-Comp would either have to add some hardware mods (maybe tie a few GPIOs together, or add an EEPROM to an I2C bus) or start running slightly modified versions of the OS.

R-Comp would either have to add some hardware mods (maybe tie a few GPIOs together, or add an EEPROM to an I2C bus)

This would mean recalling all units sold so far. (Perhaps they could be modded at shows if owners bring them along.)

I would have thought that just tying it to the extended machine ID would have been sufficient.

R-Comp would either have to add some hardware mods (maybe tie a few GPIOs together, or add an EEPROM to an I2C bus) or start running slightly modified versions of the OS.

Neither of these are particularly desirable I’d have thought either from a user’s or from R-COmp’s point of view.

I would have thought that just tying it to the extended machine ID would have been sufficient.

Quite likely. But I only have a vague idea of what result would occur on other platforms as the documentation does not say what range of results would be produced by specific machine types… I can’t generalise from a single example.

I would have thought that just tying it to the extended machine ID would have been sufficient.

At the moment it’s only the OMAP HAL that provides an extended machine ID. But any new ports that are made in the future will likely return an extended ID as well. So checking for the presence of an extended ID won’t be sufficient, but checking the extended ID against a known-good copy of the ID that was made when the program was installed will be sufficient (except for the one in a billion chance that two machines have the same ID).

Another vote for duck typing – if it quacks like a duck and walks like a duck, it’s a duck – regardless of what its extended ID says.

The fact is that if you’re using software interfaces to check whether your software should run, then a SIGNIFICANT proportion of RO users could make it run if they really want to.

The easiest way of making something non-portable is to write a C module and link it into the ROM image – it’s a lot of work to make one of them soft-loadable! ;-)

I think you have convinced me that there is really no need to try to ‘prevent software running on certain RISC OS platforms’.