RISC OS on Raspberry Pi

[BrokenFrog]

Yep. USB is up and running as far as I can tell. At least it runs my Acer Revo wireless keyboard and mouse, a San Disk Fit 4gb (formatted to ADFS) drive thingy and the onboard ethernet port.

Fantastic work and a great start.

[Burngate]

I know this is a bit previous, but I'm getting all excited! Having got (several) ADFS-formatted hard-drives, is there any hope of mounting them using a USB-ATA dongle?
I know it won't be quite that simple - first hurdle is to get a Pi!

[BrokenFrog]

If you have a look at https://www.riscosopen.org/wiki/documen ... st#storage, there's a few USB to hard drive thingies mentioned that seem to work with RISC OS and USB on one or other of the Beagleboards. Obviously, this is no guarantee of anything, but if you're going to fumble with one or two, might these be the best place to start?

[trevj]

It was never quite clear to me if Risc OS in general didn't support USB, or that it only couldn't handle the USB hardware of the PI.

It was "just" the Synposys driver for the BCM2835 port:
https://www.riscosopen.org/viewer/revis ... 29138.html

USB has been working on the BeagleBoard for a couple of years and was previously available on the Iyonix (and even a RiscPC podule).

On a rather unrelated issue (regarding a conversation I believe we began elsewhere) I don't think the graphics output uses the Linux binary blob... but I could be wrong, in which case the ROOL forum would be the place to ask.

[pygmy_giant]

Will RISCOS utilise the floating point hardware on the Pi?

[pygmy_giant]

also - will it have I2C drivers?

I found this: http://www.acornusers.org/wishlist/show?cat=9 which says '- I2C is implemented on all riscos machines as far as I know. It's used to talk to the real time clock and cmos ram I think. As far as I can remember, RS482 is supported (at least I think it was on my A3000). CAN bus would be fairly easy to implement.' so that coud be a yes?

Hoping RISCOS could be a better faster replacement for bloated debian for robotics...?

[tank]

also - will it have I2C drivers?

I found this: http://www.acornusers.org/wishlist/show?cat=9 which says '- I2C is implemented on all riscos machines as far as I know. It's used to talk to the real time clock and cmos ram I think. As far as I can remember, RS482 is supported (at least I think it was on my A3000). CAN bus would be fairly easy to implement.' so that coud be a yes?

Hoping RISCOS could be a better faster replacement for bloated debian for robotics...?

See https://www.riscosopen.org/wiki/documen ... w/OS_IICOp .
I have accessed a TMP75 and an 4 x MCP23017 16 bit I/O expanders on a Beagleboard, so once the port is more stable, and I get the time I'll check out the I2C on the Pi.

[arm2]

On a rather unrelated issue (regarding a conversation I believe we began elsewhere) I don't think the graphics output uses the Linux binary blob... but I could be wrong, in which case the ROOL forum would be the place to ask.

The Binary blob is used by RISC OS. On power up the Blob is run, it sets up the GPU then boots the ARM processor and then the Operating System: Linux, RISC OS or other OS is loaded and run.
I wonder if the Blob is considered an operating system itself? Is it Linux like?

[Grumpy Mike]

I had a look at the RISC OS download but couldn't quite understand the bit where it says run the boot system off a pen drive. Is there somewhere that describes putting it on a pen drive and what "it" is.
Thanks.

[svrsig]

I had a look at the RISC OS download but couldn't quite understand the bit where it says run the boot system off a pen drive.

Have a look here:
http://www.riscosopen.org/wiki/document ... 20image%29

With no external pen drive, this boots RISC OS to the Supervisor promt, i.e. command level only 6 seconds from power on. Type 'BASIC' and you will have a screen looking like the BBC Model B computer (but with 127Mbytes of RAM and a 1920x1080 16M colour screen rather than 32kbytes and 40x25 teletext screen). To get a GUI you need a boot structure and that requires a RISC OS formatted pen drive onto which you copy the 'HardDisc4' image so that RISC OS can start up with a nice GUI desktop.

RISC OS can read and write FAT formatted pen drives up to 2Gbytes (only) but cannot boot from them.

At the moment RISC OS on the Raspberry Pi is pre-alpha. You need to wait a little while and a much friendlier SD card image will appear.

[xChris]

BTW in the current 'alpha' version, the resolution is fixed to 1900x 1080, which is useless if you don't have a HD display..

[trevj]

The Binary blob is used by RISC OS. On power up the Blob is run, it sets up the GPU then boots the ARM processor and then the Operating System: Linux, RISC OS or other OS is loaded and run.
I wonder if the Blob is considered an operating system itself? Is it Linux like?

OK yes, the device boots the GPU first. But I don't know whether RISC OS then needs to use the binary blob again itself.

[trevj]

Is there somewhere that describes putting it on a pen drive and what "it" is.

Generic OMAP port setup information 'Putting the HardDisc4 image onto a USB drive' is probably what's needed.

[trevj]

To get a GUI you need a boot structure and that requires a RISC OS formatted pen drive onto which you copy the 'HardDisc4' image so that RISC OS can start up with a nice GUI desktop.

But that's to get full use of the GUI. You can simply type 'desktop' at the Supervisor prompt to move to the GUI, can't you (as with the BeagleBoard port)?

[svrsig]

But that's to get full use of the GUI. You can simply type 'desktop' at the Supervisor prompt to move to the GUI, can't you

Yes.

[jamesh]

On a rather unrelated issue (regarding a conversation I believe we began elsewhere) I don't think the graphics output uses the Linux binary blob... but I could be wrong, in which case the ROOL forum would be the place to ask.

The Binary blob is used by RISC OS. On power up the Blob is run, it sets up the GPU then boots the ARM processor and then the Operating System: Linux, RISC OS or other OS is loaded and run.
I wonder if the Blob is considered an operating system itself? Is it Linux like?

The blob runs a real time OS, not Linux.

Any OS running on the Pi uses the blob to some extent - it handles the video output for example.

[helpful]

If you are anywhere near London and want to see RISC OS running on the Raspberry Pi, then come along to the next ROUGOL meeting on Monday 18th June.

See - http://www.rougol.jellybaby.net/

Bryan.

[pygmy_giant]

Exciting! Unfortunately I live in the North of England - will RISCOS be available for download soon?

[svrsig]

will RISCOS be available for download soon?

Yes. The pre-alpha version is available now but this is not for new users. A much friendlier image is being worked on.

[pygmy_giant]

Fantastic - will it have arm hard float support?

[trevj]

Exciting! Unfortunately I live in the North of England

There are clubs closer than London:
http://www.riscos.info/index.php/User_Groups

[pygmy_giant]

Interesting - will RISCOS have arm hard float support?

[theom]

RISC OS' core is almost entirely integer-only. There's a Floating Point Emulator (FPE) module, but this is for the original 1980s ARM FPU floating point instruction set, which is used by most software that needs floats. So most things are typically compiled hard-float already, but using the wrong instruction set. Due to few Acorn machines actually having a FPU, many things are written to avoid floating point arithmetic ('soft float' being a comparatively new introduction to ARM compilers, compared with 1980s).

There's nothing to stop you compiling things to use the current VFP instruction set - RISC OS on BeagleBoard uses it a little from assembler (and some NEON things for graphics, which won't work on RPi's ARMv6). I don't think the Norcroft compiler will support VFP, but GCC should do. There's a few OS-level issues regarding process switching and FP registers, where I don't know if there's ARMv6 VFP support yet, but RISC OS is cooperatively multi-tasked, so the programmer has control over when processes switch anyway and this is less of a problem.

The FPE traps and emulates ARM FPU instructions - it could convert them into VFP, but there's limited gain to be had given the main overhead is the instruction trapping. So that means there's not a lot to be gained from existing applications, with or without a recompile.

[pygmy_giant]

thanks for the comprehensive reply - am readinf it through a few times...

[theom]

That was a bit convoluted, so here's an executive summary:
RISC OS: doesn't using floating point
Existing applications: often integer-only (no need for FP), or old-hard-float (slow, use FPE)
Floating Point Emulator: could use VFP, but little gain (maybe useful for trig, not for arithmetic)
New applications: welcome to use VFP hard float
Old applications recompiled for VFP: may get significant gain if they use floats

(slight lies have been included to simplify)