www.virtualacorn.co.uk/forum

Evening All,
Is there any way of running RISC OS Open on Virtual Acorn?
Or are there any plans to get it running?

I'm aware that the Risc PC port of RISC OS Open isn't complete yet, would this need to be completed first?


Regards,
Rob.

I presume you mean the "shared source RISC OS 5", RISCOS Open is a company

I can't see any reason why this shouldn't work, well, work as well as it can. However I can't really see the point. RISC OS 5 is a 32bit version of RISC OS 4, it won't run a great deal of 26bit RISC OS software and has a number of bugs.

Thanks Aaron,
I never did get around to trying it!

I'll have a go soon, and post the results back here.

Thanks,
Rob.

Hello,

although you don't see a point to use RISC OS 5 on VA, is there any chance that VirtualAcorn supports the work that is needed to use RISC OS 5 on VA ?

Best regards

It's not that I don't see a point in having RISC OS 5 running on VirtualRPC, it's that there really *is* no point.

The reason RISC OS had to be converted from 26bit to 32bit was that ARM dropped support for 26bit mode from the processor designs some years ago. The last chips that had 26bit (as well as 32bit) suppport that was guaranteed to work were Arm Version4 (e.g. StrongArm). Later processors, such as the ARM 9 and XScale use ARM Version 5, which is only guaranteed to work in 32bit mode.

So, in order to produce a new machine with a "better" processor than the StrongARM, RISC OS had to run in 32bit mode. The versions of RISC OS in the A9 and Iyonix are both 32bit.

VirtualRPC supports ARM Version 4, as supplied in the "real" RiscPC. This enables it to run the 26bit bit versions of RISC OS. Although it can still run apps that are compiled up to be 26/32 bit neutral.

Some work was done at Pace with regard to getting RISC OS 5 to run on the older ARM V 4 processor machines, such as the RISC PC. If RISCOS Open released a version of RISC OS 5 designed for the RISC PC, then it should run on VirtualRPC. But, this is a backward step.

So my question is simple. What would be gained by getting RISC OS 5 running on VirtualRPC?

To make it work as good as possible it needs 32 bit compliant versions of the podule ROM's that are supplied with VirtualRPC. If that is not already done, it is not in the hands of RISCOS Open. And when you are in a dead-end street it can be necessary to make a backward step before you continue to go forward.


The answer is as simple as the question. It could help to get back to one version of RISC OS instead of having two versions that develop in different directions.

I'm sorry that you think RISC OS 5 is a "dead end street". I'm not sure I agree.



That's a "political" advantage *not* an advantage for users of VirtualRPC. At present users can run either 26bit or 32bit RISC OS applications. In addition they can also run RISC OS apps that aren't even StrongARM (ARM Version 4) compatible. So a VirtualRPC provides the widest range of compatability. This allows the user to run a lot of applications that aren't supported on newer machines.

Moving to a 32bit version of RISC OS would restrict the user to running 32bit ARM V4 applications. Thus reducing the number of applications that a VirtualRPC can run by at least 80% at a stroke.

As such running a 32bit RISC OS 5 really is pointless as one of the main reasons users purchase our products is that they know that the applications they already have (and which may well have been abandoned by the authors/publisher years ago) are going to work.

Re: It's not that I don't see a point in having RISC OS 5 running on VirtualRPC, it's that there really *is* no point.

Here's an idea - what about a version of Virtual Acorn that is designed to run under the new Cortex-A9 hardware that will be appearing in the next 6 to 12 months - i.e. a fast desktop machine with fast graphics and a fast HDD. As Cortex-A9 is pretty hardware-compatible, then RISC OS 5 would work with very little emulation (but 26bit stuff is not an option) - but 32-bitted RISC OS 6 might be even better.

Hence having RISC OS 5 running *might* be a worthwhile stepping stone to having RISC OS run on new hardware as an emulation (but with the code running natively in fact).

Presumably this would get around the present difficulties of a new RISC OS machine with native hardware - i.e. licensing issues?

Our products are designed to run on top of another OS (either Windows or Mac OS X). Some parts are hand written in either X86 or PowerPC assembler. So as you can see their are some major problems with your suggestion:

Firstly what OS will a VirtualAcorn be running on top of on these Cortex machines?
Are you suggesting re-working the entire VirtualRPC as a stand alone emulation environment?
Are you also suggesting re-coding the X86/PowerPC code to ARM code?
If so, who's going to pay the cost of this work? (You'll never recover the many tens of thousands it would cost).

Anyway, the idea is pointless. The far better (and much cheaper) solution would be to virtualise large parts of RISC OS (already done) then get it running natively on the hardware. This would be both cheaper (for user and developer) and faster (as it's running directly).

The whole aim of VirtualAcorn products are to allow the users to run RISC OS on hardware that RISC OS *could never ever run on normally*. The VirtualAcorn products are not a BIOS, which is what you are suggesting.

Re "The far better (and much cheaper) solution would be to virtualise large parts of RISC OS (already done) then get it running natively on the hardware. This would be both cheaper (for user and developer) and faster (as it's running directly)."

Obviously I agree. I just thought that there might be commercial obstacles that prevent that and that the 'virtual' solution (in terms of licensing rather than how it is achieved) might be attractive. My understanding (no doubt imprefect) is that a suitable 'ROM image' for a Cortex A9 hardware platform, via the RISC OS Open route, is quite feasible but there would be difficulty in selling it as a product. Whereas the 'I/O interface' that sits between RISC OS and Windows hardware could, perhaps, just be recompiled for a different target processor. Looks lke this is in the too difficult category.

So the best technical solution (ROOL) has insurmountable commercial problems and the proven commercial route (VA) has insurmountable technical problems. Shame the hatchet can't be buried and the new hardware exploited for profit.

I can't leave these deeply innacurate comments without addressing them:

Firstly there are no "insurmountable technical problems" related to VirtualRPC. The product was designed for a purpose. That purpose was to allow users to run RISC OS on non ARM hardware. This is what it does. It allows the user to run the operating system they want, on the hardware that's available to them. For example using a VirtualRPC is the only way to run RISC OS on a laptop. Business users may be required, as policy, to have a particular PC (or Mac) and not allowed to use any non prescribed hardware. A VirtualRPC allows them to run RISC OS, where other "real" RISC OS hardware would not be allowed.

When developing the products we had a very clear vision of what was needed. The resulting products fit that clear vision.

I think what you meant to say was that a VirtualAcorn product was not suitable for your "concept". This is hardly suprising as the products were developed for a different purpose. There are no " insurmountable technical problems" with a horse, unless you want it to be a row of semi detatched houses.

Moving on to the "insurmountable commercial problems" quote. I am not sure what "insurmountable" problems exisit. If one wants to distribute a product containing RISC OS then a licence fee needs to be paid. It really is very simple.

The final comment of yours that "Shame the hatchet can't be buried..." makes no sense at all. There is no "hatchet" between VirtualAcorn and RISCOS Open. Their product(s) are simply not suitable for our product(s). Read my earlier comments as I have explained why at some depth.

"If one wants to distribute a product containing RISC OS then a licence fee needs to be paid."

It's just that the Castle web site still says details of commercial licences 'to follow' - I hadn't realised it was resolved.

There was never anything to be resolved. We have been paying licence fees for the use of RISC OS for years. We pay to the company who purchased the rights to RISC OS in 1999. The same company who has subsequently developed and licenced RISC OS 4. We have no commercial dealings with Castle Technology Ltd who have ceased trading.

I'll give you one good reason for it:

I want to use a more recent version of RISC OS than 4.39. 4.39 has issues with displaying long filenames on the desktop which drive me bananas! For the time being I am using a little utility which shows the long filenames in little yellow balloons, which is better than nothing but not good enough.

I tried RISC OS 6. It was great ... except for the fact that they removed old ADFS file format support which meant that I could not use Look System's font manager. So I had to abandon that.

I would like to use a more modern version of RISC OS, but on hardware faster than my Iyonix.

RISC OS Open looks like what I need. The IOMD version ought to work on VirtualAcorn but I haven't succeeded with it yet. It does work on rpcemu, but that is very primitive compared with VirtualAcorn.

RISC OS 5 is basically a 32 bit version of RISC OS 4.02 with some extra stuff, for example UniCode Font Manager, on top. RISC OS 4.39 is considerably more advanced than RISC OS 5.

I take the point about Font Directory Pro not working as support was removed for the image file format it uses. However it's worth me pointing out that Acorn told developers to stop using this particular RISC OS 2 image file format when RISC OS 3.1 came out as it was depreciated and would be removed from a future version of RISC OS.

When Font Directory Pro was launched the particular image file format was already depreciated and developers shouldn't have been using it. Look Systems had years to update Font Directory Pro, but choose not to.

Of course none of this helps users, but there is a limit to the size that a RISC OS ROM can be and if you want to add new features something else has to be removed. Removing items that Acorn had already marked as depreciated was the safest approach.