Iyonix Issues

Progress

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).

Graphics glitches

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.

Other updates

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 problem

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).

The solution

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.

The competition

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?