Any updates about RiscOS on the Raspberry Pi?

Sorry there hasn’t been much progress on SD cards recently – I’ve had a busy couple of weeks. Hopefully when the next autobuild rolls round you’ll all get to play with a wider range of SD cards and more reliably. Although I’m hopeful that it should still work on older firmware, I’ve been doing my testing on one of the most recent releases from github, so if you have any trouble, please try upgrading your firmware before reporting issues.

Most SD cards of class 4 or above are capable of running at a bus speed of 50 MHz. For best performance on these cards, you will want to add the following line to your config.txt (that’s one followed by eight zeros):

init_emmc_clock=100000000

Some initial speed testing shows good results compared to the OMAP3 (beagleboard) controller. Data read speeds are often limited by the bus and/or controller: on the OMAP3, these topped out at around 14.5 MB/s, but the BCM2835 (Raspberry Pi) manages 22 MB/s.

Write speeds can be much lower, because they are usually limited the the flash memory in the card. Typically class 2 – class 6 cards run at about the same speed on both controllers, but the BCM2835 seems to squeeze an additional 2 – 3 MB/s out of class 10 cards; the best I’ve seen is a PNY card which manages writes at 17 MB/s. It’s definitely worth choosing a class 10 card on either controller if you can stomach the price premium.

Hopefully when the next autobuild rolls round you’ll all get to play with a wider range of SD cards

Very impressive – all the SD cards I rejected now work! Quickly. I have updated the distro – I’d call it adolescent now (shows flashes of brilliance but is still immature) – note it is still ‘A for Alpha’!

It does seem to show the occasional ‘abort on data transfer at &000102FC’ when using !Browse that didn’t occur before… choosing to ignore them at the moment as they are intermittent.

Nice work everyone. Works great now with a SanDisk 8GB class 4 card.

Managed to download net surf which works fine for e.g. BBC news but unfortunately complains about certificates when trying to access here.

Hopefully when the next autobuild rolls round you’ll all get to play with a wider range of SD cards and more reliably.

These changes have been a lot more reliable for me.. Before I couldn’t read or write to the SD card without either causing corruption or (Eventually) having the request timeout.
With the latest changes I’m now booting from SDFS instead of a USB HDD and downloaded and extracted the BCM2835Dev tarball without any issues.

the only problem I have seen (I always seem to find one) is that whilst building the BCM2835 ROM it suddenly failed with a ‘disc error’ and any subsequent SD disc access I tried also threw up a disc error. After a reboot the problem had gone away, so not sure what has caused that.

Thanks for the hard work!

Managed to download net surf which works fine for e.g. BBC news but unfortunately complains about certificates when trying to access here.

Run !Netsurf, Menu over Icon, Click Choices, Click any option, Click set.
Restart !Netsurf.
It should now be OK.
This took me months to find out!!!

Massive thanks to Chris Hall for the latest distro package – and thanks too to Tank for the tip above – this post is coming from my Raspberry Pi running RISC OS :)

This worked absolutely first time on an SD card I had issues with before. Totally plug and play as far as running a Google search.

I will be able to demo this at the next Oxfordshire Raspberry Pi meetup – which by then will be a Raspberry Jam. I am impressed by the progress to this point from the RISC OS development community – I am just a lay hacker with few ideas about the core internals, but it’s obvious from the little I know that there is strength and depth in the talent pool available to modernise RISC OS.

To get to the point of releasing a version to unsuspecting Raspberry Pi owners, I’d prioritise the following aspects of the user experience next:

1) Fix as many minor usability issues in !NetSurf as possible – such as Choices issue above, loss of credentials if you back up, etc.
2) Fix screen redraw issues that cause bits of pointer icon to get drawn all over windows
3) Fix bottom 100 pixels issue to allow full HD display
4) Tidy up boot text messaging as much as possible and look to shave off any wasted time.
5) Create a really great package of free/permissively licensed software as an optional SD card image to show what we have to offer.
6) Create more ‘new user’ documentation exactly as Chris has started. Acorn got it right with their ‘Welcome guides’ – a printed version would be a nice touch.
7) Update icon set – priority to a R-Pi switcher, and the SD card and SCSI logo
8) Amend RISC OS internal labelling of “SCSI” for USB sticks etc – can a new branch be added, or the whole term be made generic – IE “External Drives” – or plain switch over to “USB” if running on a R-Pi? It’s jarring for technically literate non-hackers.
9) Test as much software as possible in structured user acceptance testing – I volunteer.
10) UAT as much hardware as possible – again I volunteer. Who to send bug reports to?

NB- it is not an error that I put !NetSurf issues at the top – people use an OS to get to a browser to get to the internet for a hug proportion of tasks these days.
A big omission is to better exploit the hardware of the Pi – for example to play a YouTube video in !NetSurf, or to add sound – I don’t know what effort there is in doing this – but it could be considered a bare minimum by a large proportion of R-Pi owners.

I’m really pleased things have already come so far that it’s in user-experience territory rather than ‘will it work’ – amazing stuff!

Could those who know more about the core development comment on the relative priorities/difficulty of these?

1. Not sure about these… ask Steve Fryatt (I think he’s RO NetSurf maintainer) by posting to netsurf-users? I’m not sure how close they are to NetSurf 3.0, but possibly fixing 2.9 would be safer at this stage.
2. Lots of graphics stuff needs to be done:
   1. Modes that aren’t 1920×1080 and 16bpp (will currently downscale, but nastily)
   2. Hardware cursor support
   3. GraphicsV (not sure what’s needed here)
   4. 3D acceleration/video (tricky)
   5. MODE 7 (very low priority)
3. also sound support
4. Yes, the boot sequence could be optimised
5. We did a bit of work on this before Christmas (see the original RPi thread and wiki page) – main issues being vague license terms and authors being fussy about distribution methods (eg can’t provide on an SD card that is sold). RiscPkg will pull in quite a bit of stuff (and add in riscos.info’s repo for more) but it’s not exactly cherry picked.
6. Printed version would be nice, but a PDF would do for the moment. Maybe some YouTube videos too.
7. Also a modern window theme
8. This one is tricky, since the SWI name also depends on it. The filing system name could be divorced from the SWI name, but I don’t know what that might confuse. Unless the whole stack (SCSIFS, SCSIDriver, SCSIFSFiler) is renamed and renumbered (in which case, anything that tries to talk to SCSI-anything will be out of luck – eg CD drivers)
9. Testing good
10. Bug reports… to whoever is maintaining things? (carefully not volunteering ;-)

How are people getting their USB sticks formatted with a cluster size that RISCOS will accept? I can’t get XP, Windows 7, Mac OSX or Ubuntu to partition/format something that works.

I’m only really interested in this to get Netsurf onto the RPi. I was about to try and use the same trick at boot that used to load the Hardisk4/util into a ramdisk but of course that’s all gone now.

I have had no problems with any FAT format on a USB stick for a long time.

It isn’t the 2GB limit is it? If you wish to get rid of that you will need to install FAT32FS, otherwise (and to install it) you’ll need a partition or drive less than 2 GB (XP is funny about partitions on USB sticks, Linux is OK)

Hi Theo,
Thanks for responding!

2 – I guess hardware cursor support fixes the pointer painting issue. Non 1080 modes also important. For the other video issues – 3d would obviously be suberb but just making YouTube video play solidly using the Broadcom chip better would put the internet experience into another league.
3- sound – yes, if just to support the video! Perhaps Mr Lees at Broadcom could help with the GPU optimisation?
5- I will try out RiscPkg soon!
7- Funny thing with the window theme is that (in my opinion as a returning RO user) it’s actually less dated looking at high resolution on an HD TV than on my RiscPC… it’s also distinctive compared to other OS’. I was setting out to mention the stuff that’s jarring to a newbie or gets in the way of using RISC OS to get to the full content of the internet. The “NewerLook” style icon set on Chris’ distro with the hardware icons updated would easily pass muster for a release. I’m thinking about making a new backdrop texture though because it does look a bit old.
8- The simplest level would be to just put a new SCSI desktop icon – perhaps with USB logo – instead of the Zip disc which is super dated. But I can’t believe it’s not possible to sort out the way it’s named even if you had to fork the naming of the entire stack to ‘USB stuff’ and ‘SCSI stuff’…? Surely it’s just naming convention on some level?

Finally, just wanted to add that I’m finding more things to say about the RISC OS / NetSurf combo that will appeal to new users every time I try – for example selecting and dragging text to copy it. I was not expecting the scroll wheel to ‘just work’ which I guess happened in Iyonix days. I think a real selling point for RISC OS is that it must be the fastest power-on to Google search!

Now… USB webcam support by August?

Jonathan/Jess – I have a 1GB USB stick but struggled to format it under RISC OS – previously FAT32, used !HForm defaults. failed with error. Ideas? Thanks!

Some cheap sticks will only work as a fat32 superfloppy, I have one that would not work with NTFS etc and couldn’t be partitioned.

Ah ha, not to worry, I’ve realised Netsurf is already on the latest Distro!
Writing this from my RPi! I love it!

Alex, renaming SCSI is non-trivial because things refer to SCSI by name – for example, BASIC programs are likely to call SYS “SCSIFS_DiscOp” rather than SYS &40980 (in other words, the name is looked up at runtime). So if you rename SCSIFS then the SWI doesn’t exist. Forking isn’t great because the SCSI stuff is actually still usable on machines that have SCSI (eg the Iyonix or Risc PCs with SCSI cards). You could do a few evil tricks though… a dummy module that just passes everything through to SCSIFS, or some nastiness with path variables (if you set Foo$Path to something like SCSIFS::DiscName, you can refer to things such as Foo:$… this gets horrid pretty quickly). Changing icons is easy, and I agree is worth doing. Anyone feel like designing some new icons?

On the RiscPkg front, you might find PackMan to be more ‘friendly’ than RiscPkg, which rather assumes you understand the Debian packaging model. They both use the same underlying infrastructure (package repositories, etc)

Webcam support, well volunteered ;-) This is non-trivial because it needs isochronous support in the USB stack… there’s currently a bounty on that that nobody has claimed. More feasible for the moment might be to use the RPi’s CSI camera port with a camera module … the GPU does most of the post processing so you should just get a clean picture out of it (once the RPi Foundation have released a suitable module) – you might wish to read the RPi CSI camera forum

@Ronald May

Thank you, !Nettle is working well enough now

I’d be delighted to design icons – I have one in mind for the switcher which is a blend of the RISC OS cog with the Raspberry Pi graphic device… will try to mock it up.

I can’t help with webcam drivers except to test which I’d be pleased to – but I think the approach of supporting the R-Pi foundation’s CSI camera module is the better bet. From their description the heavy lifting is done within the GPU and the linux interface is still a work in progress – RISC OS needs a developer involved in that discussion from the off, I wonder if Adrian Lees at Broadcom is already on it?

Another thought on hardware support – Can someone more easily/quickly write a module to allow the user to control the R-Pi GPIO pins? From BASIC?

For me this would highlight RISC OS’ strength as an embedded OS in a way that could give it a potentially large new user base for control projects. If we can demo lighting an LED over the internet using RISC OS, as has been done on Debian etc, I think it will open a world of possibilities – there were some great applications written for the BBC and Archimedes for controlling robots etc – anyone remember Logo from classrooms in the early 90’s? This would be accessible and reliable, perfect for teachers.

I for one have control projects where I would definitely use RISC OS over Debian because a) it boots faster and b) I could program in BASIC which would for me reduce the learning curve compared to Python.

Can someone more easily/quickly write a module to allow the user to control the R-Pi GPIO pins?

I think there is a GPIO module that got put together for the BeagleBoard or similar. I’ve not checked if there is a RPi version of it yet, but it shouldn’t be too hard to put together.

I might try and have a look at it this week/weekend as I was thinking about having something like that running before the Cambridge Raspberry Jam meeting on the 14th.

GPIO module

See Tank’s sticky hands!

Tank – do you now have a Raspberry Pi to play with? Could you and Leo add the necessary lookup table details to the module etc please?

If you’ve not got a R-Pi yet I have a spare, or can definitely test remotely. I really want to light that LED from RISC OS before resorting to Debian!!!

Couple of details –
1) It sounds as though the GPIO module could then be compatible with the BeagleBoard version which is good!
2) When deciding how to address the GPIO pins, there are two possible approaches – the SoC labelling and the R-Pi pinout.
I reckon the latter is more user friendly – but there is software being written on the Linux side using both. I wonder if we could accommodate both with the lookup tables, with these labelled clearly for a newbie user?

there are two possible approaches – the SoC labelling and the R-Pi pinout

it would be good to get that choice right! I think I’ve seen at least three different diagrams listing the GPIO pinouts on the RPi and wasted some time trying to work out why my code isn’t working…

On the original RPi ‘squeeze’ image its only been the Broadcom SoC labelling that’s worked for me.. however I haven’t checked if this has changed in the ‘wheezy’ image that is in beta (I would assume they are moving towards the RPi defined pin out).

at the next Oxfordshire Raspberry Pi meetup

Look out for Mike Brownlow of Sharp Labs’ System Displays Group (corporate ref). I’ve no idea if he attends but he worked on a voice activated Space Invaders game on the BBC Micro, so should be an interesting person to talk to.

Leo – agree we need to get the choice right but if the module has already been coded so helpfully that it’s about updating a lookup table, why make the choice – it sounds like it wouldn’t add much work to cover both possibilities, one will prove to be the standard and the other will become a relic, but a working one that could be deprecated at leisure later!

Posting this from RISC OS, using Chris’s latest build.  It’s working very well – no problems booting or with !+Resources. Me very happy, and impressed.

With the SCSI/USB thing, could the Filer not be changed so instead of displaying “SCSI” in the title bar of the windows, it displays “USB” instead if the drive in question is a USB device? Perhaps add to this a dummy USB module that provides a *USBFS command for command line junkies which just calls *SCSI in the background, and *USBDevices that calls *Devices. It doesn’t have to be elegant, so long as it works.

Chris, can I just check how your latest distro with 2 partitions works from within RISCOS? I tried to download a large file onto the Pi and ran out of scratch space, so I tried to work out a way to format/access the unallocated space on my 4G SD card.

It looks in Windows like there is a ~210M “Unallocated” space in the first partition, which I’m assuming is the HardDisk4 image, followed by a 32M DOS partition which must be for the RPI boot stuff and ROM/kernel image.
How comes the RISCOS partition is first, and yet the RPI will boot from partition 2?

Also I read somewhere that RISCOS only understands 1 partition. Is this why the RISCOS partition is the first one? Is there any way I can resize this? Should I revert back to the RAMdisk version and do it from there?

I take it also that Netsurf always downloads to scratch areas and then you drag and drop the file from there, rather than using something like “Save As.”?
THe only problem here is that it fills up the disk with stuff that is buried in scratch folders and it’s not easy to see how to clear this out (rebooting doesn’t seem to do it)
Can anyone point me in the right direction?

Alex, I found that my cheap USB stick wouldn’t partition, as you say and only supported 2048 byte clusters, and didn’t even show up in GParted, whereas my more expensive USB stick seemed to behave better and does show up in GParted.

Also the cheap one (freebee giveaways from my employers) can’t be booted from on a PC, where the better one can.

Clearly all USB sticks are not born equal.