Drobe logo

My Iyonix and I


Published on 20th Jul 2004, 22:47:27, source is drobe.co.uk
By Martin Hansen

How was it for you?

Six months after purchasing a Castle Iyonix, drobe.co.uk writer Martin Hansen recounts his experiences with RISC OS 5 and his new XScale powered hardware, serving an illustration of life with the latest generation of RISC OS machines.

It was at the South West Show in February, earlier this year, that I bought my Iyonix. I had a suspicion my wife was right; for me this might well turn out to be a rather expensive and frivolous purchase. For I already had a Kinetic RiscPC that did all that I asked of it via a laser printer, two SCSI scanners, network card, Viewfinder and a top of the range 19" LCD monitor. I already had adequate email and Internet access via my work LAN and a Windows '98 laptop provided 'free'. I even had free use of my daughter's new A6 machine from Stuart Tyrrell running RISC OS 4 breathtakingly fast under VirtualAcorn emulation. However, by the time of the South West Show, Iyonix was well past its first birthday and I didn't want to return to being a "left behind" as I had allowed to happened to myself by 1998 when I was still using an A5000 whilst the real enthusiasts had moved on to StrongARM machines. And emulation is all very well, but if you are deeply serious about RISC OS, as I am, then Iyonix is a big part of the future. Period.

While Iyonix was past being one year old, I was clocking in at 43. I reasoned that at such a ripe old age one ought to be able to indulge in an odd whim or two. Plus, experience has taught me that it's often best to wait a little before buying into a radically new technology. Waiting about a year seemed right. And let us not forget: the Iyonix was a massive step forward for RISC OS. It jumps, what many thought was, the impossibly high hurdle that takes our compact, curious and ingenious operating system to a very new CPU and integrates it with hardware that utilises cheap mainstream, mass produced computing components and interfaces, including PCI and USB. This without losing the essential character that makes RISC OS so much better than the alternatives. Iyonix seems expensive but less so than would have been the case had off-the-shelf kit not been used to cuts costs and development time. Allegedly, it took just six months from the moment Castle saw the opportunity, to having a product available for end users to buy.

So, I momentarily had the funds, I had the urge, I took the plunge. A thick bundle of ten pound notes was handed to Jack Lillingston on the Castle Technology show stand. I first got aboard this ride with an Acorn Electron in 1984. Twenty years on, Iyonix was 600 times faster and had 16,384 times as much memory. Maybe I was old and stuck in my ways to still be 'an Acorn man' but it felt good. In truth, I wasn't sure if the Iyonix rather than VirtualAcorn emulation was the bigger future for the majority of RISC OS users, but as I handed over the cash I sensed that I truly had signed up for the next few loops on the RISC OS roller coaster ride into the future.

Since then, half a year has passed and I thought that perhaps it was time to reflect upon the wisdom, or otherwise, of that impulse purchase; my Iyonix. I felt it time to share with others the joy and tears as my new roller coaster ride got under way. Of course, if working with an Iyonix was much the same as with a RiscPC, then there would not be much to say. However, my view is that the fundamental nature of working with RISC OS is now evolving at a brisk pace and I'd like to discuss some of the more significant aspects of this.

When I think back to arriving home from the February show, it's curious what sticks in the mind; Castle was being criticised in those pre-Panther days for the unadventurous colour of a characterless off-the-peg case that housed their flagship machine. Part of the problem was that it wasn't especially photogenic but I distinctly remember lifting my Iyonix out of the box and immediately appreciating how well built and solid it was. Not so the keyboard which, although it worked well enough, seemed cheap and insubstantial. Switching on, I recall not quite seeing the point of having a new set of icons for old applications even if they had been upgraded. Although, I have since come to really like the Iyonix icon set, as designed by Richard Hallas: first impressions are not forever.

Before my initial session was over I'd networked the Iyonix to the Kinetic and managed to arranged two 19" monitors, two keyboards and two mice on my rather small desk in a way that didn't confuse me too often. To me, there seemed no point in using the Iyonix to replace my Kinetic RiscPC and I had every intention of using the two together. This was not just laziness; In order to move my expensive Nikon Coolscan III SCSI photographic slide scanner across to the Iyonix, for example, I'd need a podule backplane, an Acorn SCSI podule and an Iyonix compatible driver quite aside from needing a 32 bit version of the scanning software driver which David Pilling may, or may not, have been able to supply. And all this to support an interface that, as far as the rest of the world was concerned, is obsolete.

I also wanted both machines interconnected following some seat squirming at a show theatre presentation, in which RISC OS Ltd's Paul Middleton had been warning punters of the dangers of not reliably backing up all hard disc data frequently. Well, each of my Iyonix and Kinetic could now back up the other. I'd got away without backups for many, many years. With my Iyonix's arrival I decided to wise up before the inevitable happened.

I've always been quite taken with the Acorn philosophy that underpinned their entire concept of computing; "doing more with less". The 'R' in RISC stands for 'reduced' but RISC OS claims to be 'the more productive operating system'. I enjoy spending large amounts of my spare time working with the RISC ROM fundamentals, writing BBC BASIC code using Edit, and, more recently, using that duo to produce Draw files. Far more fancy languages and editors abound but Edit and BASIC are the minimalist tools that I love to use. So, as my second week with Iyonix began I copied the current project across, a promising application called !TurtleChalk and was later released at the Wakefield Show, May 2004. Back then there was much to do before it would be ready and I began to program in earnest. The fact that the existing code seemed to run without requiring any alteration at all to accommodate the new machine was a source of considerable satisfaction, and relief. 'Backwards compatibility' was another Acorn philosophy worth far more than most ever gave them credit for. (As indeed is 'File format openness'. With help, writing Draw files is tough - thank goodness that the Draw file format is not a secret.)

Now, at the risk of stating the obvious, when you use a piece of software for hours every day, you inevitably unearth a few bugs. Years of using Edit and BASIC under RISC OS 4.03 had found a few. There is an odd one that very occasionally will drop an "EVAL" keyword into BASIC but without displaying that keyword in the code listing via Edit. Listing the code from within BASIC lets one see and erase this spurious and apparently randomly placed program crashing command. I've yet to get to the bottom of that one. Most of the other RISC OS 4.03 Edit bugs I've come across are to do with overlapping windows leaving bits of black line within the Edit window as they move over it in a high resolution, deep colour depth, (Viewfinder) desktop mode. My guess is that Edit does not quite always refresh all that it should, probably due to a one pixel rounding error, but this is a fairly trivial problem. The chaff can be cleared by using another window as a wiper.

Under the Iyonix's RISC OS 5.05 some major Edit bugs were quickly apparent. Window scroll buttons frequently scrolled the window the wrong way and sometimes with repeated entire window flickering and juddering. Equally annoying, I found that within Iyonix-Edit the action of the and keys was different to that of RiscPC-Edit. However, in the bundled Iyonix word processor application, Writer, the established actions of these keys was respected. Thus, within the bundled Iyonix applications, an irritating inconsistency had been introduced.

I began to think that my BBC BASIC code was contaminating Edit in some way when I unearthed a way of crashing my program through a sequence of operations that gave no such trouble on the Kinetic. Iyonix Week Two was bad, and in frustration I began searching the Internet for help in understanding the problem. Here I found a report confirmation that Edit under Iyonix had several known bugs caused by some parts of the shared C library having been broken when it was recompiled for the true 32 bit OS of the Iyonix. I was shocked. All that money for a machine with a fundamental problem with a major ROM resource. Worse, it was unresolved over a year after the launch. So, Edit had problems. What about BBC BASIC?

The passions aroused, a long day at the end of that second week passed as I grimly resolved to sort out why the same piece of code generated an error on Iyonix but not Kinetic. Heaven help Castle if it was a kink in yet another mainstay of the platform, BBC BASIC. I resolved to be on that phone asking for my money back if this one was the fault of the OS.

Eventually, I realised that the program crash was centering around a routine that prepared a string of characters and set a flag that then told a later part of the program to insert the string into the keyboard buffer. Often this code worked fine on Iyonix but as I probed I isolated a certain sequence of TurtleChalk commands (TurtleChalk itself being a programming language) that caused this manoeuvring to always fail. Finally, I realised that what was wrong; I had not avoided a situation in which my program expected characters to be there from the flag being set, when in fact there were none. So, the error was mine. The Kinetic RiscPC forgave whereas the Iyonix did not. The error that took hours to find, once identified took a few seconds to fix. My sense of humour resurfaced, my patience returned, and a began to enjoy using what was, after all, a fabulously fast machine upon which to execute BBC BASIC.

I'd had my Iyonix for only a few more weeks when a drobe.co.uk news item reported that Robin Edwards, author of "1st", the premier RISC OS statistics package, was no longer intending to attend shows to sell his software. He also had no means of 32 bitting "1st" to run it natively on Iyonix. This is an all too familiar story for RISC OS where major applications, often the work of one or two people, fail to be developed as the capabilities of the platform's hardware marches onward. As he lived near to me, I got in touch, hoping that I could do a little to stop another big app being lost. One thing lead to another, and I eventually lent Robin my Iyonix for a couple of months to help him update his outstanding application to run natively on the latest RISC machine. '1st' later joined TurtleChalk on sale on my Wakefield stand.

The Kinetic once again became my main work-horse but my enthusiasm for Iyonix began to increase when I accepted an email invitation from John Ballance to join the Iyonix support group. I've always taken a fair amount of pride in resolving any problems with my machines by myself, with help from manuals and books. As I said at the start of this article, the nature of RISC OS computing is changing, and the support group, I quickly realised, was where the real enthusiasts were to be found. Here they thrash out problems concerning a machine for which the authoritative Programmers Reference Manuals have yet to be written. Typically this group generates a dozen or so emails a day and although not all of the topics raised interest me, I began reading every single email posted by the groups members.

As a support mechanism, Iyonix-Support is as good as one could possibly wish for, and yet, at the time of my purchase I knew nothing of its existence. Only when I registered my Iyonix on the Castle website, to tidy up a few loose ends, did I receive the invitation. The essential idea is nothing new; both old hands and new are welcome at any time to drop in with an email describing a problem and anyone who feels so inclined can reply with help or advice. By default, every communication gets emailed to everyone in the group. This arrangement may not be new but what is impressive is the speed and the high quality of the responses. Often within an hour helpful emails start being posted back and I've yet to read something that was not focused and purposeful. Good humour pervades everything, and many issues get resolved very quickly indeed, often within twenty-four hours of the first posting. Most topics are simple inquiries, such as, "How do I listen to Internet Radio on my Iyonix?" or "Help me choose an Iyonix compatible USB scanner." or "Why has my Pendrive stopped working?"

Some of the technical topics tackled by Iyonix-Support are pretty formidable, and hanging on to those discussion threads can require a certain amount of determination. But they do often end up being very informative. Many of the most knowledgeable people in the world of RISC OS contribute and the ideas can really start to fly once a tricky area becomes the point of focus, as has happened recently for example, with "Audio In". The idea of "Audio In" was to use the Iyonix to sample a microphone plugged into the "line in" socket. Alas, the quality of the sampled sound was very poor but several users attacked the problem with relish. Sample rates, missing samples, pitch shifting, input voltage levels, impedance matching, the specifications of the mother board chip involved, and pre-amps all got discussed in enormous depth, with some folks bringing expensive investigative electronic kit in to analyse what was really going on in their machines. The problem has yet to be resolved but optimism that it will be is running high.

Over the months, through following the support group discussions, I have come to appreciate what a very complex interface, in its various modes, USB is. It has thrown up a daunting stream of problems for Castle to try and resolve. Getting digital cameras to work with the Iyonix and then keeping them working each time a USB or ROM upgrade is applied seems to be tying down several of Castle's top engineers. The current Iyonix RISC OS version is 5.06 which, incidentally, fixes the major problems with Edit that I mentioned earlier. Quite a few cameras are struggling under 5.06, including some that worked previously under 5.03 or even 5.05. John Ballance is working hard on this problem, and trusting folks are even lending him some of the expensive cameras causing problems in an effort to track down bugs far more convoluted and entrenched than my BBC BASIC keyboard character poking problem described earlier. Of course, the situation is not helped by the short life-span of a typical digital camera. Within a year of their launch most camera models are superseded with a technically superior product. But Castle are not willing to fall behind in this area and Iyonix Support is a vital point of contact between themselves and users.

I'm not aware of anything that worked anywhere near this well for any previous RISC machine and it means that the Iyonix is not the static experience that, for most people, the RiscPC was. Tied in with this, and illustrated in part by the above, is the fact that to get the most out of a modern RISC OS machine, and for the first time, a user needs to have Internet access.

With Kinetic, as I've already mentioned, my Internet access was actually via a Windows '98 machine connected via a LAN at my work. This has been fine for accessing, for example, drobe.co.uk and, indeed, the Iyonix support group.

What I did not fully appreciate when I bought my Iyonix in February, was the fact that, for the first time in a RISC OS machine, the OS ROMs are upgradable by the user via !IyoUpWtch via a direct Internet connection. More than the simple fact that this facility is there, is the fact that Castle are developing the OS and expect, perhaps not unreasonably, users to keep up with the upgrades placed on line and to apply them in the order in which they are released. It looks like I'm going to have to forgo my 'free' but restrictive works Internet access, and shell out for a private line and a direct personal connection for my Iyonix.

It's time to return to where I came in, which, you may recall was to question the sanity of my mind in buying an Iyonix when I already had a machine, a Kinetic RiscPC, that did all that I felt I required.

Six months has left me in no doubt that, yes, I would have become a "left behind", as I thought was becoming the case, had I not bought an Iyonix. Buying an Iyonix means buying into something that's evolving with every month that passes by. I further understand both that the Internet is now a crucial part of RISC OS and why. Iyonix-Support is a vital resource that works well to help users know the strengths of their machine, and also how to circumnavigate its areas of weakness. Yes, I had problems with the OS. Yes, the steady flow of new USB products is an ongoing interfacing problem. !IyoUpWtch is a timely application that lets Castle cope and place OS improvements in the field for users to try out and then, via Iyonix Support, report back upon. !IyoUpWtch checks that your Iyonix has all of the latest upgrades installed and grabs them from the net if you do not. This is the new nature of RISC OS: a far more organic, evolving and involving experience than it ever was in days gone by.

Am I pleased with my purchase? Well, I've just personalised my Iyonix by giving it a Scottish name: I call it "The big aye".

Links
Iyonix review part 1 and part 2
drobe.co.uk also welcomes articles from Select, VirtualRiscPC and Omega users on living with their RISC OS environment.

Related articles
Early Soundblaster Live Iyonix driver released
Firefox 2 port now Iyonix and A9home friendly
Independent Select for Iyonix interest list opened

This article has been linked to, or is available in the following formats:  
 
 
 
 
 
[Printable] [Digg this] [Blog search]


Design and concept (c) Fudgecake Design, 1999 - 2001. Content (c) The Drobe Team, 1999 - 2006. See www.drobe.co.uk for more information. For non-commercial personal use only.