Understanding the RISC OS architecture: Hardware interface

Hi all.

Lately, I’ve been studying to learn RISC OS, both its components and its overall architecture.

I’ve got the RISC OS 3 PRM (in book form, even :) ), as well as the PRM 5a as PDF, which I’ve been reading. I’ve also read up on information I’ve found about changes to RISC OS since version 3.6, as documented in the PRM.

Yet, also due to hardware changes in more recent RISC OS based computers (like the Iyonix and the BeagleBoard), I’m struggling somewhat to see how it all fits together, when it comes to the hardware interface…

With RISC OS 5, we got a HAL, which abstracts away some of the hardware details. The HAL, being very low-level, is probably mostly useful for the kernel and device drivers.

A step up from this would then be the kernel and device drivers. Currently, I’m trying to learn how RISC OS interfaces with the hardware, such as keyboard, mouse, mass storage devices, network, etc., which on the BeagleBoard is all done using USB, and I’m struggling with it…

For example, there’s a module called InternationalKeyboard, which appears to be a device driver for the keyboard: It calls OS_InstallKeyHandler, and the PRM has this to say about that call:

“Custom key handler

The SWI OS_InstallKeyHandler (page 1-947) allows replacing the module that decodes key numbers into ASCII. It is outside the scope of this manual to discuss this procedure in depth.”

In fact, as far as I can tell, it isn’t discussed at all… Does this mean that the keyboard interface is not documented (at least in the PRM)?

What I’d like to understand is how the current RISC OS Cortex A8 port works when it comes to the USB devices mentioned above. In short, which part of the OS knows that it’s supposed to go to the USB, when it’s interfacing with keyboard, mouse, mass storage and network, and what are the drivers for these devices?

I know there may not be an easy answer to these questions, but any pointers or info would be most welcome…

I know RISC OS fairly well beyond the kernel, but not when it comes to the hardware interface…

Regards,

Terje

For the keyboard, the lowest level drivers call the KeyV software vector to announce key presses and releases using ‘low-level’ key codes.

The kernel monitors this vector and uses the installed keyboard handler, which knows the keyboard layout, to map these to character codes and the key codes used in SWIs. The interface is described here though it is quite low level.

The mouse drivers call the PoinerV software vector.

For network drivers, there is the DCI 4 specification which isn’t published AFAIK. Each driver (e.g. EtherUSB) provides a SWI to send a packet and provides an interface to allow protocol modules (e.g. Internet for IP) to register an interest in certain types of incoming packet.

• A FileCore file system, e.g. ADFS, SCSIFS (and via that USB mass storge), RamFS. For these the ADFS or RAMFS is the hardware driver and it uses FileCore to hook into FileSwitch. SCSIFS uses FileCore but itself has ‘backends’ of which SCSISoftUSB is the one talking to the USB system.
• An image file system (e.g. DOSFS, SparkFS) behaves more like a file system on other systems. It has access to a image ‘file’ (either an image via a file type or the contents of a mass storage device) and provides functions to create direcories, open files, read data etc which are called by FileSwitch. Image FSs have a filetype which is how SparkFS makes archives look like directories, similarly for DOSFS and DOS disc images. Sunfish works as an image FS by making its image format a textual description of how to connect to the NFS server. Images FSs are used and abused in this way as FileSwitch does more of the work so it is easier to write an image FS than…
• Full FS modules. These include special file systems (e.g. DeviceFS, ResourceFS, PipeFS), some network file systems, CDFS.

Hi again, James, and thanks a lot for the detailed information. I understand much more, now, regarding the interface for keyboard, mouse, filing systemes and network.

There’s a few more things I wonder about regarding the keyboard and mouse interface:

So, if I understand it right, there’s a USB keyboard device driver somewhere, and at system initialisation, it registers itself as a device driver (using DeviceFS_Register?), or it simply registers itself with the USB device to receive notifications from it, and it then calls KeyV when keys are pressed?

Is this USB keyboard device driver called anything, or is it simply compiled into the kernel?

Does this mean that each version of the kernel is compiled for a specific type of hardware, e.g. one version for the old Acorn keyboard interface, and another for the newer USB keyboard interface, or is the kernel able to use either, depending on what is present, and are these keyboard drivers identified/accessable in some way, or they just part of the kernel?

The same questions goes for the mouse device drivers.

Many questions, I know… :)

P.S. Also thanks for the link to the KeyHandler documentation.

I think the USB mouse and keyboard drivers are built into the USBDriver module, which provides the core of the USB stack. AFAIK all kernel – keyboard driver communication goes via KeyV, all kernel – mouse driver communication goes via PointerV.

DeviceFS is not involved at this level and is a distraction. Keyboard/mouse drivers do not in general create DeviceFS devices.

The mouse/keyboard drivers will be provided by modules, e.g. USBDriver, PS2Driver or SerialMouse. These may talk to the HAL, to other modules or to hardware directly.

Thanks again for the additional information.

Following my previous posting, I read up on PRM 5a, again, and realised there was quite a bit of information on the keyboard and mouse drivers that I didn’t realise was there, and which confirmed and complemented what you wrote above.

However, due to the hardware not supporting USB at the time, there was no information on that, so it was useful to get information about that.

To add to what you said above: Actually, according to the PRM, the mouse button presses are passed to KeyV, but the mouse movement information is passed to PointerV.

Edit: Ah, yes, now I found all I wanted to know about the USB support here.