Taking OS features for granted | RISC OS news and information from Drobe


Beta! \| About us \| Contact \| Submit news \| RSS \| Twitter	Webspace \| Tech docs \| Downloads \| BBC Micro \| Gallery \| Wallpaper

Taking OS features for granted

By Chris Williams. Published: 1st Nov 2005, 12:00:41.

Are we under-selling RISC OS?

A while ago, we covered a comparison between RISC OS and AmigaOS from a 'political' angle, in terms of OS ownership and the battle of native hardware versus emulation. AmigaOS, like RISC OS, is a minority OS that has seen better days but after being handed from company to company, it's starting to look up. The closed source OS recently celebrated its 20th birthday, so its age is comparable to RISC OS. Its developers have created a new website, including a page with 20 key features. Of all the operating systems on the planet, comparing RISC OS to AmigaOS is probably the fairest. Despite Apple's image as the 'little guy' in the computer industry, Mac OS X benefits from billions of dollars in the bank, which afforded them a totally new platform and kernel. The Mac OS dock and filer are comparable to their RISC OS counterparts, but that's about as far as it goes. Microsoft's Windows couldn't be any more different, and the development model of Linux and its Unix roots set it apart from RISC OS.

This isn't an attempt to bash AmigaOS - far from it. The OS, which aims to make computing fun again, deserves kudos for setting up an informative and friendly online presence, and for its advances in modern hardware support. While we have a few things in common with them, it's also a source of ideas for the future.

AmigaOS 4.0 claims to boot up in seconds and shutdown just as rapidly, very much like RISC OS starting up from ROM. The OS also has an interesting system for allowing third-party software to interpret different file formats: An individual application does not have to understand how a particular file is structured, as it instead consults a separate program called a 'datatype' that operates on the file on the application's behalf. This is similar to RISC OS Select's Image File Renderer sub-system, except it applies to all file formats rather than to just images. AmigaOS provides a library to developers so that applications can also access compressed archives, such as zip and tar files, transparently. A piece of software doesn't need to know how the files are compressed, as it can just ask the library to take care of it. The OS also allows individual files to have their own custom icons, which is achievable on RISC OS using a patch. The desktop GUI is configurable, allowing users to replace window buttons and other furniture, which is possible with RISC OS and notably, RISC OS Select.

Amiga OS 4 desktop

The PowerPC compatible OS provides a context-sensitive menu system, which is a fancy way of describing the menu 'middle' mouse button on RISC OS. It also preserves the stacking order of windows when you use them, which is something that drives me, personally, insane on other operating systems: It's so annoying when a window jumps to the front and obscures other windows I'm currently looking at. The OS also provides virtual desktops, which are available under RISC OS using third-party software, and allows the user to use multiple virtual desktops at once. A virtual desktop is a way of sharing the space taken up by many desktops on one monitor. The AmigaOS developers are also working on OpenGL compatibility for 3D graphics, which Iyonix users recently gained, thanks to Simon Wilson's efforts.

The OS includes a scripting language which sounds powerful, and the team is bringing Python on board at some point too. RISC OS users usually resort to writing a simple Obey script or BASIC program to perform a repetitive or complex task, or Perl if they're feeling confident. Script-based automation of tasks is certainly useful, especially for image processing. AmigaOS uses pre-emptive multitasking (PMT), as opposed to the cooperative multitasking (CMT) used by RISC OS. PMT means a single application can't easily hog the processor, unlike under CMT where every RISC OS user knows what it's like to have ChangeFSI or Oregano steal away desktop responsiveness. A third party patch, Wimp2, exists for RISC OS to implement PMT, but it's not entirely compatible with all applications. AmigaOS uses PMT to boost processor time for interactive tasks, leaving the desktop feeling slick and responsive. AmigaOS 4 also has full memory protection, virtual memory and resource tracking - currently thorns in the side of RISC OS.

The OS also has a RAM disc, just like RISC OS, and it can preserve files stored in memory to disc on shutdown, which can be done on RISC OS too. Another attractive feature of AmigaOS is its crash debugging application, called the Grim Reaper. This ensnares troubled applications and displays their current state in memory and other low level details. Debugging tools similar to this exist on RISC OS. AmigaOS has a polished configuration program for the user to select which country and time zone she lives in, and which languages and character sets she prefers. Applications also use a system very similar to the RISC OS 'messages' mechanism, which allows software developers to provide multiple translations of their programs. AmigaOS also supports a means for creating virtual labels for hard discs and other media. For example, all your fonts could be referenced using 'Fonts:'. At first, this seems rather attractive, but then you realise that RISC OS has an equivalent feature through the use of its path variable system. For example, Font$Path is set to point to all my fonts and I can access the Homerton typeface using Font:Homerton. Under RISC OS Select, I could also point MP3s$path to my directory of music and do filer_opendir MP3s:$.DepecheMode to view that particular directory. AmigaOS also provides a command line and an iconbar, to which animated icons can be attached.

Comparing AmigaOS and RISC OS is an interesting exercise, especially when it provides inspiration for things like scripting languages, friendly internationalisation configuration, and transparent file format handling. However it also shows areas where RISC OS is grossly under-selling features we take for granted every day, but are seen as almost revolutionary elsewhere: For instance, being efficient on a sub-1GHz RISC CPU, anti-aliased fonts, supporting virtual disc labels, using a RAM-based temporary disc, and providing an iconbar.

Links
20 years of AmigaOS

Discussion

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

Saw this website the other day and was amused that RAM Discs are seen as revolutionary by the Amiga team.

I remember being so impressed with drag and drop when I first got my RPC; even more so that I could drag a file straight from one application to another without having to save it inbetween. That's a neat trick we should be selling.

I do hope that ROL will extend the ImageFileRender facility to other file type. That would be nice.

jms on 1/11/05 12:45PM [ Reply | Permalink | Report ]

I've never found the perfect virtual desktop addon for RISC OS with various bits not working like some windows won't get off the screen or when pulling a window to the current screen it won't work. So my question is which is the best one to use?

dansguardian on 1/11/05 12:47PM [ Reply | Permalink | Report ]

An informative article and quite relevant to us, I'd say.

Let's just hope RISCOS Ltd is listening and at one time implement some of the things AmigaOS4 has onboard, such as PMT and transparent file-handling. Like Neil Spellings mentioned in a previous article, ROL's features planned for Select4 seem "bells & whistles" compared to some of the things mentioned in this article.

hEgelia on 1/11/05 12:56PM [ Reply | Permalink | Report ]

This article brought back lots of memories.

My first computer was an Amiga.

My folks brought it for me sometime around 1989/90 from some show in London (can't remember where)

My mates got A3000's for their school work but my mum said it was too expensive and brought me the cheaper Amiga. I never did use it for school.

Actually my mums still got it and still uses it (but only for playing games).

Sorry, wandered off down memory lane.....

Col1 on 1/11/05 1:22PM [ Reply | Permalink | Report ]

At the same time that the new AmigaOS website went online I was looking for a website as a springboard for other people to understand what RISC OS is. I wish there was a really nicely presented website like the AmigaOS one that I could point people to (in the end I had to use Wikipedia; maybe someone has a better suggestion?)

I do I think it highlights the difference in "image" presentation between the Amiga and RISC OS, something that Amiga users have been better at since the dawn of time.

flypig on 1/11/05 2:34PM [ Reply | Permalink | Report ]

Thanks Chris. I keep saying that we undersell RISC OS and are more likely to apologise for its failings rather than promote its advantages. Whilst we need to take note of the advantages of other systems - and tell ROL that we want the best included - we need to be publicly loudest with RISC OSs plus points.

jc on 1/11/05 2:38PM [ Reply | Permalink | Report ]

Maybe one of the magazines might be able to act as a focal point for creating a "what is risc os, and why we love it" website? It is a shame all the different www.riscos.(whatever) have been taken, as I'd love to be able to point people to www.riscos.something to give them an overview of what RISC OS does. The RISCOS Ltd site is clearly a business site (and rightly so) so it would be nice to have a separate, independant OS site of some kind.

arawnsley on 1/11/05 3:41PM [ Reply | Permalink | Report ]

jms: "amused that RAM Discs are seen as revolutionary by the Amiga team. "

Which rather reinforces the point Chris is making in the article - easy to use RAM filing systems have been a feature of RISC OS since RO2, way back in the 1980s. But if you mention that to a typical MS or Mac user, they'll just say "what's a RAMdisc?". A site that lists (and explains) all the basic features of RISC OS that we take for granted would be no bad thing.

Perhaps the drobe team, who own riscos.org.uk, might transform it from a rather bland redirection page into something suitable?

chrisj on 1/11/05 3:53PM [ Reply | Permalink | Report ]

Andrew: We would be very happy to host a site - maybe using the acornuser URL. If anyone thinks they could sell RISC OS on a web site - and keep it up to date - then we would be pleased the hear from you.

jc on 1/11/05 4:18PM [ Reply | Permalink | Report ]

I know that Amiga had a RAMdisk in the A500 days but I remember that when I started using mac the second time (about 1995 and OS 7.5 I think) they had a RAM disk. That was on a Performa 6200.

Thye first time I used Mac's was when they replaced the trs80 IN 1979.

The AmigaOS will not be mainstream until it leaves its specific low-volume hardware-dependent routes behind. IE It can run on a G3 so why not have the OS run on old Mac's. Lots of people will try it out on an old machine. Or have it ported to intel so it can be used on an up to date box-shifter cheapo machine.

Come to think of it; paralells with RISC OS there.

Cheers Bob

nijinsky on 1/11/05 4:31PM [ Reply | Permalink | Report ]

Thats funny I looked at the web site and saw Math Acceleration ( read as Floating point ) Pre-emtive Multitasking. Virtual Memory Memory protection Web browsing Support for QT, MPEG-4 DivX

I thought such things Risc OS users only dreamed about in their best wet dreams. I think to say we have had some of AmigaOS features like ram disk for some time misses the point. Risc OS architecture compromise decisions made when the OS was new now make it look fatally flawed. AmigaOS does not look that way inclined.

Next month or so Billy Gates will ship Xbox 360 and people will start to download TV shows to their PC and beam them over Wifi to Xbox 360 to display on TV. How long before we see such things with Risc OS ?

Jwoody on 1/11/05 5:02PM [ Reply | Permalink | Report ]

arawnsley:

I used to point people to [link] although its arguments are possibly less compelling than they were 5 or 6 years ago.

Other possibilities are [link] [link]

although I agree that RISC OS could be sold better than by any of these.

richcheng on 1/11/05 6:08PM [ Reply | Permalink | Report ]

One of my problems with a lot of sites is that the desktops they show are often very cluttered or customised, compared to a shipping RISC OS machine. Whilst it may be obvious to those familiar with the OS what everything is, to an outsider it is often another meaningless desktop. Often screenshots have random wallpapers and a mish-mash of (often irrelavent) files open, so it can be rather confusing. Another problem is resolution - if you're going to have lots of windows open, don't do so at 640x480, because it just looks clumsy (RISC OS with its multi-windowed filer/applications is at its best on higher resolution displays).

As an example, even the productsdb.riscos.com images don't use the standard icon set, or standard fonts, or standard applications!

I do appreciate "vanilla" RISC OS can look rather bland. But if you look at shots of other OS's, they tend to focus screenshots on specific things, rather than "general desktop" imagary.

So there's the challenge. Create something eyecatching, yet simple, presenting the best bits of RISC OS, whilst erm, glossing over the rougher edges!

arawnsley on 1/11/05 8:38PM [ Reply | Permalink | Report ]

jwoody does have a point, despite being marked down by the fanboys. AmigaOS had pre-emptive multitasking for years but lacked other useful operating system features. Meanwhile, RISC OS has been plodding along on a microcomputer-era compromise architecture for almost twenty years. Bigging up the RAM disk is like parking a decrepit rusting vehicle next to its modern counterpart and bragging about the furry dice.

guestx on 1/11/05 11:34PM [ Reply | Permalink | Report ]

I think guestx is quite correct, but clearly nobody knows quite what to do about the PMT issue. Maybe Castle could look at Wimp2, and see if it can be made an integral part of the OS. I don't know whether this is a serious option, but I for one would like to hear Castle's (or indeed ROL's) viewpoint on this.

thegman on 2/11/05 8:28AM [ Reply | Permalink | Report ]

I have been using Lua as a scripting language for RISC OS for quite a few years now - one version as a relocatable module, though that was trickier for error-handling. But seriously, Lua is dead easy to integrate into anything written in C or assembler, is tiny, and a lot easier to learn than Perl or, dare I say it, Basic. The shortcomings of Obey file syntax and semantics have been obvious from the days of Arthur.

GavinWraith on 2/11/05 8:35AM [ Reply | Permalink | Report ]

Jwoody: I have a telephone in my pocket that can do lots of things that my RiscPC cannot do. But so what - it's a different product. Microsoft things pretend to be general purpose computers - but they long ago stopped being that with their emphasis on pirating CDs and now DVDs.&c. If you want to compete with what Microsoft choose as their battleground then you will lose. There is plenty of alternative territory on which to place the RISC OS standard. That's what we need to talk about.

NB It doesn't mean that we shouldn't ask ROL for other improvements - just don't do it loudly, in public, to the exclusion of everything else.

jc on 2/11/05 10:21AM [ Reply | Permalink | Report ]

jc: That sounds too much like a "bury the head in the sands" attitude, which won't benefit RISC OS at all. If you can't do something then finding an excuse to dismiss it as unimportant or irrelevent is usually just running away, especially considering that the list Jwoody put up contains several things that are generally accepted as normal for any modern OS. They aren't application-specific bells and whistles.

SimonC on 2/11/05 11:37AM [ Reply | Permalink | Report ]

Looking at Jwoody's list... * Math Acceleration ( read as Floating point ) Not actually a RISC OS issue. If chips with floating point hardware are utilised, this can be used, and has before.

* Virtual Memory You can buy this; admittedly it isn't available 'out of the box'.

* Web browsing Widely known to exist.

I may concede some of the others as desirable, although doing the comparison the other way could also generate a list of equally or perhaps more desirable features.

In my opinion probably the major advantage of RISC OS is that it allows the average user to actually compute, rather than just perform a number of defined tasks.

Loris on 2/11/05 12:06PM [ Reply | Permalink | Report ]

Loris: I would argue that maths acceleration IS a RISC OS issue, when you consider the whole computing platform instead of just the operating system running on that platform, which is what really matters at the end of the day. The lack of fast hardware limits (or makes tedious) tasks that can be done easily elsewhere.

Virtual memory isn't one that bothers me in the slightest, and its existence elswhere is more a sign of memory inefficiency, rather than the existence of a few applications which genuinely need lots of memory.

Web browsing exists, but isn't great. However, it's an area that's constantly improving on RISC OS, thanks to Netsurf, Firefox, and if it ever appears, O3 (I hope).

The major advantage of RISC OS is by and large what it does do it does very well, leaving you to concentrate on putting the effort into the work instead of wrestling with the system.

SimonC on 2/11/05 12:28PM [ Reply | Permalink | Report ]

In reply to SimonC:

I think you mis-understood jc's comment. I don't think he was advocating a 'bury our heads in the sand' attitude but rather we should promote the things that RISC OS is good at while, at the same time, encouraging ROL to develop the things we don't have.

Which is what the discussion thread was debating.

I agree with him that if you try to compete with Microsoft on *their* terms then we will lose. We need to show where RISC OS is different, and indeed better than other Operating Systems.

Col1 on 2/11/05 12:36PM [ Reply | Permalink | Report ]

The point with Virtual Memory is that the current system requires each app that needs it to reinvent the wheel. It should be an OS managed system. No 'if's or 'but's. As for browsing, I binned Browse a lot of years ago because a lot of sites needed javascript. Nice as Netsurf is, it doesn't do js. Perhaps someone can comment on O2 but I wouldn't be surprised if it struggles to render a lot of sites correctly these days. I think in general there is a lot of the 'make do' approach on RISC OS because it doesn't have the features to provide a high quality experience. HTML email viewing is another good example of this. -- Sprite

Spriteman on 2/11/05 12:50PM [ Reply | Permalink | Report ]

Spriteman: How many apps actually need virtual memory, though? There aren't that many that are that memory hungry on RISC OS, so I don't think it's a big problem.

You're right that the browsing situation isn't great, but it's constantly improving. O2 makes a mess of rendering a lot of sites, but it does, as you say, "make do". I agree that's not ideal, but as long as things look like improving I'm happy enough with "make do".

The lack of HTML email viewing (other than by dropping the HTML into a browser) has to be one of RISC OS's strong points. HTML emails should be buried at a crossroads with stakes through their hearts.

Col1: Fair enough, up to a point, and it's clear that I'm guilty of the negative highlighting that is under criticism here.

SimonC on 2/11/05 1:15PM [ Reply | Permalink | Report ]

SimonC: "That sounds too much like a 'bury the head in the sands' attitude, which won't benefit RISC OS at all." It might have sounded like that (but it would be wrong) if I hadn't added the NB at the end. Advertising the good of a product does not mean that you must ignore improvements that are required. The RISC OS problem is that we constantly, loudly, and publicly apologise for its inadequacies. That's stupid.

jc on 2/11/05 1:54PM [ Reply | Permalink | Report ]

Virtual Memory

Will become more of a issue as applications like Firefox get ported. The problem with putting it in an application is that its not very elegant to say the least. What does Risc OS do when it gets a page fault, pass control over to another task. I suspect not it will wait for the disk. 10-20 msecs that a lot of processing could be done by. 5 - 10 per second and thats a lot of processing going to waste.

Also as applications get bigger there is the issue of Wimp_Slot. The whole Wimp Slot has to be swapped when a task switch happens. Which for large wimp slots is a problem and wasteful if the other tasks are not going to do much, such as a null poll.

Sure shared libraries in modules helps but that then leads to other problems.

These sort of things are not problems with the OS has Virtual Memory and proper tasking

Jwoody on 2/11/05 2:42PM [ Reply | Permalink | Report ]

There are a lot of problems with Riscos .But the first and foremost in my book is the Archaic way of selling soft and hardware.Take for example APDL. I want the Technodream/Nevyron compilation but don't seem to find any indication for paying with paypal or any other online paying method why do these riscos companies don't addapt to modern eshopping standards? Riscos ltd is one of the worst offenders how can see how much it will cost me to add Adjust to my A7000? I'm a student who has to pay everthing for himself . It would be much easier if everything was clearly indicated.

highlandcattle on 2/11/05 2:44PM [ Reply | Permalink | Report ]

Jwoody: On newer versions of RISC OS, parts of the wimpslot are only paged in as necessary, not the whole area (what seems to be called 'lazy task swapping') so things aren't as bad as you claim. Regarding virtual memory, I've yet to fill my 512Mb of RAM with anything sensible, so I'm in no hurry for it. I would much rather see problems like file size limits in Fileswitch and image file systems resolved first.

jamesp on 2/11/05 3:20PM [ Reply | Permalink | Report ]

DivX MPEG4

One of the things AmigaOS was supporting is DivX and MPEG 4. Just in case you don't know what DivX is you take a DVD and compress its contents down to one or two CD's depending if you will accept a small amount of loss of quality or not. To make DivX a reasonable proposition one is going to need Math Acceleration ( read as Floating point ), Pre-emtive Multitasking, Virtual Memory. Its fine saying RiscOS does not have any/many heavy applications, but the world of computing moves on a lot faster than the set of Risc OS developers can keep up.

Jwoody on 2/11/05 3:25PM [ Reply | Permalink | Report ]

In reply to jwoody: you are wrong about swapping the entire wimpslot, we've had lazy taskswapping since RO4 to get round that. But you've touched upon the real issue with paging. Its absolutely pointless considering pre-emption or vitual memory in isolation, by themselves they are of very little benefit and you would end up with a system with the resonsiveness and stability of Windows 95. The only sensible way to implement such things is to start with a proper multi-threaded kernel with overlapped I/O - so both application pre-emption and threading are supported, VM paging allows switching to another task/thread rather than stalling. This of course means re-writing almost all of the operating system.

Then of course you have RISC OS applications, which are fundementally tied to the sequential message architure of the window manager, and just will not function correctly in a pre-emptive environment unless the main message thread blocks to wait for responses from all applications - reducing system to co-operative multitasking for most of the critical interactions. Threading support would allow background operations to continue - but this is possible at the moment. To gain full benefit from PMT a new asynchronus system of message passing would have to be developed and applications would have to be re-written to support it, and to also remove the vast number of assumptions of they make about thier effective single tasking operations between wimp polls.

So to gain any realy benefit, and not some hideous lash up that only gives PMT or VM as hollow tick list features demanded by those who don't really understand them, a vast amount of OS and application code has to be re-written - whos going to do it? Who can be bothered, it really isn't worth, you might as well start again with an OS which supports this from the ground up and has other advantages such as a security model, more device drivers etc - i.e. not RISC OS.

Therefor I think its a total waste of time discussing any of it, RISC OS is always going to remain CMT - which isn't in itself a fundemental obstacle to implementing any type of software or providing a seemless illusion of multi-tasking to the user. So you might as well make the most of it or go elsewhere.

druck on 2/11/05 3:32PM [ Reply | Permalink | Report ]

druck: "So you might as well make the most of it or go elsewhere."

Indeed. What you've said does much to make the point that bringing RISC OS right up to date is not a viable activity (where virtual memory and pre-emptive multitasking are more than "tick list features"). One alternative is to run RISC OS applications in other environments (either system emulators or lightweight virtual machines), but then one has to ask how interesting it really is to deploy aging, often abandoned software alongside its contemporary rivals.

Some RISC OS applications were great, but going elsewhere, unlocking the proprietary formats and taking the important stuff with you (all that document data) is a pragmatic approach that shouldn't be underrated.

guestx on 2/11/05 3:53PM [ Reply | Permalink | Report ]

If you really want virtual memory on RISC OS, you want <a href="[link]">Virtualise</a>. Read this link for the state of play, and let that be the end of it.

Regarding floating point, don't think I don't agree it is desirable. RISC OS Ltd and Castle presumably do as well. But it is out of their hands, as they don't make the chips. It isn't a software (ie operating system) issue.

The odd wasted cycle when accessing disk doesn't bother me on RISC OS, because it hardly ever happens at productivity-limiting points (ie at random). If I mouse over to save and click then maybe that takes a second or something - but that is 1) not a point where I'd be doing something else, or 2) basically hidden from me, perhaps because RISC OS seems to be capable of queuing further input (whereas Windows often doesn't). The use of cooperative rather than pre-emptive multitasking doesn't really concern me for another related reason. It is true that some intensive processes can take over the machine for a while. But usually in apps this is because it is something you want to happen as fast as possible. Pre-emptive behaviour would just slow getting the result down. It is noticable in Windows that the time that pre-emptive multitasking would be useful - when loading an app or fetching from virtual memory - the benefit is actually negated due to GUI design. Working on A, decide to load up B. Cannot then go back to work on A because B keeps popping up windows in front with the input focus!

Loris on 2/11/05 3:58PM [ Reply | Permalink | Report ]

druck: Would the wimp message system not just extend in the obvious way - a task would send a message which would be queued by a task and returned to it by the poll. If one of these tasks doesn't respond before it next calls wimp_poll (regardless of whether context switches occur), then it is passed onto the next task and so on until one responds or there are no more and a bounce is sent to the original sender. Even if older tasks were blocked while their message are passed around, ones written for a newer wimp could be treated with more intelligence and the older tasks blocking is no worse than the current behaviour anyway but with the advantage that unrelated tasks would continue to be responsive.

jamesp on 2/11/05 4:01PM [ Reply | Permalink | Report ]

In reply to jamesp: If you implement queuing of message for each application and stall the sender until a reply is received, you run a very big risk of creating race conditions and deadlocks. You certainly would not be able to allow a second message to be sent until the first had been completed, therefor just delaying the onset of effective CMT. In RISC OS here is only a limited amount of independent forground activity which can be handled by applications before an interprocesses messaging event occurs and risks being stalled by any applications which are unresponsive.

druck on 02/11/05 4:49PM [ Reply | Permalink | Report ]

druck: Fair point, the sender can't block. Though with the current system, is there anything to stop a task handling two data save operations simultaneously (other than Wimp$Scrap issues) if it fires off the messages to initialise them without calling wimp poll between?

jamesp on 02/11/05 5:52PM [ Reply | Permalink | Report ]

I also wonder how other systems that did the CMT to PMT move handled these problems. -- Sprite

Spriteman on 02/11/05 8:26PM [ Reply | Permalink | Report ]

I *think* both MacOS and Windows did it via a form of emulation, 16 bit Win 3.x applications running on Win95 onwards for example.

Gulli on 03/11/05 01:45AM [ Reply | Permalink | Report ]

On Windows 95, 16 bit windows apps still still run CMT and can easily take out the system.

Wouldn't a way forward be to use something like wimp2 to create a PMT environment, so new software could be written to use it. (This environment acting as one CMT task). A future version of RO could be PMT and have a CMT environment (maybe even as an option) for old software.

I notice a distinct lack of obviously available new Amiga hardware. Shouldn't Mac or XBox 360 versions be possible?

jess on 03/11/05 07:39AM [ Reply | Permalink | Report ]

The PMT system I'm using at the moment freezes every now and then (15 seconds dead as a dodo as the VM system moves things around) as well as grinding to a near halt when certain applications run (especially over the network). In other words no different from CMT. I am suspicious that the PMT advocates are so for theoretical rather than practical reasons. A lean CMT system with good memory protection and well written applications will perform just as well as, and probably better than, a bloated PC PMT system.

As Dave has already pointed out rewriting RiscOS is non starter so the argument is pointless and done to death several times before. Instead we should work towards improving what we have e.g. better memory protection, multimedia handling, a single OS fork etc

mripley on 03/11/05 08:55AM [ Reply | Permalink | Report ]

I agree with mripley. Now RISC OS is relatively good, that is, there are apps that do their work very good (ex. ArtWorks). The biggest problem that I see with RO HW and SW is the lack of floating point HW. I know that we have a FP emulator, and thanks to Mech on my RPC it doubles the old FP performance, but let's see: there are a number of project that were slowed down or aborted due to the lack of FP (F16 flight emu and Iron Dignity, MP3 encoding or DivX decoding are examples of that). Programmers are forced to reinvent the wheel (integer arithmethic) every time a ported app was done on platforms that have native HW FP support (WIN and Linux for X86 for example). I wonder if some type of FP HW could be made to settle in the 2nd processor slot of a RPC for example. I know it's old HW, but on an IYONIX I don't see how this could be implemented. Maybe piggybacking a new processor board on top of the old? (on some older platforms this could be, and was, done).

bernie on 03/11/05 10:01AM [ Reply | Permalink | Report ]

In reply to Malcolm: spot on.

In reply to James: Its possible to have multiple messages in flight between two tasks, but most applications will asume that the first datasave has been abandoned if they receive another one with a different session id.

In reply to Stefano: It was possible to use an external maths co-processor with older processors such as the ARM2,3 and 7, and WSS even managed to get some useful gains from farming out FP from an ARM7 to the x86 second processor. However with faster processors the overhead of synchronisation and data transfer via shared memory (especially as the StrongARM and later lack cache snooping) far exceeds any benefit from an external accelarator. The FP unit needs to be on chip taking instructions from the main pipeline and gaining direct access to the data cache.

As more sophisticated audio and video codecs come in to use, mobile and embedded processors are increasingly gaining FP support. Many recent ARM cores now have integrated Vector Floating Point co-processors. These only work single precsision and not compatible with the old ARM FP instruction set, but given a suitably adpated FPem module, would give significant benefits for some code.

druck on 03/11/05 10:32AM [ Reply | Permalink | Report ]

The main thing about RISC OS is the lack of up to date software.

Perhaps a port of something like Pixel for image manipulation.

I actually aproached the owners of metacard but Rod said that the platform was too small for them. etc etc.

RiscOs has some good apps, but some are not up to it these days. Also for science there are a lot of good java apps. Eg ImageJ. Rather than addressing programmer techie things, the platform just needs software that is comapatable with the big wide world.

cheers bob

nijinsky on 03/11/05 12:10AM [ Reply | Permalink | Report ]

druck: I think VFP is both single and double precision (ARM say so on their website), however I am not sure what exactly is implemented in hardware and what in software.

hubersn on 03/11/05 1:06PM [ Reply | Permalink | Report ]

Bob: "programmer techie things" - whatever you think that means - is _precisely_ what RISC OS needs. It's all very well waving your hands and insisting that RISC OS gets certain software, but the at bottom line remains three issues: long term apathy from many users, lack of financial support, and finally addressing the often very hard technical issues that must be resolved before we can even think about bringing new software to RISC OS. i.e, the "programmer techie things".

mrchocky on 03/11/05 2:59PM [ Reply | Permalink | Report ]

In reply to Peter: If say you have a team of 10 programmers who can re-write RISC OS to support PMT and another 10 to modify all the major applications to use it, and they can do all this in the totally unrealistic time of a year, what does the user see at the end of it? - The hourglass appearing slightly less frequently.

However if you take that team of 20 engineers and set them to writing applications to takle the areas where RISC OS is lacking, they may take slighly longer due to the lack true PMT, but at the end of the year you will have a number of new programs that will benefit users far more than any tick against PMT in the list of OS features in a RISC OS vs Amiga OS news article.

Your stirling work is the perfect example of this. If you'd decided to work for ROL or Castle and bring PMT to RISC OS, no doubt you'd still be there toiling away with the many difficulties. But instead you've brought dozens of new programs including FireFox to the platform, despite the lack of OS features which may have made the process easier. I think everyone appreciates you've acheived at lot more this way.

druck on 03/11/05 4:05PM [ Reply | Permalink | Report ]

Why are you patronising me? I never mentioned PMT, nor any other specific issues - OS or application level. Please read what I actually said, rather than making up things. FWIW, PMT is a very hard issue, and doesn't directly help in many cases.

mrchocky on 03/11/05 4:21PM [ Reply | Permalink | Report ]

It looks more like praising than patronising to me.

SimonC on 03/11/05 9:36PM [ Reply | Permalink | Report ]

Peter you really need to take something for that attitude of yours. I have read many many discussions both here and and on CSA and Dave has defended you to the hilt (or have you forgotten?). Personally I think you are technically talented but your people skills are abysmal.

mripley on 03/11/05 10:57PM [ Reply | Permalink | Report ]

nijinsky: Trouble is that lack of "programmer techie things" is actually a big factor in the current lack of up-to-date software. When programmers get used to having tools and support* for what they do, it can be quite difficult to convince one self that the extra work of doing without these things is really worth it. Worse yet - is the extra development costs worth it? Unfortunately for RISC OS application development you can hardly expect any extra work required being financially "worth it". It will always come down to commitment to the platform and sometimes that simply isn't enough.

* I'm not referring to support as in people patting you on the back and/or giving you money for what you do but to support provided by e.g. the operating system.

Gulli on 04/11/05 12:15AM [ Reply | Permalink | Report ]

Part of the problem, I think, is that different people draw the line in different places. To some people, GCCSDK is a vital set of basic applications; to others, it's a "programmer techie thing" that they'll never have any use for. The trick is to explain to the latter that good compilers are a necessary prerequisite for up-to-date web-browsers.

The other thing that isn't always explained clearly enough is the benefit of some "invisible" changes to the end user; people can usually understand bug-fixes and speed increases, but "RISC OS is bug-free and super-fast anyway, isn't it?"

I've certainly met people to whom DHCP was a pointless "programmer techie thing" because no-one had explained to them that it's now basically essential for any machine that's going to be connected to a workplace network, or a broadband internet connection. Yes, you can do both without DHCP - but it requires much more knowledge, and most people expect to have a machine that "just works". RISC OS "just works" amazingly well for a lot of things, but fixing the gaps is important, and usually requires "programmer techie things" to be done before relevant applications can be written

chrisj on 04/11/05 1:59PM [ Reply | Permalink | Report ]

mripley: there is no attitude here, apart from the one which you're expecting to read into what I said because I happened to refute a number of points. If Dave or anyone else wishes to respond to what I said, then they need to do that, not make up things from not reading my comments carefully.

chrisj: that might be true in certain instances, but in the case of my work, what I've been doing has been explained very carefully indeed. But often people simply aren't interested in understanding, no matter how carefully or exciting you make the explanations, and there are also plenty of unfortunate cases of head in the sand, where individuals would not make any effort despite trying to have strong views about matters.

What I repeated to the point of exhaustion is that I _didn't_ do a port of Firefox. What I did was a 3 year marathon of improving a whole host of tools, toolchains, libraries, applications as well as coordinating releases, subscriptions - and all ultimately at significant finanical loss. All this work was crucial, or the results would have been impossible, which is why druck's reasoning is at least in part, faulty, and what Bob has said is quite naive.

mrchocky on 04/11/05 2:54PM [ Reply | Permalink | Report ]

in reply to peter.

In your opinion, what I said was naive. Perhaps you don't understand what I was saying from the end users point of view.

As for your 3 year marathon, I'm not going to patronise you by saying whether I appreciate it or not.

:-)

in reply to anyone. :-)

In general I understand that RISC OS (I hope that is the correct way to spell it) requires updating, however, it seems to me that the emphasis these days is wrong IMHO. It is either on things that the end user may not actually use (but the techies may really need) rather than more software that the new user may need before they are tempted into buying a modern machine.

I really dont understand how the tools that were available to make apps like Impresion, ovationpro, etc require updating to make modern-style software.

Regards Bob

nijinsky on 04/11/05 4:26PM [ Reply | Permalink | Report ]

Bob: I understand the issue painfully well, as I've demonstrated.

What's required to be updated depends exactly on what people want, but in many instances, it's not the OS itself, although there are plenty of things it could do with. Rather, it's tools, libraries, applications and other paraphernalia, especially when we're talking about OSS.

As I just explained, and others have explained, the emphasis is precisely correct. Without these crucial improvements, the apps that you so crave are impossible.

"I don't understand how the tools ... [for] Impression, Ov Pro ... require updating". Some of these programs were originally developed using considerable amounts of assembler/Basic, for a commerically viable market with lots of available programmer resourses. Neither of these things is true any more for RISC OS, nor are these the sorts of apps that users are asking for. They're after headline OSS apps or technologies such as VoIP, and other items that must be ported from other system or based upon existing systems, using minimal effort. The precise reasoning as to why lots of things must be updated is quite complex, and I won't go into it, but it is nevertheless the case; although in a nutshell we can say that traditional RISC OS tools are only suitable in many cases for small scale hobbyist development.

mrchocky on 04/11/05 4:44PM [ Reply | Permalink | Report ]

Bob:

You say that too much time is spent on stuff that only techies use, rather than tools for the end user.

But end users *do* use this "techie stuff". They just don't realise they're using it, because they don't understand what it is, or because they are using it indirectly.

As Chocky points out with his Firefox example, the techie stuff is *required* for the end user applications to be written.

richcheng on 04/11/05 5:48PM [ Reply | Permalink | Report ]

[link]

MWS on 05/11/05 00:02AM [ Reply | Permalink | Report ]

nijinsky: "I really dont understand how the tools that were available to make apps like Impresion, ovationpro, etc require updating to make modern-style software."

Which really shows that you seem to have absolutely no knowledge of modern software development. One of the main reasons mentioned that development stopped on Impression was the lack of a modern development tool - a "programmer techie thing". Without the tools - the programmers will not develop applications - it's as simple as that.

While developing applications in ARM assembler was "cool" and generally accepted in 1990 - that is not the case today. For development and maintainance to be viable a higher level language is needed for shorter development cycles and easier maintainance which in turn means more applications and more frequent updates - if the tools are not available the programmers will simply go where the tools are available. Same applies to other "programmer techie things" that are taken for granted on most systems - if they're not available for the OS, people will stop bother programming for it and move somewhere where you don't have to reinvent the wheel several times a week.

You can theoratically plough a 20 acre land with a pitchfork, but given a choice of the pitchfork and a modern tractor with all necessary appliances most people would go for the tractor any time.

Gulli on 05/11/05 00:24AM [ Reply | Permalink | Report ]

hmm, that "theoratically" wasn't supposed to be in there - move to strike!

Gulli on 05/11/05 00:46AM [ Reply | Permalink | Report ]

IN reply to Gulli. "Which really shows that you seem to have absolutely no knowledge of modern software development. "

That may be the case. I'm only writing simple windows, mac and linux software, like a cross platform database RAD.

Perhaps impression was not the best example. What I'm really trying to say is this; I appreciate that tools are required for software development, however, IMHO and that is all it is, MHO, more focus is needed on end user apps. Is it really as dificult as some suggest to write apps for RISC OS without "new" tools. IE is there nothing there at present? I think there may be.

Anyway, since I know absolutely nothing about software development (I normally leave that to my 4 software developers), I'l leave it at that.

Cheers Bob

nijinsky on 05/11/05 11:23AM [ Reply | Permalink | Report ]

Bob:

"I'm only writing simple windows, mac and linux software, like a cross platform database RAD. "

Now ask your development team to do it using only ten-year-old tools. You'll find that they go off and work for someone else after a few weeks. End user apps (like Firefox) are appearing - but they're only appearing because someone has spent a lot of time dealing with all the technical stuff that's needed first. It's like viewfinder for the RPC - just writing software that listed modes the VIDC can't handle wouldn't be any use; first, John Kortink had to design (and build) the physical interface, write a driver for it, capture and reroute the VIDC SWIs....

Peter: I should have said that the third part of the problem is that people don't always read the explanations; also of course that something that's crystal-clear to one person can make no sense at all to someone else because they think differently. (I once had a long argument with Tony Houghton where it eventually turned out that we agreed with each other entirely - we were just using the same words to mean different things.)

chrisj on 05/11/05 11:48AM [ Reply | Permalink | Report ]

chrisj: Sadly, Bob seems to be a case in point. He's still insisting that the "focus needs to be on apps", despite several lengthy explanations saying why that is impossible without other work. It is very frustrating when someone who does not have the requisite knowledge insists tooth and nail that something ought be done another way.

Of course, this is all a bit academic, and perhaps if a concrete example were considered, a case study could be put together to determine what work would have to be done.

mrchocky on 05/11/05 3:36PM [ Reply | Permalink | Report ]

In reply to Bob, Peter and Chrisj and the many others:

I am no programmer, but reading through the comments here, I think I can see both points of view, and agree with both of them. However please feel free to correct.

Bob and many other people, llike myself would llike to seem more up-to-date software released that give us, the users, similar opportunities to use our RISC OS computer in the way other users are able to use Linux, Windows and Max OSX(is that what's called these days?). However all we seem to hear about is the "under the hood" things that get done, and developers complaining about the lack of development tools or necessary bits and pieces in the operating system. But I suppose what is annoying is that we had great apps developped 10 years or more ago with similar tools ("so what is the problem with the development tools?").

But then these days wih the wealth of development tools available on other platforms that make life so much easier for the development of big apps, I can also understand why the programmers moan at the lack of such tools for development on RISC OS.

So, the reason we need all the "techi stuff" is to make the development of and maintenance of software quicker and easier. But the problem with such a small platform is there is only so much that developers such as Peter can do at any one time. Which for us end users is frustrating. But in the long term will make programming for RISC OS a much more pleasurable experience for the remaining developers.

sa110 on 05/11/05 9:07PM [ Reply | Permalink | Report ]

sa110: No, what you're mentioning is really a side issue, and there is only one correct view here, which has already been repeated a dozen times: Development of modern applications and systems which RISC OS users want _requires_ (not, "makes easier") extensive background development of libraries, tools and other technologies, whether in the OS or elsewhere. There is no avoiding this issue, and trying to reword it will not make it go away.

mrchocky on 06/11/05 12:31AM [ Reply | Permalink | Report ]

Paul:

Basically, yes. In particular, the shrinking of the platform is a problem - ten years ago, it was worth David Pilling spending a couple of years developing a new DTP package (Ovation Pro) from scratch, because the return at the end of that time would repay him for two years not doing anything else. Charles Moir could afford to pay a team of people to work non-stop on Impression and Artworks... Now? Martin W. does superb work, but I don't think he makes enough money from Artworks 2.x to pay half-a-dozen other people to work on it with him.

Actually, a good example has just occurred to me; consider games. Twenty years ago, BBC games were often state-of-the-art (despite being written by one person in their spare time at college

. Move on to 1998; RISC OS gets HOMM2 (a good conversion of a then 3-year old DOS game), Wizard Apprentice (a cute platformer) and Destiny (an imperfect but under-rated 1st-person shooter). What about PC releases of 1998? They include Starcraft, Quake 2, Diablo, Riven (the sequel to Myst), Unreal and Age of Empires.

TEK is a nice little strategy game, but doesn't have the polish of AoE or Starcraft. Rob Templeman spent several years pulling off a near-miracle in making Destiny run playably fast on a RPC (and never got the credit I felt he deserved for his dedication and coding), but the game could have been much improved if there'd been a team of a dozen or so suitable people to work full-time on level design, music and graphics.

Flip forwards to today. One man working in a cupboard after work is never going to produce Doom 3, or Return to Wolfenstein, or GTA: San Andreas. But someone who writes a really fast 3D plotting engine with a good simple API (or ports and optimises an open-source one) is, in the long run, doing RISC OS gaming more good than someone who spends the same amount of time producing a half-baked, slow and clunky 3D game. A timeline would probably be helpful here:

Year Programmer 1 Programmer 2 1 creates 3D library starts writing game 1 2 optimises library completes game 1 3 writes game 1* starts writing game 2 4 writes game 2* completes game 2 5 writes game 3* starts writing game 3 6 writes game 4* completes game 3

* Of course, if the library is publically available, other people can write games using it as well; in which case by the end of year six you might have eight (or more) 3D games by this method, instead of three from programmer 2....

Because P1 has started by creating a set of useful tools, he takes longer to do anything that the non-programming public notices. But in the end, he gets more done. And he makes it much easier for other people to do things - imagine a "Programmer A", who is working separately but never finishes anything: he starts work in year three, writing his own game. With P1 around, he takes the existing 3D engine, and writes half a game to go with it, which he then abandons into the public domain. With P2 instead of P1, "A" writes... half a 3D graphics engine, which he then abandons into the public domain. Programmers B,C and D are much the same. So in the P1 scenario, we now have several half-finished games; in the P2 case, there are several half-finished 3D graphics libraries. The former are obviously much more likely to reach a state where the non-programming public get to play something....

[Phew, that was long - maybe I should have offered it as an article, rather than a comment ;-)

]

chrisj on 06/11/05 1:17PM [ Reply | Permalink | Report ]

Lets try that table again; I hadn't realised it would strip all the spacing out!

Yr ! Programmer 1 ! ! ! Programmer 2 1 ! creates 3D library ! starts writing game 1 2 ! optimises library ! ! completes game 1 3 ! writes game 1* ! ! starts writing game 2 4 ! writes game 2* ! ! completes game 2 5 ! writes game 3* ! ! starts writing game 3 6 ! writes game 4* ! ! completes game 3

chrisj on 06/11/05 1:20PM [ Reply | Permalink | Report ]

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

Create a new account
Forgot your password?

Search this website

This week's poll

Recent developments have left me feeling...

Assured ROS will appear on new hardware		55%
Pleased OS desktop features are being developed		10%
ROL and ROOL will eventually kiss and make up		5%
App developments are critical		10%
Dave Holden sleeps easy at night		19%

Discuss this | Archives