ARMv7 compatibility list

This…

Good grief.

…doesn’t seem like a good way to engender…

[Meanwhile, over in the land of] constructive debate…

“ARMv6+” is in danger of sounding like an advanced form of the ARMv6 architecture. Jeffrey’s proposal of the simple “ARMv6/ARMv7 compatible” seems the safest and clearest way to go.

“ARMv6/v7” is shorter than “ARMv6/ARMv7”, and carries just as much information.

Perhaps the list would get updated more often if people could edit it from RISC OS :)

That’s true. When I first started populating my BB I came across a number of changes & additions I could have made. The list structure being unfamiliar & shared, I didn’t dare.

Of course now I have no recall of the things I found.

Perhaps the list would get updated more often if people could edit it from RISC OS :)

Yes, that’s the main reason I haven’t actually made any changes yet. (Well, OK, the other main reason is that I gave Magic Mushrooms what I thought was a cursory test on the ARMini, expecting it to give no problems whatsoever, and it crashed. Admittedly the crash doesn’t seem to have been anything to do with the ARM and more to do with something bizarre R-Comp did to the MDF which causes it to report “Screen mode not available” when you try to change back into the screen mode the desktop was already in, but it was still a bug in any case. Actually, it was more of a side-effect of some inexplicable idiocy during the early stages of programming the game which I just rediscovered and wondered what on earth I was thinking.)

Ghostscript 1.05 was ported by the same person who designed the ARMv7 OK logo, and said logo appears next to its download link, and yet it’s marked as “Seems OK”. WTF?

That’s nothing… Some of my stuff was marked “Has issues; unsupported” (or words to that effect) and listed with version numbers several years out of date, until I changed the entries.

listed with version numbers several years out of date

I think we missed a trick here – whilst it is important to know the earliest version known to work correctly on ARM7 it is also important to know whether earlier versions worked at all, sometimes with only minor issues. It was also difficult (when reporting software that had issues) to know whether a later version existed at all and how to upgrade something that might be a few years old.

The A9home equivalent ‘compatability’ page was a nightmare not least because the (Castle) 32bit shared C library didn’t work properly so you didn’t know whether it was the app or just the broken library.

Presumably the ‘works OK’ items do indeed show the earliest version known to work on ARM7. Perhaps the item should be locked once it gets to this point? A lot of links have stopped working in the last few years which doesn’t help.

There’s a link to the full history of the page so you can tell when an entry was added and what version it was at the time.

There’s no guarantee that something on the list is 100% armv7 compatible. Last time I checked a few days ago all the links were working apart from Memphis.

all the links were working

It’s a lot of the things that are not on the list where I’ve found the most trouble finding valid links – often there is a link somewhere, giving the latest version number and description, but the download link fails. The aemulor web site has been taken over by the Chinese for example!

Once more: Can somebody please recompile the unzipsfx utility? I need it to make an ARMv7 compatible version of Infozip available.

What’s the situation with NetTime? Is it officially part of RISC OS now, or do I need to keep its entry on the table? I guess FreeTime should just be deleted altogether now.

I’ve had another idea for improving the table – how about adding a ‘Purpose’ column giving a brief summary of what the software does? A ‘Software’ column containing names like “Avalanche”, “Moonfish” and “Pluto” isn’t very helpful for a newbie.

EDIT: New thought. There seems to be a significant subcategory of applications like Zap and Ticker which are not officially supported by their authors, but have nevertheless been unofficially modified by third parties to run on the BeagleBoard (in most cases because people wanted to use them, hence they’ve been heavily tested). Should these be marked as “OK and Supported”, or should we invent a new category?

I’ve finally started work. I’ll keep a running tally of things accomplished in this post.

• Astronomy: Ignoring for the moment, still tempted to delete altogether.
• ArcFS: Email sent inquiring about current status. Reply received! Sadly, nope.
• Infozip: Waiting on ARMv7-safe unzipsfx. Done! OK and supported.
• DataPower 2: Can we please just delete this row? Deleted.
• DataPower 3: Email from R-Comp confirming version 3.15 is supported. Done!
• FontCat: Ancient, marginal interest, author deceased and source presumed lost. Recommend deletion.
• Ghostscript: Marked ‘ARMv7 OK’ on its own homepage, so definitely safe to change to ‘OK and Supported’. Done!
• GView: Absolute !RunImage of 2006 vintage. Sounds dodgy. Email sent. Reply received! OK and Supported (so even if it turns out not to work after all, MW says he’ll compile a new one).
• OHP_Show: Its homepage is here, and that should be added. Status dubious – email sent.
• SpellCheck: What is this and who do I ask about it?
• Zap: See post above. It is supported, but doesn’t satisfy the “involvement of author(s)” criterion. We really ought to have a new status for that. (Also, InterGif.)
• SchemEd: Website assures us version 1.04b was “developed using Beagleboard (sic) hardware and the latest ROOL C tools.” Upgrade requested. Reply received! Confirmed supported.
• RiscPCB: Author has been working on support for quite some time.
• A310Emu/ArchiEmu: Ditto
• ArcEm: Confirmed supported (see Jeffrey’s post below).
• DosBox: The usual suspect has a new version.
• Chuckie Egg/Dare Devil Denis: Seem to work (with mentioned caveats), but support unknown. Email sent. Reply received! Author has no time, but Source Available.
• -————————-
• All David Pilling’s software (MicroSpell, Thesaurus): David Pilling’s website is a bit on the vague side about compatibility. Email sent. Reply received! See post below.
• DiscKnight: Website says 1.49 compatible. Email sent requesting upgrade. Reply received! OK and Supported. David Ruck has also recompiled all of his freeware (e.g. GraphTask) so we can add those as well.
• Photodesk: Website says “believed to be compatible”. Email sent.

I still haven’t made any changes to the table, since that’s way too awkward to do from RISC OS.

I’ve received my first reply, and it raises an interesting issue.

David Pilling says he doesn’t have time to test everything, but that he can offer a “promise” that, if anyone finds an ARMv7-related problem with any of his software, then he will fix it.

As far as I’m concerned, this goes far enough towards satisfying the “OK and Supported” criteria, but does anyone have any problems with this? Possibly the ARMv7 badge should be renamed just “Supported”, if the application isn’t guaranteed to work out of the box, but you can at least guarantee that it will eventually work, or maybe (yet) another category should be created to make this distinction.

Looking at it another way, it’s not that different to ordinary bug reports; when you download anything (particularly for free), you implicitly accept that the software you’re downloading may contain bugs, and that if you find any it’s your duty to report them and the author’s duty to fix them.

Any thoughts?

This is in addition to the ‘Zap clause’ I’ve hinted above, where the ARMv7 OK distribution isn’t the ‘official’ one.

Yet Another Additional Status Idea™:

“Ongoing”, for applications which aren’t ARMv7 compatible but where the author is known to be working on a compatible version.

For example: RiscPCB, ARMalyser.

FontCat: Ancient, marginal interest, author deceased and source presumed lost. Recommend deletion.

<shiver> Dude, cold.

Once more: Can somebody please recompile the unzipsfx utility? I need it to make an ARMv7 compatible version of Infozip available.

Here are some unzip binaries built from the unzip 6.0 sources (plus my RISC OS fixes). I would give you binaries from the 6.10b sources, which have my RISC OS fixes incorporated in them, but since that’s a beta release the tools (or at least unzipsfx) print out “do not redistribute” warnings :(

The unzip binary in that archive is probably the same as the one you’re already using from my site, but the archive provides the full set along with the readme docs.

What’s the situation with NetTime? Is it officially part of RISC OS now, or do I need to keep its entry on the table? I guess FreeTime should just be deleted altogether now.

NetTime is officially part of the OS – it’s been in the disc image for a while now, just hidden away a bit since it wasn’t until recently that a configure frontend was added.

David Pilling says he doesn’t have time to test everything, but that he can offer a “promise” that, if anyone finds an ARMv7-related problem with any of his software, then he will fix it.

As far as I’m concerned, this goes far enough towards satisfying the “OK and Supported” criteria, but does anyone have any problems with this? Possibly the ARMv7 badge should be renamed just “Supported”, if the application isn’t guaranteed to work out of the box, but you can at least guarantee that it will eventually work, or maybe (yet) another category should be created to make this distinction.

Sounds good to me.

Jeffrey and I were obviously compiling at the same time… here are my unzip binaries
I haven’t tested these at all – I’m not near a RISC OS machine at the moment. I’ve checked them into the GCCSDK autobuilder, so if they’re OK they can appear on the website soon.

Jeffrey, what are ‘your RISC OS fixes’? Just SWI stuff for compiling? These are mine

Jeffrey and I were obviously compiling at the same time…

Well, not unless you compiled yours over a year ago.

Jeffrey, what are ‘your RISC OS fixes’? Just SWI stuff for compiling?

Good question! Here’s a diff that looks sensible. Note that further changes were made for 6.10, e.g. directory timestamps/attributes will now be restored correctly. There’s a summary of all my changes here on the info-zip forums (My posts appear under the name ‘osterdale’ – it looks like the forum DB got screwed up a bit at one point, as I originally posted under my usual moniker phlamethrower). I was going to submit a nice clean GCCSDK autobuilder recipe once unzip 6.10 was released, but it seems the pace of development of unzip is almost as slow as the pace of development of RISC OS.

Excellent, Theo and Jeffrey, thank you! I’ll give those a test in a minute.

Jeffrey’s probably best-placed to answer the next one: Is ArcEm ARMv7 OK and Supported, and what is the first OK version? (I know it seems like a bit of an obvious question, but I’m being ultra-cautious here!)

Where can the ‘fast’ version be got from these days? The riscos.info one (linked from the wiki) appears to be eighteen months out of date (which explains the “Still a little slow” comment).

I’m coming to the conclusion that it’s simply not possible to have one column marked ‘Status’ – there are two variables at play here. Firstly, whether or not it works; secondly, whether or not it’s supported. Something can be supported to the extent that it’ll be fixed if it doesn’t work, and something can work but not be supported. I think it’s important to list both.

I propose the following classification:

Compatibility
One of:

• ARMv7 OK logo: Believed working by official developers (or the person who made it so; see ‘Third Party’)
• Seems OK: Working, tested thoroughly by third parties (we’ve had a lot of incompatible software marked as ‘Seems OK’ after five seconds of testing!)
• Has Issues: Partially working but some things can go wrong
• Not Working: Don’t bother
• Unknown: Nobody’s tested this yet and the author hasn’t made any changes

Support
One of:

• Supported: Official developers are willing to address issues should they arise
• Ongoing: The developers are still working on compatibility (e.g. RiscPCB)
• Third Party: Official developers not involved, but somebody else has made it compatible (the aforementioned ‘Zap clause’)
• Source Available: Nobody’s touched the source, but it’s still there if you want to try
• Not Supported: Nobody is developing this software and nobody else can
• Unknown: Nobody’s bothered to find out or the official developers are unhelpful/unreachable

Jeffrey’s probably best-placed to answer the next one: Is ArcEm ARMv7 OK and Supported, and what is the first OK version? (I know it seems like a bit of an obvious question, but I’m being ultra-cautious here!)

OK and supported: Yes. First OK version: That’s the tricky one! Officially ArcEm’s been at version 1.00 for the past 10 years. However since I’ve just found the bit on sourceforge which actually explains how to manage projects I’ve now uploaded a (tentatively named) 1.50 alpha build, so it’s probably best to list that as being the first officially supported version.

Where can the ‘fast’ version be got from these days? The riscos.info one (linked from the wiki) appears to be eighteen months out of date (which explains the “Still a little slow” comment).

The arcem-fast branch was merged to trunk a couple of months ago, so see the above link for the latest version.

…OK, next question: can anyone furnish me with an ARMv7-safe copy of zip?!

It seemed to be working, until I attempted to create a self-extracting archive. I haven’t yet managed to do that – it always fails with the error "unknown compression method" when I try to run the resulting executable.

Then I tried turning alignment exceptions on to see if that made a difference, and lo and behold, it did. unzip still seems to work (Jeffrey’s version), but now every time I compress something with zip it produces the ever-so-helpful message, “Interrupted (aborting)”.

This is the version linked from the wiki on riscos.info – datestamped July 2011, FFS!

I still haven’t managed to get unzipsfx to do anything, so the possibility remains that there’s a bug there too. (I did compress and decompress a rather large archive – with exceptions off – before discovering this, so zip must be very subtly broken. unzip still successfully decompresses that same archive with exceptions on.)

Your zip, Sir

Let me know if that works, and I’ll ask Alan to update the riscos.info website.

unzipsfx (and zipsfx which is the same thing I think) I’m slightly worried about… since they do things with self-extracting archives that might imply a certain amount of platform knowledge that a straight port won’t have. Their method for creating SEAs looks relatively portable, but there’s always the chance of gotchas.

Jeffrey, looks like yours and my unzip changes were very similar. There’s the thing about increasing filename lengths, which I’ve yet to put in. InfoZip have awkward conditions that say you can’t distribute something as zip or unzip if the sources are modified. Allied with the fact that beta binaries are not distributable, 6.10b3 was the most recent beta (in 2010), and they don’t have any kind of public version control system, it’s all a bit of a mess. I think taking raw Debian source and very light patching it to compile is probably as safe as it’s going to be, given that mainline source isn’t 32 bit safe so has been unusable for a decade.

Typical, you wait ages for an executable, and then two turn up at once… Thanks to Chris Gransden who also sent me copies of zip and unzipsfx (by email).

It’s a good job he did, because Theo’s new zip fails in exactly the same way as the previous one, but Chris’s worked with alignment exceptions on.

I’ve also discovered that Jeffrey’s unzipsfx isn’t ARMv7 compatible either, as the following selected extract testifies:

F25C : DCB "process_zip_cmmnt",0,0,0
F270 : DCD &FF000014
F274 : MOV     R12,R13
F278 : STMDB   R13!,{R4-R6,R11,R12,R14,PC}
F27C : SUB     R11,R12,#4
F280 : CMP     R13,R10
F284 : BLMI    &11E68
F288 : LDR     R1,&E36C ; = &133E0 (EOF)
F28C : MOV     R4,#0
F290 : ADD     R5,R1,#&7C000
F294 : LDR     R2,[R5,#342] ; whoops!
F298 : MOVS    R2,R2,LSR #16

Definitely not ARMv7-safe! If that was compiled at the same time as unzip, I’m inclined to be suspicious of unzip too.

Thankfully, Chris’s zip and unzipsfx have both behaved impeccably. I’m hoping to badger him for a new copy of unzip as well, just for peace of mind.

Hold on, I see I do Jeffrey an injustice… This is the equivalent code in unzip:

LDR R0,&16A70 ;EOF
LDRB R12,[R7,#340]
LDRB R2,[R7,#341]
ORR R2,R12,R2,LSL #8

So unzip is definitely safe, then. I wonder why unzipsfx doesn’t match?

Interesting – maybe I rebuilt unzip after switching to a compiler that worked, and didn’t think of rebuilding unzipsfx at the same time. Anyway, it should be easy enough for me to rebuild everything when I get home.

Archive updated to be contain ARMv7-safe versions of everything.