Mac VirtualRiscPC undaunted by Apple x86 switch

By Chris Williams. Published: 13th Jun 2005, 14:00:14 | Permalink | Printable

A rumour is sometimes just a rumour

The recent news of Apple switching to Intel processors is unlikely to affect the release of VirtualRiscPC for Mac OS X. Following the announcement that the iPod manufacturer will be moving its PowerPC based platform to x86, there was speculation that the RiscPC emulator will require further substantial programming in order to work on the Intel platform. Apple is expected to complete its transition to x86 by the end of 2007.

However, Apple have told developers that they can create 'universal binaries' for application executables, which include code for PowerPC and x86 processors. Plus, of course, the emulation engine from the original Windows VirtualRiscPC, which converts ARM to x86 instructions, can be employed on the x86 Macs of the future. Graeme Barnes, VirtualRiscPC developer, explained that Apple's transition to a new architecture "shouldn't make any difference to the current OS X version of VRPC".

"I hope to have that out well before the x86 Macs come along," he explained. "The OS X version does contain an ARM to PPC JIT but when they release OS X for x86 I can use the original x86 JIT for that platform".

VirtualRiscPC for Mac OS X was demonstrated at Wakefield 2005, although is unavailable as yet. Interestingly, Apple will be bundling an emulation layer in the x86 version of Mac OS X, which will run PowerPC targeted code on x86.

Links

VirtualAcorn website

Previous: Riscos.org switches to weblog format
Next: Portrait monitor support for A9home

Discussion

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

I quite like the idea of running !6502Em on VirtualRPC for Mac OS X on an x86-based Mac through the emulation layer ;o)

md0u80c9 on 13/6/05 7:39PM
[ Reply | Permalink | Report ]

Were there any emulators that ran on the BBC Micro? ;-)

alexsingleton on 13/6/05 8:07PM
[ Reply | Permalink | Report ]

The entire business of Mac OS X running on these fast and powerful x86 Intel Chips makes one wonder if it could be possible to likewise get RISC OS running 'natively' on such hardware.

I know this idea has been dismissed as involving too much work to be practical in the past, but one can't help wondering, " what if ? ".

The Virtual Acorn emulator is an amazing advance for RISC OS, but the MacMen seem to be going one better...

martin on 14/6/05 8:24AM
[ Reply | Permalink | Report ]

martin:

Why is the emulator "...an amzing advance for RISC OS..."?

ROHC on 14/6/05 8:54AM
[ Reply | Permalink | Report ]

martin: then we'd have massive incompatibility problems to contend with. It makes no sense on such a tiny platform

mrchocky on 14/6/05 9:00AM
[ Reply | Permalink | Report ]

alexsingleton:

Yes....I remember using a PC emulator!

em2ac on 14/6/05 9:12AM
[ Reply | Permalink | Report ]

In reply to ROHC .... because it allows RISC OS to run on more mainstream hardware at comparable speeds and does so in a way that is stable and robust and....

vauguely and not exactly in reply to mrchocky ... has not raised comatibility issues. (As far as I'm aware)

I don't personally use my A6 windows machine running Virtual RISC PC (It's my daughter's machine) but for a lot of RISC OS folks, such set ups had given them a way to remain involved in the RISC OS world while also being in WindowLand, the latter often being essential for work or educational reasons.

Although Virtual Acorn is not for me, quite possibly it may well have been what kept, and is keeping, RISC OS Ltd/Developments going until, perhaps, the A9home comes along....

....and, in consequence, select for Iyonix becomes a possibility....

martin on 14/6/05 10:03AM
[ Reply | Permalink | Report ]

In Reply to Martin:

Apple is a much bigger platform than RISC OS and can no doubt fund the move(not that it would be their first change of architecture) to Intel x86 chips. Here on RISC OS, we have trouble shifting to newer ARM chips, letalone a completely different platform. IMO RISC OS platform today has neither the funds or the resources to do such a move. Besides, we have the Iyonix, the forthcoming A9 and already a two forked OS - Do we really need another fork that will be completely incompatible with the other two? As newer and quicker ARM chips are produced, no doubt we'll get quicker RO machines, should there be sufficent market demand.

I believe the RISC OS platform has navigated very treacherous and murkery waters these last few years, and whilst the seas have calmed somewhat there is still a long journey ahead of use before we see the beautiful green land that we once knew.

sa110 on 14/6/05 10:41AM
[ Reply | Permalink | Report ]

sa110: But whilst RISC OS relies on ARM it'll inevitably stuck with slower and more expensive hardware than other platforms. I really wish I was wrong there, but I can't see ARM wanting to change direction (unless someone tries to design a completely integrated system, from mobile phone to desktop machine, all running the same OS and software. I dream on).

A move to x86 would probably bring in a huge number of new and returning users, and something like VRPC could be used for legacy stuff (including parts of the OS, no doubt). If it did get the numbers then whatever fork it's on would quickly become the main one. OTOH if I'm wrong about it bringing in users then the whole exercise would be a monumental waste of time and effort, if it's even techincally feasible in the first place.

SimonC on 14/6/05 11:32AM
[ Reply | Permalink | Report ]

In reply to SimonC: I guess it is feasable, no doubt Peter and other programmers will be able to enligthen us on that. Problem is the money, programming resources and time to do it. Don't forget it's not just the OS. Programs will need updating and changing not to mention a new version of Aemulator. Is it really worth all the hassle? RO has not run on super quick hardware for such a long time that I don't think it really matters that much. We don't exactly have a need to run at 3Ghz, do we?

sa110 on 14/6/05 11:50AM
[ Reply | Permalink | Report ]

Not if we don't want to use our machines for the sort of things that other people use theirs for. I'd be interested in any machine running at 1Ghz or over. The faster the better. Cheers!

fwibbler on 14/6/05 12:02PM
[ Reply | Permalink | Report ]

It's already been hashed over several times, I'd rather not repeat the reasons again. All I will say is that there would be considerable disadvantages in running RISC OS "natively" on x86 compared to an existing solution that already works and isn't years of work off: Virtual RiscPC.

mrchocky on 14/6/05 12:42PM
[ Reply | Permalink | Report ]

You know guys, Peter has raised a good point. We already have a good emulator in the guise of Virtual RPC that runs on x86 hardware. Currently it is available under Windows, but soon to be available under Max OS. So that means RISC OS is/will be available for use on three different platforms, native, Windows and Mac OS. Why waste OS development time porting it when it can be better spent developing new features

sa110 on 14/6/05 12:47PM
[ Reply | Permalink | Report ]

Exactly, and one such possible feature might be multi-processor-support, wich would give us a nice advantage over other system, because ARM chips are cheap, small and cool. Imagine a RISC OS computer with 30 CPUs for around 1500 to 3000 USD...

And IIRC ARM are working on multi-processor-support embedded in their CPUs.

JGZimmerle on 14/6/05 7:41PM
[ Reply | Permalink | Report ]

But do we really have any software available that needs so much power?

sa110 on 14/6/05 9:55PM
[ Reply | Permalink | Report ]

sa110:

Yes, easily. We have software that can use any amount of processing power. Take Draw, for instance. If you think your processor is fast enough to render a Drawfile, simply duplicate all objects 10 times - the file will take 10 times the processing time to render. The same goes for ArtWorks, even more so when using dynamic blends, nested dynamic clipping, transparency, etc. Exporting a high-resolution bitmap or generating a PostScript file for printing sometimes takes in the order of minutes for complex files. Any processor speed-up helps immediately. Of course, just for displaying dialogue boxes it does not make any difference.

wuerthne on 15/6/05 1:17PM
[ Reply | Permalink | Report ]

In reply to wuerthne:

Point taken. I guess I don't use anything that requires such power.

sa110 on 15/6/05 1:23PM
[ Reply | Permalink | Report ]

One can always use more power. Apart from the occasional 'as fast as possible' demands (like 'archive this file' or 'process this picture') there are many cases where a better result could be generated ('use better but more computationally intensive compression', or 'increase resolution of the output').

Loris on 15/6/05 1:28PM
[ Reply | Permalink | Report ]

And there are also many applications wich were never seriously attempted on RISC OS, simply because the processing power was never there.

Also cheap, powerful systems attract lots of developers, simply because they are cool.

JGZimmerle on 15/6/05 7:10PM
[ Reply | Permalink | Report ]

Applications that use lots of processing power (off the top of my head): DVD and higher resolution video, manipulating images (bitmap as well as vector), 3D graphics generation (CGI, games, whatever), speech recognition, scientific modelling.... Increasingly, cryptography will too, and any system without decent crypto will be locked out of internet businesses. And as JGZ says, you attract programmers because the system is fun (how else are they going to get to play with significantly parallel systems at home?

) And they attract other people, because they're producing interesting software....

My 10-year-old RPC is still adequate for email and occasional hacking, although only when my arms are up to typing - hence my obsession with speech recognition; I have a Win2k box at the moment because I have to have speech recognition.

chrisj on 15/6/05 9:49PM
[ Reply | Permalink | Report ]

(if we ignore the fact that it's highly unlikely to happen

) Wouldn't a system that ran RISC OS ARM programs, and could use either RISC OS ARM modules or special x86 modules to exploit the power of the hardware be the most desirable? (Whether acieved by a port of RISC OS with an embedded emulator or a minimal OS that just runs an emulator with RISC OS running on it)

jess on 15/6/05 9:56PM
[ Reply | Permalink | Report ]

Jess: Well, the obvious ideal would be a system that could use any processor, and had sockets for PCI (and modern variants) as well as podules and ISA cards (for legacy hardware) as well as the complete range of user-accessible connectors from firewire and SATA to BBC user and tube ports. ;-)

Seriously, though, the obvious advantages of having an x86 would be for hardware-supported emulation and FP. And there are probably better (ie superior power- or cost-to-MFlops ratio) solutions for the FP. At which point you find yourself calculating the number of 600MHz ARM 9 cores needed to emulate a top-end Athlon....

chrisj on 15/6/05 10:17PM
[ Reply | Permalink | Report ]

I remember applying a blur effect in Photodesk 3 on my Kinetic RiscPC. This took around an hour. One hour!!! Absolutely ludicrous (at the time, Kinetic was the top machine). For graphics work and the like, the more speed the better. Plus as has been mentioned, powerful hardware and a fun OS are what attract developers and users.

If it was feasible, porting to x86 hardware would make sound commercial sense for the desktop, as it offers RISC OS on cheap but powerful hardware. Develop one version of RISC OS for x86 desktop use and one for embedded/portable ARM-based devices.

But back to reality, I'd like to see faster ARM processors coupled with more powerful graphics hardware. Perhaps dual-processor boxes. Something powerful enough to encourage some software development, such as new bitmap editors, video editors etc.

arenaman on 15/6/05 11:36PM
[ Reply | Permalink | Report ]

I'm with Julian. I think most of the things we want more power for are 'embarassingly parallel'. So never mind dual processors, I want lots. This is a definite hurdle to jump, in the same way switching cache architectures for the StrongARM was. But I think it will be necessary at some point, and since ARMs arn't being made as fast as other architectures, it would be nice to be sooner rather than later. (I say this without any knowledge of the probably considerable engineering involved.)

Loris on 16/6/05 12:10PM
[ Reply | Permalink | Report ]

Since this has been brought up many times in the past and no-one seems to have taken much notice, maybe we should start a petition?

JGZimmerle on 16/6/05 12:14PM
[ Reply | Permalink | Report ]

Hey, wait a minute...

Has the work not already been done by Simtec for the Hydra API.

JGZimmerle on 16/6/05 12:21PM
[ Reply | Permalink | Report ]

So whatever happended to the Hyrda? I remember Acorn User doing an article about it at the time, but after that....

sa110 on 16/6/05 1:18PM
[ Reply | Permalink | Report ]

IIRC the StrongARM came out and caned it for performance, so it was dropped. They couldn't use StrongARMs in it for some reason, perhaps it was a cache issue. Maybe it could be resolved with some reengineering, I don't know. It would be really nice if that were the case. But creating parallel processors seems to be quite tricky. I don't think a company would (or should) take any notice of a pertition unless it was backed up with cold hard cash.

Loris on 16/6/05 1:51PM
[ Reply | Permalink | Report ]

It's now possible to get ARMs with multiple processors on a single chip ( [link] ), which presumably would be easier to utilise than creating something like the hydra from scratch.

I'm not sure how suitable RISC OS would be for multiple processors though. Most programs don't use threading for example.

Whilst it'd be great to have multiple processor RO machines and maybe it's the most sensible solution to the limited ARM speeds, personally I'm still happy that there are some great native options for RISC OS available right now.

flypig on 16/6/05 2:34PM
[ Reply | Permalink | Report ]

For a while recently, you could buy Hydras from Simtec from their bargin bin bit on their website. It would appear they did make quite a few. There was also a threading module that was floating about that would take advantage of the Hydra, too.

I think the main reasons it never really happened was that the StrongARM came along, which wasn't compatable with the Hydra, and lessened its usefulness a little, and that RISC OS itself wouldn't support it, only very specialised applications.

nunfetishist on 16/6/05 3:34PM
[ Reply | Permalink | Report ]

I just had a look at the Hydra API documentation on Simtecs website.

Of course current applications would not benefit at all from such a system, because they would still run on the main processor. But applications wich are still maintained could be altered to use the hydra threading API for data processing. They would still run on single cpu systems with almost no performance hit, but with greatly increased performance on a multi-cpu-system. The reason why no developers used the Hydra API was surely down to the very small number of Hydra cards ever made. If however a new machine came with multiple CPUs as standard and the Hydra software (or something similar) would come as standard with new versions of the OS and be available to download for older systems, I would think some developers might start to use it. :-)

The hydra itself made little sense once the StrongARM was out, due to the slow bus in the RiscPC, as one StrongARM was already pushing the RiscPC to the limit and five ARM710s were still slower than a single StrongARM.

A new multi-cpu-machine however would be designed with buses that could cope and come with 32-bit-compatible software (the hydra software was not even StrongARM compatible).

JGZimmerle on 16/06/05 4:39PM
[ Reply | Permalink | Report ]

Oh, and a simple two- or four-CPU system would not attract new developers, because its nothing special. You can get cheap PCs and Macs with two to four CPUs. Thats why I would like a massively parallel system with at least 16 CPUs. Of course the additional performance would also be nice... :-)

JGZimmerle on 16/06/05 4:44PM
[ Reply | Permalink | Report ]

actually it was acorn that killed the hydra - they saw galileo as the way forward with multi CPUs

not RISC OS :-(

ROHC on 16/06/05 8:01PM
[ Reply | Permalink | Report ]

yes galileo that looked very interesting back in the day, wasn't it going to run on all types of CPU (x86, PPC, ARM ect.) how far did they actually get with that one? (knowing Acorn not very far ;-)

) would have loved to see it in action though. Back on topic OSX on intel could perhaps help us to gain a few more users (die hard mac fans won't go near anything x86 based) ..... i can dream :-)

leeshep on 16/06/05 8:14PM
[ Reply | Permalink | Report ]

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

+++ Message board +++

Read messages or start a new thread

Search the archives

Today's featured article

Online banking with RISC OS
We thought this would be of high interest

28 comments, latest by devine on 25/9/05 8:30AM. Published: 1 Sep 2005

Random article

Castle and ROS Open reveal plans for 2007
Vetoes non-ARM port, will release Javascript Browse, and more

102 comments, latest by druck on 01/02/07 09:09AM. Published: 20 Jan 2007

Create a new account
Forgot your password?

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
"Thanks for leaving out a significant part of my statement. Is that the standard of journalism we can expect from Drobe?"
Page generated in 0.1146 seconds.