Cortex-A8 software compatibility list slightly reorganised

Hi all.

A while ago, I went through my entire software collection, testing each one for BeagleBoard compatibility, and recording the result. Based on this, I’ve updated the Cortex-A8 software compatibility list.

The list of applications had now become rather long, and with only alphabetical sorting by name, it could be difficult for someone to find what software exists for a specific category, unless they know the application names.

For this reason, I’ve taken the liberty of reorganising the list, grouping the applications by category (and alphabetically within each category). I hope this is ok, and the list is now similar to the Cortex-A8 hardware compatibility list, and I’ve used the same formatting as that one.

With URLs provided for most of the software, this list also helps to provide a one-stop-shop for RISC OS software, especially for the BeagleBoard, now that many other archives seem to languish for lack of maintenance.

As the list was, it could seem that only a handful of applications works on the BeagleBoard, when in reality, it seems that most of the Iyonix-compatible software works there, and major applications like ArtWorks 2 and Photodesk were missing from the list. I’ve only added applications that work at the BeagleBoard, as that still gave a rather long list.

Hard-working RISC OS porters: You can be proud of yourselves!

Regards,

Terje

P.S. I’ve still got a bunch of utilities to add to the list.

The latest version 2 of QuickFiler is (and has been for many years now) available from www.avisoft.f9.co.uk, and is the version most likely to be used these days, rather than the original v1 from Dave Thomas.

Ok, I’ve now updated that entry with the new URL and version.

That’s a job well done, Terje. Thanks. As a slight amendment, I’ve added ‘Top’ hyperlinks at the bottom of each section (and done the same for the Cortex-A8 hardware compatibility page too) as recently included in the Build FAQ .

Note that there are also a number of games (converted using GCC) which have been reported to work .

Note that there are also a number of games (converted using GCC) which have been reported to work .

That’s excellent. :)

We’re really missing games on the BeagleBoard, and one of the main problems, it seems – and this also goes for several demos – is that they assume a certain screen mode (typically in the range of the ones available on the Archimedes), and I guess it may simply be a problem to get the BeagleBoard to use such a low resolution as e.g. 320×256, and ditto for the monitor.

Could anyone with BeagleBoard/monitor knowhow comment on this, perhaps? I mostly assume it, as the BeagleBoard mode files I’ve seen haven’t gone below 640×480 in resolution.

Anyway, I will test out those games when I get home.

I’ve also tested the RISC OS demos at pouet.net, but not a single one of them runs on the BeagleBoard… Again, it seems that missing modes is a key problem for several of them.

Speaking of GCC: This is somewhat OT here, but has anyone managed to get GCC 4 to run on the BeagleBoard? I tried to install it last night, but RiscPkg aborts with an error message about “Bad source path”, or something like that, after having downloaded all of the packages for it…

I’ll try a manual install tonight.

We’re really missing games on the BeagleBoard.

There’s relevant discussion in this IGEP thread too (but no MDFs).

The only real problem with using low-res modes on the beagleboard is that most modern monitors (especially ones with only DVI or HDMI input) won’t like them. Luckily there are a few solutions to this – upscale the image using the video controller (but unfortunately this won’t work with palettised modes, which is what most games would be using), upscale the image in software (could be a fairly nasty CPU performance hit if it the scale factor isn’t an exact multiple of 2/3/4), upscale the image using the SGX (if only we had the docs!), or – something I’ve just thought of now – upscale the image using the DSP. Using the DSP for upscaling could be very convenient, as it would allow us to use smarter algorithms than if we just used the SGX (e.g. write a scaling algorithm which only writes pixels to the destination if the source pixels have changed). Plus we have access to all the docs and tools!

Another solution for the low res modes would be to use the TV-out. At some point I’ll need to remember to add special support for modes with double-height pixels, since the interlaced output allows us to do 2x vertical upscaling for free.

Anyway, apart from not having the right MDFs available, I suspect the bigger problem with running demos and old games on the beagleboard is that a lot of them aren’t 32bit compatible to start with. For that all I can do is hope that someone writes a decent Archimedes/RiscPC emulator for ARM before I’m forced to do it ;)

Speaking of GCC: This is somewhat OT here, but has anyone managed to get GCC 4 to run on the BeagleBoard? I tried to install it last night, but RiscPkg aborts with an error message about “Bad source path”, or something like that, after having downloaded all of the packages for it…

GCC itself will run without any problems, but I’ve never tried installing it via RiscPkg. In fact I’ve never even used RiscPkg before, so I can’t comment on whether it runs correctly or not :)

Thanks for the thoughtful reply. Your posting will serve as a nice reference for anybody revisiting this issue.

GCC itself will run without any problems, but I’ve never tried installing it via RiscPkg. In fact I’ve never even used RiscPkg before, so I can’t comment on whether it runs correctly or not :)

I hadn’t used RiscPkg before yesterday, either, but it seemed like a good idea, as a convenient way of being able to download, update and remove applications en masse, and keeping track of all dependencies, removing stuff when it’s no longer needed.

I’m not too happy about the solution of having each application be installed at a fixed place, but that’s a minor thing, and it worked for a few things, but not GCC.

There’s relevant discussion in this IGEP thread too (but no MDFs).

Thanks for the tip!

Amazingly, testing this on the BeagleBoard now, I can actually get several of the following modes. Here’s the complete list (table taken from here):

Mode      Col x Row   Colours   BeagleBoard
0  80×32  640×256       2       Ok
1  40×32  320×256       4       -
2  20×32  160×256      16       -
3  80×25  Text only     2       Ok
4  40×32  320×256       2       Ok
5  20×32  160×256       4       -
6  40×25  Text only     2       -
7  40×25  Teletext     16       -
8  80×32  640×256       4       Ok
9  40×32  320×256      16       -
10 20×32  160×256     256       -
11 80×25  640×250       4       Ok
12 80×32  640×256      16       Ok
13 40×32  320×256     256       -
14 80×25  640×250      16       Ok
15 80×32  640×256     256       Ok
16 132×32 1056×256     16       -
17 132×25 1056×250     16       -
18 80×64  640×512       2       Uses corresponding VGA mode
19 80×64  640×512       4       Uses corresponding VGA mode
20 80×64  640×512      16       Uses corresponding VGA mode
21 80×64  640×512     256       Uses corresponding VGA mode

Unfortunately, some of the missing modes are rather popular with existing games and demos…

To get these (or even to be able to run them with a regular boot sequence), it seems we have to resort to one of the alternatives Jeffrey mentioned.

RISC OS 5 (as well as some versions of RISC OS 4/6) provide software emulation of teletext mode (i.e. mode 7). I’m not sure what the exact requirements are in RISC OS 4/6, but for it to work in RISC OS 5 you need a 640×500 mode (see here for more details). I think if you dig round through some of the standard MDFs supplied with the boot sequence then you might be able to find a premade 640×500 mode.

Modes 3 and 6 – I believe these were “gap modes” where there was an extra scanline or two inbetween each row of text. To keep things simple support for the scanline gap was removed in RISC OS 5, so although you can still select those modes they won’t look quite the same as they did before.

> Note that there are also a number of games (converted using GCC) which have been reported to work .

Quite a few of the games on riscos.info default to full screen mode. Which has problems on Beagleboard/LCD monitors.
You’ll have to fiddle with !Run file options to get them to run in a window. Hopefully they’ll be updated soon. I’ve got them
all working locally plus a few others.

Here’s a couple of games that aren’t on the site yet.

lemmings

flobopuyo

If anyone’s got any requests for other games i’ll see what I can do. See The linux game tome for ideas.
It just needs to support SDL and not rely on opengl.

@Terje: You said ‘Ok, I’ve now updated that entry with the new URL and version’ in response to my comment about QuickFiler. And indeed, the history shows you did. However, 2 minutes later the next update by Trevor removed your change!

Are pages not locked while updates are in progress?

And how are quotes done on the forum? – there is no mention in the Textile Reference!

I put an entry on the wish list for a simple automatic modes system.

@Terje: You said ‘Ok, I’ve now updated that entry with the new URL and version’ in response to my comment about QuickFiler. And indeed, the history shows you did. However, 2 minutes later the next update by Trevor removed your change! Are pages not locked while updates are in progress?

Apparently not! I noticed the same, and changed the URL once again. I guess the system doesn’t know when someone “finishes” editing a page (someone might click the edit button and then leave, locking the page forever), so any locking system could be difficult.

For this reason, to avoid overwriting other people’s changes, I usually refresh the page just before saving any new content, to make sure that nobody else has done any changes in the mean time (it would then show by who last edited the page).

And how are quotes done on the forum? – there is no mention in the Textile Reference!

I asked the same recently in another thread. See here for the solution. For single-level quoting, you can use "bq. <text>", and for multi-level quoting, it’s possible to nest <blockquote> elements.

However, 2 minutes later the next update by Trevor removed your change! Are pages not locked while updates are in progress?

Apparently not! I noticed the same, and changed the URL once again.

It appeared at July 04, 16:34 and was still there at July 05, 08:02 but ISTR searching for QuickFiler at the time and not finding it. It doesn’t seem to have disappeared in the history (so I’ve probably missed something).

For this reason, to avoid overwriting other people’s changes, I usually refresh the page just before saving any new content, to make sure that nobody else has done any changes in the mean time (it would then show by who last edited the page).

That’s a good safety measure to adopt. I’ll try to remember to try it.

(Perhaps there’s some sort of bugfix update which somehow checks whether the Edit link was activated by multiple users before their changes were committed and then checks for differences! Or, rather, perhaps not.) Anyway, it could always be submitted as a ticket under I2 to lock pages as Martin says.

"There is a listing of some [software] on the ROOL site, but parts of it are out of date, and it doesn’t seem to be updated very often."

There are very few applications listed as “Crashes”. Perhaps it’s the case that people try a useful bit of software, only to find it not working but don’t list it as crashing in the table. Therefore, how about encouraging use of specified terms in the “Status” column and asking for all other info to go under “Notes”? e.g.

• ApprovedOK (recompiled/addressed by author(s) – willingness to address further issues as they arise)
• OK (appears fully functional)
• Partial (list details under “Notes”, including if modified files are required from elsewhere)
• AlignOff (appears to function correctly with alignment exceptions turned off)
• Crashes (refuses to run, or fails to function under basic use, whether alignment exceptions are turned on or off – list details under “Notes”)

I agree with the need for specified statuses. For one thing it would avoid people testing with alignment exceptions off and then putting OK in the status column: I have found examples of this in the table before. I think in the early days some people were habitually using their machines with exceptions off. Maybe they still are!

I wonder whether “Supported” might be a better wording than “ApprovedOK” for software where the author is involved. It would also apply to open source software for which someone has taken responsibility for recompiling/updating the application.

I would be tempted to combine “Partial” and “Align Off” because the latter is a subset of the former and I don’t really like people thinking that something working only when alignment exceptions disabled means that they can safely use the software in that case. The truth of the matter is that it is executing undefined instrutions and nobody has yet found the magic circumstances where something terrible results… So I would have four categories:

1. OK and supported
2. Seems to be OK
3. Has known issues
4. Doesn’t work

(Maybe not those names but meaning that.) At some point, we could possibly have some sort of formal test/acceptance process which would mean the top-most group get the stamp of approval whereas the second group don’t, but are still marked as seeming to work.

# OK and supported
# Seems to be OK
# Has known issues
# Doesn’t work
(Maybe not those names but meaning that.)

Thanks for the suggestions. I think it could be simpler for people to complete the form if the status definitions are kept short and use WordsRunTogether. This can speed up copy/pasting and also make it easier to follow at a glance without reading several words. Therefore, how about:

1. OKSupported
2. OK (There could be a note explaining that “OK” actually means “Seems to be OK”)
3. HasIssues
4. NotWorking

If people think those terms could cause confusion, the table can be updated instead with the fuller definitions Steve just proposed. In any case, when comments are finished with, I’m happy to tidy the table up within the next week or so.

I think it would be more readable in separate words, but I think Trevor’s suggestions for briefer descriptions are fine. There will have to be an explanation of what they all mean anyway to ensure that misguided users don’t put “OK” against software they have tested with alignment exceptions off.

Thanks – how’s this?

1. OK and Supported¹
2. Seems to be OK²
3. Has Issues³
4. Not Working⁴

¹ Works OK, involvement of author(s), willingness to address further issues as they arise.

² Appears fully functional (with alignment exceptions left on).

³ Observed to have issues, but some functionality is available.

⁴ Does what it says on the tin.

I’d be happy with “OK” rather than “Seems to be OK”. If Steve is keen on being a little less definite, then “Seems OK” might be shorter but still carry the same meaning!

Let me know when you decide to go ahead, then I can log in and put “OK and Supported” against our software….

Right, I’ve made a stab at updating things. Apologies to anyone whose software is showing an incorrect status. All references to “OK with alignment exceptions off” have been removed. If people feel it would useful to retain such notes, perhaps they could be included in the ‘Notes’ column. The old version is of course still available, for reference.

Any (polite) suggestions as to the best category for my USB toy drivers?