Any plans to have an open source toolchain to build RISC OS?

I was interested in seeing how the integration with the VideoCore IV GPU is implemented on the Raspberry Pi, and decided to take a stab at building RISC OS from source. The first hurdle I encountered was that it appeared I needed to pay £50 for a closed source toolchain in order to build RISC OS. Is that correct, or is there an open toolchain I can use?

Mostly correct. See this thread and the DDE FAQ for details.

There are some free copies available for developers who qualify, though.

Building RISC OS with other toolchains is hampered by the fact that Acorn never saw the need, and so there’s lots of dependence on being built using the DDE running on RISC OS within the sources.

Yes/Maybe, see the bottom section of the post here https://www.riscosopen.org/news/articles/2020/02/21/new-desktop-development-environment-reaches-out

Many thanks Steve and Mike! I’ve sent an email to ctools@roo – let’s see what they say. Fingers crossed! :-)

Had a brief look at the FAQ (https://www.riscosopen.org/content/documents/dde-faq) and I think something missing from the description of how Acorn ANSI C and Desktop C differ from the DDE is that in those days the assembler was not supplied as standard.

As you can see from the 1989 price list (http://heyrick.eu/random/acorn_september1989_retail_price_list.pdf) the compiler was about £170 while the assembler was £228! Maybe twice that, I have no idea what the software developer’s toolbox consisted of.

There’s a reason why all my early code that linked to assembler uses Nick Roberts’ ASM! ;-)

Ah thanks for the context – that is interesting indeed. Especially to see the 1989 price list!

While I’m here, can anyone point me to the code that makes the mailbox requests to the RPi GPU firmware? Am I right in thinking RISC OS runs with the standard Broadcom GPU firmware, or can it also run with e.g. https://github.com/christinaa/rpi-open-firmware? I also saw (new) open source GPU firmware mentioned here (MESA): https://www.raspberrypi.org/blog/vc4-and-v3d-opengl-drivers-for-raspberry-pi-an-update/

I’m curious how the ARM/VC4 interface works – whether the interface is comprised of firmware mailbox calls (https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface), whether RISC OS contains code that is compiled directly for VC4 target and then remotely executed, or if there is a higher level OpenGL ES / other graphics API interface somehow that bypasses the mailbox interface entirely. I’m relatively new to this area, and thought looking at a real world implementation (in this case for RISC OS) would be a good way to build an understanding. Until now, the bare metal experimentation I’ve done has simply allocated a frame buffer, and written to it directly via the ARM.

Many thanks!

As you can see from the 1989 price list (http://heyrick.eu/random/acorn_september1989_retail_price_list.pdf) the compiler was about £170 while the assembler was £228!

Which is why all my coding is done using BBC BASIC. Getting it to run fast enough used to be a problem, but not so much now with fast computers. I managed to get a 250KHz square wave from a GPIO pin by bit-banging from BASIC, which I was rather surprised to see.

I’m not about to try learning C and derivatives now.

I’m not about to try brushing up my C either, but I regret the resulting inability to write modules 8~(

You do not need C to write modules – I and many others do it with BASIC (and some assembler). Do you know of any good assembler documentation?!

Building RISC OS with other toolchains is hampered by the fact that Acorn never saw the need, and so there’s lots of dependence on being built using the DDE running on RISC OS within the sources.

So many people seem to moan about the cost of the DDE, yet nobody seems to want to invest some time to at least look into the finer details of making RISC OS buildable with GCC.

Writing modules in C isn’t that difficult… https://heyrick.eu/blog/index.php?diary=20150323 (jeez, a half decade old already, where does time go?)

The main things to remember about C are:

• There are no statements other than loop constructs (for, while, etc). Pretty much everything else is a function that lives in a library. printf for writing strings? It’s part of CLib.

• Adding libraries adds available functions. TCPIPLib, DeskLib, OSLib, blah blah blah. As long as names of things don’t clash, you can pretty much mix and match as you require.

• Pay attention to pointers (anything defined with a ‘*’ in front of it). It’s the bit of C that causes the most confusion. You can write stuff like *(&array[0] + index) == *(index + &array[0]) as legal code, but hopefully you’ll prefer readability to clever tricks.

• Unlike BASIC, all variables must be declared before use.

• Unlike BASIC (and many other languages), you can not only choose a number of different variable types (short, int, long, float, single, double…) but for the integer ones you can specify signed or unsigned.

• Note, however, that the choice of “int” and “long” are determined by the platform. In 32 bit x86, int is 16 bit, long is 32 bit, and long long is 64 bit. Under RISC OS, int and long are both 32 bit. This will mean nothing if you intend to write code only for RISC OS, however it can bite if you wanted to port something to Windows console (like I did with my Ovation HTML convertor) which will then bite you in the ass as all the ints would max out the 65K rather than 4G!

• Most of all, don’t panic if you get something wrong and the compiler has a total nervous breakdown over it. The compiler will tell you on the first line what it thinks is wrong. Every subsequent line is the compiler attempting to parse the rest of the source and getting more and more confused until it blows itself up. Seriously, ignore the screenfulls of gibberish and just work on whatever the first line is saying. That’s what went wrong. The rest is just misplaced electronic psychosis.

• Finally, don’t worry if it seems hard, weird, bizarre, oh-god-why-am-i-doing-this, and nightmarish. I’ve been there. I felt that. I hated C. I wanted to forget all about it and go back to the comfort of BASIC. Then one day, it suddenly just clicked. Like something in my brain got itself rewired in a way capable of understanding the 1970s cannabis haze that surely gave birth to C.
  The benefit? Speed. I have a program that draws a bunch of things on the screen. A prototype in BASIC, with the VSync wait removed, can manage about 240fps. The version in C can draw a more complex screen and crank it out at around 460fps. That’s like twice as fast. Because there’s no interpretation, no delays, what is spat out of the compiler is pure assembler. In cases of shifting a lot of memory around, C can outclass BASIC by two orders of magnitude. Simply because the source code gets read once and turned into a program, where BASIC needs to do it over and over for each line. That’s not to say that BASIC is a slouch, AmCog demonstrates quite nicely what it can do. But C can do it faster. ;-) Oh, and unlike assembler, C is both readable and frees you from all the nitpicky trivia like managing stacks and register assignments.

Hmm, kind of went off on a tangent, I think…!

I managed to get a 250KHz square wave from a GPIO pin by bit-banging from BASIC,

Did you use assembler or calls to the GPIO module?

If you need stable square waves, I’ve seen some nifty tricks along the way. With the BBC User Port, pushing values into the shift register was able to clock out pulses (and rudimentary PCM) faster than the machine would have been capable by bit banging alone.

I’ve also seen similar done with serial ports, setting up the word format and transmitted data to give a square wave, that could then be speed adjusted using a mixture of how many bits on and off and the speed the port is running at. As you’re basically writing bytes to a serial buffer, it can run pretty fast with minimal overhead. [obviously I’m thinking 3.3V serial, you’d need some level shifting if dealing with RS232]

Of course, where there’s an output port, there’s a nerd with way too much spare time. ;-)

https://hackaday.io/project/162477-serial-port-sdr

I managed to get a 250KHz square wave from a GPIO pin by bit-banging from BASIC,
Did you use assembler or calls to the GPIO module?

BASIC, calling the GPIO module. The only speed-up was to use the SWI number instead of name. It wasn’t multi-tasking though.

So many people seem to moan about the cost of the DDE.

I don’t really get it. OK, so it is fifty quid, but how much have you spent on all the hardware to run it? And how much is your broadband? Or mobile? Or a tank of fuel?!

So many people seem to moan about the cost of the DDE, yet nobody seems to want to invest some time to at least look into the finer details of making RISC OS buildable with GCC.

Not sure if that was aimed at me, given the quote? It’s not something that’s ever bothered me enough to want to look at it.

A few years back, a few people pointed out that Tokenize might be useful in helping build RISC OS away from RISC OS (ie. on a conventional Linux-based CI system). I don’t think it ever got mentioned again.

OK, so it is fifty quid, but how much have you spent on all the hardware to run it?

On a Pi? Possibly around as much as the dev tools cost.

And how much is your broadband? Or mobile? Or a tank of fuel?!

All largely irrelevant, since most of those would trump buying a set of development tools to investigate an obscure Open Source OS that you’ve just stumbled across on the internet.

But then, that’s the problem that ROOL’s current offer addresses.

A different viewpoint (well, in line with Richard Walker) was made to me last week by a fairly smart guy. In the IoT world (which a version of RISC OS could be vaguely useful in), the only sensible choice for coding is the ARM toolchain which costs thousands per year. GCC isn’t really an option for that audience (I forget quite why – he explained it). By comparison, the 50ukp DDE generating ARM code is a veritable bargain, esp if you multiply that up by number of devs and devices and…

It is also worth remembering that the DDE is included in NutPi too.

(The background to this was a suggestion that if the kernel implemented a bit more in the way of idling so that power management could be controlled outside of the desktop, an IoT build of Pico could attract more kernel devs).

I’m curious how the ARM/VC4 interface works – whether the interface is comprised of firmware mailbox calls

RISCOS mostly uses firmware mailbox calls, with a few direct register writes such as setting the gamma.

The VC4 hasn’t been properly documented at register level as far as I know.

An alternative viewpoint.

If you employed someone to work on your project, you wouldn’t make them pay for the dev tools.

If you want people to write valuable code for you for free, you want to charge them?

I realise RISC OS is a spectacular ivory tower backwater. At least put some effort in to attracting developers from elsewhere, because there’s about 4 people left here.

You do not need C to write modules – I and many others do it with BASIC (and some assembler). Do you know of any good assembler documentation?!

ROFL – you did know I wrote ARM’s own Assembler Guide, and the Instruction Set pages in the ARM Architecture Reference Manual up until 2007? I hope that’s good enough – as long as we’re not talking v8, any changes since then are surely minor? I presume RISCOS is still all v7? v8 is essentially a completely different beast that I don’t know at all.

It’s not assembler language that’s the problem for me, it’s how modules work, which I’ve never got to grips with. But actually I don’t think I’d have a problem writing a module – it’s more doing anything with existing modules when I think about it. Even so, a pointer to some information about writing modules (in BASIC and assembler) would possibly be useful – don’t worry about needing assembly language, I’ll have no problem getting back up to speed with that.

You did know I wrote…

Of course! :-))

Somewhere I have a skeleton module in BASIC/Asm, if you are interested.

Somewhere I have a skeleton module in BASIC/Asm, if you are interested.

Definitely!

Sadly I suspect though that until I bite the C bullet, I won’t be able to give Draw or Paint the kind of palette controls that I’d like, but such is life. There are lots of things that are more important to me than that…and I’ve not even been following what others have been doing on that front, possibly even meeting my desiderata anyway!

So many people seem to moan about the cost of the DDE.
I don’t really get it. OK, so it is fifty quid,

The point, for me at least, is that at the time when I might have started to use it, the cost was closer to 400 pounds. The computer cost about the same. Now I have a very large investment in experience and code in BASIC that I’m not going to translate into C.

I agree than a Pi is very cheap, but less so once you consider the ancillaries (OK, so not everyone needs to buy everything from scratch).

Professionally, I would agree with Peter H. I would equip a developer with the tools they need, no expense spared, because the cost is dwarfed by their salary. But in RISC OS land, we are talking about volunteers, so there is nothing to compare the cost to. I think it is a touch unfair to try.

I think other household bills, particularly those which are non essential, are a fair comparison. It’s about choices. A year of cable TV would be more than the DDE.

One final thought, and maybe this only applies to me, but I have found that there are many more factors which stop me working on USBJoystick or contributing to RISC OS. The cost of the DDE didn’t come into it. Back when I started USBJoystick, I just bought it, feeling that it was cheap enough to do so on a whim – certainly compared to its previous pricing!

Developing things for RISC OS is like working on a building site with no electricity or running water, having arrived on a bicycle. Meanwhile other platforms are like having a warm, well-equipped workshop with all the tools you need to hand.

Sure, some people like making log cabins in the woods with their bare hands, crafting tools from whatever junk they find lying around – and don’t let me dissuade them from doing so. But sometimes you can be a lot more productive with an electric pillar drill than a hand drill. Having a productive environment gets more things done more quickly. And if the competition is offering better tools, the temptation is to go over there where you can get more done with less hassle. You’re more likely to entice people to work for free if you offer them a nice environment than if they have to suffer much pain on the way (a monetary cost being only one kind of pain).