A9home software compatibility table created

By Chris Williams. Published: 7th Jun 2005, 22:22:00 | Permalink | Printable

What works and doesn't work on RISC OS 4.40

An A9home owner has taken the initiative to create a software compatibility table for the recently launched RISC OS 4.40 powered machine. The unofficial web page, set up by developer Paul Stewart, hopes to show which applications are known to work and not work on the ARM9 powered computer - currently only available in beta form to paying programmers.

"I believe it is important to have a page that indicates compatible software, as this will help those developers who do not have A9home hardware to be able to ensure their software works on it," explained Paul earlier today.

The table shows that desktop user favourites, such as NetSurf, Nettle, StrongED, Zap, Cocognut, are known to work on AdvantageSix's kit. Each piece of software tested is listed with the version number, which is useful when checking if the particular application is Iyonix safe and therefore theoretically 32bit compatible. If you wish to request a title to be tested, you're welcome to drop Paul an email to paul [at] pstewart [dot] freeserve [dot] co [dot] uk.

AdvantageSix admitted during the launch of the A9home that it's likely that there will be compatibility issues with RISC OS 5 friendly software and RISC OS 4.40. It's understood that RISC OS 4.40 is still in development, having being made 32bit safe by RISCOS Ltd. and made compatible with the A9home's Samsung S3C2440 and Silicon Motion SM501 chipsets by Ad6.

Update at 11:54 8/6/2005
Paul reports that as well as email from fellow programmers, he's also getting "general questions about the A9home" from people. Trust me, we've already pestered Paul with benchmark and photo requests, to which he politely declined. "Any enquires with regards to the speed and features of the A9home will not be answered. The A9home I have is a developer machine, as such it is incomplete and I would be doing it an injustice to answer any feature/speed related enquires," explained Paul earlier today.

Any other A9home beta owners are welcome to get in touch, of course.

Links

A9home software compatibility table

Previous: Unix Porting Project to seek UK admin
Next: RISC OS 3 audio tapes preserved in MP3

Discussion

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

Being a RISC OS software developer is going to be an expensive business if one has to buy a variety of machines in order to thoroughly test and debug code.

Perhaps we just have to accept that that is the way it is.

By way of illustrating this viewpoint, let me comment upon how delighted I was when my software, developed on StrongARM, worked straight away on Iyonix. Even so, in retrospect, I'm glad I bought an Iyonix, as two bugs did later emerge that a RiscPC forgave but the Iyonix did not. I'd not have found and removed those bugs without having my own machine to work with. At the recent Wakefield Show I found out that my code does not quite work properly on an Omega. Alas, I'm not willing to buy an Omega to sort that problem out...

So, I guess, a few developers (many coding for freeware) are hoping that the some of the titles that don't currently work under the developmental RISC OS 4.40, will work, as it becomes commercially release ready.

Paul's evolving and changing list could, perhaps, prove to be an interesting indicator of how backward compatable the A9home is becoming.

And I have to decide if I feel about the A9home as I do about Iyonix (I bought one) or Omega (I did not).

martin on 7/6/05 11:33PM
[ Reply | Permalink | Report ]

Good idea with that table!

I had a quick look at that table ... some of the apps not working are not the current versions so that I expect that if trying the newest apps things might work. For the freeware apps like FTPc this shouldn't be hard to verify.

One issue might be that if the applications check the RISC OS Version to determine if they should expect a 26 or a 32 bit system that this probably is done by RISC OS 4.x = 26 bit and RISC OS 5.x = 32 bit. For such a check it should look at the processor state like ArtWorks 2.4 does.

hzn on 8/6/05 5:00AM
[ Reply | Permalink | Report ]

martin: I'm afraid you're falling into a trap novice programmers sometimes make - that of generalising from a single program which you happen to have spent lots of time on. Most correctly written programs will work just fine from RISC OS 3.7 (perhaps the oldest worth caring about) to RISC OS 5 without even checking them on more than one machine. Naturally, there are always exceptions, but you're going to have testers anyway.

hzn: yes, the processor state can tell you this, and there's a very simple instruction sequence to detemine this, which has been recommended for at least 3 years. But problems arise if that check is used to assume RISC OS 5. For applications written before the A9 that need to check for RISC OS 5/XScale/Iyonix it's far from clear what might be the best course of action if it finds itself on an unknown machine, It might press ahead, and hope for the best, it might just fail to perform the action. So, there's a good chance these applications (which are a minority, however) would have to have some modifications no matter how much previously careful coding took place.

mrchocky on 8/6/05 7:41AM
[ Reply | Permalink | Report ]

In reply to hzn:

If you are aware of a new version of any software on my list, please get in touch, and I will endevour to obtain the latest version and test that too.

sa110 on 8/6/05 8:17AM
[ Reply | Permalink | Report ]

martin: Hi Martin, I've tried your software on the Omega again with a normal CRT plugged in and it runs perfectly. There's an issue with the MDF I had for the LCD at Wakefield which didn't like the mode you were running in which would have gone wrong on an Iyonix or Risc PC too. So just to clarify, it's not the Omega.

liquid on 8/6/05 10:34AM
[ Reply | Permalink | Report ]

In reply to Peter Naulls (mrchocky)

I think Martin's point is that if something doesn't work, it is much easier to fix if one has direct access to the system. And I think this is true. The alternative for most RISC OS developers would be to have a beta tester with that machine try out iterations and correspond via email. Which is unwieldy at best.

Secondly bear in mind that a significant proportion, perhaps most RISC OS apps are written by what you term novice programmers.

Finally, I think it is fair to say that most programs have bugs, and it is likely that a large proportion of the "Well it works on my machine" variety.

So anyway, this table will be really useful.

Loris on 8/6/05 10:42AM
[ Reply | Permalink | Report ]

Clearly it is easier, and clearly in fact, many RISC OS developers do have multiple machines. But as I say, such incompatibility isn't as common as might be suggested.

Yes, I'm well aware of the novice or otherwise status of many programmers, and we desperately need more. The point was only that Martin's observation based upon a single program is one made by such programmers, and may not be valid.

And whilst I'm sure the table will have its uses, I'd like to see Paul be proactive in contacting the developers involved and fixing the issues. Plus these types of tables all too often have the danger of quickly becoming out of date.

mrchocky on 8/6/05 10:54AM
[ Reply | Permalink | Report ]

liquid Your comment seems to confirms Martin's point ;o)

. Without access to a machine a developer relies on an owner of that machine being able to help trace the problem.

This works fine in the case of someone like yourself with sufficient experience and knowledge. It can also result in a lot of wasted time if, in the communication between developer and user, vital information is overlooked or not passed on verbatim.

blahsnr on 8/6/05 10:57AM
[ Reply | Permalink | Report ]

From my experience, I was able to convert my C software to 32bit without a problem, it worked first time and I haven't had any iyonix specific bugs reports yet. I've only got a ROS4 SA RPC to test on.

jogu on 8/6/05 10:59AM
[ Reply | Permalink | Report ]

Is there a guide to making sure a program does work across all machines (at least anything reasonably new)? I think I've seen such things in the past, but dealing with specific points, such as 26 v 32 bit. What I really need is to actually get around to writing something - ever since I had an A310 I've been meaning to learn to write nice proper RISC OS applications, and have never got around to learning how (despite churning out plenty of mostly useless little bits and pieces in BASIC, and later C). With a book on the subject now downloadable I've even less excuse, other than the usual one of not wanting to do anything serious on a computer after being sat at one all day at work. It'll require self-discipline (in other words, I'm stuffed).

SimonC on 8/6/05 11:04AM
[ Reply | Permalink | Report ]

Check out peter's site there is a pretty good guide to make a proram 32/26 compatible.very usefull!

highlandcattle on 8/6/05 11:08AM
[ Reply | Permalink | Report ]

In reply to Peter:

Your quite right, sites such as the one I have done all to often become rather quickly out of date. No doubt mine will be no different. My plan is to finish testing the software I have on my RPC this week and update the website. I will then start looking at contact the authors/maintainers to try and get software update. I have already had correspondance relating to one of the application on my "not working" list.

sa110 on 8/6/05 11:39AM
[ Reply | Permalink | Report ]

Having looked at the table, I'm not sure of the usefullness of including programs known to be not 32bit compatible, Oregano 1, Ovation etc.

The interesting list will be those programs if any that are known Iyonix compatible but not A9

I would have thought that there inclusion in a seperate 'A9 Aemulor compatibility' list (when available would have been more appropriate)

The lsit should be a very useful resource in the future, thanks Paul.

CJE on 8/6/05 11:58AM
[ Reply | Permalink | Report ]

In reply to CJE:

I will be updating the list with Aemular compatible applications soon.

Also, having simply copied most of my stuff across from my RPC, which I guess many other people will be doing, I thought it would be a good idea to list them anyway.

sa110 on 8/6/05 12:51PM
[ Reply | Permalink | Report ]

highlandcattle: That is probably one of the ones I've come across. I was talking about an overall guide, the 26/32 bit example being one small area of a number, and one of the more obvious ones. Perhaps there aren't any significant other differences anyone should worry about, but I'd be surprised if life was that simple (i.e. if you compile with a 32-bit producing compiler what other problems could you run in to). When it comes to RISC OS specific programming this is possibly a case of me trying to run before I can walk, but it's always a good idea to try to get things rigth from square one.

SimonC on 8/6/05 2:15PM
[ Reply | Permalink | Report ]

CJE: Indeed. The list shows the 26 bit version of Ovation as not working (no surprise there, then) but doesn't mention the version which *is* 32 bit compatible.

I have to wonder if this is repeated in some of the others.

apdl on 8/6/05 5:33PM
[ Reply | Permalink | Report ]

blahsnr: I was just clarifying that it wasn't a problem with the Omega (as Martin kind of implied). It was either the MDF or the monitor which wasn't supporting the screen mode properly. Martin uses a mode with different-to-normal eigen values and either the monitor or the cut down MDF I was using didn't like it.

liquid on 8/6/05 10:14PM
[ Reply | Permalink | Report ]

In reply to SimonC:

It's true that an overall compatibility guide would be welcome. I remember for example that the DigitalCD plug-ins didn't work at first on the Iyonix due to some problem with the SWI I used to detect the amount of allocated screen memory and that I had to resort to another SWI to get the information. Another example on RO 3.7 was the necessity to give all 256 colors sprites a palette to your sprites to avoid redraw crashes in other applications such as the filer. I doubt such information is easely available.

andretim on 9/6/05 7:47AM
[ Reply | Permalink | Report ]

re Aemulor compatibility for the A9

We will be updating our own Aemulor compatibility database on www.aemulor.com to add an extra flag for A9 compatibility. We really dont forsee their being many differences, but until we start mainstream testing, we wont know for sure.

Regards,

Neil

spellinn on 10/6/05 12:09PM
[ Reply | Permalink | Report ]

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

Search the archives

Today's featured article

South East 2008 show round up
News from the event in the south of the UK

42 comments, latest by diomus on 9/11/08 8:45PM. Published: 19 Oct 2008

Random article

Fast prime number generator developed
100 million primes in less than six minutes

Discuss this. Published: 19 Aug 2007

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
"We incurred the wrath of Chris Williams, the main journalist at Drobe, who told us to 'Take our filthy spam and shove it where the sun doesn't shine'"
Page generated in 0.0582 seconds.