Word is out there? Making sure it is!

I was talking to the IT guy at work commenting that their “public information display” (a company-related powerpoint style show) was quick to start. The machine (some x86 box, spec unknown) runs Ubuntu with an orange-coloured version of Unity. The slideshow automatically loads. From reset to slideshow running in under twenty seconds. Pretty impressive and laughs in the face of booting Windows. ;-)

So he asks me what my interest in computing was. I had a printed photo version of the Pi/Vonets/hub that I posted here a few days back (link if you don’t remember). I had a photo made for discussing the Pi with a cow-orker.

Anyway, he immediately recognised the Pi and what the Vonets was. I said I like to write ARM code, at which he whistled and asked what sort of things? “Well, I recently got USB MIDI running and I’m pulling apart the kernel to see how it works.”
Then I added: “The operating system is RISC OS. Have you heard of it?”

“Yes”, he said (could have knocked me down with a feather at that point). He understands that the multitasker is braindead but it is easy to talk to hardware without latency.

I guess the single-tasking command line and CMT Wimp might be “braindead” if your yardstick is a modern Unix. But yes, he is dead right on the other point. Perhaps one of RISC OS’s strong points re. homebrew robots, automation, and such is that it will obligingly get out of the way and let you bash the hardware to your heart’s content (or dig yourself a really big hole to fall into if you think it is run to prod the MMU or the like ☺).

Still, I was impressed that a French guy who does computer stuff for the company knew of RISC OS – and even knew an attribute or two.

I think, perhaps, word is getting out there that there is a small, simple, fast, friendly alternative to Linux where homebrew hardware developers can get on with doing the task they want to do, instead of offering blood sacrifices to placate the kernel before it will allow them so much as to sniff the hardware.

So… With this in mind – how could/would we start a grass-roots initiative to promote RISC OS and its strengths? Let’s face it, it is unlikely to ever match RaspBMC in what it can do. But then RaspBMC is a version of Debian (IIRC?) that is extremely targeted to one task, one task that it does really well.
What does RISC OS do really well? And how do we shout that?

Personally, I like the fact that you can programmatically choose to hijack the system. It might be an anathema to modern operating system design, but if I have code that responds to an interrupt to do something “complex” as a user mode program, I can push RISC OS out of the way for a bit. I don’t have to fight against half a dozen daemons that I don’t even need.
Example? My PVR (ARM926@200MHz) runs lighttp which I think I’ve used maybe three times (telnet is easier), and that’s a stripped-down install; there’s a lot more rubbish running on a ‘normal’ setup. Stuff that is harder to silence.

The user mode program part is important as the code can be written and tested as a regular application, but it could attain the same sort of responsiveness as a low-level driver, only without the complications of having to know how to write such a thing (example: my parallel port IIC driver for XP requires GiveIO.sys to allow it to poke the LPT1 hardware registers directly, as I never did figure out how to make a device driver for XP).

While I have not made use of this functionality myself (yet), I do see it as one of the strengths of RISC OS.

Perhaps one of RISC OS’s strong points re. homebrew robots, automation, and such is that it will obligingly get out of the way and let you bash the hardware to your heart’s content

Pretty much one of the feelings I’ve formed wrt to purposes like using a RO machine as something like an audio player for situations where the user doesn’t want a ‘desktop’ but to simply play music. Small, no fans or mechanical HDs. No fuss. One of the longer term ideas that should pop up once we have cracked using USB DACs – and ADCs for those who want to record audio. May seem a ‘tiny’ area to general computer programs. But lots of people like music whilst many also find Windows, etc, an overkill PITA for what should be a simple process from the user POV. Add other specific uses as you see fit. :-)

Jim

Yes – like a custom MP3 player.

I use (an old) WinAMP on my XP box because it offers the features I like. As I write this, I’m listening to some CDs I picked up second hand for a few euros – Benny Goodman “King of Swing” (I quite liked Swing Girls so thought I’d try some more of that style of music), Julie Zenatti “fragile” (a bit like Céline Dion, only Julie can sing…), and tATu’s “200km/h in the wrong lane” (don’t like most of it, though I really like “Stars”).

I have a variety of hardware MP3 players (of the runs-from-an-AAA-cell type) and generally I find the things tend to be… lacking. Either random doesn’t work, the playlists are broken, the song play counts are simplistic, or the filesystem navigation is crap (or impossible). But instead you get dumb things like “it changes colour”. Whoo.

I’m looking at the Pi in its little orange case and thinking that I could probably hack around the GPIO to build in a small matrix LCD (or 16×4 alphanumeric or somesuch) to provide a simple UI controlled by some buttons. Then I could make my own music player that does what I want, namely:

• Programmable EQ with multiple memories (for headphones, speakers, etc). Not simplistic presets.
• Ability to rate songs, and to play songs either based upon rating, or weight random selections to favour my favourites.
• Don’t count a song as “played” until it has played past the halfway point (so skipping over songs won’t count the ones skipped).
• Play by playlist, play by folder, play all. I would add “play by genre” but this assumes MP3s are correctly tagged and that the tagging makes sense – is a song “pop”, “rock”, “vocal”, “soundtrack”, etc etc.
• Multiple playlists – so I can set different ones for different moods.

I (possibly) could do this now using the onboard hardware and some homebrew code… I would if I could find a cheap backlit LCD panel with datasheet (Chris – do you have that in stock? ;-) ). If I didn’t need RISC OS to function as RISC OS, it could just power up and wait for a USB device to be plugged in, and when it is, mount it and start playing stuff. Of course, a USB DAC will sound better, but as I’ve said a lot, I’m hardly your target demographic, Jim!

Mmmm… Could be interesting and fun. And unlike portable single-chip (Sigmatel) MP3 players, could be extensible – maybe in the future adding Shoutcast and the like? Could be interesting.

“So… With this in mind – how could/would we start a grass-roots initiative to promote RISC OS and its strengths?”

Perhaps first by looking at the code and understand how the kernel really works.

I have the impression that the kernel is a monotask one, with interrupts and vectors, a big toolkit and milli-micro-timers.

If I’m correct, RISC OS is really a fantastic tool for people who wan’t to do bare metal things. Perhaps the only one in fact. I mean: it’s pretty easy to hijack most of the system things (preemptive RT, memory protection, etc.) since they do not exist, and to go directly to the metal with minimum interruptions (only from devices) and a very useful toolbox, and even a graphic system with cooperative multitasking.

For embedded things, there is simply no real equivalent to RISC OS.
I’m sure it could be even possible to make it run on a Cortex-M4 microcontroler (without Wimp).

So 3 uses:
1- Small ARM computers, where RISC OS makes more (than Linux) with less.
2- Without WIMP for dedicated systems (web server, presentation system, etc.)
3- Perhaps even on embedded things, or Internet of things, with even smaller ARM cores.

1- is a reality today… on a small set of cards, but the best ones (Pi/Beagle/Panda). Multi screen and AMP mode could be a good evolution to make a better desktop system. Support of Mali 400 / Cortex A9 devices too.

2- could be a reality. Just need more CLI tools and more developers tools. Currently I work on developer tools for RISC OS… with the idea to embed it inside small hardware tools.

3- A CLI tool made on RISC OS that would work on a minimal Cortex-M4 system (of course alone, due to memory issues). That would be fantastic. And here, there is no Linux competition.

For example, this board: http://www.digikey.com/product-search/en?lang=en&site=us&KeyWords=STM32F4DISCOVERY&WT.z_slp_buy=ST_STM32_Kits

Only 192 KB RAM and 1 MB Flash, but perhaps enough for a minimal RISC OS setup with Basic.

Of course, a USB DAC will sound better, but as I’ve said a lot, I’m hardly your target demographic, Jim!

You are if you just want to play the music and enjoy it. :-)

Jim

“So… With this in mind – how could/would we start a grass-roots initiative to promote RISC OS and its strengths?”

FWIW when I was an academic running a research group (sic) I found that the best way to draw attention was to have a working device or prototype. When I went to a big company and took a 95GHz tunable oscillator out of my bag and put it on the table and said, “We’ve started making these, are you interested?” the answer was a quicker “yes” than if I’d said, “I’m think I can make something, can you give me some money?” :-]

Ok, that is off the point in technology terms. But I think that simply getting RO systems doing things and then talking about that is what draws attention. You just have do something neat that people want. My ‘special interest’ is audio, but transfer that to some other area which you think maybe a runner. :-)

Jim

You just have do something neat that people want. My ‘special interest’ is audio, but transfer that to some other area which you think maybe a runner. :-)

Not much reason to comment for a few days¹ but I’ll chip in and suggest that the audio aspect of the work done by Colin and Dave is, I suspect the tip of an iceberg of functionality.

¹ Plus fixing an XP laptop machine (without the use of a bootable CD) to keep the other half happy.

I’m sure it could be even possible to make it run on a Cortex-M4 microcontroler

I doubt it. The M4 processor offers Thumb/Thumb2 which runs in two modes (Thread (akin to USR) and Handler (akin to SVC)); and while registers R0-R12 (plus SP, LR, PC) exist, the 16 bit Thumb instructions can only access R0-R7 (or some, R8-R15). There are various PSRs and two stacks. It is close to traditional ARM, but I wonder how difficult it might be to port the kernel? [you’re welcome to try! ;-) ]

Cortex-M4 datasheet (free) / ARM v7m TRM (needs login)

Just need more CLI tools and more developers tools.

For these sorts of things, I am thinking that a good idea might be a packet-debug interface using Ethernet. I’m sure such a thing exists in Unix-land already; that you can start the client on a workstation connected to the LAN and then start RISC OS (or whatever you were tracing) and a dump of activity would be broadcast across the LAN and displayed on the client – a but like the old Econet monitor, if people still remember that.
For more interaction, an ability to set breakpoints and examine/change memory, etc would be nice.

Only 192 KB RAM and 1 MB Flash, but perhaps enough for a minimal RISC OS setup with Basic.

I wonder if RISC OS could run in that? The smallest (not currently working!) that I have made RISC OS so far is about 1800KB. I am hoping for under 1MB but I am not really familiar with the many many build options. I suspect embedding messages directly instead of using MessageTrans might allow for some things to be saved (no messages? probably don’t need any of ResourceFS, etc). It’s a matter of working out what depends upon what.
I would say, however, that we ought to include CLib if possible. BASIC is good for prototyping ideas, but I would be inclined to want to write my music player in C. If I did such a thing, I would nick all the playback modules from !DigitalCD (or rather, have that installed and use the same modules), so the choice of language is not so important. However, if code is brought in from the Unix world (consider ffmpeg), it is written in C so there would need to be a C runtime.

Only 192 KB RAM and 1 MB Flash, but perhaps enough for a minimal RISC OS setup with Basic.

I would like to get RISC OS “embedded” down to under 1MB but still be useful. I’m not so hopeful on the reality of this, however.
192KB, on the other hand, may be extremely tight. Looking at the Pi:
PCI shared memory – 308K (is this supposed to be draggable?)
Real time stacks – 128K
SDFS map (2GB SD) – 952K
Memory management – 1840K
Hardware/System – 92K
System heap – 144K
System stacks – 56K
Module area – 2184K
And that isn’t including the space claimed by the OS itself. Whether the OS can run from “ROM” or not depends upon how the circuitry is laid out – is the Flash accessed through a 16 bit pathway? Would it be quicker to load the OS from media?

Obviously the numbers above relate to a full build of RISC OS running on a Pi – I’ve left off DAs and Fonts (another 4MB), plus the Wimp sprite pool (2MB) and some other stuff. We could trim down a fair amount of this memory consumption by examining the kernel and its behaviour in detail – but that said – how much functionality are you willing to sacrifice? In my “minimal” build concept, I am keeping video, ethernet, USB, and FileCore/FAT. Get rid of those, you severely impact the usefulness of the finished product. Again, it depends a lot on what you actually want to do – if you are looking to run a smart washing machine, you won’t need most of those.

On the other hand, you won’t need an ARM capable of running RISC OS for a washing machine. I have plans somewhere for a concept I put together for our near-dead machine. It contains a 6502, 6522, 2K SRAM, and a 2K ROM, could probably be wired up on breadboard, and runs a custom “application” with minimal “bios services” that could be recycled for other things. I never built it……because these days it is cheaper/easier to buy a little Arduino-style board. :-)

Now, having said all of this – and back to my fictional MP3 player… there is no real need to mess with RISC OS at all for that. Indeed, if the software is to run on a Pi, then I have at least a quarter GB of memory to play with. I can just base my application code on top of a standard off-the-shelf build of the OS. They system has booted to Desktop with a 1280×1024 display and I still have 210MB free.
I’ve just loaded everything in my Apps folder (Alarm, Calendar, Chars, CloseUp, Draw, Edit, Help, Maestro, NetSurf, Omni, OvationPro, PackMan, Paint, Printers, SciCalc, SparkFS, Squash, Store, StrongEd, StrongHelp, Zap; plus DigitalCD, MoreKeys, and USBInfo). With this resolution, the iconbar still isn’t full!
I have 188MB left. :-)

That’s a lot of space for data tables, say, to make a pen-plotter based upon RISC OS and one of these small boards.

“We’ve started making these, are you interested?” the answer was a quicker “yes” than if I’d said, “I’m think I can make something, can you give me some money?” :-]

That’s what always confused me about these kickstarter concepts. So many people were pledging insane amounts to wishy-washy plans. I recall reading on TheReg a while back about a new mobile phone but at the stage of announcing the project, there was no real idea of what the basic specs would even be.
Now, I can understand that reality bends ideas into submission – the RaspberryPi people utterly failed in their target to make an ARM computer the size of a traditional USB flash stick, as was the original concept. Reality no doubt kicked in when they tried to work out where to put the various I/O ports. The result is many times larger (but still tiny) and they utterly succeeded in making a dirt-cheap ARM platform for playing witheducational purposes. However, I rather suspect that Pi knew what they wanted and traded off as much as possible re. functions vs cost.

Which is better than “I wanna make a cool phone, gimme cash”.

But I think that simply getting RO systems doing things and then talking about that is what draws attention.

http://www.riscoscode.com/Pages/Item0121.html – a Pi setup in a boat named after a chilly wind that drives people crazy. It is a simple thing to do, and obvious when you think about it (DC → AC → DC? don’t be silly!). However, seeing it in action is a bigger incentive than just “I wonder if this would work?”.

You just have do something neat that people want.

I’m afraid my speciality is doing neat things that nobody else is interested in…

I suspect the tip of an iceberg of functionality.

I said that ages ago. I can see this kicking off a whole host of potential options.

Hopefully the result of the RISC OS poll will show how much the work is appreciated:

And the winners, with a massive 80% of the vote,
are Colin Granville and Dave Higton for their work on USB audio.

Need anybody say more?

I’m afraid my speciality is doing neat things that nobody else is interested in…

Small pool¹ limited space for fish. You want another interested person? Bigger pool and more fish.

¹ Fortunately, in keeping with the current weather, the pool appears to be getting bigger

Hopefully the result of the RISC OS poll will show how much the work is appreciated:
And the winners, with a massive 80% of the vote,
are Colin Granville and Dave Higton for their work on USB audio.
Need anybody say more?

Well, I’ll say: “Wonderful! Well deserved!” :-)

Jim

Small pool limited space for fish. You want another interested person? Bigger pool and more fish.

Errr… That could be interpreted as “jack it in and go write apps for android”…?

Errr… That could be interpreted as “jack it in and go write apps for android”…?

Does one not read footnotes?

Does one not read footnotes?

The pool is getting bigger.
That could apply to anything that isn’t called Windows Mobile. ;-)

On the subject of making things small, I have a neat demo if anyone can make ARM BBC BASIC fit in 32KB (yes, kilobytes)…

I’m sure it could be even possible to make it run on a Cortex-M4 microcontroler

I doubt it. The M4 processor offers Thumb/Thumb2 which runs in two modes (Thread (akin to USR) and Handler (akin to SVC)); and while registers R0-R12 (plus SP, LR, PC) exist, the 16 bit Thumb instructions can only access R0-R7 (or some, R8-R15). There are various PSRs and two stacks. It is close to traditional ARM, but I wonder how difficult it might be to port the kernel? [you’re welcome to try! ;-) ]

And don’t forget that there’s no MMU either! You’d need a very custom build of the kernel to cope with that, and the Wimp would be a definite no-no.

I would like to get RISC OS “embedded” down to under 1MB but still be useful. I’m not so hopeful on the reality of this, however.

Acorn sold machines with 512KB of RAM. I’d say 1MB is a fair goal for a usable version of RISC OS 5. Assuming the OS is running from ROM, of course!

PCI shared memory – 308K (is this supposed to be draggable?)

It’s a heap, similar to the RMA, so you could probably ask the same question about that. On the Pi I’d expect most of that memory to be being used by USB (since there’s obviously no PCI bus!)

Memory management – 1840K

The CAM and MMU page tables – so fairly proportional to how much RAM you have in the system.

On the subject of making things small, I have a neat demo if anyone can make ARM BBC BASIC fit in 32KB (yes, kilobytes)…

Strip out the assembler and use hardware FP and I reckon you could get it down to around 40KB. Maybe strip out support for some statements you don’t need? A lot of them probably won’t be usable anyway since you won’t have the rest of the OS there to provide vector graphics, file I/O, etc.

On the other hand, you won’t need an ARM capable of running RISC OS for a washing machine. I have plans somewhere for a concept I put together for our near-dead machine. It contains a 6502, 6522, 2K SRAM, and a 2K ROM, could probably be wired up on breadboard, and runs a custom “application” with minimal “bios services” that could be recycled for other things.

Yep, but probably not enough for Internet of Things. It’s strange but RISC OS without Wimp could be perfect for future microcontrollers. Could be cool also for true microservers.

Yep, but probably not enough for Internet of Things.

Given the usual level of security of such devices, and the increasing assumption that “it’s okay, trust us” regarding things bleating information to exterior places… I fear for what may happen if The Internet Of Things should come to be, especially when IPv6 will make everything directly addressable so you can’t even hide stuff behind a NAT. <sigh>

The STM32 processors are suitable for small embedded applications. Applications this small usually don’t need an OS.

They are too small to port RISC OS to.

256 KB max. Not a lot, but who knows… Many modules are not necessaries with a system without graphics, sound, storage, pci, etc.

Of course, today, there are not a lot of microcontrollers suitable for RISC OS. But if the OS stays modular (both in use and compilation options) and light, it could be perfect for future offers.

Given the topic of this thread it may be of interest to say that I got a copy of ‘Hi Fi News’ cover-dated March this morning, and that RISC OS gets a positive mention in the letter pages. (This is via a reader’s letter about a column I’d written.) ARMiniX and PandaRO also mentioned.

Jim

Here’s an interesting snippet that I’ve discovered.

I was trying to figure out why my usb hard disc wouldn’t play 192/24 on my iyonix. It turns out that it doesn’t fill the buffer fast enough.

I have a buffer in IsocPlayer 1536000 bytes long. Data is read from the file and put in the buffer. At the same time, in the background, data is being removed from the buffer by the usb module and played.

For the audio to work the read from the disc to fill the buffer has to be faster than the rate at which the audio device uses data. Reading the extent of the buffer (amount of free space) just before each buffer fill shows:

1. Filecore Formatted USB hard disc always has 1536000bytes free space in the buffer – indicating data is leaving the buffer quicker than it is entering.
2. RAM disc reduces the free space to 0 in 0.58 secs
3. FAT formatted memory stick reduces the free space to 0 in 1.15 secs
4. Filecore formatted memory stick reduces the free space to 0 in 7.01 secs
5. Main Hard disc (PATA – filecore) only reduces the free space to 780824 bytes (about half buffer size) in 15 secs (the duration of the music file).

I didn’t expect the hard discs to be so slow.

3. FAT formatted memory stick reduces the free space to 0 in 1.15 secs
4. Filecore formatted memory stick reduces the free space to 0 in 7.01 secs

I have heard of this before – that FileCore is “slow”. I wonder if there is a ‘specific’ reason for this (if correct) that could be nailed down and resolved?

5. Main Hard disc (PATA – filecore) […]
I didn’t expect the hard discs to be so slow.

The obvious question is – how would it fare with a harddisc formatted FAT?
I mean, if FAT (an image filing system, no less) takes twice as long as RAMdisc and about a fifth of the time of FileCore – would you see something similar with spinning rust?

This post is ‘special’. First one ever that I have written on RISC OS. Yay for the Vonets do-hickey!

256 KB max. Not a lot, but who knows… Many modules are not necessaries with a system without graphics, sound, storage, pci, etc.
Of course, today, there are not a lot of microcontrollers suitable for RISC OS.

To be frank, I think there is a lot of baggage that would be unnecessary – think of OS_Byte and WRCHV and the like.
What might be more profitable is for somebody to look at what RISC OS ‘does’ in the kernel, and then recreate a leaner Thumb ‘clone’ that works along the same principles. I reckon this may get further than attempting to port RISC OS as it is. The kernel source alone is 3MB which assembles to about 205K¹, and what would you do with AMBControl?

The big problem is – using RISC OS may require some baggage. It would be nice to say “let’s load an application written in BASIC on a mini-RISC OS”, but the immediate question is “load from what?”.

Tricky questions aside, it ought to be possible to strip back a version of RISC OS with a reasonable number of features inside a 512K image (with ~32K unused!), to run in only 512K of memory (or 1MB if loading OS into RAM). Why? Because that’s what this was…

For what it is worth, there were only 23 modules in the machine:

-- Kernel (Arthur)
 1 UtilityModule
 2 FileSwitch
 3 DeskTop
 4 BASIC
 5 Debugger
 6 SystemDevices
 7 ADFS
 8 Econet
 9 NetFS
10 NetPrint
11 ARMBasicEditor
12 WindowManager
13 FontManager
14 SpriteUtils
15 SoundDMA
16 SoundChannels
17 SoundScheduler
18 WaveSynth
19 StringLib
20 Percussion
21 HardCopy
22 International
23 Podule

The later, better, RISC OS 2 fit into 512K as well, and shook things up a lot to introduce FileCore with filing systems (ADFS, RamFS) working from that. ARMBE was dropped and some useful things split out into separate modules and/or expanded – IIC, International(Keyboard), Obey, TaskManager, ShellCLI… The “DeskTop” (which was little more than a demo really) was replaced by “Desktop” (which really was).

¹ Determined by taking the generated library file in Kernel.o and hacking off the library pointers and stuff.