It's not what David claims to be a bug in OS 6.14.
It's a bug that I found out by making some tests for David, i.e. that SWI OS_SpriteOp 15, when checking if it must create a 64 cols or a 256 cols palette, will create a 256 cols palette when your desktop mode in 256 or 64K colour mode and a 64 cols palette for other desktop screen modes.
This means that the SWI is reading some information from the current screen mode intead of the screen mode passed as parameter to the SWI.
I wonder what the "HD" media capability of that processor represent? The windows notebook I use for work can handle most of the HD divx available on the net but it is not powerful enough to handle a full HD stream (at least in resolution 1920x1080 but at DVD rate, not HD-DVD nor BR) and not even
the maybe 3 years old 2.4GHz PC of my firend could handle it.
Since most of the usage I make from a PC (off work) is browsing, torrent download and divx viewing, and the notbook is from my company my intention is to buy this year a compact PC, as silent and low power as possible, using USB2/e-Sata connection for mass storage and DVD-writer, if possible offering HDMI/DVI with HDCP and optical stereo jack for future compatibility and combined with a RISC OS emulation so that I can still develop for RISC OS.
Now if a RISC OS solution can offer the same functionality I am in perfectly willing to buy it. For that we could always port and optimize a linux multimedia player for that CE2110 processor even without a multimedia API in RISC OS, but I would certainly appreciate RISC OS supporting non-blocking IO (the time spend waiting idly for a block of data to be read from the harddisc could be used by the main processor) and support of USB PC drives larger than 2 GB which I use every week to exchange data with friends (and for which I currently have to slowly transfer data with Samba over my old 10Mb Ethernet connection between my notebook and my RPC).
Very few opensourcing of RISC OS so far apart from Unicode and the SharedCLibrary. It seems they want to only opensource peripheral components. With that in mind I think there are a few more components that would be interesting to propvide (if they have the rights to them): !Java and CDFS related components.
I find it amusing that someone at Castle is advocating for open sourcing RISC OS when in the past they forced RO Ltd to withdraw the open sourced version of !Printers.
That said l agree with Julian there are a few developers out here with the technical knowledge to seriously improve some parts of OS, especially since it seems that on both Castle and RO Ltd sides manpower is now seriously limited.
The fact that Select 4 won't use the HAL API doesn't mean there is no Hardware Abstraction in Select 4, only that they decided to do it another way. If you look at Castle's HAL API ([link]) you will notice that there isn't much to it (interrupts and timers), there is nothing in it related to graphics or sound. Till recent work on newer graphic cards Castle admitted that RISC OS 5 was tied to the graphic card used in the Iyonix.
It certainly would be better that they cooperated together and avoided the divergence of the versions of the OSes but given the current state of affairs ...