RISC OS Open
Safeguarding the past, present and future of RISC OS for everyone
ROOL
Home | News | Downloads | Bugs | Bounties | Forum | Documents | Photos | Contact us
Account
Forums → General →

Cortex-A8 software compatibility list slightly reorganised

Subscribe to Cortex-A8 software compatibility list slightly reorganised 32 posts, 9 voices

Posts per page:

Pages: 1 2

 
Jul 4, 2010 9:16am
Avatar Terje Slettebø (285) 275 posts

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.

 
Jul 4, 2010 7:11pm
Avatar Martin Avison (27) 1375 posts

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.

 
Jul 5, 2010 7:02am
Avatar Terje Slettebø (285) 275 posts

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

 
Jul 5, 2010 7:19am
Avatar Trevor Johnson (329) 1645 posts

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 .

 
Jul 5, 2010 12:36pm
Avatar Trevor Johnson (329) 1645 posts

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

 
Jul 5, 2010 2:44pm
Avatar Terje Slettebø (285) 275 posts

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.

 
Jul 5, 2010 3:05pm
Avatar Trevor Johnson (329) 1645 posts

We’re really missing games on the BeagleBoard.

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

 
Jul 5, 2010 3:25pm
Avatar Jeffrey Lee (213) 6034 posts

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

 
Jul 5, 2010 4:04pm
Avatar Terje Slettebø (285) 275 posts

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.

 
Jul 5, 2010 4:43pm
Avatar Terje Slettebø (285) 275 posts

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.

 
Jul 5, 2010 5:01pm
Avatar Jeffrey Lee (213) 6034 posts

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.

 
Jul 5, 2010 6:51pm
Avatar Chris Gransden (337) 1130 posts

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

 
Jul 5, 2010 9:24pm
Avatar Martin Avison (27) 1375 posts

@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!

 
Jul 6, 2010 6:49am
Avatar Jess Hampshire (158) 864 posts

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

 
Jul 6, 2010 10:13am
Avatar Terje Slettebø (285) 275 posts
@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.

 
Jul 6, 2010 11:04am
Avatar Trevor Johnson (329) 1645 posts
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.

 
Jun 9, 2011 12:55pm
Avatar Trevor Johnson (329) 1645 posts

"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”)
 
Jun 12, 2011 6:34am
Avatar Matthew Phillips (473) 661 posts

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.

 
Jun 13, 2011 4:48pm
Avatar Steve Revill (20) 1361 posts

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.

 
Jun 13, 2011 7:17pm
Avatar Trevor Johnson (329) 1645 posts
# 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.

 
Jun 14, 2011 6:43am
Avatar Matthew Phillips (473) 661 posts

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.

 
Jun 14, 2011 7:36am
Avatar Trevor Johnson (329) 1645 posts

Thanks – how’s this?

  1. OK and Supported1
  2. Seems to be OK2
  3. Has Issues3
  4. Not Working4

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

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

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

4 Does what it says on the tin.

 
Jun 14, 2011 9:02pm
Avatar Matthew Phillips (473) 661 posts

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

 
Jun 20, 2011 2:19pm
Avatar Trevor Johnson (329) 1645 posts

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.

 
Jun 20, 2011 4:12pm
Avatar Dave Higton (281) 668 posts

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

Next page

Pages: 1 2

Reply

To post replies, please first log in.

Forums → General →

Search forums

Social

Follow us on and

ROOL Store

Buy RISC OS Open merchandise here, including SD cards for Raspberry Pi and more.

Donate! Why?

Help ROOL make things happen – please consider donating!

RISC OS IPR

RISC OS is an Open Source operating system owned by RISC OS Developments Ltd and licensed primarily under the Apache 2.0 license.

Description

General discussions.

Voices

  • Terje Slettebø (285)
  • Martin Avison (27)
  • Trevor Johnson (329)
  • Jeffrey Lee (213)
  • Chris Gransden (337)
  • Jess Hampshire (158)
  • Matthew Phillips (473)
  • Steve Revill (20)
  • Dave Higton (281)

Options

  • Forums
  • Login
Site design © RISC OS Open Limited 2018 except where indicated
The RISC OS Open Beast theme is based on Beast's default layout

Valid XHTML 1.0  |  Valid CSS

Powered by Beast © 2006 Josh Goebel and Rick Olson
This site runs on Rails

Hosted by Arachsys