RISC OS 5 pictured running on ARM Cortex-A8 kit

Published: 25th Apr 2009, 15:03:35 | Permalink | Printable

Picture exclusive - This grainy photograph shows a port of RISC OS 5, sourced from the RISC OS Open project, running on a Beagleboard - a device powered by a 600MHz ARM Cortex-A8 processor with a built-in graphics chip. The port, developed by Jeffrey Lee with help from Uwe Kall and ROOL staff, is seen as a major breakthrough for the shared-source project as it proves the OS can be ported to new hardware without the need for a large team of engineers.

Click for a larger image

The picture, taken on Jeffrey's webcam, shows a Beagleboard and RISC OS 5 booting from a ROM image built with ROOL's sources with 256M of RAM and reaching the command-line prompt. The core of the operating system is able to drive a monitor via a DVI connector and can communicate with the outside world via a serial port. Jeffrey said his next step is to work on bringing in USB support so that a keyboard and mouse can be attached to make the device a useful desktop machine.

The low-power Beagleboard, which sells for about 100 quid, uses an ARM-compatible processor from the Texas Instruments OMAP350 range. It features a built-in OpenGL-compliant graphics processor to speed up 2D and 3D drawing to the screen, a maths unit mainly for processing streams of data, memory card slots, audio in and out, USB and other interfaces.

The port also means ROOL's RISC OS 5 is capable of running on the ARM Cortex family of processors, which are set to be used in a much-awaited range of trendy handheld netbooks.

Jeffrey told Drobe: "Video output is certainly working on real hardware.

"Regarding the status of the port, the kernel and critical HAL components (such as the interrupts, timers and serial IO) are the only real things that are working apart from the video code.

"Now that video is working the next goal is likely to be writing the USB drivers, since they should allow for a ROM image to be built that contains all the key features of a computer - the RISC OS desktop, keyboard and mouse support, and access to storage devices. This should hopefully make it a lot easier to test and develop the remaining features than just using the serial console and VDU output.

"Once all the hardware drivers are working there'll still be plenty of work to do to improve their functionality, and to update the kernel and other software to make use of the new CPU features - the most notable features are likely to be the VFPU and an API to allow use of the spare hardware YUV overlay."

* RISC OS Open demonstrated for the first time an A7000 running 32bit RISC OS Shared 5 at the Wakefield 2009 show to prove that its drivers for the Acorn IOMD chipset do work, paving the way for a freely-available RISC OS 5 ROM for RiscPCs.

RISC OS Open was born after RISC OS 5 developers Castle decided to share the source code to its operating system with the world to encourage third-party programmers to contribute to the OS and allow free copies of the OS to be built for end-users to download, test and install. RISC OS 5, as a desktop OS, has been exclusive to the Castle Iyonix range of computers - until now. The Iyonix employed Intel's ARM-compatible 600MHz IOP321 processor.

Links

RISC OS Open website
The port's development discussion thread
The Beagleboard hardware The ARM-compatible OMAP processor from TI

Previous: Long-awaited Organizer 2 on sale with iCal import and export support
Next: Wakefield 2009 wrap-up, photos and video

Discussion

Viewing threaded comments | View comments unthreaded, listed by date | Skip to the end

Assuming a port can be made for a device with a functional desktop and access to storage devices, what would be the next stage?

AW on 25/4/09 3:19PM
[ Reply | Permalink | Report ]

The Beagleboard is capable of being a functional desktop with access to storage devices (there's someone running a GNU/ARM Linux desktop installation on it at the Wakefield '09 show). So the next stage, as Jeffrey said, is to finish USB support drivers so that you can plug a keyboard and mouse into it for the desktop.

diomus on 25/4/09 3:45PM
[ Reply | Permalink | Report ]

This is really an impressive milestone in RISC OS history. And it shows how well-designed the HAL in RISC OS 5 is. So now we have covered the lower end of the market, how about tackling the Intel IQ81342 dev board...

hubersn on 25/4/09 3:46PM
[ Reply | Permalink | Report ]

It has to be said, if the Beagle on the ROOL stand was anything to go by, only a handful (less than 10) of the modules have actually been ported; just enough to do what is shown in this photo. There's a huge amount of work to be done yet past what the HAL allows you to do with respect to the very low level parts of the hardware; USB, sound, mass storage, better video use, etc. will be much more effort than has already been spent.

rjek on 26/4/09 12:23AM
[ Reply | Permalink | Report ]

Rob,

I think you vastly overestimate the work to be done to get something useful, and underestimate the work already done to get that far.

Implementing the low level USB driver to connect the stack to the hardware is certainly (if the docs are there - and since there is a Linux running, it should not be overly difficult) doable. Having USB running automatically enables keyboard, mouse and mass storage. The video is certainly good enough for basic RISC OS usage. Sound support is completely non-essential, as many A9 and Omega users will happily(?) confirm.

There are obviously a lot of things to be done from the "nice-to-have" department. Having a driver to connect the SD/MMC interface to the SCSISwitcher would enable non-USB mass storage. Using the OpenGL accelerator for video would be nice. And implementing a driver for a USB network device would be very good.

But compared to the work that was apparently needed to port RISC OS to other hardware in the past (initial IYONIX work, A9, RiscStation, Mico, Omega), I am pleasantly surprised what two dedicated individuals can achieve in a comparatively short timeframe.

One of the most important things for the platform (IMHO) is to build up porting knowledge and a driver repository to make RISC OS more easily portable. With the hopefully soon-to-be-available ARM-powered Netbooks, we might have a nice range of RISC OS-capable hardware soon.

hubersn on 26/4/09 4:46PM
[ Reply | Permalink | Report ]

I'm not saying it's not possible, I'm just saying don't underestimate the amount of work that has to be done; it's quite likely vastly more than has already gone in; and if you want the SD (its only on-board storage past internal flash) and reliability, a new file system might even be needed! (Most SD cards, unless you buy the really nice expensive ones, have wear-leveling algorithms based around FAT.)

rjek on 26/4/09 5:26PM
[ Reply | Permalink | Report ]

I had wondered about the filing system actually. The current one, for all that it may have been a nice system when it came out, is a pain for compatability.

It may even be good for riscos to be forced onto a FAT file system. I'm vaguely aware that its flawed and outdated, but also that it is, as you say, the fs of choice for flash memory where the problems with it account for little.

Obviously this would also be a lot of work, but were it to happen I feel it would be removing an important obstacle to file compatability (This is based off limited knowledge of the issue though, so may be of no consequence).

Monty on 26/4/09 11:13PM
[ Reply | Permalink | Report ]

FAT could be /an/ option; modern implementations are almost universally actually rather good (guess which company can't produce a good implementation). I keep thinking RISC OS needs a JFFS2 implementation. A project on my todo list

rjek on 27/4/09 12:14AM
[ Reply | Permalink | Report ]

The wear-levelling algorithms in ordinary consumer flash devices are nothing to do with FAT. Cheap consumer flash has a built-in wear-levelling algorithm, and it is normally formatted with FAT, but the two aren't related.

FAT is a ghastly filesystem used with DOS, nobody likes it but it became the de facto solution for devices which must be shared between a variety of machines simply because of the popularity of PCs running DOS.

The wear-levelling algorithms (except in high-end SSD devices) do something noddy like maintain some blocks in a ring buffer and rewrite the next available block in the ring on update. This avoids writing the same block over-and-over, and thereby extends the life of the device.

JFFS2 (and its predecessor JFFS and their successor LogFS) are intended for use with a software translation layer on raw flash devices ("memory technology devices") with no built-in wear levelling. So for example, a set top box with 2MB of RAM and 32MB of raw flash, might use JFFS2 to store some resources like graphics for its OSD. When you switch the box on, JFFS2 requires a full filesystem scan, but that's OK because 32MB doesn't take long and people leave their STBs in standby anyway.

FAT and JFFS2 are like car batteries and jet fuel, they may share some properties in theory, but they have no real applications in common.

tialaramex on 27/4/09 10:46AM
[ Reply | Permalink | Report ]

Our experience differs from yours; where the cheaper end of the market only wear-levels the first few sectors; enough to cover the FAT.

I suggested JFFS2, because many modern ARM systems have bags of NAND in them that goes unused. (In the A9, for example, there's something like 256MB of which about 6MB is used, and it's all formatted JFFS2).

JFFS2 can mount things significantly more quickly if your implementation has summary node support. And unlike LogFS, it has a stable, clean, and understood implementation and behavior.

rjek on 27/4/09 12:06PM
[ Reply | Permalink | Report ]

Rob, I'm still trying to understand why you think that a vast amount of work is still needed. Do you agree that, once USB is available, the system is in a workable state? Do you think adding audio support is much work? What would you class as a "maybe not ideal, but it works" state?

Speaking of SD cards, I only ever read the spec of the wear levelling employed by SanDisk, and this is 100% compatible with FileCore. Since they are cheap enough, I can't see a problem telling people "buy SanDisk SD cards instead of the really cheap stuff". With prices currently at 30€ for 16GB for the UltraII cards, it is really cheap enough. If there is really a problem with FileCore on SD, just use DOSFS/Fat32FS as the default FS. Problem solved. Or else, use USB mass storage driver to connect a real HD. Problem also solved.

hubersn on 27/4/09 5:23PM
[ Reply | Permalink | Report ]

THIS IS WONDERFUL!!! The first concrete example that our favourite OS can indeed be made to work on new, inexpensive, and available hardware within the resources available to the RiscOS community... ...my heartfelt congratulations to the developer(s). The platform has a future.

As hubersn says it will also be good to see the same 'trick' done on more heavy-duty kit too...

Charlie on 25/4/09 9:16PM
[ Reply | Permalink | Report ]

Full marks to Jeffrey Lee, Uwe Kall and the ROOL lads this is indeed a significant development.

The newer ARM CPUs do offer facilities we could really do with, like fast floating point, added graphics and DSP support - if RO5.xx can be made to support these then we may see RISC OS do stuff that would have appeared a fanciful idea in the past.

The A7000 port of RO5.xx is at one level no less significant, and if it means that the RISC PC could in future be supported then we may even get a common OS across all the legacy native platforms - and available to most RISC OS users.

As the OS is a shared source there's no reason why it can't be even ported to A9Home - which would mean *all* the native ARM based hardware could be covered.

Interesting times indeed!

AMS on 25/4/09 10:37PM
[ Reply | Permalink | Report ]

Why would Risc PC and A9home users want to downgrade their OS in terms of features, just to run RISC OS 5? Better they stick to what they already have, and the effort is put into getting RISC OS 5 up and running on the Beagle board.

sa110 on 26/4/09 12:40AM
[ Reply | Permalink | Report ]

He, he. That is about as negative a spin as you could hope to put on the possibility of RISC OS 5 for the RiscPC.

A slightly more balanced view would be:

* It's a big upgrade for anyone running RISC OS 4.02 or below * It's fully 32 bit so the 28 MB application slot limit is removed * Old 26-bit applications can be run with Aemulor (which is free) * Most software is 32 bit now anyway * You can have the same OS across your RiscPC and IYONIX (in the case where you own both) * It's free and future updates are free * If you're a programmer and find a bug, you can get at the source code and fix it yourself * There is a bugs database and active forum at www.riscosopen.org where you can discuss any issues if you want

Apart from that though, it's hard to see why users would want it.

riscosopen on 26/4/09 2:02AM
[ Reply | Permalink | Report ]

Nitpick: Aemulor is free? Unless I'm missing some other site that has it for free...

[link]

This says £50.

bhtooefr on 26/4/09 2:20AM
[ Reply | Permalink | Report ]

> It's a big upgrade for anyone running RISC OS 4.02 or below

Apart from Unicode FontManager support (which, so far, only one mainstream program is using when it is available), what makes the upgrade "big" ?

> It's fully 32 bit so the 28 MB application slot limit is removed

Not sure what real end-user difference this makes but most, if not all, memory hungry applications can happily use DAs these days.

And as soon as you're running the Aemulor, the 28MB application slot limit is back.

> Old 26-bit applications can be run with Aemulor (which is free)

Free? Ahem.

> Most software is 32 bit now anyway

Which happily run on non-RISC OS 5 versions as well, so ?

> You can have the same OS across your RiscPC and IYONIX (in the case where you own both)

Eh, yes? And what advantage would that be ? Today RPC, VRPC and to some extend A9Home already can run the same OS. Hardly an advantage of RISC OS 5.

> It's free and future updates are free

I think this is the first time I see this long time promise. Does this mean Castle will never ask a fee when you distribute a licensed RO 5 under all circumstances ?

> If you're a programmer and find a bug, you can get at the source code and fix it yourself

We don't need to have RO 5 running for that. I suppose cherry picking could be an option as well.

> There is a bugs database and active forum at www.riscosopen.org where you can discuss any issues if you want

There is a similar forum for Select users as well. And I suppose the ROOL bugs database can be used to log bugs of all RISC OS versions, which incidentally would be great to track which fixes have been made in which RISC OS versions.

TBH I don't see many user convincing arguments here for replacing RISC OS 4 or RISC OS 6 by RISC OS 5. As developer I can see some potential excitement to do this kind of development, but this does not have a chance for ending up with a clean & reasonably QA'd OS version which end-users can comfortably install and use.

And it puts a further burden on the few RISC OS developers which see their product being deployed on yet another variant of RISC OS which need testing and supporting.

joty on 26/4/09 12:51PM
[ Reply | Permalink | Report ]

John,

I guess DHCP is the major features that makes RISC OS 5 a real upgrade for RISC OS 4.0x users. The large application memory slot feature might be a big advantage if you are running a 256 MB Risc PC and suffer from DA clamp/high bit DA problems.

I agree however that - at the moment - there is very little real, user-facing advantage for Select/RISC OS Six users. However, people actually paid for an upgrade from 4.39 to RISC OS Six despite the lack of real, user-facing advantages...

I also don't buy the QA argument. The changes people submitted for RO 5 so far are surely of similar quality than ROLs changes after the 4.39 release.

The big advantage RISC OS 5 has is of course its ultimate cheapness. You are not sure if you want to replace your trusted RISC OS 4.02 with RISC OS 5.xx? No problem, it is softloaded, and if it does not work as expected, you always have a safe fallback. Compare that to the 4.39 upgrade which some people had to rip out again because of severe problems.

I also cannot see the validity of the "burden for developers" argument. Currently, the biggest burden for developers is the rather expensive and sometimes incompatible RISC OS Six branch of the OS. A free RISC OS 5 variant for RISC OS 3.7 users would actually reduce the developer's burden.

hubersn on 26/4/09 2:03PM
[ Reply | Permalink | Report ]

> I guess DHCP is the major features that makes RISC OS 5 a real upgrade for RISC OS 4.0x users.

Point taken. I forgot we didn't had this in this about 10 year old OS. But for those RISC OS 4.0x users needing DHCP, spend 20 pound at ROL online shop and this problem is solved.

> The large application memory slot feature might be a big advantage if you are running a 256 MB Risc PC and suffer from DA clamp/high bit DA problems.

Aren't those high bit DA problems ironed out by now ? And if DA using software is not fixed for those problems, then on a 32bit OS they are equally buggy.

> I agree however that - at the moment - there is very little real, user-facing advantage for Select/RISC OS Six users. However, people actually paid for an upgrade from 4.39 to RISC OS Six despite the lack of real, user-facing advantages...

Repeating this statement doesn't make it any true. I don't think you're trolling but truly mistaken.

Direct visible user features are things like filer shortcuts, filer thumbnailing, significant upgrades to the core RO applications like Draw and Paint, 64K colour mode (twice that many colours for the same VRAM usage), transparency support, CIELab, CMYK sprite support, better JPEG support (more variants), well integrated graphics card support (better than what the original Viewfinder could do), submenus which are no longer obstructing each other but sliding away, more user friendly system configuration tools, ... and I probably am doing injustice by only summing this up and leaving out the 101 smaller things done.

These are perhaps not enough or well communicated by ROL themselves at [link] but very recently being written on here at this very same website. You missed it ?

Ever wondered why emulation users want RISC OS 4 and even RISC OS 6 ? I don't think I saw an end-user wanting to emulate RISC OS 5.

And as developer or technically interested person, when you look under hood of RISC OS 6, you see a much cleaner design by modularization, richer API (unfortunate underused) and a much more interesting grow path for development than RISC OS 5 currently is.

> I also don't buy the QA argument. The changes people submitted for RO 5 so far are surely of similar quality than ROLs changes after the 4.39 release.

I think that's a reasonable assumption but not my point. Who's going to do QA or shall we just hope for the best ?

Note that there are RO5 specific bugs which are not present in RO 4 nor 6 and this is based on ROOL's bugs db. From my own experience I can tell that RO5's FontManager does have regressions against RO4 one and I'm not talking about Unicode support. And being a little bit aware of the amount of bugs fixed in RO4 and 6 I believe RO5 has a big catchup to do in this area.

> The big advantage RISC OS 5 has is of course its ultimate cheapness.

I'm sure you didn't mean this but in Dutch 'cheapness' has a 2nd meaning which is not positive at all.

> You are not sure if you want to replace your trusted RISC OS 4.02 with RISC OS 5.xx? No problem, it is softloaded, and if it does not work as expected, you always have a safe fallback. Compare that to the 4.39 upgrade which some people had to rip out again because of severe problems.

I'm not sure which problems you're referring to (not FUD I hope) but if so, one could equally softload RISC OS 6.16 or any newer RISC OS 6 version in case of those so called problems.

> I also cannot see the validity of the "burden for developers" argument. Currently, the biggest burden for developers is the rather expensive and sometimes incompatible RISC OS Six branch of the OS.

Incompatible with what ? Is there a reference ?

I've seen several of those 'incompatible report' being later analyzed as in fact buggy programs. E.g. when an application is wrongly writing to address 0 this will be faulted in RISC OS 6. From user POV, this might be perceived as an OS being less stable, but when you really look at the facts, using RISC OS 6 results in a more stable end result because otherwise the whole system might be taken out if we leave this buggy program further running.

Or is RISC OS 6 so called incompatible because it has richer sprite and JEPG support which RISC OS 5 does not support ? Reversibly the argument can be hold for the Unicode FontManager support. It is just a feature difference.

> A free RISC OS 5 variant for RISC OS 3.7 users would actually reduce the developer's burden.

Really ? I'm not sure if we have significant number of active 3.7 users but I'm sure a RISC OS 4.0x upgrade instead will not increasing the variants a developer needs to consider.

BTW, on a 32bit RISC OS 5 RPC how will all 26bit podule software suddenly work ? Who's going to fix that (assuming those podules have flash) ? Or will it be a 26bit RISC OS 5 RPC version ? How will the Viewfinder ever work ? Ask JK ? Or hope the current driver software will work as is ?

Unless major things happen beyond what I consider realistic, I don't think RISC OS 5 on hardware like RPC is solving anything for the end-user and I believe it to be disruptive for the very fragile RISC OS market we have right now.

joty on 26/4/09 5:15PM
[ Reply | Permalink | Report ]

Applications storing data in DAs is an ugly hack. Storing it in the Wimp Slot is much much much wiser, but unfeasible under ROL's OS. Plus, 32 bit gives us shared libraries. Obtaining the sources to ROL's OS to fix glaring bugs is much more difficult than the same for ROOL's. I would certainly choose RISC OS 5 over any recent Select; I favor simplicity, design pedigree (as little as RISC OS has) and proven stability over Sun Raster import in Paint, a bundle of new APIs no applications use, broken abstractions from the kernel, and badly-drawn curved buttons.

rjek on 26/4/09 5:31PM
[ Reply | Permalink | Report ]

<bold>DHCP</bold>: Why spend 20 pounds at ROL online shop for this if RO5 has it for free?

<bold>User-facing advantages</bold>:

Filer shortcuts & filer thumbnailing are there to have since quite some time by other apps that are free (and run on RO5 too). Submenus no longer obstructing: Freeware offers similar features.

Draw & Paint: It's amazing how important these are taken - I prefer ArtWorks and Photodesk for most work.

64K colour mode: Well, I think whoever decided to do more serious colour work would have a new computer by now, or VirtualPRC or a ViewFinder; and in any case for that kind of work I'd opt for 16M colours!

These are perhaps not enough or well communicated by ROL themselves: Absolutely!

<bold>Emulation</bold>:

Emulation users do not want RO 3.x since it's too old and has too many restraints I'd say. And since until recently just RO4 was there to have and worked and the emulators emulate old hardware (i.e. RPC) so what's the reason to ask for RO5.

<bold>Under the hood</bold>:

As for the "under the hood work": That's not really an end-user feature, is it, but one of the favorite features ROL promotes is my impression.

Bugs: Well, I assume all RO variants have bugs but from my memory I had more issues when I had Select opposed to RO3 or RO5. And I'd not be surprised that quite a few RO4/6 bugs are side-effects of the changes done to this OS variant and which then have been fixed.

Incompatible RO6: It's incompatible with RO4 and earlier RO6 in some areas. The new screenmode being a more prominent example which some apps need to know of to handle.

Well, zeropage protection is an old one... and there are fixes/tools around!

<bold>RO5 for RPC</bold>:

There are quite a few 3.7 users there mainly due to the simple rule: never change a running system coupled with the upgrade to newer RO versions requiring ROM change and if it is to make sense harddisc reformatting (no tool to convert there). Add to this the information (or lack of such) from ROL about the end-user features (stability fixes are not of any importance to users who's 3.7 system is dead stable!).

Guess what: I had the odd chat with such users and understand their point of view. For me RO4's main benefits were DHCP and long file names. As for further benefits I got from Select ... well ... nothing jumps to my head off head.

Why not give the RPC user the choice: pay for RO4/6 which is the sensible path in case of e.g. podules, or RO 5 (be it 26 or 32 bit) for those just wanting the long file names and DHCP eg.

hzn on 26/4/09 6:06PM
[ Reply | Permalink | Report ]

He, he. That is about as negative a spin as you could hope to put on the possibility of RISC OS 5 for the RiscPC.

Kewl

I agree that for anyone running 4.02 or below that upgrading to RO5 does offer them some extra features. However I would not class being 32bit as a feature, all this means is those users would need to purchase Aemulor to run their old software, which would be a tad slower than running on 4.02 or one of the Select branches.

Having application space >28Mb for most users will not be an issue due to dynamic areas.

sa110 on 26/4/09 2:02PM
[ Reply | Permalink | Report ]

You sure it's a downgrade? Though one must admit that in the recent past ROL did seem to publish upgrades more often.

Anyhow - how about all them RPC users who didn't go for RO4 or Select?

And then there are users who prefer open source OS or who want to support RO5 and ROOL hoping to see RO on some new hardware at some point?

BTW, RO5 on an A9home might be very tempting for many :-)

But from my personal point of view you're right that it is preferreable that RO5 effort is into new hardware like Beagle/Cortex opposed to the old and quite a bit slower hardware.

hzn on 26/4/09 9:32AM
[ Reply | Permalink | Report ]

AMS: Except we can't use the floating point without recompiling everything and searching through the OS to find all the assembler that uses the old FPA10 instruction set, and the DSP development tools are eye-wateringly expensive.

rjek on 26/4/09 10:04AM
[ Reply | Permalink | Report ]

The Beagleboard would be an excellent and inexpensive hardware option for running RISC OS so it's fantastic to see progress being made - no matter much work remains to be done.

Fingers crossed for the future!

JohnB on 26/4/09 8:38AM
[ Reply | Permalink | Report ]

Aemulor is £24.99 and Aemulor Pro is £49.99

DaveW on 26/4/09 8:40AM
[ Reply | Permalink | Report ]

Perhaps Castle could market one of these kits or devices for the non-technically minded.

AW on 26/4/09 10:58AM
[ Reply | Permalink | Report ]

Aemulor would be a bit on the slow side on a RiscPC, wouldn't it? IMO the more important aspect is that it's showing a more flexible version of RO than we've had before, which could conceivably end up closing the fork, especially if RO6 features start getting ported (RO6 is definitely nicer to use than 5, I've not tried the latest ROOL release yet).

SimonC on 26/4/09 11:07AM
[ Reply | Permalink | Report ]

rjek>Yes I take you're point, but there's nothing to stop (for example) when new features (addition of *sound*) implementing *that* using VFP to up it's performance. Likewise there's nothing to stop someone using VFP code to enhance MP3 decoding/encoding.

That's not to say either would be easy - but as we *never* had the option before it's nicer to face a *difficult* task than an *impossible* one.

AMS on 26/4/09 11:27AM
[ Reply | Permalink | Report ]

AMS: You can't easily use the VFP and the FPA10 emulator at the same time; so you have to choose (their instruction spaces overlap); compatibility and low performance, or high performance but only a handful of apps that work with it.

And by "can't easily", I mean a right complete ballache.

rjek on 26/4/09 12:35PM
[ Reply | Permalink | Report ]

rjek>Hmm ok that would be a problem.

Is there no way out of this? I'd be reluctant to wave "bye bye" to a very substantial increase in Floating point performance. If that means some *pain* (some old apps not working - and a longer progressive update of the OS to use VFP then I'd say so be it (mind you not everyone would)).

Unless some reasonable technical alternative presents itself that is....

AMS on 26/4/09 1:55PM
[ Reply | Permalink | Report ]

Now I am cofused... and curious. The instructions spaces may overlap, but (IIRC) the coprocessor IDs doesn't (FPA ID 0&1, VFP ID 10&11)? How do they interfere then?

Raeddie on 27/4/09 7:34PM
[ Reply | Permalink | Report ]

The instruction spaces don't overlap as far as I'm aware. If they did the FPEmulator wouldn't work any more and lots of software would break.

The only necessary change to RISC OS that I can think of would be to preserve the VFP registers on task switches.

There is a problem with the endianness of stored double precision numbers differing between the FPA and VFP, so there are potentially linking issues there I think.

Cogs on 27/4/09 9:35PM
[ Reply | Permalink | Report ]

The FPEmulator continues to work, because you can turn the VFP off.

rjek on 28/4/09 12:05AM
[ Reply | Permalink | Report ]

So, is there any scope for rewriting the FPE to be written using the VFP. Surely that's got to be an order less work than it originally was to write it to translate FP calls to integer code. Presumably if the instruction spaces do clash it'd need to turn on VFP before it does its work and turn it off afterwards (and presumably disable all interrupts while it's at it). How much that would bugger up RISC OS I don't know - I guess it depends how expensive turning the VFP on and off is, since you'd need to have all interrupts disabled for at least that time.

ninja on 28/4/09 3:08PM
[ Reply | Permalink | Report ]

Yes, that's one option. The overheads are still obviously much higher than using VFP directly, but is more compatible. A floating point emulator is not an easy thing to write at the best of times. And you're right; the expense of turning it off and on all the time may quickly add up such that it's not worth bothering.

rjek on 28/4/09 3:54PM
[ Reply | Permalink | Report ]

I still don't see why that is necessary. The FPA uses coprocessors 1 and 2, VFP uses 10 and 11. Where's the clash?

The main problem I see for using VFP for speeding up FPEmulator is that the FPEmulator works in extended precision. But it doesn't really matter as FPEmulator is for compatibility, not speed.

Cogs on 29/4/09 6:33PM
[ Reply | Permalink | Report ]

sa110>Downgrade? Are you *serious*.

The option to run on *new* native hardware, hardware that does video overlays, that can support video decoding *in hardware* (remind me how good does a RISC PC or A9 do that?). Some new Cortex type SOCs even do HD video....

The new options RO5 opens (or potentially offers) outweight the occasional missing "round button" or having thumbnail images in your filer or other such eye candy.

I'd also point out that compared to several other OSes the GUI appearance of *both* versions of RISC OS look very dated. So given that both look stone age the decider should be technical advanages - particularly the ability to run on new more capabile hardware while at the same as offering users of legacy platforms an option to use code on a *single* OS rather than the forked set up we have at the moment. RO5 offers this RO6 does (IMHO) not.

AMS on 26/4/09 11:33AM
[ Reply | Permalink | Report ]

"AMS> sa110>Downgrade? Are you *serious*. "

Sniping out of context, I see!

The Downgrade I was refering to is for users running => 4.39. Those running =<4.02 would probably find some extra useful features.

sa110 on 26/4/09 2:06PM
[ Reply | Permalink | Report ]

sa110>Moving to RO5.xx from 4.02 or 4.39 or 6 is *not* IMHO a downgrade so whatever way I snipped your comment makes no difference.

AMS on 26/4/09 2:35PM
[ Reply | Permalink | Report ]

Whatever

sa110 on 26/4/09 2:52PM
[ Reply | Permalink | Report ]

AMS> I'd also point out that compared to several other OSes the GUI appearance of *both* versions of RISC OS look very dated. So given that both look stone age the decider should be technical advanages - particularly the ability to run on new more capabile hardware while at the same as offering users of legacy platforms an option to use code on a *single* OS rather than the forked set up we have at the moment. RO5 offers this RO6 does (IMHO) not.

IMHO RISC OS has always had the dated look, ;-)

the granite desktop has been around for years!

I couldn't agree more with your thoughts - technical advantages, esp. those ones which have allowed at lest 12 videos to run simultaneously on the desktop and one of those lip sync'd - aka !Replay

Two forked versions of the same OS - I just wish one would feed the other - fedora / red hat?

However, sadly we'll always have people bleating on about the lack of this and that, rather than its abilities and historically RISC OS has been ahead in some areas for years.

The concept of new hardware is a good one and in times where the polar ice cap IS melting - new low power / high performance systems to play music and watch videos, etc. can't be bad thing!

Mac9 on 26/4/09 12:29PM
[ Reply | Permalink | Report ]

Just curious - what features does RISC OS 5 offer that outstrip 4.39/6 on the same hardware ?

JohnB on 26/4/09 2:55PM
[ Reply | Permalink | Report ]

Main feature: Open source and thus things can be fixed!

Take this as an example:

While RO was closed source >2GB FAT media were not supported since both OS-suppliers decided to not touch the crap called DOSFS - despite ROL calling their OS cutting edge :-)

.

Now for RO5 work is done in this area with step on being a filingsystem Fat32FS and the obvious step 2 is then intrgation into the OS.

hzn on 26/4/09 6:11PM
[ Reply | Permalink | Report ]

Oh another one:

RO5 support for new hardware is under way and being worked on.

RO4/6 is aimed at pretty old hardware or the emulation of such. Well an older variant runs on A9home but is not complete and I see no progress on this one since quite some time.

hzn on 26/4/09 6:15PM
[ Reply | Permalink | Report ]

Perhaps you should visit the Advantage 6 stand now and again. Progress is happening on RISC OS 6 for the A9home. Many RISC OS 6 features are now supported in the development builds of the A9home OS.

sa110 on 26/4/09 6:28PM
[ Reply | Permalink | Report ]

RO6? How about making Select4 work properly? Who gives one damn about "development builds" -- get features out to users. Development builds mean NOTHING.

imj on 27/4/09 9:24PM
[ Reply | Permalink | Report ]

The Real question remains were can we download this A7K rom and how do we softload it

highlandcattle on 26/4/09 4:42PM
[ Reply | Permalink | Report ]

There is a softloader in the ROOL sources.

IvanDobski on 27/4/09 12:12PM
[ Reply | Permalink | Report ]

Surely the thing that makes such a development so fantastic is not any perceived advantages of one branch of the OS over another but that the platform we care for has a future - no new hardware = no future. It may be a purely psychosocial difficulty but no platform can survive under emulation only.

For myself I don't care which branch we all use as long as there only ONE branch in general use - better still; the best of both merged.

All the ARM computers I own run ROL OS's but if they all ended up soft-loading ROOL OS's that would be fine by me assuming that's the branch everybody else is using. (or vice versa)

After having no future, which the above news hopefully addresses, by far the worst thing for RiscOS is having all this business with two OS's.

Charlie on 26/4/09 5:54PM
[ Reply | Permalink | Report ]

This is excellent news.

The fact that RO 5 is a significant downgrade from select (mostly) is not important.

What is important is that new RISC OS kit is possible.

Hopefully the way things will develop is that ROL will make RO6 use the same HAL as RO5. This would then give the potential for any suitable hardware to run RISC OS 5 for free or upgrade to RISC OS 6 for a fee.

jess on 26/4/09 7:05PM
[ Reply | Permalink | Report ]

ROL will chop their hands off with a rusty knife, before changing RO6 to use RO5's HAL.

IvanDobski on 27/4/09 12:57PM
[ Reply | Permalink | Report ]

In which case they would deserve to fail. And why wouldn't they? (Since they claim to own RO 5 anyway). If they used the same HAL, they would be able to sell RO 6 for any system that worked with RO 5. Hopefully a few more target machines would make it more attractive than just the Iyonix.

jess on 27/4/09 7:44PM
[ Reply | Permalink | Report ]

RO5 is open source, I don't see how charging a fee is realistic or ethical for that matter. The idea AIUI is that it's an ongoing concern i.e. RO% is the future and there should therefore be no talk of charging for the operating system.

AW on 26/4/09 7:21PM
[ Reply | Permalink | Report ]

Please do not confuse the terms "open source", "shared source", and "freeware".

rjek on 26/4/09 7:49PM
[ Reply | Permalink | Report ]

Yes, because web hosting with suitably large traffic allowances grows on trees. As, apparently, does developer time. Being able to see the source code doesn't change that.

jmb on 27/4/09 1:11PM
[ Reply | Permalink | Report ]

As jmb said. For you to be able to have RO5 for free, someone has to be paying for the developers, for the hosting, for the bandwidth, power, offices if needed, etc.

Basically all the "Open Source" or "Free Software" movement gets you is the possiblity of seeing the source code and thus being able to change it yourself or fix bugs for yourself etc.

What it does not get you is a magic pill which causes it to cost no money.

Free speech != Free beer.

Kinnison on 27/4/09 1:18PM
[ Reply | Permalink | Report ]

Again lack of progress get much less negative comment then actual progress and its potential. The bad thing about risc-os is its community!

Jaco on 27/4/09 7:18PM
[ Reply | Permalink | Report ]

What are you talking about? It's freely available isn't it?

AW on 27/4/09 7:33PM
[ Reply | Permalink | Report ]

What are /you/ talking about? Which of the 40-odd postings here are you replying to? Please, try and use technology as it is intended, and not just mash nonsense at the keyboard.

rjek on 27/4/09 8:34PM
[ Reply | Permalink | Report ]

First of all, why am I not surprised that half the comments here are negative even though what was demoed at the Wakefield Show was undeniably a positive step for RISC OS?

Next, we've done quite a few RISC OS ports in the past and to say that this is just a small step and all the hard work is yet to come is just plain wrong.

Getting _anything_ happening it the hardest part, especially if you don't have access to JTAG, MultiICE, etc. Then, you can get bits of the HAL working and maybe bits of the kernel. After that, you bung some more modules in and look for problems.

You might need to do a lot or a little work to get some peripherals working (e.g. USB).

Then, you bung the rest in and fix a few remaining issues. For the most part, that bit doesn't take much time or effort - it's very much an exponential graph of progress.

For someone who is new to the RISC OS sources and who has never done a RISC OS port before to have got things this far is both a great reflection of their skills and of the design of the HAL.

In the particular case of the Beagle port, I expect the most trouble from now on will come from strange effects of the subtle changes to the ARM instruction set in the V7 architecture.

riscosopen on 27/4/09 9:31PM
[ Reply | Permalink | Report ]

I for one, have always leaned more towards the ROL version of RISC OS. However wherever you stand in the RISC OS 5 or RISC OS 4 branch, I think it has to be said that the efforts being made to put RISC OS on newer hardware have to be commended.

sa110 on 27/4/09 9:49PM
[ Reply | Permalink | Report ]

The news was good enough for The Inquirer..

[link]

Which I'm quite pleased about.

diomus on 28/4/09 1:11AM
[ Reply | Permalink | Report ]

Shame about the negative comments after the article. Anyway, I've added it to the Wikipedia entry, which should hopefully help to spread interest. [link]

trevj on 28/4/09 9:39PM
[ Reply | Permalink | Report ]

JTAG and MultiICE? Luxury! We do most of our Linux porting to fruity hardware without any of that, and don't have many problems. Saying that, it's amazing what a good deal of printk() and an oscilloscope can do for you.

(OK, we do use JTAG, but only for the initial programming of the flash with a boot loader.)

rjek on 28/4/09 10:00AM
[ Reply | Permalink | Report ]

What are you working on, if I might ask ? Besides Netsurf ofcourse

highlandcattle on 28/4/09 9:37PM
[ Reply | Permalink | Report ]

Nothing besides the kind of thing already on my employer's website.

rjek on 28/4/09 10:05PM
[ Reply | Permalink | Report ]

Can we please leave the bloody RISC OS 5 vs 6 wars out of every topic, there is nothing more boring or more likely to discourage people from using this platform.

Instead let's concentrate on the good news that RISC OS is running on a Cortex processor, which is something I thought would be a lot more difficult than it appears to have been, judging by ROOL's comments.

However, the OS is only part of the story, what is now needed is the RISC OS applications to run on this system. Developers need information on the changes which will be necessary, and I'd like to upgrade ARMalyser to aid in the porting effort.

druck on 29/4/09 9:31AM
[ Reply | Permalink | Report ]

Hi Dave (Druck).

I whole-heartedly agree. The RO 5/6 "war" of words should not infultrate every thread. Remember that this is now on OSnews and "the reg"... so the big world is reading.

I woulod buy a beagle to use ROS on as a cheapo computer. If I could get one on an ARM mini laptop (not netbook since Psion have rights to that name) then I would rewrite my database app for it. :-)

Cheers Bob

nijinsky on 29/4/09 1:25PM
[ Reply | Permalink | Report ]

none of you seen this? posted links on ROOL and Icon bar some time back.

It is a convertable tablet/netbook which is built from a beagle board

[link]

So we already have portable hardware ready to rock when this port is ready.

John

mrmac on 29/4/09 3:01PM
[ Reply | Permalink | Report ]

Would I be right in thinking the Beagleboard's 600Mhz Cortex-A8 processor has roughly twice the performance of the similarly clocked X-Scale in the Iyonix? The ARM website quotes 2.0 DMIPS per Mhz.

bucksboy on 29/4/09 4:20PM
[ Reply | Permalink | Report ]

Where can you buy Beagleboards and at what point would it be wise to buy one? The point being, how far advanced is this - still early days?

AW on 29/4/09 7:40PM
[ Reply | Permalink | Report ]

Digikey, and early days.

rjek on 29/4/09 11:56PM
[ Reply | Permalink | Report ]

Thanks.

AW on 30/4/09 8:52AM
[ Reply | Permalink | Report ]

Who are you thanking, and for what?

rjek on 30/4/09 3:15PM
[ Reply | Permalink | Report ]

Please login before posting a comment. Use the form on the right to do so or create a free account.

Search the archives

Today's featured article

Select preview
Every feature in Select 1 covered, what's in, what's out, what's it look like and what do we think of it?

9 comments, latest by diomus on 15/3/03 1:10AM. Published: 31 Oct 2001

Random article

Alternative Shared C Library in development
The hare and tortoise face new competition

22 comments, latest by nodoubt73 on 21/3/06 3:27PM. Published: 18 Mar 2006

Useful links

News and media:
Iconbar • MyRISCOS • ArcSite • RISCOScode • ANS • C.S.A.Announce • Archive • Qercus • RiscWorld • Drag'n'Drop • GAG-News

Top developers:
RISCOS Ltd • RISC OS Open • MW Software • R-Comp • Advantage Six • VirtualAcorn

Dealers:
CJE Micros • APDL • Castle • a4 • X-Ample • Liquid Silicon • Webmonster

Usergroups:
WROCC • RONE • NKACC • IRUG • SASAUG • ROUGOL • RONWUG • MUG • WAUG • GAG • RISCOS.be

Useful:
RISCOS.org.uk • RISCOS.org • RISCOS.info • Filebase • Chris Why's Acorn/RISC OS collection • NetSurf

Non-RISC OS:
The Register • The Inquirer • Apple Insider • BBC News • Sky News • Google News • xkcd • diodesign

© 1999-2009 The Drobe Team. Some rights reserved, click here for more information
Powered by MiniDrobeCMS, based on J4U | Statistics
"I was actually referring to drobe itself as the 'young upstart' rather than the age of the contributors"
Page generated in 0.5886 seconds.