Let's get started with a Pandora port

I concur that long-term, it would be better to support different pixel formats. Preferably in a way that is opaque to applications that don’t care about such things. Those that do will obviously need some way of finding out what the current mode’s pixel format is. I expect there’s already API for this somewhere :)

I’ve not looked at the WIMP in any great detail, but if it can transparently make applications render their window contents to an off-screen buffer, instead of direct to the framebuffer, that could be one way to provide a transition (along with providing a long-term mechanism for abstracting the underlying framebuffer format).

Although all the pixel formats are RGB ordering instead of BGR, there’s a 3×3 colour phase conversion matrix which can easily be used to swap the red and the blue channels of the pixel data as it leaves the graphics pipeline.

Well spotted (section 15.4.2.5.1 of manual), that’s sneaky. I was going to point out that the video planes would be incorrectly displayed if you did that, but I see that the YCbCr->RGB conversion is also fully programmable. Obviously this was intended to support HD vs SD video, but luckily for us, the Cr/B and Cb/R matrix entries appeat to have been implemented, rather than just being assumed to be 0.

Unfortunately it only applies to the LCD output, not the TV-out – but I doubt many people would be interested in TV-out anyway.

I concur with your analysis. It’s a shame – I’d already thought of an application for TV-out, but it’s not as big a problem as I thought, especially if we can persuade TI to do proper RGB/BGR support in later revisions.

Regarding the alpha values – there’s a suitable 32bpp mode available where the pixels don’t have an alpha channel. The alpha is instead forced to 255 (i.e. fully opaque).

I think that’s the one that we would have to be used for maximum compatibility – lots of legacy applications will just set the transparency bits to 0 in the colour number (as indeed is specified in PRM 5a-110).

The way I’d implement things would be to

• If a RGBT (existing) mode is selected, use the OMAP non-packed 24-bpp framebuffer format.
• If an RGBA (new) mode is selected, use the OMAP 32-bpp framebuffer format (with alpha).
• The kernel’s default transparency LUT for existing 32-bpp modes is all-zero (ie all settings of the transparency bits result in opaque pixels). If anyone calls HAL_Video_WritePaletteEntry with non-zero transparency, then obviously someone is doing something special, so we can usefully enable chroma-key. I don’t think RISC OS has supported chroma-key before, but at its simplest it could be a case of getting ColourTrans to return a specific colour number when a non-opaque palette entry is requested. A typical algorithm would be for all non-opaque colours to be returned as colour number &00FE00FE and for slightly-less-than-full-intensity-magenta to be returned as &00FF00FF.
• I propose the kernel’s supremacy LUT should be initialised to a 1-to-1 mapping for RGBA modes. (Even if this doesn’t apply to RISCOS Ltd’s implementation, it won’t cause incompatibilities because none of their products have video planes AFAIK.) For the OMAP HAL, I’d act upon the 0th and 255th palette entries to set the global alpha values – this is for maximum compatibility wih platforms that have a fully programmable alpha LUT because the most common operations on these would be to fade in/out the graphics and video planes.

As to the implementation of these new graphics formats, I think there are four main areas to address, in decreasing priority:

1. Mode variables / VDU variables
2. Sprite formats
3. Mode strings (WimpMode)
4. BASIC MODE command

This is something where we need to be as compatible as possible with RISCOS Ltd. I’m going from what I’ve surmised from OSLib – if anyone with more up-to-date documentation available would like to chip in, it would be useful.

ModeFlags (VDU var #0) has already been extended by ROL to select between framebuffer variants with otherwise identical settings of NColour (VDU var #3), in bits 12-15. I propose extending this as follows:

| Value | Colour space | Ordering (MSB to LSB) |
| 0     | RGB          | TBGR                  |
| 1     | CMYK         | unknown               |
| 2     | RGB          | ABGR                  |
| 3     | RGB          | TRGB                  |
| 4     | RGB          | ARGB                  |

We also need a new value of NColour for 5:6:5 bit-layout. The obvious choice would have been 32767 for 1:5:5:5 and 65535 for 5:6:5, but sadly 65535 for 1:5:5:5 is long-established. How does ROL do it?

In sprites, all this extra flexibility has to be squeezed into the 32-bit sprite mode word. Tragically, half of the 32 available sprite type bits have been lost when ROL reallocated bit 31 of the mode word to indicate multi-bit sprite masks. PRM 5a-110 currently defines:

| 0  | Backward-compatible type (8-bit mode number) |
| 1  | 1bpp                                         |
| 2  | 2bpp                                         |
| 3  | 4bpp                                         |
| 4  | 8bpp                                         |
| 5  | 16bpp, 1:5:5:5 TBGR                          |
| 6  | 32bpp, 8:8:8:8 TBGR                          |
| 7  | CMYK                                         |
| 8  | 24bpp                                        |

so bearing in mind that we need to be abe to ScreenSave or ScreenLoad sprites and switch VDU output to sprites while in one of the new screen modes, we need to define at least:

| 9  | 16bpp, 1:5:5:5 TRGB |
| 10 | 16bpp, 1:5:5:5 ABGR |
| 11 | 16bpp, 1:5:5:5 ARGB |
| 12 | 16bpp, 5:6:5 BGR    |
| 13 | 16bpp, 5:6:5 RGB    |
| 14 | 32bpp, 8:8:8:8 TRGB |
| 15 | 32bpp, 8:8:8:8 ABGR |
| 16 | 32bpp, 8:8:8:8 ARGB |

which is already one more sprite type than are available! And apart from things like 4:4:4:4 ARGB modes, there are other useful sprite formats that we might want to exploit, such as YCbCr formats (useful for interchange of JPEG or video data). Perhaps the time has come to introduce a new sprite mode word variant – using 26 of the 32 bits to encode the dpi settings seems particularly wasteful. How about:

000000000000000000000000smmmmmmm -> mode number
pppppppppppppppppppppppppppppp00 -> pointer to mode selector
w111100000000000000ccccbbbbyyxx1 -> new style sprite mode word
wttttvvvvvvvvvvvvvhhhhhhhhhhhhh1 -> RISC OS 3.5-style sprite mode word

where

• s = shadow mode bit
• m = BBC - RISC OS 3.1 mode number
• p = pointer
• w = wide mask flag
• c = colour format (as for bits 12-15 of ModeFlags)
• b = bit layout (a more compact representation of NColours):

| b | Meaning             |
| 0 |  1bpp paletted      |
| 1 |  2bpp paletted      |
| 2 |  4bpp paletted      |
| 3 |  8bpp semi-paletted |
| 4 |  8bpp paletted      |
| 5 | 16bpp 4:4:4:4       |
| 6 | 16bpp 1:5:5:5       |
| 7 | 16bpp 5:6:5         |
| 8 | 24bpp 8:8:8 packed  |
| 9 | 32bpp 8:8:8:8       |

• x,y = compact resolution specifier:

| x/y | Meaning                       |
|  0  |  180 dpi (like EX0/EY0 modes) |
|  1  |   90 dpi (like EX1/EY1 modes) |
|  2  |   45 dpi (like EX2/EY2 modes) |
|  3  | 22.5 dpi (like EX3/EY3 modes) |

• t = sprite type (see PRM 5a-110)
• h,v = horizontal/vertical dpi

and there are still 14 bits left for future expansion (bits 13-26, which should be written as 0 at present).

In mode strings, “C64K” or “C64T” is available to distinguish 5:6:5 modes from 1:5:5:5 modes (which have always been “C32K” or “C32T”). It would be useful to be able to specify which variant of deep colour modes to select. I propose they be selected (by describing the pixel format from MSB to LSB order) as “TBGR”, “TRGB”, “ABGR” and “ABGR”. This uses two parameter prefixes “T” and “A” but we’re not short of them, and this makes it easier to read. The default would be “TBGR” for maximum application compatibility, unless the hardware doesn’t support it.

In BASIC, the statement “MODE <width>,<height>,<bpp>[,<framerate>]” needs extending to create an appropriate mode selector block to choose between the different screen mode variants with the same bpp value. I’m open to suggestions.

I’ve not looked at the WIMP in any great detail, but if it can transparently make applications render their window contents to an off-screen buffer, instead of direct to the framebuffer, that could be one way to provide a transition (along with providing a long-term mechanism for abstracting the underlying framebuffer format).

That’s not an ideal solution because of the fact that we’d lose the ability to have an application take over the screen by running outside the desktop. That’s something that’s still relatively common in embedded applications.

That said, there are hooks in the Wimp, originally written to support software anti-flicker filtering, that would be the obvious place to insert double-buffering if you wanted to do so.

That’s not an ideal solution because of the fact that we’d lose the ability to have an application take over the screen by running outside the desktop. That’s something that’s still relatively common in embedded applications.

That’s true. I’m not sure if there is an ideal solution for this case, however. Particularly so if you want to ensure that legacy applications work without modification in the short term. Perhaps that’s a non-requirement though.

The other reason for double buffering is that, in certain classes of hardware, VRAM reads are hugely expensive. Whether that’s reason enough to do buffering, is another matter, of course.

| 1 | CMYK | unknown |

http://select.riscos.com/prm/graphics/sprites/cmyk.html suggests KYMC.

I’ll see about tracking down some details of ROL’s 64k colour mode. Tinct (the sprite plotting module used by NetSurf) has recently grown support for this, so documentation must be somewhere.

On the subject of sprite types, http://select.riscos.com/prm/graphics/sprites/alphachannel.html suggests that 9 has been allocated for JPEG data, though I’m not aware that anything supports this.

I might be inclined to allocate an extra bit to the bit layout field of the new mode specifier, seeing as you’ve already used over half the available values, and there’s loads of spare bits. Otherwise, it looks fine to me.

ROL appear to have used T as a prefix for Teletext stuff in their mode specifier strings. See http://select.riscos.com/prm/graphics/osscreenmode.html#L0051

How about:

MODE <width>,<height>,<bpp>[,<framerate>][,<layout>]

with <layout> being:

100000000000000000000000000bbbb

where bbbb is as per the bit layout field of the new mode specifier.

This should allow for simple distinction between a layout and framerate field, as framerates can only be positive or -1, as per OS_ScreenMode 0. The default layout would preserve the status quo (8bpp paletted/16bpp 1:5:5:5, I expect).

I presume there’s no need to allow MODE to change the component ordering?

I’ll see about tracking down some details of ROL’s 64k colour mode. Tinct (the sprite plotting module used by NetSurf) has recently grown support for this, so documentation must be somewhere.

So, the answer is that NColour remains as 65535 but bit 7 of ModeFlags is set in C64K modes.

Additionally, I’m informed that this format has been allocated as sprite type 10.

Ben, your suggestions for the new sprite mode format looks good to me. I’m a bit wary of inventing another format where we end up locked into fixed-size bitfields, but I think we’ve got plenty of space in there to describe all the sensible pixel formats that current-generation computers use.

Regarding ModeFlags, we may also want to add entries (and code!) for RGBA, BGRA, RGBT, and BGRT, even if nothing uses them yet.

Regarding BASIC, we don’t necessarily have to expand it to allow specification of the pixel layout – MODE can already accept a mode specifier string. It’s probably a lot nicer and cleaner to just use a mode string than to come up with a hacky way of specifying the layout without specifying the framerate (or vice-versa).

Also, don’t forget that we’ll need HAL/video driver extensions to allow the HAL to state the pixel formats it supports. e.g. change HAL_Video_PixelFormats to return a pointer to a table/structure instead of just a set of bitflags.

Thanks everyone for your comments. I’ve updated my proposal and uploaded it to the wiki where it’ll be easier to maintain and has the benefit of working table markup! Further comments are welcome.

Of course, there’s also the small matter of implementing it, but at least once the formats have been agreed, bits of software can start supporting them in isolation.

Further comments are welcome.

Further comments incoming!

I’ve spotted that there’s no mention of BGRA, RGBA, BGRT, RGBT formats – is that a conscious decision to exclude them or just an oversight?

Note that BASIC’s MODE <string> merely calls *WimpMode

Ah-ha! So that’s why it changes the wimp mode all the time. Is there any sensible reason why it’s been coded this way? In my mind it just makes it too annoying to be worth using, because you have to manually implement code to reset the wimp mode when your program exits. I think it would be much more sensible if we took the approach of RISC OS Select, and added new OS_ScreenMode options (13, 14, and 15) to handle converting mode specifiers to/from strings, and setting the mode using a string. The only downside I can see from moving the code out of the wimp is that it would become harder to support new specifier formats, since the parsing code may be stuck in the kernel instead of a soft-loadable module.

Since the “T” prefix has been used by RISCOS Ltd, I suggest the available options be distinguished by listing the colour components in little-endian order, leading to the following possible parameters:

Could we use a new ‘L’ (Layout) prefix instead? That way we don’t have to worry about clashes with other existing options, and it allows us to use (what I believe is) the more common and easier to read big-endian notation.

I’ve spotted that there’s no mention of BGRA, RGBA, BGRT, RGBT formats – is that a conscious decision to exclude them or just an oversight?

It’s true it doesn’t cover all the OMAP modes, if that’s what you’re thinking. I also didn’t include big-endian variants, or those wacky Windows-compatible ones where the pixel ordering within bytes is the opposite of the ordering of bytes within words.

I stopped there because

• the list of new modes is already quite long – remember we’re proposing to implement these, and the number of conversion routines (or at least codepaths and test cases) needed is roughly the square of the number of available modes!
• I stopped adding modes when I thought it had addressed all the current problems:
  • compatibility with RISCOS Ltd fork
  • red/blue swapping provides TV out on OMAP and enables Iyonix 16bpp support on DVI cards
  • alpha rather than transparency gives us video blending on OMAP (and screen modes where the default kernel palette isn’t all-opaque – you wouldn’t believe the problems we had with RISC OS STBs with the number of layers of software that tried to deal with this, all fighting with each other)
  • 24-bit 8:8:8 gives us a more compact formats for full-depth sprites. I don’t think the packed nature should be such a big speed hit these days, now that we have merging write buffers
  • 16-bit 4:4:4:4 gives useful greyscale video blending without having to go to 32bpp, and is even theoretically supportable on VIDC (not that any VIDC machines ever had video blending facilities, but this might be useful on emulators somehow)
  • the YCbCr formats provide a lossless interchange format for JPEG and MPEG data, and a format for loading and saving the contents of the video planes

I don’t see that adding RGBA and other similar formats solves any problem at present – unless you’re aware of any potential RISC OS target platform that supports RGBA but not ARGB?

Is there any sensible reason why [MODE <string> has] been coded [to use *WimpMode]?

Laziness? Not understanding the distinction? I don’t know.

I think your suggestion of adopting the ROL OS_ScreenMode 13-15 extensions is a good one. I wouldn’t worry too much about kernel changes – on any modern platform the ROM is flashable, for Risc PCs I doubt anyone anyone will make masked ROMs again when they can softload, and emulators are imherently soft.

For the record,

• OS_ScreenMode 4-6 are present in our repository, but only on the Ursula branch. They’re only really useful for squeezing a bit more performance out of the StrongARM microarchitecture. By the time the HAL branch was being developed, StrongARM was old hat and the ARM9 devices available outperformed it and sidn’t suffer its slow uncached memory access performance, so it was deliberately not merged across.

• OS_ScreenMode 7-15 are inventions of ROL. Fortunately, no clashing allocations have been made in our fork of the OS.

I don’t want to propose changing the functionality of MODE <string> since it’s been around for a very long time. I think MODE OF <string> should be a distinct if slightly strange syntax (but precedent is set by COLOUR OF <n> ON <n>).

Could we use a new ‘L’ (Layout) prefix instead?

Yes, OK. I don’t feel that strongly about it.

I don’t see that adding RGBA and other similar formats solves any problem at present – unless you’re aware of any potential RISC OS target platform that supports RGBA but not ARGB?

I suppose you’re right – the extra complexity is a bit much for us to worry about at this point, especially for something that may never actually get used.

I don’t want to propose changing the functionality of MODE <string> since it’s been around for a very long time. I think MODE OF <string> should be a distinct if slightly strange syntax (but precedent is set by COLOUR OF <n> ON <n>).

“MODE OF <string>” is a bit ugly, but I suppose it’s the only solution if you’re unwilling to break the (presumably) small number of programs that rely on “MODE <string>” changing the wimp mode. Of course we could always leave MODE alone and get people to use the new OS_ScreenMode reason codes instead, but I’m not sure if that’s any better since we’d instead be forcing people to use a SWI for something which used to be achievable through plain BASIC alone.

A brief progress update on the Cortex port.

Uwe Kall’s been helping me test code out on a real beagleboard (I’m trying to hold off on my purchase until the revision C boards are released at the end of March – they have an extra USB port and more RAM). This means that the HAL and HALTester now work, and the kernel should have working cache support, in a way that just about fits inside the current ARMops interface. However we’ve run into a new problem, which is that the MMU page table formats are significantly different. I don’t think the required changes can be implemented cleanly inside the existing ARM600 code, so I’m thinking it’s about time a new MMU interface file was added, for ARMv6 and above. (We could target ARMv7, but ARMv6 is where the big changes start happening and backwards-compatability isn’t guaranteed. I also don’t have any proper docs for the ARMv7 MMU, but as far as I can tell it does have an ARMv6 backwards-compatability mode, which I do have full docs for)

Of course the benefit to a new MMU interface file is that it will be a good opportunity to tidy up the code – it’ll be targeted purely for ARMv6/v7 on HAL, so there’ll be no messy conditional compilation blocks in the code and the header won’t reference any of the many obsolete CP15 flags.

What are ROOL’s thoughts on this? And are there any caveats I should be aware of? I’ve worked out where to add the new files, and I know I’ll have to update the MMU setup code in s.HAL, but are there any other files inside or outside the kernel that would need changing?

The guy you really want to be talking to for advice about this – if you can locate him – is Mike Stephens. If you look at the CVS logs, you’ll see just how great his contribution to the kernel has been over recent years. Having informally chatted to him about ROOL a few months ago, I don’t think he’d mind giving advice, but I don’t have current contact details for him – does anyone else?

The only comments I can make myself is that the kernel has always adapted itself to the current CPU architecture at run-time and it would be nice to continue that if it’s not too much of an overhead. As I understand it, the ARMop API is basically an abstraction of the cache, write buffer, TLB and MMU management functions so the rest of the kernel doesn’t need to know too much about the core in use. But as it’s restricted to kernel use, the API isn’t fixed in stone – the only impact would be upon other parts of the kernel, which should be easy to locate and update. Whether the new code goes in a separate source file or not is down to the judgement of the developer. Or have I got the wrong idea about what you’re asking?

Perhaps the question should be: what software manually pokes the page tables and might make assumptions about the structure thereof? Off the top of my head, I’d want to investigate debuggers like DDT or DeskDebug, memory paging systems, !Patch and the softloader, though hopefully most if not all of those will use OS_Memory to do their stuff.

I have no problem with you implementing the ARM v6 MMU interface – in fact, that would be a good thing, because v6 is far from obsolete and we might yet see a RISC OS port to a v6 chip, and it would be useful for that. I believe the information you need about the v7 MMU interface is in the ARM v7 ARM - to this end, I’ve been making enquiries to ARM to see if we can get you cleared to receive a copy.

One more thing: ROOL has just acquired a rev B7 beagle board. We’d be happy to lend it to you to help you in the bring-up process, but we’d like it back in time for the Wakefield show on 25th April so we can demo it to the punters. (It sounds like you may have a rev C board by then anyway.) Drop us a line with your postal address if you’re interested.

The only comments I can make myself is that the kernel has always adapted itself to the current CPU architecture at run-time and it would be nice to continue that if it’s not too much of an overhead. As I understand it, the ARMop API is basically an abstraction of the cache, write buffer, TLB and MMU management functions so the rest of the kernel doesn’t need to know too much about the core in use.

The ARMop interface covers the cache, write buffer and TLB; the MMU is handled by s.ARM600 (and associated header). s.ARM600 also covers a few other bits, including code for RAM and CPU setup for pre-HAL OS’s, and some of the exception veneers. I actually started work on the VMSAv6 code today, using a new MMU interface file, but once the code is complete I suspect it wouldn’t be too hard to tidy the kernel up a bit and move it to a system where it can select at runtime which MMU interface to use.

Perhaps the question should be: what software manually pokes the page tables and might make assumptions about the structure thereof? Off the top of my head, I’d want to investigate debuggers like DDT or DeskDebug, memory paging systems, !Patch and the softloader, though hopefully most if not all of those will use OS_Memory to do their stuff.

I suppose it’s possible some programs could try accessing the page tables directly – at some point I’ll have a go at searching the entire source tree for any tell-tale signs.

I believe the information you need about the v7 MMU interface is in the ARM v7 ARM - to this end, I’ve been making enquiries to ARM to see if we can get you cleared to receive a copy.

Thanks – that would be great!

One more thing: ROOL has just acquired a rev B7 beagle board. We’d be happy to lend it to you to help you in the bring-up process, but we’d like it back in time for the Wakefield show on 25th April so we can demo it to the punters. (It sounds like you may have a rev C board by then anyway.) Drop us a line with your postal address if you’re interested.

I think I can get by without a beagleboard for the time being, but if I get desperate I’ll remember to give you a call.

Hopefully we’ll have something exciting to show in time for Wakefield :)

Also, if anyone at ROOL or elsewhere wants to muck in and help with the coding, just give me a poke and I’ll update CVS.

Also, if anyone at ROOL or elsewhere wants to muck in and help with the coding, just give me a poke and I’ll update CVS.

That’s probably a good idea, in case there are lurking developers or testers with access to beagle boards. Plus it doubles as an off-site backup for your work, and in years to come having a regular sequence of checkins can help to reveal the thought processes that went into development.

On the subject of sprite types, http://select.riscos.com/prm/graphics/sprites/alphachannel.html suggests that 9 has been allocated for JPEG data, though I’m not aware that anything supports this.

Sprite Extend uses it in SWIJPEG_PlotScaled.

After a bit of a struggle, CVS finally gave in and allowed me to submit my changes. The latest OMAP3 HAL, HALTester, and kernel should now be available – except for the WIP VMSAv6 code which would have most likely failed to compile if I’d checked it in in its current state. Hopefully it will only be a couple of days before I’m able to start testing it.

Something I’ve just spotted with regards to a Freescale i.MX515 port – although there’s no documentation publicly available like with the OMAP, they do have a fairly open looking developer’s program – http://projects.powerdeveloper.org/projects.php

Regarding colour depths, Select offers OS_ScreenMode,12 which I use in KinoAmp to check which colour depths are available on the machine to define a list of screen resolutions or to check if the screen mode is in 32K or 64K (since on most OS versions NColour is given as 65535 for 32K mode).

Reading through the audio components, the only HAL component i found was that of a AC97 specific audio-mixer interface. This is used directly from the kernel. to implement the corresponding functionality for OMAP, we could either 1) add new functionality to the kernel disregarding the HAL (which is probably not good), 2) change the HAL interface by adding the omap specific interface, 3) generate a general interface ( (a)and move the existing AC97 calls from the kernel into the HAL or (b) keep them as they are without cleaning up).

Any comments?

ooooo loook here…

this looks usefull and it is on the omap3…

http://www.liliputing.com/2009/03/always-innovating-touch-book-has-a-detachable-display.html#disqus_thread

John

Detachable keyboard? That’s certainly a bit odd.

And you’re certainly right about it using an OMAP3 - if you look here you’ll see that the motherboard is just a modified beagleboard!

Unforutnately pre-orders are only available to people in the US, so I doubt I’ll be getting my hands on one of the first batches. Plus the lack of builtin SSD does put me off a bit (although I guess it might be possible to squeeze a small bus-powered SSD/hard drive into one of the internal USB ports).

But at least I now know the OMAP HAL will be useful for something closer to my original dream :)

Reading through the audio components, the only HAL component I found was that of a AC97 specific audio-mixer interface.

I admit that the HAL audio interface is rather incomplete, born out of historical restrictions and bits of the HAL having been developed in a less-than-ideal sequence. For example, the general-purpose DMA API was only settled very late on, and first implemented for the Iyonix (and after Iyonix’s sound system was completed). Every chipset I’ve seen for many years uses its general-purpose DMA controller for the sound subsystem (OMAP is no exception) so it would make sense for SoundDMA to use the DMAManager module internally, rather than including duplicate driver code.

The SoundDMA source code is not well abstracted at present, and I’d love to see that change! You’ll see that there are two separate implementations of SoundDMA in ROOL’s CVS: one for IOMD machines (Sound0), and one for Tungsten/Iyonix (named Sound0Trid after the Trident chipset that it uses). There are several more SoundDMA modules that have not been published, targetted for the various other chipsets that Pace supported, and another for Castle’s ARM9 STBs. A number of these are sure to have used I2S, so could be instructive for the OMAP port (OMAP uses I2S) but I’m not sure what the status would be on releasing any of them.

I assure you the mixer API is not meant to be AC97-specific. The API is intended to interface with the analogue audio chipset on the board, whatever that may be: granted, AC97 codecs are the most complex audio chipsets you’ll come across and so the API reflects their capabilities, but even the most basic I2S receivers will have at the absolute minimum an audio attenuation and/or mute capability. The mixer API is an example of a “HAL device”, which is one of the later developments in the HAL - if you’re not familiar with them, you can read all about it in the Kernel Docs directory. I’d strongly recommend its use for all major new APIs because of features like support for hot-plugging and power-saving modes.

The module on the OS side that corresponds to the mixer devices is the SoundCtrl module, RiscOS/Sources/Audio/SoundCtrl. At the GUI level, it corresponds to the SndSetup plugin for !Configure.

Back to the digital audio side: I’d recommend the first thing to get working is the general-purpose DMA controller. This would be accessed via the HAL device API again – but this time the module on the OS side that talks to these devices is the DMAManager module. This has now had fairly extensive testing on the Iyonix, since it is used for UDMA ATA and floppy disc data transfers.

Next, I’d suggest that a proper HAL API be defined for audio. Things like the ulaw to 16bit linear conversion code should remain in the SoundDMA module – every platform for the best part of 20 years has supported 2-channel 16bit linear audio (barring occasional quirks like varying endianness) and are likely to continue to do so, so it doesn’t make sense to place this inside the HAL.

I would recommend the use of a HAL device for audio controller, providing for the remaining functionality:

• reporting the audio DMA logical chanel, transfer unit size, physical address etc (basically, all the parameters that will be needed for SoundDMA to call SWI DMA_RegisterChannel)
• an entry point to enumerate all available sampling frequencies – maybe with an option for the device to specify an upper and lower bound if very fine-grain graduations are supported
• an entry point to set the sampling frequency

I admit that though I’ve done a lot of work on DMAManager, I’ve never studied SoundDMA in depth so I may have missed a subtle requirement, but I believe this is a good starting point for a new sound driver API, and one that should make it easier to port to other chipsets in future.

Well I’m not sure why Uwe hasn’t mentioned it yet, but earlier this week we booted the first RISC OS kernel on a real beagleboard :)

The new MMU and cache code seemed to be working OK, so after a quick tidy up I’ve now checked the code into CVS. For the moment the MMU code is handled by a new MMU interface file – i.e. the header file Programmer.HdrSrc.hdr.MEMM.VMSAv6 and kernel file Kernel.s.VMSAv6. This also means there (ideally) needs to be a new machine type specified, which will set MEMM_Type to VMSAv6 instead of ARM600 - but I’ve left those changes out of CVS since IIRC you were against the idea of implementing VMSAv6 support in a way which prevents the kernel from selecting between ARM600 and VMSAv6 MMU models at runtime. Plus I don’t have write access to all the right bits of CVS, and wouldn’t want to tread on peoples toes by inventing a machine type name myself. So remember that when you want to compile the code yourself you’ll either have to add a new machine type or hack Programmer.HdrSrc.hdr.Machine.Machine to set MEMM_Type correctly.

So, regarding the integration of the MMU code – the code changes are relatively simple and could easily support runtime switching. However the tricky part is the way that the page table constants in hdr.MEMM.VMSAv6 have had to be changed, the main issue being that AP_ROM can no longer be 0. So to support runtime switching we’d either have to provide AP_ROM_ARM600, AP_ROM_VMSAv6, etc. style AP_* constants, or use lookup tables to translate a common format (e.g. RISC OS access types) to the MMU AP flags. This is already handled in part by the PPLTrans tables, but would need updating to select the right table for the right MMU type, and would need implementing in a way that supports the initial page table setup.

• HdrSrc.hdr.MEMM.ARM600/VMSAv6 is a bit of a mess since it contains constants for page tables as well as the CP15 control register flags, and the cache type values used by kernel.s.ARMops. Some reorganisation of these headers are probably needed, especially if we decide to stick with the seperate headers.
• There’s a lot of non-HAL code in kernel.s.ARM600, as evidenced by the much smaller size of kernel.s.VMSAv6. Splitting kernel.s.ARM600 into two seperate files might help improve readability and reduce chances of error when making changes.
• When making a decision about how to best integrate VMSAv6/v7 support, we need to take into account adding support for new features such as the dual L1 page table/process ID system that allows for fast task switching. Implementing support for this may be harder if the OS has to decide at boot time which MMU model it is to support.
• ECC support – If the OS is meant to decide at boot time what MMU model to support, surely it should also decide whether to enable the XScale ECC code too? Currently it’s controlled via a flag in hdr.Options

I’m sure there are other things I’ve forgotten about, but I’m sure I’ve given you enough to think about for now :)

Why i did’n tell? Who did all the work? Well, as i see it, all praise has to go to Jeffrey :)