AMcS wrote:I am not sure of the about the HAL being " later removed by RISC OS Ltd. for the RISC OS Select versions", in that RISC OS 4 (which predates Select) didn't have a HAL either and was produced by RISC OS Ltd. As far as I know (and I am open to correction here) ROL didn't use a HAL because they hadn't got one - and given that the hardware they were developing for had the required Acorn designed parts (IOMD/VIDC) it would have (arguably) not made sense to include a HAL even *if* they'd had one.
It very likely may have been removed before the release of ROL RISC OS 4, this I can not say for sure, the earliest ROL RISC OS that I have is RISC OS 4.02.
While I am sure that there are any number of sources of information out there on this topic:
To this I will point you to Justin Fletcher (Gerph):
Justin Fletcher wrote:
Other modules were far more obvious as replacements - CMOS (configuration data) access was in the Kernel, which meant that we ended up having direct hardware access in the Kernel - an unreasonable state of affairs. Pace had decided to go about this problem by providing what they called a 'HAL'. Essentially this meant "lift bits out of the kernel wholesale, not changing any APIs and just dump them in something that you can vector through". Unlike splitting things into module with proper RISC OS APIs and the like, this had the problem that the already quite poor internal interfaces that were 'abstracted' were left in this HAL where other hardware had to be shoehorned to work with. Maybe that's a bit uncharitable, but I have the completely diametric view that hardware functionality is a modular thing, and we have a well defined, and (relatively) well implemented system for doing so already in RISC OS. These components that provide hardware access are no different to those that come on Podules, so should not be treated as special. And, of course, many hardware things shouldn't sit 'under' the Kernel in a HAL, but should live above it.
This said, in order to know which modules need to be loaded (due to Unplug constraints) on start up, you need to have access to the configuration data. So... we need to know configuration in order to select modules for start up, but we also need to have modules in order to get at the configuration. Simple - a flag to indicate that some modules need to be initialised early. Not only does this address the issue of NVRAM configuration (and many other abstractions) but means that we can ensure that the PoduleManager is started early and remove the collusion that required it to be the second module. Other extension module providers would also have early initialisation here, were they to be present.
For more see:
http://gerph.org/riscos/ramble/modulari ... bstraction
AMcS wrote:Thanks for that informative post David, much appreciated.
I thought it common knowledge, I almost never use C, as I prefer assembly, this is just a standard part of the ANSI C programming Language, and the language definition is so small that I figure that any one that has made any estencive use of it would remember the entire core language by heart.