Hardware Suggestions

Hello forum members. This question is coming from a newbie (and it’s a first time post).

I’ve been lurking here for awhile, but until now I haven’t chimed in with any noise. I would like to question the more knowledgeable forum members about their favorite hardware. I’m looking for suggestions about the best hardware to run with RISC-OS. I’m not too worried about price point (within reason). Is there a particular hardware configuration that carries the favor of more loyal forum acolytes than others? How would the following platforms be ranked, in terms of popularity?

Armini
Beagleboard Xm
BeagleBone
Panda
Lyonix
A9
Cubox
CottonCandy
TrimSlice

I’m guessing that some of those will not be supported!

For the purpose of using RiscOS, would there be much difference between BB/Xm and Panda? My lurking gives me the feeling that more RiscOS work has been directed toward BB/Xm than to either BeagleBone or Panda. Is that correct? I’ve been involved with bread-boarding and prototyping, but I’m not really interested in building hardware. I’d be looking for configurations that could run the desktop at a (minimal) development level (occasional crashes acceptable) – but hopefully not be limited to serial console IO. Don’t know if I want to do that much work!

What say?

I am of course biased, but I’d say PandaRO!

I’d say: ARMiniX (missing from your list), but I’m biased too, because I have one. R-Comp sells them (www.rcomp.co.uk)

If your thinking of recent and current hardware you’ve also overlooked RaspberryPi and our(CJE/4D) MiniITX version RaspberryRO.
PandaRO RaspberryRO
Oops; I’ve just spotted we haven’t updated the PandaRO website with our half price SSD offer yet!

Armini
Beagleboard Xm
Panda
Lyonix

ROM image versions available for the above, as well as the old RPC era (IOMD)
BTW. The name of the last of those above is Iyonix – first of the ARM machines that didn’t have a 26 bit mode and therefore needed a fully 32 bit OS (hence the build of the first version RO5)

A9

Untested may work with the IOMD version.

The following have no available ROM image

BeagleBone
Cubox
CottonCandy
TrimSlice

You missed the Raspberry Pi – for which there is an available build (the version in NOOBS is currently out of date).

Chris (we have it in stock) Evans will happily sell you the comercial builds of the RPi and Panda. Comercial versions of the Beagle xM (ARMini) are from R-Comp.

Edit: Given your stated need for experimentation I would recommend a Raspberry Pi starter kit from your local supplier folled by the purchase of a few items from the mechandise page here

The Pi official release card, the NutPi card, and the DDE will keep you busy.

Of course a cheaper option would be the starter kit and GCC for the compiler work but most of the support you can get will likely come with advice about the DDE rather than GCC

I have to tell you, I’ve spent time in a few other OS/ARM-port forums, and I’ve found that the data-rate of conversations on those forums is measured in days or weeks! I’m happy that I set up an account on this one.

Anyway, thanks to Paul Sprangers and Chris Evans for their suggestions, and to Steve Pampling for the ROM info. It’s much easier when you see it all laid out as Steve has done, rather than analyzing it by digging through assorted messages one by one, hunt and peck style. Thanks!

Best cost : RaspPberry Pi
Best performance : PandaBoard ES

Both works well with RISC OS.

If you want a more polished environment, I’d suggest either a Raspberry Pi or one of the commercial offerings mentioned above. The Pi has specific SD card image releases, while on the other boards you’re expected to set up your disc yourself. On the commercial offerings (which are repackaged standard boards like Panda and Beagle) the vendor does the setting up for you so you don’t have to.

A9
Untested may work with the IOMD version.

The A9 is completely different from IOMD hardware, so the IOMD version won’t work.

FWIW I use an ARMiniX and am fairly happy with this and the support that R-Comp provide. The PandaRO and CJE are, I think, pretty similar.

Jim

The A9 is completely different from IOMD hardware, so the IOMD version won’t work

Ta. Stuffed in the memory bank. Virtually no one seems to have one so comment about what’s in it is scant.

I recommended the Pi as a simple development environment without great financial outlay.
I mentioned the GCC option as current RO builds a pretty easy to use and knowledge transfer from other OS’s could be handy.

BTW. Beyond OS builds¹ what is the advantage of the Norcroft DDE set?

¹ Reading here suggests you can’t build a RO ROM using GCC

I have both the RaspberryPi (+Motorola Lapdock) and a Beagleboard-xM. The Beagle is my “standard” desktop machine and certainly works very well. AIU there are no “stable” releases for either Pandaboard or Pi and the Beagle did get more attention until now. This seems to be changing in favour of the R-Pi though. Apart from the price there’s also the often overlooked fact that the Pi is capable of running in ARMv5 compatibility mode, something you simply can not do with ARMv7 boards. Why does it matter? Iyonix era software will be 32-bit safe but not always ARMv7 compatible (without turning alignment exceptions off).
The NutPi (which includes the DDE!) lowers the entry cost even further.

OTOH more users picking a Pandaboard/ARMiniX/PandaRO would speed up developement I guess :-)

Edit: forgot to mention monitor options. The R-Pi and PandaBoard both support FullHD whereas you’d need a monitor capable of 30-35Hz with the BB-xM (I’m using a TV/Monitor via DVI-D).

BTW. Beyond OS builds what is the advantage of the Norcroft DDE set?

I think it depends what you are looking for? While I think they are sort of matched in terms of C compiler (I assume gcc is now able to link with SharedCLib?), things are quite different at an assembler level. Not only is the assembler a lot more capable (one of the reasons RISC OS won’t build on gcc), but have you seen gas syntax? It makes ARM code look like a foreign language!

Also – can you write modules in C with gcc? [I don’t know, the last time I looked at gcc was a decade ago when it used to create unfeasibly huge programs]

AIU there are no “stable” releases for either Pandaboard or Pi

Need to be careful with the meaning taken from that. There’s an exchange about it on the ARMiniX email support list at the moment. AIUI:

1) The terms “stable” and “development” are applied to ROOL releases of the OS and have specific meanings.

2) The ARMiniX (based on PandaBoard) has an OS that isn’t quite the same as the ROOL releases as it has been tweaked and checked specifically. (I suspect the same may be true for the PandaRO, but don’t know.)

3) The numbering of versions released for the ARMiniX don’t therefore simply indicate the “ROOL” status division for the same OS ‘version number’.

Hence there are releases of RO for the PandaBoards which are quite stable in the normal user senses. I’m using one. But the ROOL definitions refer to some other specific distinctions.

So although ROOL may not be offerring a “stable” version, that may not mean what some might take the statement to mean. Not that simple.

Those familiar with Linux Debian and its downstream distros may be able to see a parallel. :-)

Jim

GCC supports module code. GCC supports a shared library system based on ELF. GCC has probably better optimization. GCC can produce code linked to the SharedCLibrary. GCC can be used on much faster systems to cross compile RISC OS code. GCC has a competent C++ compiler. GCCSDK includes asasm which is very compatible with ObjAsm syntax. In theory, GCC should be able to build most of RISC OS.

Advantages of Norcroft include faster compilation and less memory consumption, sometimes better warnings/errors, and debugability via DDT.

Maybe someone knowledgable can expand on things like the whole FP sitaution (soffloat, FPE, VFP, Neon…).

Also – can you write modules in C with gcc?

I can’t. :-) But I think that tells you more about me than about GCC!

AIUI you can write modules using GCC. But I’m not best placed to say. Although I use GCC on Linux I use the Norcroft/Acorn/ROOL compiler on RO and have never sussed how to write modules with that either.

Jim

It’s sad people are so uninformed about the gcc port for RISC OS.

I assume gcc is now able to link with SharedCLib?

Already the case since its 2.95.4 release, i.e. since Dec 2001.

things are quite different at an assembler level. Not only is the assembler a lot more capable (one of the reasons RISC OS won’t build on gcc), but have you seen gas syntax? It makes ARM code look like a foreign language!

gcc itself doesn’t dictate which assembler is used. In our GCC 2.95.x and 3.x RISC OS ports, we used ‘as’ assembler which was an own implementation which somehow matches Acorn’s aasm/objasm syntax but certainly not having all its functionality. In our GCC 4.x ports, we used binutils’ ‘gas’ assembler as this is the assembler which is supported out of the box in the gcc codebase (but it is not part of the gcc project).

As side project, we further developed the ‘as’ assembler into asasm aiming to closely match Acorn/ROOL’s objasm capabilities and go even beyond that. It’s a continued development and AsAsm v2.00 (Apr 2012) is able to assemble the IOMD and IYONIX branches of RISC OS 5. It features AOF and ELF output (the latter now with DWARF debug info allowing e.g. to source line step with e.g. JTAG connection).

Also – can you write modules in C with gcc?

Sigh, since Jul 2005. You can also use C++ if you want. Or e.g. modules without any runtime library support if you want (handy if you want to write a low-level module to do OS debugging without SharedCLibrary dependency).

[I don’t know, the last time I looked at gcc was a decade ago when it used to create unfeasibly huge programs]

What you’re probably missing is that by default the runtime library choosen to compile your programs with is static UnixLib library, a very rich API beyond what SharedCLibrary is offering. If you want to avoid this, either use the shared library version or SharedCLibrary. BTW, the GCC port is used to build Netsurf, so I don’t think it is that bad, is it ?

GCC can produce code linked to the SharedCLibrary.

If I’ve read the documentation correctly it uses SharedC and produces 32 bit code by default, unless you specify something that forces use of the Unix lib or specifies 26 bit, the latter being a why would you?

GCC can be used on much faster systems to cross compile RISC OS code.

So for a beginner you tell how wrong you are, faster. :)

GCCSDK includes asasm which is very compatible with ObjAsm syntax.

Which could be of use for people peeling non-32 bit stuff open with Armalyser¹ to rebuild without the, often minimal, non-32-bitness.

¹ It doesn’t take anyone competent to drive this (honest)

I started back in RISC OS by buying a Pi (I’ve actually bought about 5 of them by now).
Then after about 6-8 months I bought an ArminiX (Pandaboard).

I would recommend this route to anyone, as if you buy a Pi and get sick of it you can use it for a media centre.
Or if you really get into RISC OS, you can then get an arminiX and use the Pi as a media centre – which is what I’ve done. Raspmbc is really great – you can even use the TV remote to control it!

The only advice regards getting a Pi would be, buy a POWERED USB hub if you’re connecting anything other than a keyboard and mouse to it and make sure you get a proper 1A USB power supply.
The phone power supplies will not really cut it, and will just cause you pain in the long run.

Oh yeah, and the NutPi pack is a daft price – For around 100 quid you can get a pi with the nutpi pack and all the bits you will need. (assuming you have a monitor or TV)

It’s sad people are so uninformed about the gcc port for RISC OS.

I did say “I don’t know, the last time I looked at gcc was a decade ago when it used to create unfeasibly huge programs”, I figured that a few things a likely to have improved since 2002, as you say, it is used to build NetSurf. ;-)

Sigh, since Jul 2005.

Repeat: Since 2002. ;-) Since I have the DDE, there hasn’t really been much incentive for me to follow gcc’s development.
Not really interested in cross-compiling, if I develop on the machine that runs the code, I can test the software right away, without all sorts of additional complications regarding what is connected to what, which things are being shared, blah blah.
Versus – it’s in a filer window, double-click it!

I use the Norcroft/Acorn/ROOL compiler on RO and have never sussed how to write modules with that either.

RTM?

Seriously, the C/C++ manual has a whole section on this, starting on page 295 (PDF version).

To put it briefly, there are three parts to a module written in C.

The first part is the module header, the assembler-to-C interfacing, and so forth. All of this is handled by the program “CMHG” (stands for C Module Header Generator which does exactly what it says on the tin). CMHG is controlled by a sort of script file which tells it your SWI chunk, your SWIs (by name), what commands are supported, and so on.
Here is a cut down except (the real MIDI module has many SWIs!) of the USBMIDI module header:

; Header definitions for Rick's (USB) MIDI module
; Version 0.01 Wednesday, 8th May 2013

; Module title/help
title-string: MIDI
help-string:  MIDI 0.01 USBMIDI © 2013 Rick Murray ;dev#4

; Module start and stop code
initialisation-code: module_initialise
finalisation-code: module_finalise

; SWI chunk, handler, and epic-long list of SWIs
; We offer the same list of SWIs as the original Acorn
; MIDI to provide, hopefully, drop-in compatibility.
swi-chunk-base-number: 0x404C0
swi-handler-code: module_swihandler
swi-decoding-table: MIDI,
  SoundEnable SetMode SetTxChannel SetTxActiveSensing [...etc etc ;-)]

; Service call handler for call &79 which is Service_DeviceDead so
; we can be aware of the MIDI device being disconnected. We also
; look for &D2 so we can notice and respond to a MIDI device being
; connected.
service-call-handler: module_servicecallhandler 0x79 0xD2

; Veneer handler for OS_CallEvery.
generic-veneers: module_veneer

; *Commands. The same as for the original MIDI module except three at
; the end - most of these (the Acorn MIDI clones) don't do anything,
; they are provided for compatibility.
command-keyword-table: module_commands
  MidiSound(,
     min-args:1,
     max-args:2,
     invalid-syntax: "Syntax:\tMidiSound in|out|off [<port>]\n",
     help-text: "This command does nothing, it is for compatibility only.\n\
Syntax:\tMidiSound in|out|off [<port>]\n"),

  [...etc etc]

; End - phew!

The second part of the module is your code. You should provide a module_initialise function to deal with module startup, the corresponding module_finalise to deal with shutting down.

To give an example, the USB-MIDI module initialises as follows:

• Check if DADebug is available, and if so, set a flag to say so.
• Check we are running on RISC OS 5 (defined as NOT “<4 OR >=6” – thanks ROLtd!).
• Check we have USB support.
• Allocate various buffers (in the RMA).
• Initialise the MIDI system (flag no devices found, and try looking for one).

The finalisation is:

• If USB file handles are open, close them.
• Free the various buffers.

Note that you don’t have to call the function “module_initialise”, etc. You can call them “mal”, “wash”, “kaylee”, etc if you prefer – but really a descriptive name is better.

The next step is the SWI handler. You will be passed a number from 0-63 which is the SWI number offset from your SWI chunk. Basically, (SWICHUNK AND 63) will be this. From there, handle it how you like. I have a big switch() block which directly handles very simple SWIs, or passes on to functions for the more complicated stuff.

The command handler works in a broadly similar way, the command number is a value counting from zero that matches up with the list of commands given to CMHG.

Service call handler – if you can help it, DO NOT. Because of the mode of entry into a service call, it isn’t really safe to do anything at all (including printf() to console!). What I do in the USB-MIDI module is set a flag or two, then schedule a callback. The callback will look at the flag (in maybe a few centiseconds once RISC OS is ready) and take the necessary action. The less that happens within the service call handler, the better.

Take a look at Sources.DDE-Examples.examplemod in your install. And if you need help……just ask! ;-)

Not really interested in cross-compiling, if I develop on the machine that runs the code, I can test the software right away, without all sorts of additional complications regarding what is connected to what, which things are being shared, blah blah. Versus – it’s in a filer window, double-click it!

You just need a bit more creativity and imagination.

You connect to your favourite dev OS (VNC, RDP, KVM, or host machine if using RPCEmu or VRPC) where a powerful IDE runs where you can develop with professional tools to support e.g. refactoring and which connects you to the latest (distributed?) VCS. The compiled and linked output is put into a dir which ends up in a Moonfish mount (or ina HostFS path) on your (vurtual?) RISC OS machine. Where you can of course just double click it in a filer window. And if it crashes your machine, you can go back to your dev OS to fix all the bugs while your (virtual?) RISC OS machine reboots.