RISC OS on the Raspberry Pi

fetch a single RISC OS module (usually over an IP network)

For the RPI it would be a single RISC OS module (from a file stored on the SD card, perhaps 60M or so in size)

press coverage

Brilliant! How about the LinkedIn suggestion too?

licence checking, compatibility checking

The Licence column is now split (for the Compression section only, at this stage), with a footnote explaining things. Before we faff around copying to other sections, what do people think? Maybe the Compatibility column should also behas been split ARMv7 and “Tested on actual RPi dev board”.¹

¹ Preferably the actual retail one, assuming we can get our eager collective hands on some!

Progress report

As Steve says, time is going to be very tight for a release with RPi. Here’s a rundown of what’s happening at the moment:

• USB driver: I think Adrian is working on this – I haven’t heard any news since the show
• SD driver: Ben and I are looking at this (more help welcome)
• RISC OS licensing: discussions ongoing
• Contact with RPi: discussions ongoing

Now, there are still some big areas that we need help with.

Biggest is the disc image, and that’s something that anyone with a RISC OS 5 machine can do (even a Risc PC with softload IOMD ROM). What I’m thinking is a series of applications each in their own directory containing:

• !Application
• !Boot containing any files that need to be merged (just those files), and any sensible default Choices: configuration (bearing in mind users aren’t necessarily in the UK)
• Documentation in some obvious format (ie not a hundred random text files)
• Licence (a file with the licence text, don’t include the whole GPL etc). Also an indicator of the licence in some machine readable format (eg text file saying ‘GPL’, ‘BSD’, ‘Freely distributable, no source’, etc)
• URL to the program’s homepage
• Source code (for that version of the program, if available)

All need to be in a consistent naming scheme (so that we can remove all the source code with a script, or only copy applications that are GPL, for example)

The ROOL USB stick contains the basic RISC OS disc apps plus a few extra (StrongEd, SwiftJPEG, PDF and others), so there’s plenty of scope for expansion.

Also, help with what to do when there’s no RTC would be good. And if someone wants to investigate PackMan (which I haven’t even tried) and whether it might fit in to the above idea of application distribution (eg, the above list is starting to look like the sort of manifest you might find in a package – so maybe the disc image is a load of packages preinstalled and PackMan is available to fetch more).

Plus documentation, documentation, and more documentation. Particularly something of the ‘WTF is RISC OS?’ which is displayed on first boot to show people how to do basic operations (select, menu, adjust, using the Filer, accessing Help files, drag and drop, interactive help, etc). Could we do a video of some kind (eg with one of those mouse click replay things rather than a big MPEG/Replay file)?

I’ll be a bit quieter around here as I’m busy looking at SD stuff, so if other people want to take on some more tasks that would be great. (And please add others to the wiki page that I may have missed in this thread)

#PiRO is the official hash tag for Raspberry Pi + RISC OS tweets.

Regards,
Martin.

http://www.RISCOScode.com

P.S. On a MacBook Pro laptop, # is obtained using alt+3.

Biggest is the disc image, and that’s something that anyone with a RISC OS 5 machine can do (even a Risc PC with softload IOMD ROM).

I have an old SA RPC with a removable hard drive that I fitted to play with RO 5, however, aren’t network drivers still an issue.

I also have an Iyonix, fitting a drive bay, might be possible.

(I am assume that the idea is to be running the actual release candidate.)

What I’m thinking is a series of applications each in their own directory containing:
• !Application
• !Boot containing any files that need to be merged (just those files), and any sensible default Choices: configuration (bearing in mind users aren’t necessarily in the UK)
• Documentation in some obvious format (ie not a hundred random text files)
• Licence (a file with the licence text, don’t include the whole GPL etc). Also an indicator of the licence in some machine readable format (eg text file saying ‘GPL’, ‘BSD’, ‘Freely distributable, no source’, etc)
• URL to the program’s homepage
• Source code (for that version of the program, if available)

(It’s possibly a bit late in the day but:)

Wouldn’t it make it easier for new users if the application directory idea were extended?

There is already a standard location for help. Which should be used for documentation, including licence and URL (and possibly sources).

But could this idea be extended to the resources a program needs?
i.e. a standard location containing what would be merged with the boot.

The sysmerge part of configure could be modified to look in this location if an app dir is dropped on it.

The app would load resources from this location if they haven’t been installed into the main system.

(The next logical step would be for the appdir to be an archive that the system could read directly as if it were a normal folder.)

#PiRO is the official hash tag for Raspberry Pi + RISC OS tweets.

Aw, that’s lovely. So we’re all PiRO-maniacs!

Wouldn’t it make it easier for new users if the application directory idea were extended?
There is already a standard location for help. Which should be used for documentation, including licence and URL (and possibly sources).
But could this idea be extended to the resources a program needs?
i.e. a standard location containing what would be merged with the boot.

Wouldn’t this somewhat fly in the face of what package managers are trying to achieve, which is a separation of the distribution of system-wide resources from the applications that use them? That said, a standard file within an !application directory that describes its dependencies (in terms of package names/versions) would be nice, rather than having that at the same level as, or some higher level than, the !application directory, as (I believe) is currently the case.

Or did I misunderstand what you meant?

I’ve put what are hopefully ARM v7 compatible versions of Hive and TANKS on my web site, at http://www.btinternet.com/~rik.griffin/

If someone with appropriate hardware has time to test them briefly I’d be very grateful. If someone could also add the information to the software compatibility list, that’d be great.

Sorry to moan, but it’s still not possible to edit the wiki from RISC OS. I know this web site is provided by the ROOL peeps in their spare time, but it’s rather frustrating to want to contribute, and not be able to because I’m using RISC OS!

As the author of PackMan I believe it would be a valid solution for package management on the Disc Image. I would though wouldn’t I;-)

It would be perfectly possible to install the base packages and then clone the disc with PackMan and the package information.

Ideally packages would then need to be created for everything that is going to be shipped in this way. I’m willing to help with or do that if the authors give permission.

The package management system already has the provision for a shared copy of the GPL and a few other licenses that all packages can refer to.

Ideally the packages would be available from the main riscpkg site so everybody can install them whatever version of RISC OS they have. If this is not possible ROOL could host its own package site.

The main riscpkg site has to keep a copy of all sources it distributes under licenses that require it. Would this be enough so that you did not have to put the sources on the disk image?

Would this be enough so that you did not have to put the sources on the disk image?

In that case, I think "written offers of sources" would still be required. Ideally IMHO this would be a paper copy, but that’s useless for downloaded disc images. In that case, perhaps text and HTML offers (for all relevant products/sources) could be placed on the pinboard by default. That way, users would be unlikely to miss them, and could remove them once read.

Afterthought… as the R-pi is all about coding, don’t we want to encourage the inclusion of sources?

Wouldn’t this somewhat fly in the face of what package managers are trying to achieve, which is a separation of the distribution of system-wide resources from the applications that use them? That said, a standard file within an !application directory that describes its dependencies (in terms of package names/versions) would be nice, rather than having that at the same level as, or some higher level than, the !application directory, as (I believe) is currently the case.

If everything on the image were distributed by packman, that would be far better.

This is for when packaging is not appropriate or not available. this would give the option of running an app as is (either for testing, or maybe on an external drive on system that is locked).

It would be possible to have an installer program that merged the resources with the system, and deleted them from the appdir.

Or did I misunderstand what you meant?

Only in that it came across as me not wanting packaging.

(The next logical step would be for the appdir to be an archive that the system could read directly as if it were a normal folder.)

installer program […] deleted them from the appdir.

But not if the user only has a read-only archiving system.

Alan, if you have some time to create packages that would be great. Hopefully most software will say ‘freely distributable’ or similar without having to ask permission from authors (and deal with broken websites, email addresses, etc, etc) though contact may be required if there are conditions on distribution (eg must be distributed unmodified). (Before we indulge in the standard packaging flamewar, I’m thinking of a system that comes with software preinstalled that just happens to be packages extracted in a particular way… the user doesn’t have to use the packaging system but it’s there if they want it)

Jess, if you have a chance to help that would be really helpful. Testing on an Iyonix should be fine. I wouldn’t worry so much about having an actual FileCore disc image for testing (removable drives etc)… you can just create a directory called, say, $.RPi and build up a directory structure in there. If you want to test out booting from it, move $.!Boot out of the way and make an Obey file $.!Boot which contains ‘Obey <Obey$Dir>.RPi.!Boot’. Only the final build will need to test a real FileCore disc image. Perhaps you could collaborate with Alan?

Inclusion of sources is good, but we may have limits on disc image size (128MB has been talked about). However, for things where source is provided we should have a copy of the source stored on a server somewhere so that when the author’s homepage disappears we can still cope. It doesn’t have to be in a tidy format (for the moment), just a pile of files will do. The RiscPkg method sounds fine to me.

Trevor, that ‘written offers of sources’ page highlights some of the problems with programs having all kinds of random license conditions, which is why we need an audit to check we have rights to distribute things and any weird conditions flagged up (eg can’t distribute if any money changes hands, or can’t put the source on a bulletin board, or whatever). A written offer of sources being available (where we have sources, irrespective of whether they’re under licenses that require written offers) will probably suffice… we can work on the infrastructure for sources as and when it becomes necessary.

Educational software

Does anyone here remember a Beeb program showing "a schematic diagram of the major components of a simple computer" and 6502 emulator? Who wrote it/published it? Was it in BASIC and therefore easy to adapt? It’s not modern but sounds to me as if the concept is transferable.

if you have some time to create packages that would be great.

I haven’t a lot of time, but I should be able to do this.

Hopefully most software will say ‘freely distributable’ or similar without having to ask permission from authors (and deal with broken websites, email addresses, etc, etc)

Unfortunately this doesn’t seem to be the case, quite often there
is some non-standard condition or there is no statement of copyright
at all.

However most developers I’ve contacted seem to be very helpful
and are happy to give me the copying details and let me create
a package.

I don’t really want to package anything unless I can contact the developer and he/she says it’s OK.

If the developer has left the scene and the copyright/distribution
rights are absolutely clear I supposed it wouldn’t hurt to package
it anyway.

Is there a definitive list of the packages we want somewhere?

I’m not sure of my available time, but I’m more than happy to help test the packaging. I might even be able to help with the creation.

Is the plan to get everything on the image packaged. That would be excellent if possible.

Inclusion of sources is good, but we may have limits on disc image size (128MB has been talked about).

The Compressed source sizes can also be noted. I’ll try to have a look at filling in some of the blanks when I can (initially for Printing).

!Boot structure

The current disc image contains stuff like !Boot.Utils.HOff, which AFAICT is redundant because it’s in the ROM. If this is correct, then I suppose it’s because the sequence is based on the “Universal boot”.

• Is such a catch-all boot still needed, if the intended target is exclusively RO5? If the sequence is run on a non-supporting environment, wouldn’t a message advising where to obtain a compatible sequence suffice?
• In addition to stripping out the amount of unused data, there could possibly be some streamlining of the process to require less files/accesses – as already pointed out by someone IIRC. (I’m able to look into this, but wouldn’t know at all where to start with the networking stuff.)
• There are some iconsprites (including the !boot sprite itself) which are on the disc and may be better placed in the ROM (if there’s room).

What else have I missed?

Trevor, although it’s attractive to think about replacing !Boot with a more stream-lined, updated version which is specifically designed for RO5 with the future in mind, I think it’s probably unsafe to go tinkering with it before the RPi release. We’ve probably got enough on our collective plate without fixing stuff that isn’t broken. And I’m not just saying that, I really do like the idea of having a completely new boot sequence for RISC OS which somehow can support existing apps…

OK – point taken. As you like the idea, I hope to revisit this in the future.

[Edit: This has (to some extent?) already been looked at.]

Popular RISC OS apps ready configured

Any thoughts on the contents of "the most useful freeware and public domain software" at RISCOS Ltd?

That’s a nice list! Though a good chunk isn’t 32 bit, and some things will have been orphaned/superseded since 2003-ish when it was written. It can still be a useful starting point.

I’ve put a list of the interesting files on ROOL’s native FileCore image here:
https://www.riscosopen.org/wiki/documentation/show/ROOL%20native%20USB%20image
which should give you a rough idea of starting point (assuming ROOL are happy for us to use this).

Alan, in terms of packaging/assembling disc image, I’d start with major apps (StrongEd, Zap, NetSurf, PDF, GCC, InfoZip, GhostScript, etc) and proceed from there. If there’s stuff that’s already packaged and not too esoteric, might as well bring that in too as long as it isn’t confusing/show the platform in a bad light/etc. I think a disc image organised by function (‘Apps.Editors.!Zap’) is probably going to be necessary given that people won’t have the foggiest that Zap is an editor.

According to ROL’s list and the ARMv7 compatibility list, there are huge areas where there’s no free software that is 32 bit compatible. Office apps, a traditional strong point for RISC OS, for example. So it may just be a case of ship as much as we can.

Alan, in terms of packaging/assembling disc image, I’d start with major apps (StrongEd, Zap, NetSurf, PDF, GCC, InfoZip, GhostScript, etc) and proceed from there

Already on the main packaging site are StrongEd and PDF. The GCC there is an old version. There is an autobuilder packaging site as well with lots of ports and the newest release GCC – maybe we should add this to the sources list on the image – However the programs here can get broken as they may get automatically built every now and again – Any thoughts on this?

Similarly Netsurf has a development build packaging site – could this be used or should we see about getting a stable release to the main packaging site?

I’ll look at your other suggestions and see what is involved.

In case it’s not clear I thought I better say my intention is just to create the packages so they are available for someone else to use to create the disc image – though obviously I will help with the packaging part in any way I can.

I think a disc image organised by function (‘Apps.Editors.!Zap’) is probably going to be necessary given that people won’t have the foggiest that Zap is an editor.

The current packaging system already does this. Though I think it uses Apps.Text for text editors.

For info, my new “Supporting RISC OS on Raspberry Pi” website is now online.
http://www.piLEARN.com
All done in one massive 30 hour non-stop coding session – mainly as I want to focus on content and having to do the site was an obstical to getting on with that.
Tested on IE, Firefox, Oregano2 and Netsurf where it seems to work fine.
Main hitch was finding a bug in Safari, which took ages to work out, but was easy enough to code around once isolated.
Regards,
Martin.