RISC OS on the Raspberry Pi

Coypu

but there’s !Tau which does a similar job.

Ah yes, most recently developed by the late Peter Killworth. This seems to work fine. The licence is GPL v2 (1991) and the source is an uncompiled, uncrunched BASIC runimage. To my untrained eye this looks to use logical naming for variables and procedures, and includes some comments.

So as soon as I can get my sticky hands on one I’ll update the module.

Thanks. That’s what most of us were probably hoping you’d say ;-)

@WPB

The thread was on comp.sys.acorn.misc

Just go to http://groups.google.com/ and search for freesans limited to comp.sys.acorn.*

Try this link

Theo intervened in the thread to suggest people convert a few fonts. I did FreeSans, FreeSerif and FreeMono. I’ve also got conversions of Charis SIL and Old Standard but I have not uploaded these yet.

Thanks, Matthew. Been there now and posted.

fonts

For those not uncomfortable with the retro image, how about Oxford CP (based on Christine Lord’s design)?

I think it would be particularly good to aim towards packaging as a wider goal.

Would online distribution be another goal for the future? For reference, the Pandora store seems to be finalised now.

The thread was on comp.sys.acorn.misc

I see in that thread there was some question over the latest version of TTF2f, and where to get it. There’s now a project page for it on the NetSurf site, so it should be easier to find in future.

http://www.netsurf-browser.org/projects/ttf2f/

Also, the thread mentioned using some converter to convert OpenType fonts to TrueType fonts before using TTF2f. There is no need for this; TTF2f supports OpenType and other formats itself.

Also, with respect to the proposed disc image, I don’t think it includes an image viewing app. How about PrivateEye?

http://www.davespace.co.uk/risc.os/privateeye.html

Apologies to everyone who has emailed me recently, was away for the weekend and still wading through the backlog…

‘Online distribution’ is very much a goal too… which is not restricted to RPi. The idea would be you’d buy your BeagleBoard/Touchbook/whatever, connect it to the internet and say ‘please install Zap, NetSurf, PDF, FTPc, etc etc’ and it just does it. No faffing around googling for the author’s website, finding their old site is down, that their software isn’t compatible with a modern machine but someone else has made a newer version, etc etc. If this is useful for distribution of commercial software, then that’s possibility too (would need extra crypto so that only people who have paid can use the software).

PrivateEye looks good, but there’s a problem with the copyright. The manual says only this:

This software (“PrivateEye”) is copyrighted work of David Thomas, it is supplied to you, the user, “as is”; you use
this application entirely at your own risk. The author makes no warranty as to the fitness of this software for any purpose. In no circumstances will the author be liable for any loss arising from the use or inability to use this software.

Which is fine, but nowhere does it give permission to use it or distribute it. So all users should technically delete it straightaway. Another one to add to the list of things we need to sort of licensing for.

PrivateEye looks good, but there’s a problem with the copyright.

It is open source: http://www.riscos.info/websvn/listing.php?repname=privateeye

But you’re right, I can’t see any info on the licence.

from the svn:
http://www.riscos.info/websvn/filedetails.php?repname=privateeye&path=%2Ftrunk%2Fdocs%2Fprivateeye%2FReadMe
It says it is ‘freeware’ which may be interpreted as free to distribute, right?

It’s freeware. I have no objections to you including it.

(Ideally I need to get a proper ARMv7-compliant rebuild out at some point).

Thanks, that’s good to know. Will the autobuilder not handle a build?

Apologies for being tediously pedantic (but that’s what lawyers are), but ‘freeware’ doesn’t have any legal meaning… since the default state of copy-rights is to be reserved, if the documentation doesn’t say that something has permission for distribution, use and (optionally) modification, then it doesn’t have that permission. Have you considered putting it under a licence such as Simplified BSD ?

Dear Theo, (or anyone else who wishes to chip in)
I’m about to do some work on the ‘Novice" page at piLEARN and would welcome some clarity on what a novice will have to do to get RISC OS running on the Raspberry Pi.
As I understand it,
1) Raspberry Pi are planning to sell various Linux distributions, each on an SD card. Is RISC OS going to be available in this way ? From ROOL or Raspberry Pi ?
2) You are putting together a ’disk image’ which ROOL will sell as a USB pen drive (for £10) containing all the apps that are being discussed in this forum.
Is my understanding correct, or are there complications/subtleties I’ve not properly understood ?
Regards,
Martin.
P.S. You & your team are doing a great job sorting this ‘disk image’ out.
( Any names you’d like me to mention ? )

Another 2p’s worth of suggestions for the disk image:

1p) !SysLog, which I’ve used successfully on ARMv7 hardware.

2p) AppBasic. I don’t know if this is ARMv7-compatible or not. Someone would have to check (I’m afraid I can’t right now). If it is, I think it’d be a great addition. It’s well documented, introduces the Toolbox (which I think should be encouraged as much as possible), and offers a more “visual” (in the MS sense) way of writing software.

Presumably at some point this disk image will be frozen and no more additions will be made?

‘Novice" page at piLEARN

That’s a good idea and I think it’s important for things to be checked before it’s created (as you’re doing here).

You are putting together a ’disk image’ which ROOL will sell as a USB pen drive (for £10) containing all the apps that are being discussed in this forum.

Is the assumed £10 price being based on the current native stick? This may or may not be correct, based on the cost of the media and time for duplication. It also seems to be the intention to offer an image of an SD card for download.

With the SD card drivers, the disc image should be usable on the same card as the RO ROM image. This will hopefully mean the R-Pi can use a normal boot sequence without needing a separate USB hub (even the model B only has 2 USB ports).

I think that the options for getting RO up and running for a novice could be as follows (but of course Theo, Jeffrey, Ben, Adrian, CTL, ROOL and anyone else involved will have a more informed idea):

1. Ideal scenario
   1. Obtain a prepared RO SD card containg the OS and boot sequence (either shipped with the board, created from downloaded SD card image or bought from a third party)
   2. Connect a kb and mouse (and optionally ethernet-over-USB adapter via a powered hub)
   3. Insert the SD card and turn the power on
   4. Maybe set the clock (if no internet connection)
2. Possible scenario with prepared USB boot device
   1. Obtain a prepared RO SD card containg the OS, but not the boot sequence¹ (either shipped with the board, created from downloaded SD card image or bought from a third party)
   2. Obtain prepared boot sequence in RO format for use via USB (either shipped with the machine, created from downloaded image or bought from a third party)
   3. Connect (via a powered hub) kb, mouse, USB drive (and optionally ethernet-over-USB adapter)
   4. Insert the SD card and turn the power on
   5. Maybe set the clock (if no internet connection)
3. Possible scenario involving extraction of boot sequence to USB device under RO
   1. Obtain a prepared RO SD card containg the OS, but not the boot sequence¹ (either shipped with the board, created from downloaded SD card image or bought from a third party)
   2. Obtain self-extracting boot sequence for use via USB (either shipped with the machine, created from downloaded image or bought from a third party)
   3. Connect (via a powered hub) kb, mouse, USB drive (and optionally ethernet-over-USB adapter)
   4. Insert the SD card and turn the power on
   5. Extract boot sequence, format USB drive and save boot sequence
   6. Shutdown and restart to boot from the extracted boot sequence
   7. Maybe set the clock (if no internet connection)

Is my understanding correct

I think the above scenarios as presented could dissuade some potential users, so your account probably ought to present the simplest viable option² – better to say nothing until we’re clear!

¹ i.e. the current BB situation

² But not promising the unlikely.

The way I’d like to see it work would be a minimal !boot in resources, plus a formatter and a package manager.

The package manager would then be used to fetch the entire image. (Which could then be duplicated of course.)

The package manager would then be used to fetch the entire image.

Sounds OK for those using the board with an internet connection – but a barrier for those who would find that inconvenient.

A some point someone would have to have access to the internet. They would either need to make duplicates of a fresh image to distribute, or such an image would be provided to download with other systems.

Essentially what I’m pushing for is a complete disc image… you just use ‘dd’ under Linux/Mac or the equivalent Windows tool to write it block-by-block to an SD card. Job done. None of the current faffing around with downloading a self-extracting HForm and Boot, reformatting the card underneath it (which failed on my BBxM, leaving me with a corrupted card), copying a new Boot and software onto it, etc etc.

The exact distribution arrangements of ‘official’ disc images and physical media are subject to discussions. However I think it’s important that there is not a restriction on distribution – that it can be distributed on SD card, USB stick, DVD, websites, FTP, bittorrent, by third parties, fourth parties, fifth parties… the key is dissemination. It’s about getting RISC OS and RISC OS software out to as many people as possible. Hence it’s difficult to include software where authors impose restrictions on how something may be distributed… the Linux image will have no distribution restrictions and to maximise exposure we can’t afford to either.

As for a package manager, I see that primarily as a tool for building disc images in a neat way. Once built, the package manager can also handle installing extra software and updates, but that’s a completely optional function (and subject to network access, as you say).

We’ve been working on this from a number of angles, but suffice it to say we’re getting close to having a “Live” RISC OS that can boot directly from the SD card – you have the ROM image on there (which is currently around 20MB in size) that includes the disc image within ResourceFS. During booting, a RAM disc is created and some essential bits put there (Scrap, Choices, some other things). We’ve tested the read-only boot sequence by booting an Iyonix from a CD. We’re now ironing-out the bugs in the big ROM thingy.

However, there are some blockers here – we’ve had no word at all from Adrian on his progress in various areas, there’s no RPi ROM build at the moment for us to base our work on so we’re stuck testing with Beagleboards. Adding all of the third party bits and finishing touches will hopefully happen soon.

Thanks for all the ideas on the RPi disc image proposals page – that’s all useful stuff, keep it coming!

• Amendments to the Community licensing request communication
  • Anyone can make further (sensible) amendments there
• There’s now an extra ‘Conditions’ column at disc image proposals (currently blank, and ideally will stay that way, but we have to be realistic)
  • Please can others help with adding missing applications to the list¹ which have been discussed in this thread and seem to have community support for inclusion?
• I think we could do with some help in contacting people, so please follow the instructions and send off an email or two (updating the page to say you’ve done so)

¹ And continue to do so as others arise.

“Live” RISC OS that can boot directly from the SD card – you have the ROM image on there (which is currently around 20MB in size) that includes the disc image within ResourceFS.

It’s alive, it’s alive! This is great but AIUI we don’t yet know how much space could be allocated for RO on the SD card (it would seem it’ll be significantly >20MB, but we don’t know quite how much extra room we’ll have).¹

During booting, a RAM disc is created and some essential bits put there (Scrap, Choices, some other things).

Should resizing of the RAM disc via Task Manager be disabled until the bug is squashed by the FileCore experts?

no word at all from Adrian

Hopefully he’ll have the OK to release at least what we saw at the show which, if I’ve correctly understood from Theo, probably relies on permission from Broadcom.

¹ And there’s also the issue of multi booting without using the hardware solution of pressing a button – there don’t seem to be any. If RO can’t be accessed from the same SD card as Linux then it looks as if we’ll be restricted to shipping a separate card!

Should resizing of the RAM disc via Task Manager be disabled

I fixed the one zone harddisc problem in FileCore 3.46 a few weeks ago. Keep up at the back!

Keep up at the back!

I thought I was! Obviously I should be trying harder! Thanks.

I’ve just remembered something else I wanted to add. I’m sure there’s been some talk on the RPi forum (I don’t keep up with it all, but I bet some of you do) about booting to the CLI rather than GUI. Is this an option? Something like

Going to desktop in 3 secs.
<SPACE>  go now
<ESCAPE> exit to CLI

If exiting to the CLI I guess people would probably still want the Library directory set up, and maybe the CSD set to an appropriate place too.

New to the forum/ARM/rpi.

Just to put a tiny tick on Theo’s list
Forum

I’m waiting for the rpi and have started some documentation from what is available.
Initial target is ARM assembler, GNU tools and I’ll add to it as I find out more
though mostly it will have to wait until the rpi and it’s docs come out.
E.g. No idea what VIC chip will be built into the SoC.

I’d be happy to work on RiscOS docs on the rpi once I have a handle on what it’s all about.

Dave