USB Stack

DisplayLink is famous for a certain amount of secrecy – I think their compression technology is proprietary, and no open source implementation is available, at least for the current USB3 chipset – I think parts of the old USB2 chipdset protocol was reverse engineered though. Ubuntu support is based on a binary blob. Although ISTR that Steve from ROOL had some connections to the DisplayLink guys.

Having basic drivers for all things USB on RISC OS would obviously be very valuable if you port RISC OS to a new ARM SoC – you “only” need a working USB subsystem and already have mass storage, networking, audio and video ready to go.

Clive: by coincidence, there’s a thread “riscos remote desktop” on comp.sys.acorn.misc that you may find relevant.

Cheers Dave! Will take a look.

it tickles my fancy to continue my work in a now very obscure operating system which I once devoted my heart to

Dan – I’m glad to hear it. RISC OS may be obscure, but it’s still is a great OS. And with talented developers like you, RISC OS continues to improve and play catch up with the big boys.

I’d be happy to make my USB Audio control module available, with source, although I think perhaps someone else would like to start all over again with a different API.

Work on USB Audio should be coordinated with Jason Tribeck which is working on a new standard API for Audio Input and Output.

Hi Dan, nice to see you here :)

If you’d like to get in touch with us at RISC OS Developments (my address is andrew riscosdev com) we’d be very keen to liase with you about work on the USB stack.
We’d very much like to discuss this with you.

Oh, here we go again. More development on RiscOS that most of us will only see a few years from now unless we buy some hardware from RComp.

It feels like RiscOSDev are purposely trying to sideline ROOL on some key elements of the OS. ROOL have a bounty for this work, so why do RiscOSDev need to get involved? And why do they want to have that conversation in private? The guy posted here to ask a community of users, not just one company. He even used the Bounties forum, maybe because he was interested in completing the bounty for ROOL. Wasn’t it always the intention that ROOL were the custodians of the OS, or did RiscOSDev change that when they bought RiscOS?

It’ll end up like the network stack thing. ROOL had a bounty for that but RiscOSDev went off and grabbed the developer and did their own thing. Has anyone else seen it? They asked for beta testers but did anyone get to beta test it? What if ROOL don’t accept the changes into the base of RiscOS? Will it just be sold with RComp products, a bit like all those ‘whatever browse’ things that are just Iris with a different name?

I’ve seen the argument peddled that there’s a commercial ROD customer willing to pay (for the network stack) but there’s a near £14k bounty for the USB stuff, so money isn’t that much of an object in this case. It doesn’t need a commercial benefactor. WE have already stumped up for it.

The link between RComp and RiscOSDev seems to have a strange side effect of giving RComp an advantage by having early access to RiscOSDev’s development work and then bundling it with their machines. Do Elesar and other hardware sellers get the same access to RiscOSODev stuff? After all RiscOSDev is NOT RComp, is it, I am constantly told.

This all reminds me of the Castle/RiscOS Ltd spat which only managed to fork the OS, and now twenty years later, we’re trying to recreate some of RiscOS Ltd’s work.

Thanks for your viewpoint John. There was a lot of frustration there, but I’d be happy to discuss this with you – you know my phone number, please feel free to call me. Indeed, we welcome contact with any and all RISC OS folks – I’m always happy to talk RISC OS with people :)

When RISC OS Developments acquired the RISC OS IPR, we met with ROOL (and continue to do so each month). ROOL asked us to provide vision, direction and co-ordination to push the OS forwards. That is what we have done since the company’s inception. ROD works with many partners, and is committed to making RISC OS the best it can be, under Open Source licencing with our work made available to all. Indeed our first act was to remove Castle’s restrictive licensing and make the OS properly Open Source under the Apache 2.0 licence.

The proof of that pudding is in our already-released open source offerings (LanMan98 etc) and public test code such as Pinboard 2 (which comes with full source).

Your view on the network stack is unfortunately simply incorrect, as the people involved were either already working for ROD, or approached ROD, not the other way round. The work has been rather delayed this year due to complexities getting modern DHCP working. This required implementing BSD concepts that RISC OS hasn’t done before. My hope is that this will see public, free release (or at least public beta) by the year end.

In the process of this, the remaining previously-closed elements such as Resolver and MbufManager are being replaced by new Open Source versions.

In this case, I’m keen to avoid duplication of effort, and also to ensure co-ordination with existing work like the isochronous USB support, plus test hardware and so on. Additionally, ROD has a lot more “day job” time to offer in terms of testing, sounding, developer-collaboration and so on. Some developers find all this quite useful.

I’d be happy to discuss this with you – you know my phone number, please feel free to call me. Indeed, we welcome contact with any and all RISC OS folks – I’m always happy to talk RISC OS with people :)

Thank you for your kind offer, but I think some of this needs airing for others to read and think about too. I know these concerns aren’t just my own. The “conversations in private” ethos seems to take away from community involvement in developments. Surely a community of users is better equipped to suggest end-user needs, rather than a conversation between two individuals. Or maybe some people know better than the users what it is the users of the OS want?

Indeed our first act was to remove Castle’s restrictive licensing and make the OS properly Open Source under the Apache 2.0 licence.

And that was very welcome! Although some stuff never does make it into the code base, which is very confusing. Maybe I was a little paranoid, but I did feel a tinge of concern when a prominent developer took ownership of the code base.

The proof of that pudding is in our already-released open source offerings (LanMan98 etc) and public test code such as Pinboard 2 (which comes with full source).

Again, very welcome, although I haven’t tried either, but I’m sure some people have. Where are they available from?

Your view on the network stack is unfortunately simply incorrect, as the people involved were either already working for ROD, or approached ROD, not the other way round.

My mistake, and apologies for misrepresenting that.

The work has been rather delayed this year due to complexities getting modern DHCP working. This required implementing BSD concepts that RISC OS hasn’t done before. My hope is that this will see public, free release (or at least public beta) by the year end.

In no way do I underestimate the work involved in updating a twenty year old set of components. Has it been given to any beta testers at all yet? I’ve seen it demonstrated on occasion, so surely a few select beta testers would be useful in finding bugs and even suggesting methods of implementing the code. There must be users who are au fait with RiscOS, BSD and networking. But again, what happens if ROOL don’t accept the code, like with the isochronous USB developments, and various elements of the iMX6 and other ports, which never reach a stable release available from ROOL? I’m not saying these things aren’t stable, or aren’t done properly, but if ROOL are arbiters of the code, what happens if they don’t agree with the code of the implementation?

I do still have a question outstanding though, which you didn’t really touch upon: Are RiscOSDev developments and code made available to other RiscOS at the same time as they are made available to RComp? Can CJE develop their own RapidoBrowse, or tune the new network stack to their hardware before it goes public? Or is there a deal between RComp and RiscOSDev covering this? Can you see how this looks?

The intention was to (public) beta it over the Summer (there are several private beta testers), but the delays have rather messed that up. I have a beta list created ready for when the programmers say “OK”. We felt working DHCP was a must, and in the meantime have added drivers for Pi4, and USB ethernet. It has been offered to other vendors too (ahead of beta), along with worked examples (ie. the USB ethernet driver is provided as a worked example of how to convert an existing driver).

I understand your browser point. Suffice to say that we do try to act fairly, and that I (personally) ensure that the public release of Iris is always ahead of any R-Comp release, which is actually to my detriment. For example, you could buy a Pi400 (say), and add Iris to get the most recent public release, for less money than anything R-Comp sells. Indeed, that has massively (negatively) affected my business (to a point that it affects my mental health), so I assure you I am not benefiting.

Pinboard 2.0 is available on request (free with source) to anyone who asks to test it via email. It still has a number of bugs, but a buggy pinboard is arguably less of a problem than something fundamental like the network stack. LM98 is free on !Store, alongside Impression Style, and has appeared on other vendors’ disc images from what I can tell.

One further thought – in the earlier post, you brought up OS forks and 20 year history. I find that to be extremely counterproductive, and yet a number of members of the community keep doing it. Can we, as a community, perhaps try to move on from RISC OS Ltd / Castle history? It isn’t at all helpful to anyone, and negatively impacts things for everyone. It makes our community seem extremely negative and off-putting to new members.

For reference, ROD and ROOL have monthly meetings to co-ordinate their activities and the two companies work together on many projects. Indeed, ROD commissioned some ROOL-related work within the last two weeks, for delivery directly to the ROOL gitlab. We’re also trying to co-ordinate announcements and the like.

I’d ask that you give both ROOL and ROD enough credit that we all learn from the past and are not interested in repeating the mistakes of our forbears. Let’s go forwards positively :)

isn’t at all helpful to anyone

Put the kettle, make yourself a nice cup of tea… ;)

Given the fear that was expressed in the original message, it seemed to me that the worry was that if certain organisations were going to go off in their own directions, it risks a situation such as that which happened in the… shall we call it The Dark Ages?

You’re right. It isn’t helpful to anybody, but please be aware that as much as is happening with RISC OS 5 (and there’s no doubt that we’re all grateful for these efforts), we do lack a certain amount of features and capabilities due to The Dark Ages, and as such nobody wants to see anything that even remotely resembles a repeat of that, because that really isn’t helpful.

Of course, RISC OS 5 is also better in loads of ways – still developed, can run on hardware that can kerbstomp any (genuine) RiscPC class machine, proper USB support, has a browser that can cope with 2021 not 1998, etc etc – but we’re (mostly) British which means we’ll whinge about the negatives first. It’s coded into our DNA… ;)

Surely a community of users is better equipped to suggest end-user needs, rather than a conversation between two individuals. Or maybe some people know better than the users what it is the users of the OS want?

I think this needs to be done in moderation. Ask for some outline ideas at the start to gauge what people are interested in (as this very topic demonstrates), but don’t ask us for actual guidance, otherwise you risk ten of us giving twenty different concepts. ;)

However don’t do things behind closed doors either, otherwise there’s the risk of what led up to this post, where what was delivered wasn’t entirely what people thought it was going to be (rightly or wrongly, not important, it’s the disparity).

We felt working DHCP was a must, and in the meantime have added drivers for Pi4, and USB ethernet.

Quick question – does it have the capability of supporting WiFi (should a driver exist)? Specifically can it DHCP at random times, cope with the network coming and going, and potentially with a different IP address each time? Things that the current setup gets itself in a bit of a conniption fit over.

Oh, and will it support IPv6?

Just interested…

Rick – yes, it already includes 802.11 protocol support in the stack, but of course we have no drivers (yet) to connect to any of that. IPv6 support is also included, and seems to be working. Testing of IPv6 is somewhat limited by the fact that most ISPs and home networks aren’t really set up for IPv6.

DHCP has been implemented to (AFAIK) allow it to happen transparently, and the OpenBSD original code has been auto-munged to output a RISC OS module. A core tenet of the project is making sure that as much as possible can be automated to make translation from BSD to RISC OS easy. We don’t want to wait another 20 years to do this.

There are more layers required to get to a point where wifi hardware drivers can be written for (any) hardware, but rest assured that both ROD and ROOL are working (together) to make this a reality.

One piece of tech that we’re currently missing is a decent config UI. The existing one is, unfortunately, rather sub-par and is arguably in part to blame for the DHCP issues you mention previously (technically the existing stack can bring up and re-dhcp within the desktop, but the UI doesn’t allow for anything like that). Something more modern, perhaps profile-based, with a supporting network manager application (to provide Wifi UI etc) is still needed. Realistically, this is a project that someone else could tackle – it doesn’t necessarily need to be the stack guys, as the UI elements merely need to generate the config files and/or prod the stack as needed. I haven’t spent much time visualising the UI yet, because I feel like none of the major OSs quite get network config right.

I think this needs to be done in moderation. Ask for some outline ideas at the start to gauge what people are interested in (as this very topic demonstrates), but don’t ask us for actual guidance, otherwise you risk ten of us giving twenty different concepts. ;)

I think it also must be borne in mind that most regular contributers to this forum are a million miles away from what your average RISC OS user is like!

I think it also must be borne in mind that most regular contributers to this forum are a million miles away from what your average RISC OS user is like!

Well said.

I would be a lot richer if I had a pound for everytime the product development /testing guys said “Why would they be doing that” in response to a bug/product issue whilst doing beta testing.

I think on where RISCOS is heading it needs to top level strategic guidance ROOL/ROD and other elements may be better suited to mostly end user input.

It is about getting the balance right and after all sometimes we seem to forget that RISC OS still has some commercial value and things may be dictated by that as after all it may mean more money available for the nicer things..rounded icons anyone..steps back quickly :-)

. The work has been rather delayed this year due to complexities getting modern DHCP working.

All those options that are currently ignored – option 252 comes to mind.

In the process of this, the remaining previously-closed elements such as Resolver and MbufManager are being replaced by new Open Source versions.

Removing a whole collecion of limitations that have impeded RO networking for 20+ years

In this case, I’m keen to avoid duplication of effort,

As a first responder to the thread that was what I was trying to do by reminding someone that the bounty text invites people to contact and discuss.

@John:

Wasn’t it always the intention that ROOL were the custodians of the OS, or did RiscOSDev change that when they bought RiscOS?

I think Andrew has partly explained that one. What he hasn’t said, probably because he thinks it might come across as an excuse¹, is that Castle had over a decade to grow into the ownership role and build the relationship with the members of ROOL. Andrew is still finding his way.

¹ Damned if you do and damned if you don’t really.

Testing of IPv6 is somewhat limited by the fact that most ISPs and home networks aren’t really set up for IPv6.

Standard users of the BT setup have that thrust upon them. I’d expect PlusNet (BT in different clothes) to be similar.
Everyone I know looked into the settings and turned IPv6 off internally wherever possible, except the ones that don’t even know what IP is, never mind v4 vs. v6

yes, it already includes 802.11 protocol support in the stack,

Sweet!

but of course we have no drivers (yet) to connect to any of that.

Of course, but it’s more likely to turn up sometime given that one doesn’t need to fight the stack in order to get it working.

Testing of IPv6 is somewhat limited by the fact that most ISPs and home networks aren’t really set up for IPv6.

I’m 2a01:cb08:xxxx:xxxx::/56, and heyrick.eu is 2a00:b980:2:3:0:0:1242:34c2. :-)

We don’t want to wait another 20 years to do this.

Yes, like AcornSSL – make RISC OS fit the code, not the other way around.

because I feel like none of the major OSs quite get network config right.

The joy of trying to configure a complicated thing in a simple way.

Though, I know what you mean. While getting networking running under XP is pretty easy (usually with the help of some sort of third party “wizard” to make it look effortless), if you delve inside Network Connections → Properties… my god, what a nightmare.
I kind of get what they’re trying to do, it just seems like a really klutzy way to do it.

everytime the product development /testing guys said “Why would they be doing that” in response to a bug/product issue whilst doing beta testing.

That’s the joy of beta testing. Other people can come up with a degree of deviousness that is quite astonishing. “Wait, you managed to crash my program by having a cat sleep on the keyboard overnight?” “You managed to mess up the screen display by grabbing the scrollbar and yanking it up and down for several minutes?”
Don’t ask why, just be glad the tester found it before the general public. ;)

In the process of this, the remaining previously-closed elements such as Resolver and MbufManager are being replaced by new Open Source versions.

I presume MbufManager’s new code is stable now. As it is independent of the network stuff, pushing it in the main repository now so it can be exposed to nightly build users could be a good idea.

I have sympathy with both views here.

Andrew is boldly standing up and trying to coordinate. That enthusiasm is great, and I cannot knock it. If I thought I could do better, then I should do so, shouldn’t I?

But sometimes these developments feel a bit like a secret club. For example, if there is a new network stack (or even subcomponents like MBufMgr) then wouldn’t it make sense to have a branch on ROOLs GitLab with the changes, including all the source control check in history etc? Surely ROOL wouldn’t appreciate a zip file with some new source code?

This problem isn’t exclusive to ROD, mind you. I think much of the RISC OS marketplace (including non-paid stuff) is rather hidden and hard to discover. We could do with a one-stop place for software etc.

Andre, yes, we have discussed that very topic with ROOL at a couple of meetings. The biggest challenge is (IIRC) that there are some dependencies on other parts of the OpenBSD stack port (libraries?) so there’s a bit of untangling there to make it standalone.

But yes, it is very practical, and planned. IIRC both mbufmanager and resolver should work with either stack and be standalone. Of course, testing with the old stack has been rather limited so far – I think there was one bug remaining last month in resolver on the old stack, but my brain isn’t firing on all cylinders tonight.

I do actually agree with Richard Walker’s comment about having a branch (another topic that we discuss regularly with ROOL). The same can be said for bounties too, which could benefit from more visibility in development. The main reason that neither methods tend to be visible (we’re all guilty here) is that work-in-progress code is often extremely ugly, and you may well not want it to be seen in a public manner. As such, devs tend to do things on private servers until they’re happy it works well, then do the “ok, let’s make it look nice” pass once they’ve established that it works.

(pause for breath)

One of the reasons that we pre-announce ROD stuff (rather than pulling it out of a hat like I tend to do with R-Comp) is so that other RISC OS coders/developers know what we’re working on. This way, if it might impact them (eg. network stack / drivers) they have fore-knowledge and can ask questions from us ahead of time. They can be as involved (or not) as they wish.

It is also easy to forget that a lot of us work best on phonecalls. I tend to have periods where I cannot deal with forums etc because I am not thick-skinned. My offer of a phonecall to John above was entirely sincere – it is how we all communicate within ROD and outside. This is kinda old-school, but our numbers are well known, and we always try and keep in touch with other developers and community members as much as possible. We just don’t do social media etc, and feel like fish-out-of-water in some of these environments.

Standard users of the BT setup have that thrust upon them. I’d expect PlusNet (BT in different clothes) to be similar.

PlusNet may be owned by BT, but they don’t have IPv6 or any serious plans to implement it, and that’s been the case for a decade.

work-in-progress code is often extremely ugly

Hmm. While I’m as guilty as anyone else of bodging in a hack “to get the damn thing working”, I also subscribe to the idea that code is as much a set of instructions for a compiler, as it is an artistic expression. As such, ugly code is to be avoided. Now, clearly we all have our own perspective on this (don’t mention K&R braces or hard tabs!), but we should all aim for pleasing code.

It will reward you in the future when you come back to the project after doing other things, and you don’t have to ask yourself “what the hell does foo() do?” or "why is half this code commented out saying “broken”, how/why/what?

Above all, comment, comment, and comment some more. If you had a teacher who told you to comment minimally, if at all, your teacher likely never had to actually maintain his/her own code. Don’t rely on you remembering it. What all makes perfect sense now will seem like an alien language in a decade (unless you spend that decade working on the same thing). It doesn’t take much to drop in comments along the way.

Also, don’t be afraid to add notes of things that might need seen to in the future (potential issues that come to mind, or ideas for additions). My preferred prefix to these is “##TODO##” because I can easily search for that. Do it right then as the thought occurs to you. You probably won’t recall everything that popped into your head “in a few minutes”.
And above all, remember that you are writing this code for a person to understand and appreciate every bit as much as for a compiler. You are creating art.

Most open projects are more than happy to share work in progress code, as the primary intention is to encourage community participation in helping to fix it!

Unfortunately ROOL and particularly ROD haven’t been great at building a community interested in helping them. Things are discussed and decided behind closed doors, a user base considered a cash resource rather than development resource, and barriers such as charging programmers to contribute to the codebase (by charging for the tools) have created little interest outside the usual contributors who are motivated by money.

If people have not had a chance to read these rather influential essays from the mid 90’s they might be worth checking. They explain a lot of the ethos behind successful open projects and the people who want to contribute to them;

http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
http://www.catb.org/~esr/writings/cathedral-bazaar/homesteading/