The long term future of RISC OS

6 had Wifi?

I think a lot of the important groundwork is being done. When I look at the changelogs or the forum I see people discussing and fixing various ancient peculiarities, or adding desirable functionality.

Haiku is insanity. They had some bits and pieces of BeOS and built a new OS around it. It’s like restoring an old aeroplane from the dataplate. Although I feel I do have to point something out. It can be built to be BeOS compatible, or not. To many, compatibility with the old BeOS software comes second to being able to use modern tools, other architectures etc. Ie to move forward.
I’m not a rabid Haiku proponent. I’ve ran it in a VM for years on my PC though. While I’m rambling on, has anyone had a look at Haiku’s Wifi? I think it was ported across from FreeBSD. Given their differing ideology there’s a chance it’s more monolithic than the original. Ie less external dependencies.

Wifi was implemented in ROS6

[citation needed]

Not quite that straightforward!

ST Developments sort of had wifi for RISC OS around the era of RISC OS 4/6

I wonder if this might be a starting point for new wireless networking. I’m sure I read on Drobe that it had WEP encryption, so that might need updating a bit!

Thought I had…
http://www.drobe.co.uk/article.php?id=531

Hmm…

clicks

Aha:
Here it is on STD’s website.

Thanks Andy & Vince :)

Aha:
Here it is on STD’s website.

That web site page has not been updated for 14 years…

That web site page has not been updated for 14 years…

My guess is they don’t sell them any more! :-)

But at least someone had a go at it once and got it to work. I seem to think the NET100 was a partnership between several RISC OS companies, so maybe one of them can get STD to release the source to bring it up to date?

I seem to think the NET100 was a partnership between several RISC OS companies, so maybe one of them can get STD to release the source to bring it up to date?

I think Castle were part of the equation and probably the only ones with activity this decade so contacting the owners of all their IP might work out.

I think Castle were part of the equation

I also think that RComp might have been too, so that may actually be doubly relevant!

I think Castle were part of the equation

No. Simtec, R-Comp, STD. At least for Net100. Not sure about USB, UniPod and VPod – maybe only STD and Simtec.

That web site page has not been updated for 14 years…

I thought that was obvious – I posted the link because it contained more detail about something being discussed than the Drobe page linked. With hindsight, though, I should probably have said something to that effect.

SMP was implemented in ROS3/4

No. At least not in any meaningful way.

Wifi was implemented in ROS6

No. A specific USB dongle for a dead USB API that connects you to Wifi with WEP encryption is not the same as useful Wifi support. And that USB dongle driver was not ROS6 specific.

A specific USB dongle for a dead USB API that connects you to Wifi with WEP encryption is not the same as useful Wifi support.

Ah, that’s what I figured – because there’s just too much that WiFi does that would require big changes to how the Internet stack behaves (such as finding and choosing access points, plus understanding that if the signal drops out and reconnects you’d need to do that DHCP stuff again and maybe get a different IP address) and all of this happens normally all the time.

So it sounds more like a directly-connected USB incarnation of a Vonets adaptor (that manages the WiFi stuff for itself so RISC OS doesn’t have to!).

As for the SMP – Acorn has a history of running multiple processors (and not necessarily the same as the host), from the Tube on the BBC Micro to the x86 co-processor in the RiscPC. However SMP specifically refers to multiples of the same processor coupled together.
The only thing that ever did that was the Hydra expansion. Which was not supported as standard by RISC OS…

With four slave processor cards fitted a RiscPC with Hydra has, in theory, five times the processing power of a standard RiscPC. Unfortunately the operating system RISC OS is not a multiprocessor OS and has no way of taking advantage of this increased processing power. One way to make effective use of Hydra is to switch to an operating system which does support multiprocessing such as RiscBSD, Helios or Taos. This has the advantage that any applications software which can multithread will automatically take advantage of any available processors. However, for the ordinary RISC OS user, the easiest way to harness the power of Hydra is to use application software written to enhance parts of RISC OS which uses the Hydra API. As the API exists independently on RISC OS, any MP aware applications will make use of the new resources and ordinary applications will run unaffected.
[source document]

So no, there has been no standard SMP in any version of RISC OS ever produced. There is a start available for multi-core devices, but it hasn’t to my knowledge been included as a standard part of the stable ROMs, yet…

However SMP specifically refers to multiples of the same processor coupled together. The only thing that ever did that was the Hydra expansion.

While the Hydra card was multi-processor, there was no software support that could reasonably be called “SMP” – at the end of the day, what Jeffrey provided as multicore support for our current RISC OS 5 platforms is not that different from the Hydra API – basically, you set up everything by hand, and it is assembly only.

The Hydra was not even StrongARM-compatible (there was a prototype in Simtec’s labs apparently…), and its software support never evolved into something halfway useful. Just providing a carrier board for multiple CPU cards is not “SMP”.

Just providing a carrier board for multiple CPU cards is not “SMP”.

Sorry, I want entirely clear. When I referred to hydra, I was referring to the “multiples of the same processor” part, not the SMP part. SMP must, by necessity, be a functional part of the OS to qualify, not an add on (bodge?) requiring specific (was any ever written?) software.

BTW, I noted this further down when I said there’s never been an SMP for any version of RISC OS ever produced.

what Jeffrey provided as multicore support for our current RISC OS 5 platforms is not that different from the Hydra API – basically, you set up everything by hand, and it is assembly only.

I believe that recent versions of C (11 and 18) have built-in threading support. I wonder how practical it would be to implement these functions in RISC OS C, where they’d call Jeffrey’s features for you.

NB: My threading/multicore knowledge doesn’t extend far beyond “I know that they exist”.

IIRC the threading is a stub in UnixLib. I think part of the plan for Jeffrey’s SMP code was to eventually add that missing support to UnixLib.
That’s just a rather faded memory, so I may well be wrong.

I haven’t looked, but I imagine that UnixLib contains POSIX threads (“pthreads”) stubs rather than the “native” threading provided by newer versions of C. I wonder whether one is “better” than the other.

I haven’t looked, but I imagine that UnixLib contains POSIX threads (“pthreads”) stubs rather than the “native” threading provided by newer versions of C. I wonder whether one is “better” than the other.

I am not a C expert (and even less of an expert on newer C standards like C11), but I think the general idea was that the “native” threading was more like a least common denominator which would be implemented on POSIX systems as a wrapper to the POSIX threading functions.

IIRC the threading is a stub in UnixLib.

No, it is a “real” multithreading implementation (single tasking, single core execution naturally…) based on callbacks. See Jeffrey’s post in this thread:

https://www.riscosopen.org/forum/forums/3/topics/921

No. At least not in any meaningful way.

Could be better today.
The idea was not really SMP, but more a ‘time limit’ implemented as interrupts.

Anyway, with selected apps (and only them), it was working very well.

Ah, that’s what I figured

I was not here :)

As for the SMP – Acorn has a history of running multiple processors (and not necessarily the same as the host), from the Tube on the BBC Micro to the x86 co-processor in the RiscPC

AMP?
I love AMP. It’s not easy, but efficient. SMP is lazy.