Roadmap for the future of RISC OS
Posted by Steve Revill Thu, 29 Jul 2010 21:51:00 GMT
Following from the publishing of the source code on the ROOL site, RISC OS development has gained momentum over the past couple of years. We are close to a point where we can say one flavour of the OS, RISC OS 5, can run on most of the current platforms: Beagle Board, IYONIX pc, RiscPC, A7000 and emulation.
Within ROOL, we don’t want things to stop there. What we would like to see is for all of the talented developers out there to be paired up with tasks that they are interested in working on which contribute to the ‘greater good’ of the system.
As a tentative first step in that direction, we have published a list of the sorts of tasks which we feel could be adopted in order to move things along. We haven’t prioritised them or done anything more than simply enumerate everything (significant) that we can think of.
We’re sure there are more good ideas out there and there is probably some stuff in our Wish Lists forum that we’ve missed. We would very much welcome feedback from the community – so add the things to our list that you think are important to the future development of our favourite operating system.
Another thing which we believe is holding back the development of RISC OS is the lack of time that we the developers actually have to spare on doing the stuff we really want to be doing. The one thing that we believe could change that is cold, hard cash. It may sound mercenary but there is only so long anyone can give up their evenings and weekends before the family start to get annoyed! :)
An idea that we have been kicking around internally is to set up a fund, collected via donations, and then distributing this fund to developers in order to complete specific tasks. This would be done under a fairly formal contractual basis so we would effectively be paying contractors – but probably not at the rates they are used to!
If anyone is interested in developing this idea further, or can think of a way to raise a significant pot of funds, then please don’t hesitate to get in touch. Some time after the Summer, we might arrange for a get-together of interested parties to flesh out these ideas further.
Nice list. I’ve added a few bits which you’ve missed :)
Would a bounty system work?
If online payments are like cheques and have 6 months to be cashed, you could have a system where people “buy” a feature and if it doesn’t happen within 6 months then they don’t get charged.
eg If the Iyonix supported DVI, it would save me buying a VGA switch box. (£10) if a dozen other users were in the same situation, then perhaps that would be enough for a devoloper to do it (at McDonalds rates, maybe).
Excellent. Having a clear set of objectives is something RISC OS development has needed for years. Looks like a very good list to me. A couple of comments:
- I would be prepared to donate money to any scheme which was properly transparent and contractually binding (i.e., there was some reasonably level of certainty the work would be done). I think it should be done on a piecemeal basis (one project at a time), unlike the Select Scheme. Successfully completed projects, even if they start small, will generate confidence.
- There are already things which have taken place in recent months that would have fitted this model. For example, MW Software’s Postscript Drivers could well have taken place as an OS upgrade if they had been likely to receive a similar amount of money for the work done as by doing it independently. I think it would be worth sounding out the few remaining commercial developers to see if they’d consider doing work on the ROOL OS for cash, and under what terms.
I’m sure Jeffrey Lee will be wondering if he can get backdated pay on his work.
Perhaps we could just rebrand it JLOS instead ;)
Seriously though, this is an important step forward and I am sure that others like myself will support such an opportunity to vastly improve RISC OS.
As the list shows; there are plenty of things that need improving/fixing. It could keep many developers busy as well as supplementing their main income.
Looking forward to hearing more about this soon.
Perhaps something like FOSDEM on a smaller scale and without the “free” aspect? Anyway, this sounds like a good idea to encourage development :-)
And here’s another vote for backdated payments to Jeffrey and the other keen coders (speaking of which, there may be some recent additions needed to the heros list ).
I’m not particularly interested in getting paid for my RISC OS work, and I don’t think I’d particularly enjoy being tied down to a contract either (My day job gives me enough deadlines and boring tasks as it is!)
I’d be much happier if the money went towards inticing other people to get involved, so that we have a chance of getting everything done within a couple of years instead of a couple of decades.
Or if we can get enough money together, it would be nice to buy some JTAG kit so I (or anyone else) don’t have to spend hours debugging the major crashes using nothing more than a serial port :)
> JTAG kit
We have an ARM MultiICE JTAG kit but I suspect it’s too old and things have moved on since that was relevant…
So how much is a single JTAG kit that Jeffrey was talking about?
In the $1000s, if the links here are anything to go by. On a related note, according to his CV, this guy Nigel Hathaway did some work on the JTAG emulator for ARM 5 years ago… perhaps he’s got an old one he could lend, if that’d be more up-to-date than the one that ROOL have!
Jeffrey, is an IAR J-Trace any use? I could lend you mine.
Excuse my ignorance, but is a JTAG kit specific to a manufacturers ARM processor? Or simply just the processor type? i.e. Cortex-A8 vs Cortex-A9
As I understand it, there are a few JTAG interface standards floating around. E.g. the beagleboard uses a TI-specific 14 pin interface which isn’t the same as ARM’s 14 pin one. But if you’ve got a JTAG adapter which is mechanically and electrically compatible then in theory you can use it to talk to any device with the right connector.
But the bigger issue with JTAG is that it’s down to each silicon designer to decide how the debugging interface should work – what commands should be used to read and write registers, the correct procedures to go through in order to ensure the internal state remains consistent, etc. So unless you’ve got a debugger that knows all the details of the chip you’re debugging you’re out of luck.
Luckily it looks like the JTAG situation isn’t as bad as I/we thought – a quick search lead me to this wiki page, which says that this $99 adapter can be used with Code Composer Studio (TI’s “free” toolchain) to debug both the ARM core and the DSP.
Note that I say “free” because there’s this big wiki page about licensing, which will surely need a good deal of reading to work out what our options are. As I understand it CCS is the only (or at least the best) way of compiling code for the DSP, so at some point we’ll want to look into acquiring it for that purpose as well.
Ah, just spotted this bit on the CCS download page, which coroborates what’s said on the Blackhawk website:
“Can be used for FREE with EVMs, DSKs and eZdsp boards that have on-board emulation as well as simulators and XDS100 emulators”
That doesn’t sound too bad, but what about this CCS forum post ? It refers to (somewhat pricier) USB560 rather than USB100. (All available in the UK from Direct Insight in Banbury.)
Unless I’ve misunderstood1, we’ll need to “think of a way to raise a significant pot of funds” as the news item says.
1 Which wouldn’t be the first time!
Perhaps the USB100 is sufficient after all.
Yes, I think it’s only recently that it’s become possible to use the USB100 (v2) with the OMAP3.
Good to know that the USB100 is readily available in the UK, although it’s a bit of a shame that as usual we’re stuck with an effective $1=£1 exchange rate!
Once all my immediate tasks are out the way I’ll probably buy one and see how practical it is to use (e.g. whether it’s possible to get CCS to work with the debug data that Norcroft produces)
Two fundraising ideas.
1. Encourage RISC OS folk to donate a regular monthly amount by standing order.
2. Ask for donations for specified projects that ROOL plans to get done.
1. The amount of the SO can be quite small, £5 to £10 minimum a month, and used for maintaining the website, administration, speakers expenses, exhibition expenses etc..
Charities, campaign groups and other societies and institutions use this method successfully. To the doner it seems very little, but over the year it is a useful amount for the recipient.
2. ROOL should make the decision on the projects to be funded and the amount required for each project needs to be stated. A rough idea of what folk should give, perhaps 3 levels according as the giver is poor, comfortable or rich. Martin Wuerthner did this for some of his software. If folk know how much is needed they are more likely to rise to the occasion and dig deeper in their pockets. It is not just about having a clear set of objectives, but having a clear idea of the money needed and asking for it. This is how it works in other voluntary bodies.
We don’t seem to be very good in the RISC OS community at getting our act together, the approach is to amateurish. For example, the JTAG kit needs to be properly evaluated as to its suitability and expense. Don’t expect money to be forthcoming unless the case and the funds required are made clear.
David R. Lane (77) said 16 days later:
> Two fundraising ideas. 1. Encourage RISC OS folk to donate a regular monthly amount by standing order. 2. Ask for donations for specified projects that ROOL plans to get done.
> 1. The amount of the SO can be quite small, £5 to £10 minimum a month, and used for maintaining the website, administration, speakers expenses, exhibition expenses etc..
> Charities, campaign groups and other societies and institutions use this method successfully. To the doner it seems very little, but over the year it is a useful amount for the recipient.
I agree and would cheerfully make out a suitable standing order.
But the addition of charitable status would provide even more money as the charity would (should?) be able to recover in addition the standard rate income tax from the charity. So a donation of £50 becomes £60. Further if the donor pays higher rate tax he gets that rebated to himself, enabling him to increase the amount donated.
The trouble with charities is that they need to be set up with a trustee or two and be approved by the Charities Commission. The trouble with this is that it needs suitable people: reliable, methodical and trustworthy – so I cannot volunteer!
But I would still recommend that if sufficient people would make pledges, a Charity be set up and the donations chanelled through that charity.
About the item from the list labelled “Improved task/process management (e.g. making more state per-process instead of global. An important stepping stone to full preemptive multitasking, and will benefit us now by making taskwindows more reliable/versatile)”, may I suggest that the CWDSupport module available from http://bgilon.free.fr/RISCOS/CWDSupport/UK/main.htm might fit the need (at least in part)?
Regarding the item labelled “Multi-CPU support and preemptive multitasking (a simple job, clearly)”. Would it be possible to split it in two? as the only thing shared by this two concepts is just the term “multi”? Likely an intermediate list item named “multi threading” which considers concurrent execution within one application memory adress space (no memory context switch) would be more reachable. I’ve seen some articles from CAUGers describing some techniques to approaching threading capabilities within applications but this is clearly a work in progress.
Yes, that looks like it might be useful. A couple of years ago I did try writing something similar myself (just for providing a per-task CSD), but I couldn’t get it to work properly in all situations. I haven’t tried your code (nor can I remember exactly what caused mine to fail), but hopefully you had better luck than me.
Yes, it would be possible to split it in two. Multithreading (pre-emptive or not) is a lot simpler to implement for single-core machines than it is for multi-core machines, especially when you’re trying to add it onto an OS that’s already got tons of programs that aren’t expecting to run in a threaded environment.
GCC has had pthreads support for several years now. It’s not an ideal solution, but it can be used to implement threaded Wimp tasks, such as the (experimental) threaded version of FireFox. So since there’s already a solution available for in-task threading, I think it would be better if we focused on the bigger issue of pre-emptive multithreading between multiple tasks.
For any other potential developers reading this, I concur in hoping that you’ll be able to "look back in old age and in the finest spirit of Acorn and say that one of [your] life-achievements was doing what people said could never be done."