Let's get started with a Pandora port

The Pandora handheld computer/console is now available for preorder. I doubt we’ll get a better target for RISC OS than this. Who wants to get cracking?

Link is here – http://www.openpandora.org/

Ok – I have a Pandora on pre-order. If someone is willing to port RISC OS to it, I will buy another and gift it to the porter.

That’s a good offer. Do you want to post this on comp.sys.acorn and see if you get any takers?

I can only second the idea of porting RiscOS to Pandora (as I also have a Pandora on pre-order and some RiscOS-systems at home). What would be needed to get such a task going?

I’m guessing no-one’s actually started work on this yet?

Although I don’t personally want to run RISC OS on the Pandora, I would like to see it running on one of the ARM netbooks that are due out this year, so I feel that it is important that we start work on a port to Cortex-A8 platforms.

1. Buy a Pandora and port to that. However Pandoras are rather hard to get hold of at the moment, and I’m not sure whether new models will have accessible JTAG connectors for debugging the initial attempts at getting the kernel running.
2. Buy a BeagleBoard and port to that. A better development platform, but due to its bare-bones nature it’s perhaps not the best choice if you’re planning on using it once you’ve finished porting RISC OS.
3. Use an emulator. qemu-omap3 is a recently started project which adds OMAP3530 emulation to QEMU (i.e. the same Cortex-A8 SoC as used in the Pandora/BeagleBoard). So far it emulates enough to be able to run the BeagleBoard bootloader and the sample linux kernel. Video support isn’t complete, but it works well enough for the bootloader to be able to display the BeagleBoard logo. I’d say that this is enough to enable us to port the RISC OS kernel to it. For the moment this is the approach I’ll be taking for development (although I suspect it will be a while until I actually try running anything).

1. Produce a small, independent test ‘kernel’ that can be loaded using the beagleboard bootloader and sends(/receives) data through the serial port. Until video drivers are written the serial port is likely to be the best I/O interface available, both for regular interaction with the OS and for any debugging/trace messages.
2. If people are using QEMU and there aren’t enough built-in debugging features, add whatever is needed.
3. Create a new OMAP3530 HAL. Or perhaps a generic Cortex-A8 HAL if there aren’t any major differences between each Cortex-based product.
4. Modify the ROM build process so that it produces something that can be booted as if it were an ARM Linux kernel. I.e. rather than having to worry about writing a bootloader for each device we want to port RISC OS to, we can just use the existing bootloader to load a RISC OS kernel instead of the linux one. This should also be safer, since some bootloaders may have built-in recovery modes which allow you to repair broken systems by copying/booting from SD cards, etc. As far as I know we wouldn’t actually need to change the ROM build process to support this, just the HAL, but I’m mentioning it just in case.
5. Determine the minimum set of modules needed to create a working ROM image. I.e. something to allow us to boot the kernel and interact with the CLI (most likely via the serial port).
6. Build said ROM image and get it working.
7. Rejoice!
8. Begin the long, hard task of filling in all the other missing features.

1. Does anyone have any better ideas? Obviously I’ve written most of the above from the perspective of performing initial developing using QEMU, but if you’re going to develop on real hardware than feel free to suggest any changes that would make that task easier.
2. Does anyone want to volunteer for any of the above? (Except for the rejoicing task, I’m sure I can handle that one myself)

I’m guessing no-one’s actually started work on this yet?

Well not me, anyway.

With regards to [running RISC OS on Pandora], I think developers have three choices [Pandora, Beagle Board, qemu-omap3]

The closest I’ve personally come to bringing up RISC OS on a new board was tweaking the IOMD HAL just before Christmas to run on an A7000 rather than the Risc PC it was written for; this was without a JTAG of course, and I have to say it was a painful experience. Outside the RISC OS world, I’ve used JTAGs (and the associated runtime debugger runnning on a host system) and also worked on systems where JTAGs were not available, and I have to say I’d always choose the JTAG option whenever available for any low-level work, or even complex software such as codecs. I’m not familiar enough with qemu to say whether it provides equivalent debugging access to the emulated system, and I’d also be a little wary developing for an emulator in the sense that it may have bugs in the emulation, and it’s unlikely to emulate certain aspects of the hardware such as PLL registers. Its big advantage is the price, of course.

Acorn used emulators in the development of the Risc PC - but this was before the likes of JTAGs were commonplace. All the new CPU support and HALs developed by Pace and Tematic were brought to life using JTAGs. Also, in all cases except the Iyonix, the first port to any given chip family (let alone each new CPU core) was always done first to a development board – and even then, the XScale core support was initially implemented on an 80200 development board by Pace, so we only had to write support for the IOP chip family from scratch for the Iyonix. The Beagle Board appears to be a development board for the TI OMAP-3 chip family, so I’d definitely target it before the Pandora.

I’d add that it’s a risk attempting to jump straight to Cortex-A8, especially when so much experience of porting the OS has been lost. RISC OS has always been developed incrementally, and currently supports ARM-6, ARM-7, ARM-8, StrongARM, ARM-9 and XScale cores. The HAL was first developed for ARM-7 variants which lacked 26-bit mode before we moved on to ARM-9 and XScale devices. If it were up to me, I’d want to do a port to at least one development board based on ARM-10 and ARM-11 before moving on to Cortex.

Produce a small, independent test ‘kernel’ that can be loaded using the beagleboard bootloader and sends(/receives) data through the serial port. Until video drivers are written the serial port is likely to be the best I/O interface available, both for regular interaction with the OS and for any debugging/trace messages.

In early stages of board bringup, it is normal to direct console I/O through a serial port or other UART, especially since keyboards tend to require a functional USB stack these days! Look for the kernel build switch DebugTerminal (which is disabled on mature builds), which redirects kernel console I/O through HAL entries HAL_DebugRX and HAL_DebugTX, which are usually implemented as a UART driver.

Create a new OMAP3530 HAL. Or perhaps a generic Cortex-A8 HAL if there aren’t any major differences between each Cortex-based product.

It’s highly unlikely that it’s appropriate to have a single HAL for all Cortex-A8 devices. Cortex-A8 only defines the CPU core and associated hangings-on like caches. The OMAP3530 will contain a large amount of silicon designed by TI which won’t be present on any Cortex-based devices made by other ARM licencees.

I’d say that the obvious device bracket to code into one HAL would be TI’s OMAP-3 family. The bulk of the HAL code for an OMAP3530 board (such as Beagle or Pandora) would be the same as that for an OMAP3503, OMAP3515 or OMAP3525 board. Bear in mind that the HAL contains the low-level (nominally OS-independent) driver code for all devices on the main board, and since all these devices are integrated onto the same die, any such boards can’t help but share the same driver code. In an ideal world, it would be possible for the HAL to probe the board at run-time and determine which variant it is (perhaps for fit/no-fit options for connectors). Acorn always ensured that it was possible to do this – witness that the same OS ROM chips will work in any Risc PC, A7000 or A7000+ despite significant specification differences – but as we found out for some of Castle’s ARM-9 designs, it’s not always possible to distinguish different third-party boards at run-time and you have to drop back to build-time variants. Build-time switches are set in the Components file (RiscOS/BuildSys/Components/...).

I’d also point out that a chunk of the porting work would be need to be to the kernel as well as to the HAL. This is because support for CPU core architectures was deliberately kept in the kernel (to avoid lots of code duplication between HALs for different chips with the same core). This means things like cache management and page tables, both of which may have had significant changes – I note from my brief examination of its specs that the OMAP3530 has a L2 cache, for example.

Modify the ROM build process so that it produces something that can be booted as if it were an ARM Linux kernel. I.e. rather than having to worry about writing a bootloader for each device we want to port RISC OS to, we can just use the existing bootloader to load a RISC OS kernel instead of the linux one. This should also be safer, since some bootloaders may have built-in recovery modes which allow you to repair broken systems by copying/booting from SD cards, etc.

I’m not that familiar with the interface between Linux and its bootloaders, but I don’t think it’s a good fit with RISC OS really. It is my understanding that the model is similar to what happens when we run a soft-loaded OS - the bootloader (like the underlying ROM OS) sets up the hardware to the point when it can mount a filing system on some non-volatile storage – disc, SD card or just a partition on the NAND flash – and extract and run files from that filing system which constitute the OS proper (like the softloaded OS in my analogy). I’m not sure whether any of the driver code from the Linux bootloader is used once the OS is running, or whether there is duplicate driver code in Linux.

RISC OS ROMs are still 4 – 8 MB in size, and are not file-based; the constituent modules are concatenated (for assembler) or linked (for C) together. The HAL acts as a low-level bootloader – initialising clocks, the RAM controller, assigning addresses on the PCI bus (if present) etc. But it doesn’t need to get as heavyweight as a Linux bootloader because the OS image is invariably small enough to fit on the same boot device as the HAL - filing systems don’t need to be brought up until after the kernel is running, not before. The HAL also provides both information for the running kernel (such as tables of physical RAM layout) and a series of code entry points to do various bits of low-level jiggery pokery.

I imagine you could launch a soft-loaded RISC OS HAL+OS image from a Linux bootloader if you wanted to. You could then omit the bootloader aspects from the HAL (RAM controller initialisation’s an important one for soft-loaded code!) but you’d still need an implementation of all the HAL entry points to the API that RISC OS expects, and that’s usually the bulk of the work. If the Linux bootloader provides equivalent functionality then it’s possible a translation layer could be written, but such things usually hurt efficiency, and if the volatility of the rest of the Linux kernel API is anything to go by, it would present an ongoing maintenance headache.

Also note that there is flash recovery code in the Iyonix HAL which is probably largely re-usable in other HALs, so that’s another aspect of the Linux bootloader that we don’t need.

Determine the minimum set of modules needed to create a working ROM image. I.e. something to allow us to boot the kernel and interact with the CLI (most likely via the serial port).

That’s a surprisingly short list, we’ve had functioning ROMs with little more than the HAL and Kernel, possibly including FileSwitch, ResourceFS, Messages and MessageTrans to get token lookup working too. You’d normally need to include various other modules in the component file (labelled as -type EXP so they aren’t built into the ROM yet) otherwise the modules won’t build due to missing header files. The process of incrementally getting a ROM building isn’t all that hard once you’ve mastered a few basics.

Build said ROM image and get it working. Rejoice!

Well, it’s a start…

Begin the long, hard task of filling in all the other missing features.

There are some things – like touch screen drivers – that were developed by Pace but have never seen the light of day by ordinary desktop users.

I’d like to plead that if people are going to write drivers for generic hardware types which are new to RISC OS - such as MMC/SDIO controllers, camera controllers etc – that they take a look at the “NewAPI” HAL docs. There was a long-term plan to move the majority of drivers over to this “HAL device” API, and it makes sense for any new drivers to start from this point. There are lots of nice things about the HAL device API that are missing from the earlier generation, particularly the support for expansion cards (whose drivers are implemented as modules, not by the HAL), hot-pluggability and device suspend/hibernate support that’s particularly important for portable devices (like Pandora, for example). Yet, to date, only DMA and audio mixing have been implemented to the HAL device API.

Does anyone want to volunteer for any of the above? (Except for the rejoicing task, I’m sure I can handle that one myself)

I’m probably the sort of person you’d want on board, but I have very little free time, much of which get soaked up by ROOL admin and show preparation, and if a Pandora port went ahead, I expect I’d spend a lot of time advising people rather than writing much myself. And I do think you’d need a team of people to attempt this; previous ports have neeeded 1-4 full-time engineers for at least a few weeks to get as far as the command prompt, and this would be an ambitious port with inexperienced and probably spare-time programmers.

Well, you’ll be pleased/alarmed to hear that despite the potential problems, I’ve started work on this project.

and I’d also be a little wary developing for an emulator in the sense that it may have bugs in the emulation, and it’s unlikely to emulate certain aspects of the hardware such as PLL registers.

Yes, I am aware that the emulation may not be as accurate as required. But until the real machines I’m interested in are released (the Cortex based netbooks), qemu is at the right price point. If I run into problems later on (or safely testing kernels on the netbook looks too hard) I can always buy a dev board then.

I’d add that it’s a risk attempting to jump straight to Cortex-A8, especially when so much experience of porting the OS has been lost. RISC OS has always been developed incrementally, and currently supports ARM-6, ARM-7, ARM-8, StrongARM, ARM-9 and XScale cores. The HAL was first developed for ARM-7 variants which lacked 26-bit mode before we moved on to ARM-9 and XScale devices. If it were up to me, I’d want to do a port to at least one development board based on ARM-10 and ARM-11 before moving on to Cortex.

I’ve heard similar advice elsewhere. If I encounter any serious problems I’ll consider porting to something simpler first, but as far as I can tell there won’t be any major issues (Not that I’ve examined all the documentation in detail yet).

In early stages of board bringup, it is normal to direct console I/O through a serial port or other UART, especially since keyboards tend to require a functional USB stack these days! Look for the kernel build switch DebugTerminal (which is disabled on mature builds), which redirects kernel console I/O through HAL entries HAL_DebugRX and HAL_DebugTX, which are usually implemented as a UART driver.

I’d spotted HAL_DebugRX and HAL_DebugTX, and was wondering whether they’d be useful. Thanks for the info!

I’d say that the obvious device bracket to code into one HAL would be TI’s OMAP-3 family.

Yes, that would make sense. At the moment my HAL is called ‘Beagle’, but I suspect it will run on most OMAP-3 boards with little hassle.

I’d also point out that a chunk of the porting work would be need to be to the kernel as well as to the HAL. This is because support for CPU core architectures was deliberately kept in the kernel (to avoid lots of code duplication between HALs for different chips with the same core). This means things like cache management and page tables, both of which may have had significant changes – I note from my brief examination of its specs that the OMAP3530 has a L2 cache, for example.

I haven’t looked in detail at the cache/MMU yet, but I suspect that will be where most of my headaches will lie with getting a working kernel.

I’m not that familiar with the interface between Linux and its bootloaders, but I don’t think it’s a good fit with RISC OS really.

1. Boot ROM inside the CPU loads the bootloader from the configured boot device (as selected by pin inputs to the chip)
2. The loaded bootloader (TI’s x-loader) performs some hardware initialisation (e.g. RAM) and then loads an executable image from the boot device. Typically the executable it loads is the U-Boot bootloader.
3. U-Boot will perform some simple self-tests (tone on speakers, image on screen) and then load the linux kernel & ramdisk (compressed filesystem), validate the kernel, and then execute it.

U-Boot is a relatively flexible & user-friendly bootloader, which I suspect is why they’ve chosen it as the executable for x-loader to load, as it will allow you to switch to a different linux kernel/boot device if you break your default one. It also looks like it’s the only way to boot a linux kernel on the device (unless you replace x-loader), since x-loader won’t know to load the ramdisk or pass the kernel its initialisation arguments.

Initially I tried writing some test code which replaced the linux kernel image that U-Boot loads, but that was foiled by U-Boot’s header checks (since my code didn’t have any headers). So then I replaced U-Boot and had x-loader load my code directly, which resulted in my desired stream of characters being output over the serial port.

I’m not sure whether any of the driver code from the Linux bootloader is used once the OS is running, or whether there is duplicate driver code in Linux.

Linux will take over full control of the system once its kernel has started. This also means that U-Boot (and x-loader) leave the system in a relatively clean state ready for Linux to take over. So as far as I know there shouldn’t be much work needed to modify a softload-aware RISC OS ROM image to be bootable from a Linux bootloader. It also makes life a bit easier for the HAL, since it won’t have to worry about initialising the system features that the bootloader will have set up already (e.g. RAM).

I’d like to plead that if people are going to write drivers for generic hardware types which are new to RISC OS - such as MMC/SDIO controllers

I suspect it will be a long time before I get to implementing MMC/SDIO drivers, but I’ll certaintly take a look at expanding the HAL when the time comes.

... I expect I’d spend a lot of time advising people rather than writing much myself.

Advice is always welcome! :)

In a few days I’m hoping to have a working HAL. Then I’ll have a go at writing a simple testbed ontop of/inside that, to make sure it actually works how it’s expected. Then I’ll move on to looking at the kernel and trying to package it up into a ROM image.

Even if I do fail miserably, we’ll at least have a working Cortex-A8/OMAP HAL upon which future attempts can be based.

That sounds good to me. So let’s DoIt. I’d like to help in this. Will there be a separate repository? When, where? I have a beagle board here and am in the process of getting it connected to my local network to use it as development machine/target under angstrom. I also plan to ‘update’ to a pandora as soon as they are available.

Excellent!

Will there be a separate repository? When, where?

Unless the ROOL team offer to host our development code while we work on it, I suspect we’ll have to set up our own hosting somewhere. SourceForge, riscos.info, etc. – I’m not really bothered where we host it, but obviously somewhere with source control would be better than without. So if you’ve got any preferences on where to host just say so.

I have a beagle board here and am in the process of getting it connected to my local network to use it as development machine/target under angstrom. I also plan to ‘update’ to a pandora as soon as they are available.

Well I’m still using QEMU, so I guess your first job will be to make sure my code actually runs on a real device ;) But if it turns out that QEMU’s emulation is too poor for me to use for development then I’ll gladly spend some money on getting a real dev board.

• The HAL is 90% complete. Although I’m yet to test most of the code, the initialisation process works fine – it can identify the attached RAM, relocate itself to a safe location, clear the remainder, and then boot the OS. Currently I’m booting the HAL via x-loader, but I’d assume that the startup code is suitable to allow it to be booted from u-boot also (assuming someone adds a fake linux kernel header to the image).
• So far, ‘the OS’ is a test kernel I’ve written that just prints out the addresses of various things using HAL_DebugTX. But it’ll also provide a good testbed for the untested HAL components, and due to its simplicity can hopefully be reused in any ports of RISC OS to other platforms.

After finishing & testing the HAL I was planning on going on to look at each of the RISC OS kernel source files in detail, to track down all the machine-dependent bits that need changing. I suspect this would be the first opportunity we’d have to work in parallel on the project (assuming we have our source control set up by then).

• BeagleBoard reference manual
• OMAP3530 TRM
• Cortex-A8 TRM
• ARMv5 ARM (The latest ARM ARM, containing info about the Cortex-A8, isn’t publicly available yet – and I haven’t yet tried contacting ARM to see if they’ll give us a copy)
• And of course the BeagleBoard x-loader, u-boot and sample kernel source

Unless the ROOL team offer to host our development code while we work on it, I suspect we’ll have to set up our own hosting somewhere.

We’d be more than happy to do that! Although most people send us code updates as patches that “the management” end up committing to the repository, we always meant for a wider group of developers to get involved – that’s why we have a publicly accessible repository and all this supporting website rather than just a set of tarballs on an ftp server.

In cases like this where multiple developers are working on the same code, you really want to be using source control – so I’d encourage anyone getting involved to email us their public SSH key and a scrambled CVS password (ask if you don’t know what I mean by that) and we’ll set you up with an SSH tunnel to our host and a writable account on CVS.

RISC OS has had an unfortunate history of fragmenting when held in different repositories and we can really do without spending precious time on doing manual merging across different repositories when a central CVS can do it for us.

I’d suggest that changes to the kernel go on a development branch until we’re fairly happy that it’s stable again – otherwise we risk breaking Iyonix builds. But most of the other modules should be able to remain unchanged – all the hardware-specific bits should be in the HAL (remember the HAL contains lots of runtime driver code as well as bootstrapping, so I’m afraid your “90% complete” estimate is probably a bit on the high side).

ARMv5 ARM (The latest ARM ARM, containing info about the Cortex-A8, isn’t publicly available yet – and I haven’t yet tried contacting ARM to see if they’ll give us a copy)

You’ll definitely want the v7A ARM ARM. As long as you’re not working for one of their competitors, they seem pretty happy to hand them out, but they do insist that it’s a single-user document, so you’ll have to ask for one each. Say you’re doing work for RISC OS Open if you like.

One other thing: I know that the ROM build process can be a bit daunting at first. Would you like me to put together a bare bones OMAP3 ROM build?

I’ve written a brain dump on ROM builds here which I hope you’ll find useful. My offer to create initial versions of all the necessary files still stands.

In cases like this where multiple developers are working on the same code, you really want to be using source control – so I’d encourage anyone getting involved to email us their public SSH key and a scrambled CVS password (ask if you don’t know what I mean by that) and we’ll set you up with an SSH tunnel to our host and a writable account on CVS.

What kind of things would we be needing the SSH access for? (I’m guessing we’re using pserver CVS access, but it’s been a long time since I’ve used CVS so correct me if I’m wrong)

(remember the HAL contains lots of runtime driver code as well as bootstrapping, so I’m afraid your “90% complete” estimate is probably a bit on the high side)

Yes, I think I meant to qualify that statement with ”...from the point of view of booting the RISC OS kernel”. Working video and audio support can wait!

Would you like me to put together a bare bones OMAP3 ROM build?

Yes please!

I’ve written a brain dump on ROM builds here which I hope you’ll find useful. My offer to create initial versions of all the necessary files still stands.

Can you check in the build product for the 26-bit HEAD RiscPC/A7000 build please?

Can you check in the build product for the 26-bit HEAD RiscPC/A7000 build please?

That’s off-topic for this thread, I’ll post a reply in the thread “Previous Risc PC builds (at Pace)”.

What kind of things would we be needing the SSH access for? (I’m guessing we’re using pserver CVS access, but it’s been a long time since I’ve used CVS so correct me if I’m wrong)

Yes, we’re using pserver. The problem is that pserver isn’t secure across the Internet (the obfuscated CVS user password is sent in the clear as I understand it), so what we do for remote access is to tunnel a port on the user’s machine to the pserver port on the server over an SSH connection. The reason why we need your public SSH key is to allow you to ssh to the machine without us having to give away the shell password.

I should probably elaborate on the CVS password thing if you’re not familiar with it. Nobody has ever got round to inventing a cvs passwd command, so the procedure for setting your CVS user’s password involves you scrambling your own password, for example by doing

perl -e 'print crypt("mypassword", "randomseedchars")'

then getting someone with write access to the server (that is, me, Steve or Andrew) to install that scrambled password for you. I’m suggesting you email it to us, though technically we should use a secure communication channel for that too.

Anyway, back to the subject of ROM builds. I’ve got a very minimal build running here with a HAL that just does an infinite loop. I’m part-way through committing the changes to the repository, but I’ve realised I don’t know where to put the HAL (or where to tell the build system to look for it) because I don’t know what licence it’s going to fall under. At a guess, have you been using bits of code or headers from Linux? If so it’s going to have to be GPL, but that also means we’ll have to be careful not to merge in anything that uses the Castle licence.

OK, I’ve mailed the info to the info@... address. Presumably someone there will know what to do with it :)

At a guess, have you been using bits of code or headers from Linux? If so it’s going to have to be GPL, but that also means we’ll have to be careful not to merge in anything that uses the Castle licence.

Everything I’ve used so far has either been existing code under Castle’s license or stuff I’ve written myself. I’ve certainly got no complaints about it all going under Castle’s license.

You’ll definitely want the v7A ARM ARM. As long as you’re not working for one of their competitors, they seem pretty happy to hand them out, but they do insist that it’s a single-user document, so you’ll have to ask for one each. Say you’re doing work for RISC OS Open if you like.

Doesn’t look like that’s going to work for me:

Thank you for your interest in ARM Physical IP products. After reviewing the information provided during the online registration, we have determined that your application does not align with the ARM business profile for access due to the following: = Our company requires that the email address provided for your account must be your employer’s corporate email address. The email address provided is a personal email account. Based on the above, access to the restricted area of the ARM Physical IP web site is not available.

Luckily, the lack of ARMv7 ARM doesn’t seem to be a major problem in getting the kernel working.

(OK, so this is still under QEMU, and I’m not entirely sure I’ve chosen the correct L1 cache management functions, and the L2 cache is turned off, but it’s a good start)

Once I’m done rejoicing I’ll tidy it up a bit and add it to CVS so other people can start getting involved.

Oooh, This looks already amazing! Keep up the good work!

The code is now in CVS, under the OMAP3Dev product – except for HALTester, which you’ll have to get manually if you want it. HALTester is in castle/RiscOS/Sources/HAL/HALTester.

One thing I’m not sure about though is what to do with my todo list – do ROOL have any ideas? I’m thinking that a simple wiki page would serve the basic needs of listing things which haven’t been added to CVS yet (and who’s implementing them). Then, once something is in CVS, the bug tracker (with an appropriate Cortex/OMAP ‘part’) could be used to track any remaining progress to complete the implementation or fix bugs.

Agreed. A wiki page looks like the best solution for this. Great work, BTW!

I’ve started a wiki page – https://www.riscosopen.org/wiki/documentation/pages/Cortex-A8+port

I suspect there’s a hundred and one things missing from the task list, so if anyone can think of anything that isn’t explicitly listed, feel free to add it :)

There’s potentially a biggie relating to framebuffer formats – as is sadly often the case, the chip expects “deep colour” modes to have the red bits in more significant bit position than the blue bits, when RISC OS has always put them the other way round. Plus, the 16bpp modes can’t be configured to 1:5:5:5 as RISC OS expects, and I’m a little worried that all the alpha bitfields are just that (0 = transparent, max = opaque) whereas RISC OS works the other way round, and I don’t think the alpha bits are paletted.

I’ve asked TI about this and haven’t heard back from them yet – it’s probably time I gave them a little prod. Ideally we might be able to get a hardware fix in time for some of these upcoming platforms, since the alternatives are unpleasant:

1. Write to an off-screen buffer and do on-the-fly translation to the native framebuffer format (even if we could program the DSP to do the job, there’s still at least a bus bandwidth penalty).
2. Add a number of new sprite formats and all the attendant conversion routines. Would need to touch at least ColourTrans, SpriteExtend, Font manager. Applications that do direct screen access would need adapting (mobilising this effort would be a major task in itself). Applications which assume they can do untranslated sprite plots when the colour depth matches would need to be changed to check that the the exact sprite format matches. Sprite formats should be assigned the same numbers as those used by RISCOS Ltd where they overlap, so as to cause minimal pain for application authors.

Given that the whole RGB vs BGR issue has plagued RISC OS for some time, maybe now’s the time to bite the bullet. We already have hardware platforms with software-switchable RGB/BGR ordering (later Iyonix graphics cards). We already have hardware platforms that support both 1:5:5:5 and 0:5:6:5 bit layouts for 16bpp modes (VIDC machines). Is there the enthusiasm to do this?

The pixel formats aren’t going to be an immediate issue for the OMAP port. 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. Unfortunately it only applies to the LCD output, not the TV-out – but I doubt many people would be interested in TV-out anyway.

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). Plus there are two blending modes supported by the overlay manager – alpha mode and ‘normal’ mode, which uses a transparency colour key. So there are two solutions to that problem.

The only problem that can’t be solved in a simple manner is the lack of a suitable 16bpp pixel format.

I think the best long-term goal would be to start extending the OS so that new pixel formats can be easily supported. If we also provide functionality for emulating unsupported pixel formats (by software/hardware conversion of a fake off-screen framebuffer) then we can also support new hardware without (severely) punishing users who rely upon old, incompatible software.