Mark Rowan with our Iyonix column.
Bigger, fatter, cheaper
The technical bods at Castle have been busy recently, with the release of yet another edition of the Iyonix PC, and an update to the OS which now stands at version 5.07.
The 1GB super-souped-up Panther TC reported on last issue has now been dropped significantly in price. For the same price as a top-end standard Iyonix PC (£1399) you can get yourself a Panther TC with 1GB RAM and two 120 GB hard drives. The normal price is £1599.
An Iyonix Panther ay Wakefield
I bought my comparatively puny Iyonix (128MB RAM and one 80GB hard drive) for £1299 (bitter? Who me?) so it's good to see Castle dropping the prices of their machines. Although this is a 'special offer' which only lasts until the end of September, I would think it likely that overall the Iyonix range will lower in price over the coming months, or we'll see many more 'special offers' such as this one, as the RISC OS enthusiast upgrades market must be pretty near saturated with Iyonixes by now and Castle can't wait around forever for the remaining few potential buyers to take the step.
Minor OS update
RISC OS 5.07 was released to users over the automated update system early in September. This update is mainly a bug-fix release, addressing problems with USB devices and networking, and adding a couple of new features for programmers (such as a 'new 4 parameter variant of the COLOUR command' which sounds intriguing!). One effect of the update has been to allow the Iyonix to reboot correctly from Linux, as previously the keyboard and mouse were disabled until the power was switched off and back on. Now the Iyonix reportedly reboots as would be expected, with functional keyboard and mouse.
As such, this was a relatively low-risk update. But of course, the usual precautions apply - make sure you take a backup of vital work in case the upgrade fails and you're without your computer for a few days, and ensure you know how to activate the RISC OS 5.06 restore application even if you're typing blind (full instructions are given in the README file).
That last point is an important one, as a number of initial reports indicated that some Iyonixes were losing their ability to display the screen properly, due to an update to the NVidia graphics card driver. The cards affected seem to be of the silent (fanless) type supplied with some machines.
However within hours Castle had withdrawn the update and fixed this bug, re-releasing it the following day. A small diagnostic utility in the updated programmer looks out for these affected cards, and makes a note in a file 'Send2CTL' with some diagnostic information if it finds you have one installed. Castle request that you send this file to them to help them understand what was causing the problem.
A small update was issued not long after RISC OS 5.07 to add a couple of extra monitor definitions, and updated documentation for the EtherK ethernet networking driver. Apparently there are 'a number of non critical disc updates to follow'.
With all this activity at Framlingham Towers, one wonders how much longer it will be before the first release of the much-anticipated Merlin scheme to desktop users, particularly now that Castle and RISC OS Ltd are reportedly teaming up to work together on the project. I hope we can see some progress before the year is out. It's not long till the Iyonix's second birthday.
A quick guide to FAT (not as written by a dietician)
It's a fact of life these days that computer users have to interface with the archaic FAT filing system - even if you're not a Windows (or even DOS) user most digital cameras, palmtops, and memory cards come pre-formatted in the FAT16 or FAT32 format. It's everywhere - and worse, Microsoft are in a legal position to enforce payments of royalties for each and every use of the FAT filing system, no thanks to corporation-friendly software patenting laws (but I'll not go down that route today).
Still, in the interests of compatibility with the outside world, it's pretty important that Iyonix users can access devices formatted in the FAT filing system. After all, who wants to admit that their state-of-the-art £1399 Panther TC can't read images from a standard flash memory card?
Therefore it's a blessing that we've had a filing system known as DOSFS for quite some time (way back in the days of Acorn) which can read FAT16 discs, including most flash memory devices.
The difference between FAT16 and FAT32 (a newer version of the FAT system) is like the difference between the RISC OS 3 and RISC OS 4 disc formats - the latter is much more advanced and allows long filenames amongst other useful features. The trouble is that our version of DOSFS (still) doesn't understand FAT32-formatted discs, which applies to more and more devices as the world tries to forget FAT16.
John Ballance at Castle recently wrote on the Iyonix support list "I anticipate [...] long filenames, at some stage soon. FAT32 etc to follow that" which is very good news, particularly to users of devices such as external USB hard discs where an 8-character filename limit, as imposed by FAT16, is nothing short of frustrating.
But there's another catch - the way DOSFS works is in the guise of an image filing system (like SparkFS) - the data from the FAT-formatted disc is presented to RISC OS as a single file, which DOSFS then reads and displays to the user so you can see the individual files on the disc.
However RISC OS currently has a limit on filesizes of 2GB which pretty rules out all external USB hard discs, and in fact causes a few problems elsewhere too (removal of this limitation is one of the requests made to the Merlin discussion group, so hopefully we'll see movement on that in the not-too-distant future).
Good news comes in the form of a new program by David O'Shea, called simply DOSFS2. Rather than working as an image filing system, it reads from a FAT-formatted disc directly so it can overcome the 2GB limit imposed on normal DOSFS.
It's still very much in development, and at the time of writing is read-only, so it's no use for making backups to an external USB hard drive. Hopefully future development will see David's work combined with Castle's FAT32 work as mentioned above to allow access to all shapes and sizes of media which currently are still out of reach of RISC OS users.
DOSFS2 is available from here and is also in the software directory on this issue.
Bigger, fatter, cheaper... but not faster
It's true that as you grow with your new computer it begins to impress less. Remember when you first got your RiscPC and how much faster than the A5000 it seemed? To me even a StrongARM RiscPC is hopelessly slow compared to my Iyonix now. Yet I find myself more and more often muttering various things in impatient tones under my breath as I wait for my Iyonix to complete a task.
It's very likely that as I've grown used to the increased speed of my Iyonix I've also demanded more of it - I store more email in Pluto than I used to on the RiscPC, so it takes longer to start up for example. But the psychologically perceived slowdown over time as I get used to the computer is very apparent too.
I have an AMD AthlonXP laptop clocked at 1.8GHz. It normally runs Linux with the KDE desktop, and occasionally WindowsXP (but I don't like to talk about that!) and in general use both operating system desktops appear sluggish and cumbersome.
It's a testament to the compactness and efficiency of RISC OS that it is immensely more useable on a processor clocked at a mere third of the speed. However that's not made up for by the sheer power of the 'other' processors when it comes to raw data handling.
Take, for example, the task of ripping a CD to disc and compressing the tracks to MP3 files. My Iyonix, equipped with cdparanoia and MP3Encode (until recently available from Justin Fletcher's site) using shine to do the actual encoding, will do the task in typically about half an hour, up to 45 minutes.
On a recent occasion I was stranded without my Iyonix for a week with only my laptop for company, so I tested how long the process took on the AMD Athlon processor. Within 10 minutes I was done. MP3 encoding in particular was noticeably faster than on the Iyonix (in the order of about 10 times the speed) which is certainly not inconsiderable.
Thoughts for the future
Now don't get me wrong, I love the ARM processor and its low heat emissions which gives the Iyonix the killer advantage of being nearly silent without the use of any special equipment. And I realise that x86 processors such as the Athlon are very different beasts to the XScale used in the Iyonix.
But with the release of yet another model of Iyonix-clone running exactly the same processor as two years ago, the raw performance gap between the two architectures is getting more and more desperate. That's the sort of performance that I lament when encoding sound tracks with shine, or thumbnailing a large directory of images using PhotoFiler, or manipulating huge photos of the stars in PhotoDesk.
It's important to realise that Castle are limited by the processors Intel and other major corporations decide to release. It's a far cry from a decade ago when Acorn designed the ARM processor to order for their machines. Now RISC OS is at the whim of companies who probably haven't even heard of it. And currently, the XScale IOP321 inside your Iyonix is still one of the fastest suitable processors available for RISC OS to run on.
But faster ARM-compatible chips do exist, and GHz ARMs are on the horizon. Isn't it about time the Iyonix played catch-up with its heat-spewing American cousins?
One final thought though: should Castle really be focusing on faster hardware at this moment in time, when such significant and resource-consuming, but much-needed, software updates such as Merlin are in the pipeline to bring our system back into the modern age?