RISCOS Ltd. 'adapting to change' | Drobe.co.uk archives

RISCOS Ltd. 'adapting to change'

By Chris Williams. Published: 24th Nov 2003, 19:36:27 | Permalink | Printable

Select 4 future, politics and a fresh direction

RISCOS Ltd.'s managing director Paul Middleton has this month told Foundation readers that his company will continue by "adapting to change and seizing new opportunities as quickly as possible". As well as sketching out a RISC OS 4 road map, Paul also revealed some as yet surprisingly unreported facts.

Leafing through the lengthy briefing, we're told RISCOS Ltd. decided not to fully purchase RISC OS from Pace because they figured they had already paid for an exclusive licence for the desktop market. Also, their September AGM reportedly went down a treat due to the absence of "negative attitudes that have been prevalent at previous years' events, when certain shareholders had sought to try to gain control of RISCOS Ltd."

Also, ROL's mission statement has evolved somewhat and now pledges to provide "a continued availability and route to market for the 26-bit version of RISC OS". Additionally, the Cardiff based company are hunting for new RISC OS 4 licencees and are aiming to support new hardware where possible. ROL's original mission statement and specifically that final clause, has in the past caused a mild storm amongst users as the OS developers have stuck with the 26-bit stream with no sign of a 32-bit RISC OS 4, for now.

In their defence, RISCOS Ltd. have blamed lack of any firm commitment from their licencees that would warrant the uphill task of developing a 32 bit RISC OS 4. Paul did admit though that, "such work would have to be undertaken at some point in the future."

Select future, RISC OS 5 flirting
Turning to RISC OS Select, RISCOS Ltd.'s plans for S4 include:

Possibly, a replacement for ADFS, in the wake of larger and larger harddiscs
Support for graphics cards
Disc partitioning support
Improvements to BASIC to bring Select's BASIC in line with RISC OS 5's. Nothing like playing catch up in a market this small
One for VirtualAcorn users only: support for up to 16MB VRAM
A new Filer which will include keyboard shortcuts

RISCOS Ltd. are currently in the "final stages of developing a new RISC OS 4 ROM set featuring the major new features from Select". The new ROM set will include DHCP networking and CD boot support. RISC OS 3.x users will be expected to pay 140 quid for a set, and from there the price scales down (depending on your installed version of RISC OS) to 75 quid for "long-time [Select] subscribers".

"Whilst the merging of Select and RISC OS 5 is desirable, it is also a lot of work", Paul told the Foundation readership, writing on the touchy subject of Select and Castle's RISC OS 5.

"Many of the Select features rely on changes to the kernel and the RISC OS 5 kernel is significantly different to the RISC OS 4 version. It is, however, our intention to make as many Select features as possible available for RISC OS 5 users."

"I have to admit to feeling a bit disappointed by some of the comments made", John Peachy wrote in his report on the RISCOS Ltd. presentation at the South East 2003 show, in this month's Archive magazine. Paul's Foundation newsletter echoes what was said in Guildford, as the presentation also covered topics like the future of Select and RISC OS 5.

"It seems we've moved away from the 'let's all pull together' point of view and goe back to 'they can do what they want, we will do what we want', which will be to the detriment of us, the users. I do feel at present that Select is heading up a cul-de-sac, but I hope I'm proved wrong."

RISCOS Ltd. also have other products on the cards: An illustrated Select guidebook, a printed version of the Foundation RISC User CD articles, the RISC OS 4 PRM CD and a "RISC OS updates CD". No RON, then.

Emulation under fire
In Paul's newsletter, there's no mention of RISCOS Ltd's involvement in the recent RISC OS emulation revolution although this month has been a month of whispers regarding the legal standing of RISCOS Ltd.'s relationship with VirtualRiscPC-SE.

Castle logo

We've learnt that at a RONWUG usergroup meeting earlier this month, Castle's John Ballance suggested that RISCOS Ltd. were "outside their licence" - according to Stuart Tyrrell of STD, presumably referring to RISCOS Ltd.'s licence to develop and sell RISC OS 4.

"At the [RONWUG] meeting on Monday, we were told that RISCOS Ltd. were possibly outside their license with regards to VRPC and some other IPR issues, and that me paying my UKP80 or so for each A6 I ship to RISCOS Ltd. was somehow robbing the RISC OS market of development cash", Stuart reported in a humble iconbar.com forum. A source present at the meeting later confirmed to us what Stuart had said in his online outcry and added John was "very candid".

"RISCOS Ltd is quite happy with its licensing of RISC OS, and that its handling of all IPR issues has been done with the full approval of Element 14 and Pace Micro Technology", Paul Middleton of RISCOS Ltd. assured us last week when we made a few enquiries.

Both Castle and STD, however, have so far declined to comment on what exactly John was stirring, sorry, referring to. Also, no roadmap or feature list for the next release of RISC OS 5 has been made public, although we've heard it'll be ready "soon" and at least include suitable bugfixes.

Links

RISCOS Ltd. website

Previous: Custom Cases, The Third
Next: Welcome guides for Iyonix users

Discussion

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

So Select 4 will include - via software - yet another thing that's already present in hardware on my Iyonix? Ho hum.

I missed both the RONWUG meeting mentioned in the article, and Stuart's own presentation at RONWUG last Wednesday. Can your source (or Stuart) confirm if Stuart repeated his "outcry" during his own presentation?

dgs (Select subscriber since the start, and contributor to some of RISCOS Ltd's "other products")

dgs on 24/11/03 9:14PM
[ Reply | Permalink | Report ]

A new ADFS? ADFS is commonly said where FileCore was meant. So are we talking a new IDE hard disc driver, or a new file system module? I've often pondered the possibility of providing a modern file system in a package that exposes a FileCore-like API before now. Could be interesting. Anybody want to wrap XFS as a RISC OS module? ;-)

(Which of course, won't work, 'cause XFS is multithreaded...)

nunfetishist on 24/11/03 9:17PM
[ Reply | Permalink | Report ]

Is there a discount for those (like me) who have reprogrammable chips that RISCOS Ltd sent out in the early days? 75 pounds seems steep for media, though I only have vague ideas how much the media and labour are worth.

Keyboards shortcuts in the filer would be a welcome addition. I've played with third party utils that add this, but every new version of RISC OS broke them.

ksattic on 24/11/03 10:04PM
[ Reply | Permalink | Report ]

I am so disappointed by the RISC OS Ltd "vision". A new Filer and a new filing system - I'm with John in Archive. The Filer is fine and ADFS/FileCore (as present in RO5) are fine too. As for RO Ltd doing a 32-bit RISC OS: let me be the first to say it - it's been done guys.

RO Ltd need to concentrate on value added for the OS. They need to broaden and sustain the OS, not mess with the bits that are already there and working (witness all that time spent restructuring the kernel, that helped the users not one bit IMHO).

We need to look to some of the things that are missing from RO. Of course, these have the disadvantage of being hard but they might just encourage some more sales. Things like modern video support; we may not be able to licence Quicktime but surely there are some modern CODECs that could be bolted into Replay. Similar comments apply to sound and graphics support (the Select graphics support is a much more encouraging idea). And up-to-date Flash support...

Some of these things are available as 3rd party bolt-ons but a consolidated RO update including them all (and it would be trivial to do these things in 26/32-bit neutral form for RO 4 and 5) would give us a welcome leg-up into the 21st century. I also suspect that some of these could be ported from the Linux world (there are precedents...).

And just to criticise everyone while I'm at it, I wish Castle would use their undoubted influence to start RO Ltd down a less duplicative (is that a real word?) path.

I've never subscribed to Select because it's just never seemed to be substantial enough - please guys, prove me wrong!

Tony

TonyStill on 24/11/03 10:05PM
[ Reply | Permalink | Report ]

Gosh I'm wound up about this.

What we need is for RO Ltd to swallow their pride and licence RO5 from Castle (presumably by paying them a few Pounds for every copy shipped). Then they'd have their 32-bit OS.

Then they could do RON for a nice SA or XScale powered computer that's currently crippled by running Windows CE. How's that for an exciting vision?

Tony again

TonyStill on 24/11/03 10:12PM
[ Reply | Permalink | Report ]

Personally, reading from the article, i still think the licensing of RISC OS seems a bit messy.

Wasn't it said that Castle now own RISC OS? If so, why do ROL have to check with Element 14 and Pace check if they are still within the terms of their contract when doing the VRPC deal?

As to the up and coming select 4. I look forward to installing it on my RPC when available. The filer short cuts will be very useful (one of the things I miss from windows). Not quite sure how useful a new ADFS will be in existing RPC/A7000 based hardware. Perhaps the Omega(illusive) will be able to fully use it.

As for ROL licensing RO5, interesting idea, but why would be people buy it from them when they can buy it from Castle? The only advantage would be they would have the source code to be able to sell updates, but I rekon it probably wouldn't be financially viable.

Would be nice if they could update Replay with some modern codecs, but anything decent will probably cost money to license, and again may not be financially viable.

Now that they are aiming to support new hardware, where possible, perhaps the the Riscstation Evolution might be brought back to life, or is that another concept model consigned to the bin?

sa110 on 24/11/03 10:38PM
[ Reply | Permalink | Report ]

Are there any users that don't want the features of Select under RISC OS 5? Is someone not listening to the desktop customers who are willing to pay for this?

Something really does need to be sorted out because I can think of nothing worse that two versions of RISC OS. It's exasperating!

jonix on 24/11/03 11:16PM
[ Reply | Permalink | Report ]

OK, time to play devil's advocate.

NB that ADFS is based upon ATA and possibly ATA-2; not ATA-7, the latest specification for the ATA (formerly IDE) interface. Last major modifications were around RISC OS 2. It also is a component built almost entirely in assembler, and hard-coded to the internal RISC PC controller. Anyone who thinks that hard drives haven't changed since 1989 are, ahem, wrong, and RISC OS hasn't kept up - or even tried to keep up.

A replacement ADFS designed from the ground up would therefore allow you to:

1) Be hardware-independent, adding ATA interfaces as required with minimal code. No need to have new FS and Filer modules for every single additional interface added. 2) Use all the features of a modern hard disc. 3) Write it in C, compile it to be 26/32-bit neutral. 4) Allow easy access for the replacement ADFS or other modules to talk to ATAPI devices (the standard used fcor CD ROM drives and other non-hard disc devices on the ATA bus.) This means you could re-write CDFS to be much less temperamental. Currently CDFS sits around ADFS; it should be sat on top of it, using it to talk to the ATA controller(s) (NB I'm aware that this is more complicated than I've made it due to SCSI...) 5) It wouldn't have the old floppy disc controller and ST506 code from the A410 days, reducing the code size. 6) Allow ATA to be accessed through other buses directly by writing ATA drivers for them. 7) Allow the use of S-ATA drives. 8) Become filesystem-independent. Instead of making ADFS talk only through Filecore, why not make it support disc formats other than Filecore too?

Drew

md0u80c9 on 24/11/03 11:42PM
[ Reply | Permalink | Report ]

The whole ADFS/Filing system thing needs clearing up. The initial comments I saw on it (can't find where now) were particularly confusing, but the only thing I've seen written down from RISCOS Ltd is this from a Foundation article which doesn't give any details.

Initially it looked like they (RISCOS Ltd and Castle) at least wanted to work together somehow, but the recent signs suggest they're both annoyed with the other's reading of licences, which can't be good.

There have been people saying they won't buy Select until it's available for Iyonix, and people saying they won't buy an Iyonix until Select is available for it, so the current situation really can't be helping anyone. One small market has got to be better than two tiny markets surely?

illudium on 24/11/03 11:42PM
[ Reply | Permalink | Report ]

Filer shortcuts? Oh you mean like those provided by !QuickFiler [link] Even works in RISC OS 5.

jmcarey on 24/11/03 11:51PM
[ Reply | Permalink | Report ]

md0u80c9: Why not make FileCore a meta-filing system? ie, you could plug file systems into it, and provide a fs:drive -> file system map. That'd be much more flexible and future-proof.

I'm one for removing the distinction between different hardware completely. Rather than having ADFS::, SCSI::, ATAFS::, IDEFS:: etc paths, just have FS:: or similar, and have drivers for the hardware instead, providing just a block device for you to use whatever you want on top.

nunfetishist on 24/11/03 11:56PM
[ Reply | Permalink | Report ]

Testing from WXL. Mod this down please.

The Doctor on 25/11/03 6:43AM
[ Reply | Permalink | Report ]

sa110: Correct me if I'm wrong, but I think the Omega uses IDEFS and thus supports multiple partitions (like the Blitz card I had in my RiscPC).

jmcarey: Thanks for the link!

ksattic on 25/11/03 6:46AM
[ Reply | Permalink | Report ]

Aha, It works! Now, I do wonder why ROL would produce a 32bit OS at this stage since we seem to be a tad short of hardware manufacturers that would need it. Castle don't. MicroDigital don't and I'd guess that RiscStation aren't planning on anything that would need it either. In addition to that there seem to be no ARM processors /available/ that are /significantly/ faster than that used in the Iyonix anyway so what would be the point?

As far as the updates to ADFS go, I think ROL are wise to start thinking about this now rather than later. This sort of upgrade is not going to appear overnight and it is better that it is ready when the need is there rather than not.

If ROL were to 'swallow their pride and license RO5 from Castle' then they would be throwing away much of the work they've done over the last couple of years and taking a major step backwards in terms of the OS development .

Think that'll do for now though I have much more to say. Cheers!

The Doctor on 25/11/03 6:59AM
[ Reply | Permalink | Report ]

In reply to nunfetishist:

6 years ago I wrote a lot about a similar idea and here is a large extract of that, slightly updated to current technology:

Let us define the following module stack:

FileSwitch Device based filing systems: *Filecore*, DOSFS, CDFS and later DVDFS, NTFS, UNIXFS ;-)

DeviceCore maintaining devices/discs list (HD, CDs, ...) Card modules: IDECard, SCSICard, RapIDEcard,...

So, basically:

- card modules detect the devices connected to them and registers them to DeviceCore with hooks for performing the basic operations for the devices (for example the DiscOp swis for floppies and harddiscs).

- DeviceCore adds the connected devices to the Iconbar and when the device is mounted, it creates a 'disc' object and propose it to each registered Device based filing system until one of them accept its device type and the format of its 'disc' and adds it to its list of managed discs. From now access to that 'disc' is made through that Filing system and routed to the card and device holding the disc.

As you see, its much of the same process than current process but much more logically divided and more flexible. It has the following advantages:

- Each Filing System can be written in total independance from the hardware, which means once written it can be used no matter how you connected your device.

- You can provide DeviceCore with swis to list connected devices (maybe also mounted discs?) which would be usefull for a Find tools, Explorer like programs.

- The Free tool can now access non FileCore based floppies and harddiscs.

- A Verify tool could be defined just as ScanDisc for Windows with access to any connected device (or maybe limited to any sector formatted devices): the physical format of any disc can be checked and with the help of a hook in every Filing System, the integrity of the logical structure of the disc can be checked too.

- The stupid division of 4 Floppies and 4 HardDisc is dropped. It was already not used anymore by the latest versions of ATAFS where my HD as the number 0 and is not found by BlackHole when he try to find a file all 'All Harddiscs'.

- DeviceCore would support by default the following type of discs: floppies, harddiscs, CDs, DVDs and image files, but well designed it could support registration of additionnal device types such as Zip or Syquest drives, tape drivers, maybe even scanners and printers. As I see it Device Types would come as modules registering to DeviceCore the default icon bar icon (filing systems could provide a new icon and text when the disc is mounted) and menu for such devices, providing the logical access methods and describing the physical access methods cards need to provide whe registering such a device.

- If I understand correctly creating partitions on a disc is only a matter of organising the logical structure of a disc. In this case formatting and creating partitions could be provided by another tool accessing DeviceCore.

So, the main work to be done is DeviceCore and: - a bit of reorganisation to split FileCore into the FS itself (renamed), and the modules FloppyDisc, HardDisc and ImageFile. - the same for CDFS and CDDisc. - taking the revelant parts out of ADFS to create the IDECard module. - the same for SCSIFS.

Now for compatibility, maybe keep a simplified FileCore which will call the modules extracted from it.

Well, that was it.

timber on 25/11/03 7:41AM
[ Reply | Permalink | Report ]

'The Doctor:' It is sad to see all the work done by ROL abandoned, but it is working in a cul-de-sac, and it would be much better for the platform if the ROL developers devoted their talents to the something with a future. That future is 32bit RISC OS 5.

JWCR on 25/11/03 10:11AM
[ Reply | Permalink | Report ]

Does anyone disagree that the ideal situation would be one where we have the best of Select and the best of RO5 in the one OS? No? Well why are the companies involved not working to give the customers what they want

And to address The Doctor's points:

Forget the Mico and the RiscStation and the RiscPC. The future of RISC OS computing is with two machines: The Omega and the Iyonix. True, the Iyonix has a 32bit OS but not as fully featured as Select. The Omega can run Select but is slower and (unless someone can tell me otherwise) unfinished. Of course, another option is to port RISC OS to other ARM devices. This needs a 32bit OS and hardware abstraction (things RO5 offers). But surely we want as many features as possible in the OS if we are going to win over new users? This is why we need Select.

Also, you praise ROL for being forward thinking by starting work on a new ADFS now rather than later. I just can't help thinking it would have been nice if they'd had this attitude towards 32bit, hardware abstraction, PMT, threading, etc, etc, etc. Maybe some think they do and these things aren't important yet.

One last point. I can't think of too many OS-only companies. Apple and Acorn both use/used their hardware sales to part fund their OS development. MS are slightly different in that they use their other products to help sell their OS. To my mind it would be good to see a unified hardware/os producer. Whether this be CTL leading ahead with RO5 or a close partnership between CTL and ROL, I don't mind.

-- Spriteman - Yes, I know ROL has limited resources but it does not follow that they also have limited vision.

Spriteman on 25/11/03 10:18AM
[ Reply | Permalink | Report ]

I agree with spriteman. In addition, I would suspect that Castle believe that Omega is no threat since its incomplete and never will be completed. In which case the hardware future is Iyonix and their retrograde RO5 (NB its mostly only the 32bitness that is more advanced than select not the features). I suspect ROL think that Omega will be finished in which case their OS will work fine on that machine where 32bitness is not necessary. NB it may be desirable, faster etc but it's not necessary. If that happens then ROLtd can convert select to 32bit in a piecemeal fashion with a final kernal change when a significant proportion of current RiscPC users own Omega's.

So I suspect the entrenched attitudes of Castle and ROLtd have a lot to do with their different visions of the hardware future for RISCOS.

BUT THEY HAVE BOTH FORGOTTEN THEIR CUSTOMER BASE!

We the folks who pay their wages via sales are sitting here wondering which way to go. Come on guys Select 5, no licensing between the two of you but shared profits from sales and shared development costs.....

I want a new RISCOS machine but I see no point in spending my money on uncertainty.

regards,

Malcolm

mripley on 25/11/03 11:00AM
[ Reply | Permalink | Report ]

I asked ROL about the ADFS thing at Guildford:

PM said it would 'probably' mean a new FileCore. This would use a Unix or Windows filing system rather than the ailing FileCore format we have now. He also talked about possibly changing the filing systems so that they followed Unix file naming conventions (eg dir/file.txt) to help porting software. Regarding ADFS I think a rewrite was suggested for things like UDMA-133 and larger discs in addition to the FileCore idea.

[New FileCore and ADFS sound like very good ideas, and something that I would definitely be interested in. Swapping file naming conventions sounds like a nightmare from a compatibility point of view, but would be nice if they could pull it off].

Theo

caliston2 on 25/11/03 11:46AM
[ Reply | Permalink | Report ]

Changing file naming I think to "help porting software" is a bit specious - yes, there are issues, but they've long since been dealt with in Unixlib and others.

By all means put a different file system underneath - and there are plenty of good reasons to do this, but changing the visible naming conventions may just break lots of existing software that assumes . and / have their current meanings.

mrchocky on 25/11/03 12:10PM
[ Reply | Permalink | Report ]

I quite agree. I see no real need for UNIX style naming.

I reply to Spriteman: I forgot about the Mico and RiscStation Lite a long time ago. Discounting the Iyonix, the RiscPC is /still/ the highest performing machine we have. That doesn't mean I wouldn't like something a /lot/ faster and more powerful. If ROL were to make a 32bit OS and someone like RiscStation made a fast machine to use it then I'd be very tempted indeed! Can't see it happening though.

Castle are quite correct in thinking the Omega is no threat. It isn't. It is too slow, it still isn't fully working and Microdigital have all the PR abilities of Gerald Ratner.

I do agree it would have been nice if ROL had made a 32bit OS long ago. Perhaps then we wouldn't have the current 'two OS's' situation, but I accept it may not have been possible for them.

In any case, I'm not convinced of where Castles interests lie at the moment.

The Doctor on 25/11/03 12:54PM
[ Reply | Permalink | Report ]

What's the point when Castle already make a fast machine with a 32bit OS that you can buy today.

Filecore/ADFS: We finally get bug free (ish) version after 15 years and they decide to scrap it.

Don't play catchup though, be revolutionary, include ideas from WINFS, BFS, Reiser 4

mavhc on 25/11/03 1:04PM
[ Reply | Permalink | Report ]

Discounting the RiscPC, the A7000 is the fastet machine we have. I wish someone would make something a /lot/ faster and more powerful.

-- Spriteman - Phoning CTL to see if they can help

Spriteman on 25/11/03 1:09PM
[ Reply | Permalink | Report ]

Discounting the A7000, the 33Mh ARM 3 A5000 with FPA is the fastest machine.

sa110 on 25/11/03 1:20PM
[ Reply | Permalink | Report ]

I think that ROL should develop from Risc OS 5, for Castle, this way Castle develop the hardware (and make a good job too) - with the ability for Microdigital / RiscStation to develop hardware too, and ROL to concentrate with the insertion of NEEDED / Modern items for RISC OS.

as for proting S/W i still think that the idea of taking an MS (or other products) product and running it UNTOUCHED within the RISC OS environment. (would love to use Cool Edit Pro / Adobe Audidtion on the platform! (Stability)).

But alas I feel that too much hatrid / stupidity would get in the way as usual, so its slogg on with my aged 3.7 SA RPC.

em2ac on 25/11/03 1:23PM
[ Reply | Permalink | Report ]

Most Windows products will never run untouched on RISC OS - for lots of reasons that aren't even worth repeating here.

But many many Unix programs can and _do_ run untouched or with very minimal changes on RISC OS - this is the whole point of Unixlib/GCC/Unix Porting project. But the filenaming issue is largely incidental to this, and shouldn't be confused. If you wanted to improve portabilty to RISC OS, there are far more worthwhile projects to spend time on.

mrchocky on 25/11/03 1:32PM
[ Reply | Permalink | Report ]

Nunfetishist: that's more or less what I'm proposing may happen. Seems a sensible step forward to me.

Filecore probably does need changes: it's designed around the 1989 principles of how hard discs work (defect lists are now defunct because the drive does it for you, ST506 is dead, if you 'optimise' the sector list yourself you'll get it wrong. You can't queue filecore writes, you can't work in transactions to allow the drive to fully use its buffer because you don't know whether it's writing its catalogue or its data (and hence you can't guarantee you don't corrupt the map). I could continue...That's /without/ the much more useful thought of allowing an interface module to use any filing system presented to it.

On its own, you could optimise the Risc PC's 6Mb/sec transfer rate significantly. And if the code is in C or a total re-write, it could equally work on 32-bit hardware - optimising the Iyonix's >6Mb/sec rate. "It is, however, our intention to make as many Select features as possible available for RISC OS 5 users."

However, I'm guessing it's ADFS which needs doing first - after all, you couldn't stick those Filecore changes onto an ATA-2 standard interface module because the features aren't available, and if you're not hardware-independent, you're Risc PC only.

md0u80c9 on 25/11/03 1:36PM
[ Reply | Permalink | Report ]

Man, if you want to run Windows apps, use Windows. Part of the reason I love RISC OS is because of RO applications; they way they're designed...

moss on 25/11/03 1:51PM
[ Reply | Permalink | Report ]

Since Castle are now developing a RISC OS and so are RISCOS Ltd., the only way forward is for these two companies to get together and work together for common goals.

I don't really understand how going over 'which machine is the fastest' has any relevance to or at all helps this situation whatsoever.

Personally, I am sick of people slating various machines as 'not being part of the future'; people buying the likes of the RiscStation and Mico are still investing in a future for the platform. Some people cannot afford or do not want the likes of Iyonix and to alienate them is ludicrous.

As has been said 1000 times before, people voicing personal (and generally negative) feelings towards the companies, people and even products we have in RISC OS land are killing any chance of a future for the platform.

I too certainly hope that the firms can come to some sort of agreement over a future, common direction for the platform.

rod on 25/11/03 7:09PM
[ Reply | Permalink | Report ]

It's not just a question of which company is producing the faster RISC OS machines (I think the benchmarks have now finally settled that properly).

It's a question of which company is producing RISC OS machines with processors that are still manufactured.

The prophets of doom claimed that this was a major issue anything up to five years ago. It wasn't then, it may not be now, but it will be very soon indeed.

Quite apart from that, encouraging people to invest in ARM7 based solutions is hardly showing RISC OS in the best light.

dgs

dgs on 25/11/03 7:35PM
[ Reply | Permalink | Report ]

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

+++ Message board +++

Read messages or start a new thread

Search the archives

Today's featured article

RiscPC breaks 1.5GHz barrier
Calm down dear, this is a case mod

23 comments, latest by flypig on 13/5/04 1:56PM. Published: 12 May 2004

Random article

Sense has prevailed says RISCOS Ltd.
Oh goody

30 comments, latest by thesnark on 15/7/04 7:31PM. Published: 14 Jul 2004

Create a new account
Forgot your password?

Useful links

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

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

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

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

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

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

© 1999-2009 The Drobe Team. Some rights reserved, click here for more information
Powered by MiniDrobeCMS, based on J4U | Statistics
"Drobe often has glaring factual errors that could simply be avoided with the bare minimum of research"
Page generated in 0.1109 seconds.