RiscPC emulator for Linux lands | Drobe.co.uk archives

RiscPC emulator for Linux lands

By Chris Williams. Published: 28th Mar 2006, 02:13:18 | Permalink | Printable

Patience required

Running RISC OS on Linux took a leap forward today when the source code to the Linux port of RPCEmu was published online. Developer Tom Walker uploaded the blueprints to the port alongside the latest Windows build of his freely available RiscPC emulator.

The Linux version was created by Peter Naulls, the details of which were revealed earlier this month. As this release is an early glimpse at the emulator running on Linux, no official program is supplied; for now users must therefore be competent enough to compile the software from the supplied source code if they wish to test drive it.

Tom described the port as "preliminary", noting that RPCEmu also includes HostFS spliced from ArcEm - allowing RISC OS running on the emulator to access files stored on the host computer.

Click for bigger screenshot

Click for bigger screenshot

The emulator manages to run through approximately 10 million instructions per second on a PC fitted with a 1.4GHz AMD processor - roughly between the speed of an ARM250 and ARM3. On a 1.8GHz 64-bit AMD PC, the emulator manages up to 17 MIPS, compared to the ARM610's 28 MIPS.

Released on Monday, the latest version of RPCEmu addresses a fault with the emulation of the Acorn chipset that prevented RISC OS 3 from reliably booting. The graphics chipset emulation now supports 16-bit and 32-bit colour, correctly displays the colours in the mouse cursor, and features some video acceleration. It can also now support two hard discs, more than 16M of emulated RAM and video RAM.

Tom also authored Arculator, an emulator of Acorn Archimedes class computers. This is not available under the GPL, unlike its RiscPC cousin, and uses an implementation of HostFS that Tom created himself from scratch.

Update at 21:24 2/4/2006
With regards to the speed of emulator, Tom pointed out that on his PC, RPCEmu matches his ARM610 RiscPC.

He said: "When the software is changed to output the clock cycles being emulated, it suddenly turns out that 17 MIPS is around a 50 to 55 MHz ARM710, and that's with an infinitely fast bus. In practice it also feels a lot faster than my real ARM610, though that's not very hard."

Links

RPCEmu website

Previous: StrongARM card turns ten years old
Next: Charity stall confirmed for Wakefield

Discussion

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

Speeds aren't bad for a first release, I remember JIT RedSquirrel was only getting above 30mips well into the development cycle with 1.6GHz machines.

Of course with 2.5GHz it was getting SA speeds of around 130mips, and also RO4 seemed to run a fair bit faster than 3.7, graphics card was very important, and for some reason the Pentium-M's ran much better than AthlonXP's, well Intel seemed better than AMD in general....

How is VirtualRPC doing these days as far as MIPS? Although I'm not sure that's the best benchmark.

simo on 28/3/06 8:58AM
[ Reply | Permalink | Report ]

An optimised dynamic recompiler, rather than the block based version in VRPC (aka the JIT) has the potential to achieve better than a 1:5 clock speed ratio - but do we want to do it?

It would not only kill off new ARM based machines which would have to be well ahead of current ARM/XScale road maps at over 1.5GHz to compete on performance (given other advatanges such as memory and disc I/O speeds of x86 based hardware), but also other RISC OS hardware related development - what would be the point of producing new PCI and USB drivers without native machines. As much application development is spurred by the introduction of new hardware capabilities, this would also lead to stagnation there.

Will a RISC OS emulator end up being anything more than a PDF Viewer type program, but for old Impression and Artworks files stored on another machine's harddisc?

druck on 28/3/06 9:21AM
[ Reply | Permalink | Report ]

I'd hope not but once spares for my current RISC OS machines disappear completely, that may be a sad possibility.

terrahawk on 28/3/06 11:32AM
[ Reply | Permalink | Report ]

can you seriously see a future for riscos on native hardware?

we have a ro4 machine that runs an arm9 (or will do when it's released) or a ro5 machine that runs an xscale.

i can't really see this catching up with today's technology of multi-core 3ghz+ processors.

making the os and software available on popular oses like win/mac/linux would surely spur purchasing of software more than a 1000ukp arm box would?

i know i'd use a few riscos apps if i could run a decent speed emulator under linux, especially for free (i rarely use windows, so varpc is not really an option) just like i use snes9x to run old games, that i would never buy a super nintendo to run!

simo on 28/3/06 12:39PM
[ Reply | Permalink | Report ]

simo: Sadly true, and trying desperately to ignore the fact that emulators can do it faster is, IMO, burying heads in the sand. I've said it before, at the end of the day the native hardware just isn't up to scratch to compete. If RISC OS is to have any future it either needs a new ultra-powerful ARM, or to be ported completely to another system, and neither of those seems likely. The anti-emulator people seem to think that that would all be a non-issue if it wasn't for emulators, but as far as I can see that's all that'll keep it going for a bit longer.

SimonC on 28/3/06 12:52PM
[ Reply | Permalink | Report ]

In all seriousness, I cannot see a future for RISC OS on native hardware. Porting RISC OS and associated apps to other hardware would be the better thing to do, but I think that line of reasoning has been done to death.

I'm generally happy with an RISC OS emulator as long as it runs what I want and is fast enough on my Athlon XP 2500 box so that the RISC OS experience is not detracted from in any way.

terrahawk on 28/3/06 12:55PM
[ Reply | Permalink | Report ]

SimonC: I concur.

The RO GUI is the most flexible I know. However, hardware is not up to modern PC standards anymore, which has simply resulted that those types of software that rely on such hardware, have not and could not appear as well.

What is the Iyonix (and arguably A9home) hardware capable of -- web browsing, e-mail, word processing, DTP, audio processing, a bit of media playing, perhaps video chat, etc. However, our current software standards (arguably due to the state of market) can only provide just about half of that capability, though in a fine way.

So, there's my reasoning. If you can happily live within those software boundaries, partially due to hardware limitations and partially due to market size, you may enjoy a wonderful (British!) computer with one of the finest GUI's ever devised.

If you can't live happily within those boundaries, I find it a comforting thought that it will be highly likely that we may soon enjoy our superb GUI, with some of its terrific software, through a Open Sourced emulator. Even though I strongly recognize it's still very much in an early stage, the fact that it's GPL means that it may have a very interesting future.

One idea I've been toying with recently, similar to the way Apple chose. That is, to take the best of RISC OS, and put it on top of a solid modern OS core. Similar to what Mac OS X represents. Again, it will definitely not be easy, but it could provide a viable way out the current dilemmas.

hEgelia on 28/3/06 1:44PM
[ Reply | Permalink | Report ]

hEgelia: I don't know how the Iyonix runs with the about-to-be-released graphics acceleration applied, and only the developers know what the A9 will do at full speed. We don't want consumers to decide whether the GUi is fast enough until they have had the chance to sample those options.

jc on 28/3/06 3:05PM
[ Reply | Permalink | Report ]

hEgelia: The Apple-like solution would be the best way forward IMO, but would no doubt require a lot of investment (in both time and money terms, even assuming ROL and Castle were amenable to it), which seems a bit unlikely. Pushing RO onto hand-held devices, which sounds like it would still take a lot more investment than the RISC OS market can currently provide, might be a better route for it to have a future, since it'll be in something a little closer to its native environment, but where the hardware is current. It also strikes me as a market where an alternative OS will have a better chance of success, technical considerations aside. And who knows, if it was a success there, that might feed back into some impetus in the desktop area.

SimonC on 28/3/06 3:12PM
[ Reply | Permalink | Report ]

hEgelia: These are the makers of modern OS core's on ARM: [link] So far as I know is it only with linux, *bsd and QNX possible to (easy) separate the core from the rest of the OS. So what do you think, is the best choice?

egel on 28/3/06 3:30PM
[ Reply | Permalink | Report ]

The thing I love about RISC OS is the working environment it gives me. This boils down to the desktop user interface and the filing system. It will be a sad day when I have to get this from an emulator on a Linux box. However, if it allows me to continue using the software I am comfortable with in an environment I love, whilst opening the door to newer and faster things within this environment, then I will make the move.

JWCR on 28/3/06 3:43PM
[ Reply | Permalink | Report ]

jc: You know, to be perfectly honest, I just typed in quite a strong reply, but in the end I figured it being senseless. The point I made above still stands, although I respect the one you made. Will this acceleration narrow the gap I pointed out? Only slightly. Again, due to market size, subsequent software standards and still, I'm afraid, inferior hardware compared to PC / Mac standards. Nevertheless, let me confirm I agree with your point and it certainly will speed up things, but my point above is of a different sort, as you may understand. Our strength for the time being, only resides in our lovely GUI and its fine assortiment of software, how primitive it (comparitively speaking) may be.

SimonC: I thought you may already hinted at that same point in your above posting

Again, I completely agree with you. No really - Let's have dinner some time

hEgelia on 28/3/06 3:49PM
[ Reply | Permalink | Report ]

As I see it, the main driving force for real Operating System development, (not just bells and whistles), is support for New Hardware.

If new ARM based hardware fails to appear, then RO will effectively disappear within a few years.

Emulation use on its own will not be enough to drive OS improvement, or to keep a viable user base.

Without new ARM based hardware, the only other possible lifeline is RO being ported to other hardware.

As RISCOS Ltd has shown that it is not in a financial position to readily develop RO currently, then there is little to no hope of them porting the OS.

People will have to decide whether to upgrade to new costly ARM hardware to keep they beloved RO, or just to accept that it will wither away fairly fast.

ajb on 28/3/06 5:16PM
[ Reply | Permalink | Report ]

In reply to all: Considering the price for native RISC OS hardware I guess quite a few current users who would love to get more RISC OS performace have a financial problem to get there. And for new users when they look at what they get for how much money I must admit that chances that they do not buy a RISC OS native box is probably not low. I guess that is part of the reason why VirtualRPC did sell so well according to the figures presented on Drobe some time ago.

Adding to this the fact that web browsing with RISC OS is no fun I use Firefox more often than not and usually based on Windows since it is easier when starting in RISC OS due to UniPrint. On the other hand I know that quite a few users do not want Windows. Furthermore despite all the terrific work done for movie playing in RISC OS it seems that currently available processor power is not quite up to it.

Thus I think that a setup offering RISC OS plus the UniPrint features on top of a Linux box (as is currently available for Windows) has a decent chance to get more users to use (or keep using) RISC OS.

Simply put: I love to use RISC OS and do so for quite a few things (especially email, writing letters, drawing) but there are things I prefer to do on Windows or Linux (webbrowsing, cutting movies) - both currently on separate native hardware but for some users running both on one hardware to save space, money, KVM etc. is probably an intersting option.

hzn on 28/3/06 5:20PM
[ Reply | Permalink | Report ]

Emulation is at least a prerequiste for porting Risc OS to a different hardware platform. It might not be something to expect from Risc Ltd, but what about an open source or private venture. Surely if somebody can develop VRPC and an emulator. Why not a rewrite of Risc OS. The manuals do a good job of documenting the API.

Or how about combing ROX with Emulation so that Risc OS apps can run. Impression might be Assembler, but I am sure ArtWorks and Ovation are C and could be recompiled given the right libraries

Jwoody on 28/3/06 6:04PM
[ Reply | Permalink | Report ]

I think it's fair to say that if some new, super-duper ARM hardware is not out soon, then native RISC OS machines have had their day. Perhaps more realistic would be to do an Apple and stick RISC OS onto a UNIX base (not emulation) that runs on standard PC hardware or, failing that, RISC OS Select running in emulation on a minimal Linux install that is invisible to the user. RISC OS has the best interface - not as WOW!! as MacOS, but a little more subtle and professional. Sadly, I can't see a real port or merging with UNIX going ahead, so Linux/Emulation is the next best thing.

The death of native hardware is down to a lack of activity from manufacturers. Emulation was a bad thing back in the day, but now there is no laptop, IyonixPC is starting to get long in the tooth, let's not talk about MD and RS, or the lack of a retail A9 Home... well, emulation looks like a life-saver.

arenaman on 28/3/06 9:09PM
[ Reply | Permalink | Report ]

I think the emulator could provide a great path to effectively port RISC OS onto a native Linux & X windows base. What it needs is some resourceful person to first tidy up the emulator. Second and most important provide an ehancement as to how SWI's are handled. i.e. Provides a facility that others can compile native code to implement a certain SWI ( or set of SWI's). Take for instance the Draw Module instead of each time the emulator hits a Draw SWI and goes off to emulate the SWI in Risc OS rom it says aha this is a native SWI I go call this C module complied for native x86. If somebody provided this framework then others could implement a family of SWI's i.e. DrawModule, FontModule etc. That way you could gradually build up the system so that all SWI were implemented as native x86 code, Linux as your kernel and X-Windows as your graphics system, Shades of OS-X. All it needs is somebody with the ability y to add an option for SWI's to be implemented as native. Somebody to document how to do native things like write to the screen. Then an Open source initiative for people to implement family of SWI's. Cooperative open source development is still a bit of a new concept to Risc OS developers but works in other open source projects.

Emulation could be the best thing that happend to Risc OS.

Jwoody on 29/3/06 12:15AM
[ Reply | Permalink | Report ]

I don't see why we could not use the emulation route to move to other platforms. How about adding a way to execute non-ARM binaries under RISC OS. We could simply have additional !RunImage files in the application directories. !RunImageX86 would get executed on systems with an x86 processor (including RiscPCs with a PC card), !RunImageX64 on x86-systems with AMD's 64bit-extensions, !RunImagePPC on PowerPC systems and !RunImage would be executed on emulators wich run on a processor for wich no native binary is present and on native ARM hardware without fast second processors).

JGZimmerle on 29/3/06 12:32AM
[ Reply | Permalink | Report ]

@Jwoody: Exactly my thoughts. :-)

JGZimmerle on 29/3/06 12:35AM
[ Reply | Permalink | Report ]

arenaman: if you want to blame someone for the near-death of native hardware, blame it on the guys who failed to deliver any kind of ARM processor that is much faster than what the IYONIX uses. According to the old MPF presentation from Samsung, we should have a 3 GHz ARM10 variant by now - where is it?

Castle did a fine job creating (or taking over) the basics for not-prohibitively-expensive hardware development - a hardware abstracted OS. Unfortunately, the only thing they have not abstracted away is the ARM processor.

Since the delivery of the StrongARM, the gap between x86 based processors and ARM processors has been widening. I don't think that it is very likely that ARM processors will catch up again. Therefore, the emulation idea is inherently sensible. Whether selling an OS for an emulator is generating enough money to keep on developing the OS - I'm not sure. It would at least reduce the cost of development significantly, since the many man hours spent into fine-tuning graphic card drivers and USB stuff could be saved.

The only real problem I see is that going completely emulated will suddenly shift the goalposts for software developers significantly. Certain "classes" of software will no longer be sellable into the RISC OS market. It remains to be seen whether this will pose a problem.

hubersn on 29/3/06 10:45AM
[ Reply | Permalink | Report ]

hubersn: It seems that the rate of speed increase in other processors is starting to slow down, so there may be a chance to catch up again (if RO survives that long).

Emulation on its own will only ever be a stopgap measure, assuming there is a future. Although I'm definitely not anti-emulation, if RISC OS turns into a purely emulated OS running on top of another one, then it won't last. It may ease the transition into something else.

SimonC on 29/3/06 10:59AM
[ Reply | Permalink | Report ]

Jwoody:

For emulating the SWI natively, I think you must look at Riscose ([link]). They want to emulate RISC OS at SWI level without using ROM code. Maybe some code from it is reusable in your project.

bernie on 29/3/06 11:32AM
[ Reply | Permalink | Report ]

No, the speed increase in other processors is not slowing down at all. The CPU developers have simply changed their methods of achieving the speed-increases. They don't do it by drving up the clock speed anymore (not primarily anway), but by optimising the internal structure of the CPUs. Examples are simultaneous multithreading (permits multiple independent threads to better utilize the multiple execution units of modern CPUs), integration of memory controllers into CPUs, putting multiple CPUs on one chip, increasing the size and speed of CPU's caches and the list goes on.

JGZimmerle on 29/3/06 11:36AM
[ Reply | Permalink | Report ]

ARM development: upto now this has been dominated by the low power-consumption requirement, however, it seems likely that video downloading/streaming is about to become a mainstream activity for PDA/mobile phone-type devices, most of which are powered by ARM chips. In which case, the appearance of much faster and more powerful ARM chips or SOCs may not be so far off. Whether these could be adapted for use by RO is another question, of course.

bucksboy on 29/3/06 11:53AM
[ Reply | Permalink | Report ]

In reply to bernie

For emulating the SWI natively, I think you must look at Riscose ([link]). They want to emulate RISC OS at SWI level without using ROM code. Maybe some code from it is reusable in your project.

Looks interesting BUT NOTHING seems to HAVE HAPPEND in the LAST FOUR !!!! YEARS

Withered on the vine one might say.

Least it shows it can be done.

Jwoody on 29/3/06 1:59PM
[ Reply | Permalink | Report ]

Jwoody: "Impression might be Assembler, but I am sure ArtWorks and Ovation are C and could be recompiled given the right libraries"

Unfortunately, you are completely wrong about ArtWorks. Most of it is in ARM assembler - only some recent functionality has been written in C. You are right about OvationPro and David Pilling has produced a Windows version already.

wuerthne on 29/3/06 4:45PM
[ Reply | Permalink | Report ]

So if we don't get faster chips, what other hardware techniques could be used? Multiple ARM chips? At least they're cheap. Yes, I know Risc OS isn't pre-emptive, but as an intermediate step perhaps RISC OS could run on one, with known-safe jobs passed to the others. Most apps don't need that much power anyway, and those that do (Artworks, video processing etc) could parallelise as appropriate.

[Disclaimer : I know nothing.]

Loris on 29/3/06 6:24PM
[ Reply | Permalink | Report ]

I'm not 100% certain but I think in order for RISC OS to work on multilpe processors (more than one) a whole lot of rewriting would be needed and if that work was started it would be a lot more feasible to simply move to x86 processors than trying to patch up with multiple ARM processors.

Gulli on 29/3/06 6:37PM
[ Reply | Permalink | Report ]

Gulli on 29/3/06 6:38PM
[ Reply | Permalink | Report ]

Hmm - somebody please remove my unintentional double posting and this one along with it :S

Gulli on 29/3/06 6:39PM
[ Reply | Permalink | Report ]

To me, (perhaps because Riscos was part of my childhood) the hardware is falling behind, and emulators are for people stuck in the past. What I'd be interested in is something new. The things I liked about Risc Os are the clean file organisation (app dirs/extendible file system), the customizability, the ease of programming, the extensive use of drag and drop, the clean UI (not having window furniture take up 30% of screenspace), snappy small programs, !Draw, memory mangement... and more like that. All of these things could be incorporated into a new system. Building a new system from scratch would be difficult, but there's no need to build things from scratch. Small OSes are popping up all the time and source code is so available that even insignificant projects can compile lots of software. ROX is an interesting development for making linux more RiscOsy. Something like that but a little more radical would be just what I'm looking for. The linux habit of scattering things all over the place is a little tedious, but having a linux kernel would be fine.

I don't care any more about backwards compatibility, what I care about now, is that the things that RiscOs brought to the world aren't lost. I miss them now and have missed them ever since I left it behind.

kybernetikos on 29/03/06 11:01PM
[ Reply | Permalink | Report ]

(nt)

Stoppers on 31/03/06 08:39AM
[ Reply | Permalink | Report ]

Kyb Netikos:

I agree with you. In my opinion the best solution is something like this:

A. Create a windowing system that looks and feels like the RO windowing system that can be used by programs written specifically for it.

B. Provide the basic programs required by users (Icon Bar, Backdrop, Filer, Switcher, etc.) using that system.

(To make the filer responsive, the OS would have to support filetypes stored in the directory. I think this could make the kernel incompatible with existing Linux filesystems, since I can't see a way to extract that information even from an ADFS filesystem.)

Then, either (to run Firefox, basically):

C. Create a GDK (GDK - An intermediate layer which isolates GTK+ from the details of the windowing system.) to allow some GNOME programs to be run.

D. Modify the GNOME programs you want to work (or commonly use) to use the RO GUI paradigms (icon bar icon, icon menu with global options, context sensitive pop up menus on open windows, etc.).

E. Have an X-Server program to run any other applications not yet converted. (Yes, I know what it says on the ROX website, and I respectfully disagree; one advantage of this approach is that you do not need to have the X-Server running.)

Or (to run RO applications):

F. Create a mapping library (or set of libraries) that provide the functionality of OSLib to C programs, using the interface to the above windowing system and other free libraries, like freetype2.

G. Create a library that maps from SWI calls and parameters to calls to the above library. (This could probably largely be achieved by modifying the code generation software in the OSLib library.)

H. Use that library to provide SWI implementations for Brandy (BBC BASIC) and QEMU (ARM emulation) to that library.

I. Provide a RO OSCLI interpreter or a translator to bash commands.

Or, or course, both. I suspect that whichever option gets implemented first, someone would start on the other, because it's there.

Stoppers on 31/03/06 08:46AM
[ Reply | Permalink | Report ]

To be completely consistent a Linux emulator is just as unwelcome as a Windows one (except for the fact at least with the Linux one you avoid getting into the clutches of Microsoft). The same arguments apply to it - it will (IMHO) damage the hardware development end of RISC OS, it will *weaken* the platform as a whole and it may (unlike VARPC) be more appealing to the RISC OS "holdouts" who wouldn't contenance using RO under emulation while the only option of windows was available.

The irony I can see in the current discussion is that ARM themselves *will have to* up their chip performance simply because Intel *is* targetting newer x86 designs at the "low power consumption" niche where ARM had seen as its own. ARM have no where to run and hide and I believe when faced with that they'll raise their game.

ARM have announced larger caches (c. 2MByte), have started looking at other architectural enhancements (e.g., superscalar) and (wait for it) faster clock rates. If ARM *does* improve its hardware (or well it's licensees do) and there is *no* RISC OS base to take advantage of it (because of emulation) then we'll all be the worse off for it (IMHO).

AMS on 31/03/06 1:37PM
[ Reply | Permalink | Report ]

I disagree. If I had the choice between a version of RISC OS, that ran on standard PC hardware (through a combination of Linux-kernel-as-HAL, emulation and native binary execution), and a full Linux distribution that only looks like RISC OS and may run a few RISC OS applications that have been converted to it, I would choose the former. If I wanted a full Linux distribution, I would go with a standard Kubuntu.

JGZimmerle on 31/03/06 1:57PM
[ Reply | Permalink | Report ]

(nt)

JGZimmerle on 31/03/06 2:15PM
[ Reply | Permalink | Report ]

Damn, Drobe lost my previous post.

My previous reply was aimed at kybernetikos and Stoppers.

@AMS: There are many reasons to go for a hardware-independant version of RISC OS, not just the performance of ARM CPUs. Even if high-performance ARM CPUs suitable for desktop machines were available, we probably would not get a RISC OS machine with such a CPU, because the RISC OS market is too small now. And someone did produce such a machine, it would be way too expensive.

Yes, ARM has been trying to get higher-performance chips out for years, ever since the ARM1020E (ca. 1999?), actually. But nobody wants to produce them. When chips with the newer ARM architectures are released, they have usually been highly customised for some embedded purpose and are not very well suited for desktop use.

To grow the RISC OS market again, anyone would have to be able to run RISC OS on their existing machines. This are usually PowerPC or x86/x64 computers. If we could grow the RISC OS market again, we might even end up with new ARM desktop machines, for peaople who like low-power-consumption, quiet computers.

I find the possibility, to turn any hardware that can run a Linux kernel into a RISC OS machine, quite attractive.

JGZimmerle on 31/03/06 2:34PM
[ Reply | Permalink | Report ]

AMS: Whilst those might indeed make a difference, how long will it be before they are available, if at all? Unless it is very, very soon, then emulation may be all that keeps RISC OS alive long enough to make use of them. Right now, high price and slow speed rather understandably doesn't make many people want to buy RISC OS hardware, and emulation ain't going to change that. Trying to eliminate it to help the market (on the assumption that it would) is attempting to cure the symptom, not the disease.

SimonC on 31/03/06 8:45PM
[ Reply | Permalink | Report ]

In reply to Julian Zimmerle:

I'm afraid I don't really see much difference between my proposal (with the F-I options) and your "version of RISC OS, that ran on standard PC hardware".

The only ones I can think of are that my solution doesn't include RODL, and allows enthusiatic software developers to make a contribution. Who knows, if it works well, it might convert some non-RO people, as well.

OK, modules and other low-level system calls, vectors, etc. will not be usable, but it wouldn't be impossible to add equivalents under the new system.

I think it's selling points would be its small size and consistency of use; I'd like it to work well with a simple frame buffer and excel with meatier hardware.

Stoppers on 01/04/06 11:43AM
[ Reply | Permalink | Report ]

SimonC>But what do you mean by "low speed". Emulated RISC OS is *still* slower than RISC OS on (say) an Iyonix and probably the A9 as well (except in the area of disk write-caching and an area in the interest of security I would happily see native RISC OS beaten on - if you get my drift ;-)

).

As to keeping RISC OS alive - that spurious argument was used with respect to Virtual Acorn and all it did was effectively move a significant number of their 3000 customers onto the PC (I mean in the drobe survey *very few* of those 3000 chose to reply - so one is left with the inexcapable conclusion that they were happy without MS Word and the Windows XP experience ;( ).

All a Linux RISC OS emulator will do is coax those few holdouts that would not contenence emulation of RISC OS under Windows to opt for RISC OS emulation under Linux. In either event it means the death of the RISC OS as part of a stand-alone hardware platform - something to be regretted.

As to Julian's point - no the ARM1020 is passe we now have ARM11 (!). Your presumption is that ARM will simply lie down an do nothing and simply let Intel swing in and swipe all of ARM's licensees. That simply *won't* happen (IMHO) it will mean that ARM may have to promote and may even have to discount some of their licensing costs on the higher end processors - that is what will make them shift. Simply hoping that Intel won't someday simply encroach on the cash cow that is ARM7 and "rob" ARM of cash is not an option. The days of ARM keeping a "low profile" and hoping that Intel would simply ignore them is long gone - I seriously believe ARM will raise their game (I certainly hope so).

As to the other point - yes producing a new ARM based system *is* expensive - but some of the expense is down to working out the likely number of purchasers - having yet *another* emulator *does not* help in this (if anything it makes producing a new machine a more dodgy proposition). So the best option for RISC OS is *no* emulation (on Windows or Linux) and support for Iyonix (or a successor) or when its completed A9 (or preferably an "A10" with the things that A9 lacks added).

Simply relying on the interest of Linux fans or the "goodwill" of Microsoft is *not* IMHO a means of securing the future of RISC OS.

AMS on 01/04/06 2:28PM
[ Reply | Permalink | Report ]

I meant to say "happy *with* the MSWord Windows XP experience.

Yes another "doh" moment.....

AMS on 01/04/06 2:29PM
[ Reply | Permalink | Report ]

AMS: The speed depends on what hardware you're running it on, of course, but my experience of VRPC would say that it isn't much different from using an Iyonix, in general, and that's not on a top end machine (it's a reasonable laptop). Disc access is of course far faster, but most of the time not all that important, because RISC OS doesn't do much disc thrashing.

As for the VA customers apparently vanishing, have you any evidence at all that they have been coaxed over because of it? If they've bought VA, then found Windows better, surely that's RISC OS's and the hardware's fault for not being good enough? RISC OS needs to address these questions if it's to survive, not try to hide away from them and rely on people being ignorant of other things (although peoples' ignorance of computers certainly seems to have helped Microsoft).

SimonC on 01/04/06 4:00PM
[ Reply | Permalink | Report ]

(nt)

Jwoody on 01/04/06 5:07PM
[ Reply | Permalink | Report ]

Please enlighten me

Your presumption is that ARM will simply lie down an do nothing and simply let Intel swing in and swipe all of ARM's licensees.

I thought ARM designed the Chips and Intel produced them. If Intel decides to promote its own designs then surely ARM will have to rely on others to produce. I guess Intel will keep making ARM's whilst they make money but phase them out over time.

As to ARM producing a design and getting somebody to produce a chip that would compete in the desktop market. I just don't see it happening. Certainly not Intel and I am not sure that there are any that could cost justify the risk and for what size market.

I think the best thing Risc OS could do is embrace emulation. It would be great to see VRPC or the Linux Part start to offer native code for some SWI calls. After that its just a question of time and effot.

Jwoody on 01/04/06 5:14PM
[ Reply | Permalink | Report ]

ARM design the processor cores, etc., but other companies manufacture them. Intel is just one of those companies. Have a look at the following links on the ARM website:

[link] [link] [link] ageTitle=All%20Partners&display=7

Stoppers on 01/04/06 5:27PM
[ Reply | Permalink | Report ]

I believe the attractive way forward for RISC OS, would be for it to remain running on its own native hardware. The Iyonix path continued, so to speak. However, it is apparent it's becoming increasingly difficult to sustain ongoing development, with the current state of market in mind.

To keep costs down, profit from PC's hardware, and keep alive some of those lovely software titles, emulation is a viable solution.

If you look outside the cosy RO market, you'll find technology development is happening at a furious pace out there. From a technical perspective, our native hardware (and software, partially because of it) is seriously behind now in almost all aspects. People are leaving the platform market not just because of the OS fork, infighting, dubious behaviour of ROL, Castle offering RO for sale, lack of various types of software development - but also simply because they feel they get a better overall deal when running Linux, Windows or Mac OS X, never mind the glorious benefits of the RO GUI. Our market has become extremely small, perhaps too small, to justify commercial product developments - both in hardware and software.

The A9home and Iyonix were not developed on their own. They are side-benefits of more economically profitable developments. Just look at their Advantage Six / Pace origins. IMO they were adapted for desktop use in our humble market. That is completely understandable - it simply wasn't worth it otherwise! What I mean is that some people are still living in a substitute Acorn dream, whereas the reality is that almost nothing is left from that era. All that is left is the wonderful, but seriously handicapped, RISC OS system. How many people do you know who don't run a PC or Mac alongside their RO machine? Well, I know one ... me.

hEgelia on 01/04/06 6:27PM
[ Reply | Permalink | Report ]

I recall reading somewhere about ARM introducing processors in the excess of 1ghz, i'm not sure when these will be made available and how easy it would be for a company like castle to implement them in newer models of the iyonix but i'm sure it would be possible. I'd love to see a new acorn compatible machine as i don't see emulation as a viable future.

mark1282 on 02/04/06 01:28AM
[ Reply | Permalink | Report ]

The problem is, that even a 1GHz ARM offers only about half to a third the performance of a 1GHz Pentium or Athlon. If RISC OS could make use of multiple CPUs, the situation would be better with the ARM11, but it can't. Meanwhile, the Pentium has just achieved 4.25 GHz.

ARM's license fees are almost irrelevant, they only account for a very small fraction of the retail price of an ARM CPU. So it won't make much of a difference if ARM lower their their licence fees. The main problem is, that to get a good general purpose ARM-CPU for desktop use, we would have to manufacture it ourselves.

I was not proposing a simple Emulator on another complete desktop OS as the solution. What I am proposing is to use a Linux kernel plus a good JIT-emulator as a HAL, to extend RISC OS to enable direct use of the hardware's resources through the Linux-APIs and add an ELF-loader wich can execute application binaries wich have been compiled for the host processor (for example a !RunImageIA64, !RunImagex86, !RunImagex64 or !RunImagePPC). So applications wich offer such a native binary would get a speed increase of about 1200% over the Iyonix on current x86 CPUs.

A large chunk of the developing costs for new hardware goes into driver development. For the system I am proposing, only one driver would have to be develped for each type of hardware, wich interfaces direectly with the Linux API. An example might be a SharedSound module wich uses the ALSA (Advanced linux Sound Architecture) API to drive just about all sound hardware available. Since ALSA is also multi-threaded, it can utilise multiple CPUs. Another example would be a graphics driver wich uses the OpenGL interface of the Linux drivers, so you could use any graphics card you like.

Because it would boot directly into the RISC OS GUI there would be no Linux-UI accessible to the user.

So to sum up, we could have a RISC OS computer now, wich is: - 13 times as fast as the Iyonix for applications wich have been recompiled for it - several thousand times as fast for floating point operations - about StrongARM speed for legacy applications - much faster than StrongARM speed for all legacy applications wich make good use of native versions of shared libraries and OS functions - compatible with just about all legacy software, even ARM2 based systems could be emulated - extremely fast for all I/O operations (HDDs, DVDs, sound, graphics, USB 1&2, FireWire, etc.)

JGZimmerle on 02/04/06 05:23AM
[ Reply | Permalink | Report ]

Maybe a PCIe card with an IOP333 (800MHz ARM processor) could be used to speed up the emulator part?

JGZimmerle on 02/04/06 05:34AM
[ Reply | Permalink | Report ]

I've said it for a few years now and I still maintain that the only realistic way for RISC OS to survive is to move away from ARM based hardware to x86 hardware. JGZimmerle's suggestion is certainly one way of doing that. Using linux as a base certainly has its upsides but it probably has its downsides as well.

The future of RISC OS is always going to be expensive whether it's on new ARM based hardware or moving towards x86 hardware in one way or the other. Trouble is that the ARM based way seems to be far too much of a lottery - will enough people be willing to buy yet another "expensive and underpowered" ARM computer for the market to stop it's seemingly steady decline and start growing again? I think it's too late already for ARM based hardware and x86 hardware is the only current way forward. It should be possible to do it in a similar fashion as Apple is doing - build a computer to certain specs and develop for that in the beginning (certain graphics card, sound card etc) but leave an opening for others to develop drivers for other hardware.

Backwards compatibility is something that people worry alot about, I think that's a mistake. Too much backwards compatibility has kept RISC OS underdeveloped for so long that it's killing itself. I still stumble upon software that is being held back just so that it can run on RISC OS 3.1, what on earth is the point with that? Of course some backwards compatibility is needed and always will but as has been proven time and time again does nothing but kill new developments. Why bother developing new software if the OS is being held back to support some software that hasn't been developed for a decade? Why should people switch if the new software can't offer any real feature improvements because the OS doesn't support them? Why should people even upgrade their OS when it makes no difference on available software?

Gulli on 02/04/06 10:54AM
[ Reply | Permalink | Report ]

RISC OS has many down sides from it's lack of development for sure and it is frustrating at times.

But I still use my RiscPC600 with RO 4.02 for most of my school work.

I enjoy a RO Word processor like Impression, it does all I need so simple and in a most user friendly way.

It even stays on the Icon Bar, it is annoying using my laptop with XP Windows when Word has to load every time I open or close a file.

My school issue laptop is riddled with virus protection software, it takes ages to start and is slow while AVG AntiVirus or LarvaSoft is checking for viruses in the background while I am supposed to be able to work undistracted.

The Windows slow shutdown procedure is a pain, especially when I mess up the destop and it saves my mess. I am told that I cannot kill that Windows shutdown procedure? I would rather a RO style of settings preset manually and shutdown is instant.

I have never ever had a virus on RO too, I started using my school Windows laptop about 5 months ago and it was hit twice in the first month with SpyAxe virus.

I still in many ways still prefer RISC OS for normal computer tasks that RO is able to cope with.

Regards,

Steve.

--

It's funny how RO still has a lot of pluses (+++).

Sawadee on 02/04/06 12:07AM
[ Reply | Permalink | Report ]

SimonC>As for the VA customers apparently vanishing, have you any evidence at all that they have been coaxed over because of it?

Yes, VA outsold Iyonix (VA has claimed they've sold 3,000 copies I strongly suspect that Castle haven't quite managed that), yet Iyonix users outnumbered those in the Drobe survey who claimed to use VA. Hence VA users seemed to respond less frequently than Iyonix users either (a). Because they weren't interested (e.g., at the level of replying) or (b). had left the platform. You can take your pick of which but either I would argue would *not* be good for the RISC OS platform (the latter obviously more so...).

SimonC>If they've bought VA, then found Windows better, surely that's RISC OS's and the hardware's fault for not being good enough?

You could extend that argument to Linux as well. But the trouble is there are a variety of reasons for people using Windows - not least are (a). Closed proprietary formats unavailable on other platforms (or incompletely implemented on these) (b). Use of DRM that is specifically intended to work only on Windows. Both (a) and (b) are - it could be argued - levers used by Microsoft to "beat" all comers - by having rigid control of these standards and DRM and denying these to other platforms *all* other platforms appear to be "inadequate". If such formats and DRM algorithms (ignoring the rights and wrongs of the latter for the moment) were available on other platforms it would "level" up the playing field. VA was a "thin end of the wedge" to soften the blow of moving to Windows - once there the propretary lock ins and inconvience of having to convert between RO and Windows systems would do the rest. This is *not* the fault of the RISC OS platform - but rather the brilliant skill of Microsoft. Any platform (RISC OS and Linux included) have a tough fight on their hands when dealing with Windows... and in RISC OS's case this is not helped by making it an "emulated" extension to the Windows platform.

IMHO if RISC OS simply becomes an "emulation" running on Windows and Linux then I believe I'd have little interest in continuing to use it, just in the same way as I've long lost interest in using the BBC emulator on my RISC OS machine.

AMS on 02/04/06 7:10PM
[ Reply | Permalink | Report ]

AMS, agree 100% with all your points. Lots of people may have bought VA to run some old programs, but it soon becomes a just curio or the equivalent PDF viewer. When you have to spend time maintaining the native enviroment and using certain applications there, you less and less likely to use primarily use RISC OS, and starting up the emulator becomes a speed bump. As indicated by the polls, the people still here taking about and continuing to be interested in RISC OS are on the whole native machine users, not emulator runners.

As regard to ARM & Intel that others have mentioned. Intel is only one licencee of the ARM architecture, and the XScale only accounts for a tiny fraction of the 100's millions of ARM based chips produced every year. PDAs and a couple of Windows Mobile PDA/smartphones are a drop in the ocean compared to the mainstream mobile market which Intel have not been able to crack. If Intel were to stop making XScales tomorrow (beleiving their own marketing crap they can run Windows Vista on under 1W), hardly anyone will notice as there are suitable ARM9 designs already being used as alternatives in just about every class of device (RISC OS included). Indeed as Intel inherited some IP from DEC, ARM would probably be better off gaining, a larger royalty share from ARM9s.

druck on 03/04/06 09:26AM
[ Reply | Permalink | Report ]

True, but Intel still make the fastest ARM chips available. For us it is irrelevant how many ARM manufacturers there are, as long as they all only produce under-powered CPUs, or even high-power CPUs wich are unsuitable for desktop machines.

JGZimmerle on 03/04/06 10:55AM
[ Reply | Permalink | Report ]

I have followed this discussion with interest, and have come to the following conclusions:

1. ARM-based hardware is increasingly outclassed for desktop use; 2. Emulation under Windows means the death, sooner or later, of the platform as a live entity; 3. Development of new native hardware is expensive and risky compared to 'software' solutions, and is therefore increasingly less likely to happen. In fact, we may be in a vicious circle where lack of support leads to less motivation to develop new hardware leading to further loss of support and so on. So Julian Zimmerle's proposal, if technically feasible (and I am not qualified to judge), seems the most attractive option to me. But who is going to do it?

A final point: the RO GUI still has a great deal to recommend it IMO. I have been using Windows XP for the last 3 months and, if you have to use Windows, it's the best yet. But it doesn't come close to RO for intuitiveness and ease of use; it's still essentially what it always was, a cumbersome, business-orientated, 'linear' system. If RO could get to run on genuinely fast hardware it might start regaining support on its own unique merits.

bucksboy on 03/04/06 6:41PM
[ Reply | Permalink | Report ]

Julian, what are these high-power ARM chips and why are they unsuitable for desktop machines?

Loris on 03/04/06 7:03PM
[ Reply | Permalink | Report ]

AFAIK there currently are no high-power ARM chips (at least nothing that comes even remotely close to current x64-chips). But even there was one: ARM cores are usually embedded into chips that are highly optimised for a very specific purpose, to be used in embedded devices. In most cases that makes them useless for general desktop use.

JGZimmerle on 03/04/06 8:20PM
[ Reply | Permalink | Report ]

OK, thanks Julian. Just the way you said it made me think there were much faster chips we just couldn't use.

Personally I'd rather not go the emulation->multicompiled->x86 route. Perhaps it is just because of the legacy instruction set. A system-independent OS is another matter, and perhaps that is the best route to getting there, but I'd prefer an efficient chip for my own use, at least.

Perhaps I can suggest an alternative path to fast ROS on ARM, in the absence of faster chips? ROS has the advantage that it doesn't actually need that much power for its own use - we really only need more for power-hungry apps and funky stuff. I mentioned at the end of the article-proper comments that multiple chips could be used, and Gulli correctly pointed out that ROS as it stands would need a lot of re-writing before it would work on them. But why do that? You don't have to initially. Have ROS running on one. Then have each of the others receive tasks which need a lot of processing. I'm not well-up on parallel processing architectures, but since I'm assuming they will get dedicated to particular tasks, suppose each one had its own private memory. They also need to be able to communicate. I know even less about this, but since the Iyonix has a GPU it is obviously possible somehow. So what software would we need? I don't think it is that much (compared to rewriting ROS as pre-emptive). As I see it, you'd want SWI calls for the main system to send blocks of data to and from the 'fingers', and perhaps make them able to create interrupts in each other. You'd also need a system for apps to find out what resources were available Each finger would need a BIOS so it could collect the initial data, and twiddle itself while it was waiting for something to do.

The big advantage of this is that (besides the hardware engineering and boot-straps), it doesn't have to all be done at once. As ROS evolves, it can delegate parts of itself to the fingers. But any apps with intensive calculations would be developed in parallel, and could then of-load the bulk of the processing to one or more fingers. Creating an archive, for example, needn't put up the hourglass. Artworks2 could spread the rendering load over as many fingers as were present.

Of course the fingers don't have to be perfectly symmetrical. For example, one could hold the frame-buffer, essentially replacing the GPU. (Yes, I know, support chips would be needed). This would have several advantages. There would probably be a cost saving, and all the power of the chip could be used since there wouldn't be a proprietary driver. Also, programmers could use the base of knowledge they already have.

Loris on 04/04/06 12:30AM
[ Reply | Permalink | Report ]

I think Tony is re-inventing the Tube after almost quater of a century

druck on 04/04/06 1:18PM
[ Reply | Permalink | Report ]

I never understood the tube, I thought I was reinventing the hydra! (And I didn't know much about that...)

Loris on 04/04/06 1:35PM
[ Reply | Permalink | Report ]

Julian>Yes a 64 bit chip even using a bit of a kludge of a command set like x86 is faster than an ARM. But you're not really comparing like-with-like here. The Windows OS is *very* much more top heavy than RISC OS and add to that the load of running AV software and the various services Windows tends to demand and you'll find the multi-GHZ clock doesn't quite yield the size of difference - and for certain things may even appear less responsive.

Yes you can cite FP being a bit down on the ARM/RISC OS and maybe disk write caching (a hazardous activity that appears to make the PC perform better) - but for running RISC OS programs a native platform is *still* best. As I said elsewhere Intel is beginning to encroach on ARM's territory - I can't see ARM simply retricting themselves to "microcontroller" level processors and letting Intel walk off with the richer pickings. And remember it isn't just ARM in this - their licensees have put IP into the ARM family - Intel (on the other hand) doesn't even allow second sourcing - so if Intel wins then Freescale/Texas/Sanyo/NEC et al will be the losers). So on the whole I'd be more optimistic about newer/faster ARM's coming along.

AMS on 04/04/06 1:38PM
[ Reply | Permalink | Report ]

In reply to AMS: Julian wasn´t intending to include Windows at all, or even a Linux GUI on the the kernel, so his idea effectively chops the heavy top off the underlying OS and replaces it with the lightweight GUI from RISC OS. OK a thirteen times speed increase is a little optimistic, but how much would you like, five times?

As far as I can see (and I just checked back) you are the only person talking about write caching; if you don´t like it, use a filesystem that doesn't do it. It´s only really a problem if your OS is likely to crash when a program contains an error and Linux is orders of magnitude less likely to do that than RISC OS.

Any alternative system for running RISC OS (or RISC OS-like) programs would be capable of moving back to any ARM processors that become available in the future (I don't think anyone is recommending swapping a reliance on ARM for a reliance on x86). Does the reliance of RISC OS on ARM processors make it more likely that future processors will be more suitable for desktop use? I very much doubt it!

RISC OS needs new users. To get them it needs faster hardware and new applications. Either we can wait around, losing users, until someone produces a faster ARM processor suitable for desktop computers (which no company has said they are going to do), or we can do something to make the best features of the OS available to many more potential customers. The alternatives being suggested here are ways of doing that before there's really only a couple of us still around, and provide at least the chance of more sales of RISC OS applications.

Personally, I believe my suggestion has the potential to be better in most respects than the original, and involve less work than, say, porting Firefox to RISC OS has. I'd welcome arguments to the contrary.

Stoppers on 04/04/06 4:43PM
[ Reply | Permalink | Report ]

Stoppers: I've no idea about the amount of work, but I think you're right on all the other points. I can't see an alternative to doing something at least vaguely along those lines. The current situation can only lead to the death of RISC OS. Can anyone see a way of bringing new or returning users in any number to a desktop machine running on current ARM hardware? If you want to stick to ARM then the possible survival route would be via portable devices (and since the rest of the hardware's still totally different, that's probably a hard job too), where there isn't the competition from other hardware that's an order of magnitude faster and cheaper.

SimonC on 04/04/06 5:38PM
[ Reply | Permalink | Report ]

(nt)

JGZimmerle on 04/04/06 10:56PM
[ Reply | Permalink | Report ]

Tony: Wouldn't you still have rewrite much of the OS to make it aware of the multiple environments (cpu+memory)? At least some form of communication would be needed as you suggest and there would probably have to be a layer in each cpu/memory to pretend to be the OS and forward all OS calls to the right cpu/memory environment. Otherwise the multiple chip solution would only work for multiprocessor aware applications and that would definately not be a good step! Making application writers have to specifically write in support for multiple processor support would be insanely stupid when compared to making the OS handle all that transparently for the applications.

The way Apple did when moving to OS X is probably the best way to do this, creating an emulated environment for the old style applications while providing a new pre-emptive, multiprocessor capable OS. This provides the best transitional environment but may be far too expensive or time consuming. Then again, there are already several emulators out there that probably could provide the emulated environment (with changes of course).

Maybe yet another solution would be the best - simply start from scratch using the principals and interface design of RISC OS! This is of course hugely risky, how many would buy that instead of simply going for Windows/Linux/MacOS?

Gulli on 06/04/06 01:03AM
[ Reply | Permalink | Report ]

Of course when I say "multiprocessor aware applications" I don't simply mean multithreading applications but applications written to use SWI calls in order to communicate between cpu+memory environments.

Gulli on 06/04/06 01:08AM
[ Reply | Permalink | Report ]

Stoppers wrote>"Any alternative system for running RISC OS (or RISC OS-like) programs would be capable of moving back to any ARM processors that become available in the future (I don't think anyone is recommending swapping a reliance on ARM for a reliance on x86). "

Sorry to say but that's one pig that just won't fly ;-)

. I can't but admire the sentiment behind that thought - but the reality is *what* RISC OS hardware manufacturer is going to risk their financial future when the user base is busily moving the x86/x64 and Linux ?

I note Apple apparently are to produce software to allow Windows XP to run on their Intel x86 based machines (can't help but smile at that thought, considering they probably went to great lengths to ensure you *couldn't* run MacOS X x86 binaries on a normal Intel Windows XP PC already...).

I digress, the point is that some people here seem to think that Linux (or things based on Linux) do the following (a). Promote world peace (b). Solve family problems (c). Are better at running RISC OS than native ARM processors. Guys Linux has lots of things going for it - but it is *JUST ANOTHER OPERATING SYSTEM*, just like RISC OS is, just like BSD Unixes (or unixes more generally) or Windows or Next Step or whatever.

Every problem does not get resolved by running Linux - the thing is that *I WANT* RISC OS running on ARM hardware full stop. I *have* a linux box and a windows box I simply *don't need* or *want* one of them parroting my Iyonix (my Iyonix does Iyonix better anyway). If a faster ARM based machine arrived I'd be queuing up for it - I just can't find the same enthusiam (i.e., I could not be bothered) to try getting RISC OS running over some sort of Linux core on x86.

AMS on 06/04/06 1:32PM
[ Reply | Permalink | Report ]

AMS> Ultimately that is a rather short-sighted approach. Who cares if your GUI (the bit you actually interact with) runs on ARM, x86, fork-potato processor II etc?

jonix on 06/04/06 1:55PM
[ Reply | Permalink | Report ]

Gulli, yes and no. Basically I'm suggesting we go with the "insanely stupid" option. But wait! I agree that having the OS preemptive, multithreaded etc is desirable. The problem is how you get there from here. There is a chicken and egg situation with noone having the money or being willing to take the risk. So my suggestion is basically to smooth the transition.

As I pointed out, only very few apps actually need a lot of power - but those that do *really* do. And actually, the overhead in the app probably wouldn't be all that big at all - at least not for embarassingly parallel problems (which I think they tend to be for many of the things we want).

I agree we'd need to end up with a legacy environment, where all the old apps could live. But many apps wouldn't make the transition - and honestly, many don't actually need to. People only upgrade if there is a clear benefit. There would be an instant power increase since the obvious drains of the OS could be cherry-picked and temporarily put completely in the fingers. And then there would be a rapid and easy payoff for apps which need raw power. RISC OS could then be rewritten over time, with a clear benefit with every upgrade.

Loris on 06/04/06 2:34PM
[ Reply | Permalink | Report ]

@jonix: I agree. And the best reason to move to a Linux-as-HAL approach is to widen the user base. Many people are prepared to spend up to about 100 EUR on a Linux distribution, because they can easily install it on their existing hardware. I think a similar offer would be possible with RISC OS. The one thing we really need, is user-base growth. For the last couple of years, the userbase has been shrinking. If we allow this to continue, the platform will die.

JGZimmerle on 06/04/06 6:18PM
[ Reply | Permalink | Report ]

In reply to AMS:

I think that you and I have different opinions of what a desirable future for our platform is.

I would like to see a system that uses the best concepts from RISC OS (the GUI, typed files, simple application management) to free the power of cheaply available hardware, whatever the processor, and perform tasks I could never do with a RiscPC.

You, I think, are looking for RO(D)L or Castle to become a major player in the OS market with a return to the days when ARM processors were the most powerful desktop processors in the world. I think that's very unlikely to ever happen, especially the former.

"what RISC OS hardware manufacturer is going to risk their financial future when the user base is busily moving [to] x86/x64 and Linux ?"

Perhaps Advantage6 would still be producing the A9home as a spin off from other work, I don't know. I don't much care, to be honest. All (both) the hardware manufacturers are telling us that they don't make their money from RO desktop products anyway, so maybe they'd be better off without it!

For what it's worth, I don't think Linux is any of the things that you suggested (I don't even want it to run RISC OS, I want it to run RISC OS-like applications; the current OS doesn't get a look-in). I see it as a source of device drivers that it would take the remaining RO programmers a hundred years to reproduce, I see it as a processor independent platform that's unlikely to crash, I see it as a word that will make a couple of orders of magnitude more people than our current (desktop) userbase take notice (most of them will then ignore it, but if just a few like it, maybe they'll use it and it will have a future).

Stoppers on 06/04/06 8:08PM
[ Reply | Permalink | Report ]

Jonix wrote>"Ultimately that is a rather short-sighted approach. Who cares if your GUI (the bit you actually interact with) runs on ARM, x86, fork-potato processor II etc?"

When I read things like this I just get tired. I CARE.

GUI=Graphical User Interface. RISC OS is *not* this - it is much more - it is a *full* operating system, it presents a consistent (programmers) interface to its various elements and allows any programmers work to interact with the underlying system in a consistent manner. A GUI (on the other hand) is merely "packing". Yes from your viewpoint if all that matters is that the windows are a particular colour, the buttons a particular shape, that you can drag and drop things and that is the sum total of all that matters to you - fine (but then why not just use ROX or Windows XP - it can drag and drop too you know

).

As to the processor, do I *really* need to explain this? OK fair enough. RISC OS is predominantly ARM code - that is it runs most efficiently when it is run on *native* hardware. It also means you're avoiding additional layers of abstraction that may add to the possibility of errors (bugs, hardware incompatibilities etc.,). Yes an x86 is *faster* (when running x86 code), but is it as fast running ARM code under emulation (NO), is it guaranteed to *always* behave like the original ARM hardware (NO, emulation is an *approximation* of the underlying hardware and no matter *how good* cannot be unconditionally guaranteed to always behave as the original). Even if (and its a *BIG* if) it were so guaranteed what happens when the underlying x86 OS changes and introduces incompatibilities, or if there are "viral" problems.

Jonix it's horses for courses - if you want to use Linux and if you don't give a fig about the problems enherent with the x86 architecture *fine* but please *do* bear in mind what is best for Linux/Windows et al may not be best for RISC OS or its users.

AMS on 08/04/06 3:21PM
[ Reply | Permalink | Report ]

Stoppers wrote >"You, I think, are looking for RO(D)L or Castle to become a major player in the OS market with a return to the days when ARM processors were the most powerful desktop processors in the world. I think that's very unlikely to ever happen, especially the former. "

If that's the impression I gave I appologise. ARM is *not* going to be the fastest processor in the world again. It won't outrun an x86 or PPC. But - and this *IS* the kicker, the one thing it does *better* than any other processor is it runs RISC OS *quicker*. So you're perfectly right for compressing mega gigabyte JPEGs or something the ARM sucks, but not all ARM's do to the same degree and (in their favour) they happen to be darned good at running our favourite OS.

Julian wrote>"And the best reason to move to a Linux-as-HAL approach is to widen the user base. Many people are prepared to spend up to about 100 EUR on a Linux distribution, because they can easily install it on their existing hardware. I think a similar offer would be possible with RISC OS. The one thing we really need, is user-base growth. For the last couple of years, the userbase has been shrinking. If we allow this to continue, the platform will die."

Ahem Julian. Let's get real here shall we. Linux users *only* love one OS, Linux. You're *NOT* (IMHO) going to get droves of Linux users moving over to use RISC OS. At best they'd use RISC OS on Linux to show how "superior" Linux is and then go back to using "The GIMP" or whatever. You'll have one sale and then no more (bye bye Select subscription scheme) - besides I can't see ROL parting with RISC OS for less than they do for VA can you (and if they did would VA be eternally grateful - I doubt it).

The best way of keeping the userbase is to *assert* that RISC OS is an alternative independent platform that does not rely on hardware and software over which we have *no* control. Then build from that, when Apple finally goes x86 there'll only be one platform left not reliant on x86 - and that's our own ARM/RISC OS. Having choice is a good thing - and sometimes a that can become a selling point in itself (a slogan suggests itself "Dare to be different").

AMS on 08/04/06 3:33PM
[ Reply | Permalink | Report ]

AMS> I really think you have an unreasonable requirement for your OS to run on ARM hardware. Users who are unaware of the internal workings of a computer really aren't bothered by what processor is under the hood. Having a different processor to everyone else is not a marketing point; it's largely irrelevant unless it provides some other inherent benefit (such as low power consumption for example).

I am aware of what a GUI is, and I fail to see the point you are making regarding a consistent programmer's interface. The Win32 API is also consistent.

You seem to be overlooking everyone's point simply because they dare to suggest we shouldn't be using ARM processors. I'm not talking about emulating RISC OS, I'm talking about reimplementing its best bits elsewhere (see stoppers' explanation). I think this is the point you are missing. The whole x86 vs native ARM speculation is irrelevant.

I'm not bearing in mind what's best for Linux/Windows users because they're not part of this debate.

Finally, what are the enherent(sic) problems with the x86 architecture? I'd be interested to hear what they are.

jonix on 08/04/06 8:01PM
[ Reply | Permalink | Report ]

This is mostly aimed at AMS, but partly also at jonix.

The inherent problems of one specific processor architecture are irrelevant for this discussion. If you don't like x86, choose something else. The very elegant IA64 springs to mind, or if you don't like Intel (you are not using an Iyonix, are you?) you could go for a PowerPC system. Even without Apple, there are still a few manufacturers left.

As for ARM processors running RISC OS quicker: I think that is largely irrelevant, as long as it runs fast enough so that the user does not notice any delays. And many parts of RISC OS are already written in C/C++, so these parts could be recompiled to run natively on any processor. There would also be the option of utilising a cheap PCIe card with an ARM for acceleration of the emulation part of the "Linux-HAL". As for stability: Do you really think it helps RISC OS' stability, that parts of it have to be re-written every time you want to support a new piece of hardware (like a sound card or a network card). And we already have no control over our hardware, since ARM won't listen to us and we don't have the resources to make our own chipsets anymore.

I agree with AMS on the point that RISC OS is more than a GUI. That is why I would like to see it developed further and made independant of the ARM architecture.

In my experience most Linux users are open-minded and have actually tried several different OS in the past. Most of them stayed with Linux because it supports their choice of hardware and fulfills their needs. Most of them are also very aware of its shortcomings. Of course they get a bit defensive when people criticize their OS, we all do. That comes natural because of the constant attacks we all got so much over the years from the Windows trolls. However as soon as you mention that you are using an alternative platform, they generally get a lot more sympathetic.

I also think that the price of RISC OS (last time I checked it was somewhere around 65 GBP) could be brought down considerably, if it did not involve hardware-production and shipping costs.

JGZimmerle on 09/04/06 10:18AM
[ Reply | Permalink | Report ]

Julian wrote>"The inherent problems of one specific processor architecture are irrelevant for this discussion. If you don't like x86, choose something else. The very elegant IA64 springs to mind, or if you don't like Intel (you are not using an Iyonix, are you?) you could go for a PowerPC system."

I don't have any specific axe to grind with regards to Intel other than, in my humble opinion, their x86 architecture is appalingly bad. The IA64 (Itanium) I know little about (I think its VLIW), problem is I am not sure what Intel wants to do with it (at one stage I think they dearly would have loved it to surplant the x86 - but (alas) it's lower clock rate (not performance mind you) doomed it to small niche markets). AMD's ascendant x64/Athlon 64/opteron family probably put the last nail in Itanium's coffin (as Intel had to fight back with an x86 chip to compete against AMD's offering)s. I digress.

The point is *not* that you can't abstract an OS to run on any processor - but that given RISC OS's *lack* (relatively) of abstraction that you'd lose a lot in the translation. As over 40% of RISC OS is ARM Assembly language - so an inability to run this code optimally (i.e., Natively) would have a detrimental impact. Bear in mind some of the remaining 60% of RISC OS is written in BBC BASIC - and that would probably be best executed by the native ARM BBC BASIC interpreter (so again a "non-native" processor would be at a disadvantage). You are, of course, correct that for C/C++ (a sizeable amount of RISC OS) would not be so hampered and would be more processor agnostic).

I don't personally believe that ARM will simply withdraw from its niche and allow Intel to roll in with 1-5Watt x86 cores that would be competitive. ARM, IMHO *have* to up their cores performance - or lose market share. That being the case I would like RISC OS to be in a position to take *advantage* of those changes.

As to Linux users being open minded I did not infer they weren't - all I was saying was that their primary interest *IS* Linux - I can't imagine that that would change if they were offered RISC OS. As to the cost of RISC OS that's set by ROL - and the price they charge they charge. If the "hardware production cost" you refer to are Flash RAM (or even CD) they represent a *small* proportion of the price - and consequently I'd not foresee a big drop in price - and without that drop and a viable fast Linux based emulator I can't see enough Linux users opting for RISC OS to such an extent that economies of scale would result in a larger drop in price that might encourage further RISC OS use.

AMS on 09/04/06 6:11PM
[ Reply | Permalink | Report ]

Well, for BBC BASIC I would certainly use a native version of the interpreter. IIRC someone wrote one in C some time ago?

I just don't see where we would have to "loose a lot in the translation". If it were done right, I don't think we would loose anything, but gain a lot.

JGZimmerle on 09/04/06 10:56PM
[ Reply | Permalink | Report ]

(nt)

AMS on 11/04/06 1:26PM
[ Reply | Permalink | Report ]

In response to AMS: I'd like to hear what you had to say!

I suggest editing your postings in an editor and dropping them into the browser; that way you get to try again if it doesn't appear.

I was using Browse when my posting went AWOL, by the way, how about the other (nt)-ers?

Stoppers on 14/04/06 3:54PM
[ Reply | Permalink | Report ]

As I said elsewhere:

We can only investigate this forum problem if you treat it as a software bug - just like you would if you found a bug in an application you use on the desktop. So at the very least we need to know what browser you were using, on what OS, at what time and your Internet facing IP address. This is so that we can find you in the logs, and also pinpoint if there's a reoccuring pattern. What would also be handy is a copy of the text that you tried to post, but then didn't show up. Email it to the comments at Drobe address.

Thanks for your patience.

diomus on 14/04/06 4:07PM
[ Reply | Permalink | Report ]

(nt)

AMS on 14/04/06 5:43PM
[ Reply | Permalink | Report ]

We're on a new server now. I'll be keeping my eye open for any more (nt)'s, it is somewhat difficult to pinpoint

piemmm on 15/04/06 10:11PM
[ Reply | Permalink | Report ]

Thanks Ian (if you can read that then all is well....)

If its any help my previous postings were from MS IE (sorry) and Firefox (both on Windows XP as I do not have internet access from home from my RISC OS box). My NT postings originated from two different locations (different IP addresses and servers).

Again thanks for your efforts.

AMS on 17/04/06 1:57PM
[ 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

DialUp, R-Comp's net connectivity package, is put to the test as Michael Stubbs reviews

2 comments, latest by gary_hughes_fp on 7/8/01 3:50AM. Published: 12 Feb 2001

Random article

Techie docs for mystery Acorn CAD workstation surface
Documentation for Acorn's 1988 prototype 'high end' technical publishing workstation have been scanned and published online by collector-of-old-kit Chris Why. The A680 was an advanced Archimedes-series machine that ran Acorn's Unix attempt, RISC iX. It was initially powered by a 25MHz ARM2 and had a 67MB hard disc with up to 8MB of RAM and a monochrome display.

5 comments, latest by davidb on 12/12/08 8:16PM. Published: 10 Dec 2008

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
"Unless and until you are willing to produce the evidence to back up your assertions, please cease and desist making these allegations"
Page generated in 1.0874 seconds.