Using open source libraries on GitHub to support RISC OS in Wifi, USB etc.

Mr. Cawley, it’s about dragging RISC OS, howling and screaming a bit apparently, into the new Millennium with all it entails regarding digital standards and technologies. It’s a major undertaking for several reasons, the financial maybe the least.

Once in 64-bit-land several new opportunities can be opened up for RISC OS in several product areas, mobile phones may be the foremost in volume if not in geekness. Assumnig a new programmer-friendly SDK modern Arm CPU’s and GPU’s can do some pretty amazing tings in audio/video creation and production. Potentially. Content Creation.

A modern OS needs to be written from the ground up supporting kernel level threading.

32-bit multi-processing, multi-threading on ARM: https://github.com/Simon-Willcocks/SimpleAsPi

The (42nd) plan is to have a legacy svc stack that all legacy modules etc. use, and modify the Wimp to allocate it to the task it returns Wimp_Poll to.

The new stuff will ignore service calls, etc., and communicate using pipes and queues.

It will probably work as well as the previous 41 cunning plans. :(

Once in 64-bit-land several new opportunities can be opened up for RISC OS in several product areas, mobile phones may be the foremost in volume if not in geekness. Assumnig a new programmer-friendly SDK modern Arm CPU’s and GPU’s can do some pretty amazing tings in audio/video creation and production. Potentially. Content Creation.

You really are living in cloud cuckoo land.

Assumnig a new programmer-friendly SDK modern Arm CPU’s and GPU’s can do some pretty amazing tings in audio/video creation and production. Potentially. Content Creation.

So is this something that you personally want to do with RISC OS? I never got an answer to that question when I asked before.

“it’s about dragging RISC OS, howling and screaming a bit apparently, into the new Millennium with all it entails "

virtualisation is decidedly a new Millenium thing.

If you want to take advantage of more powerful hardware then you can have native applications that present a RISC OS front end on the emulated desktop (and you as a user would be oblivious of the difference). X Windows was designed for more or less exactly that (the application need not be running on the same computer as the display – this would be the same except the display computer would be emulated). It would be far easier and cheaper to develop the applications for that than to reimplement RISC OS.

(wonders if that might be a way to make use of idle cores…)

Don’t get me wrong, if I was a rich as Elon Musk, 64 bit RISC OS would be in the pipeline but sadly financial issues are dominant – it will never be commercially viable, but it would be higher on my list of hobby priorities than playing with rockets.

BTW its Dr Cawley (Electronic Engineering) but do call me Gavin.

Using “Mr.” (or “Mrs./”Miss" as the case may be) is considered neutral when the background/education of the person spoken to is unknown. Using first name in the same situation I’d consider a bit rude, a false use of familiarity. Now that this is out of the way,

I’ve stated elsewhere on several occasions that I used RISC OS, quite successfully, between 1992 and 1997 for desktop publishing and illustration work in my company Dolphin Design. 97/98 I wasted working for MediaLab/Network Computing with sundry Network Computer/N|C issues, mostly graphical. So no programming. But I’ve worked with programmers and picked up some knowledge by osmosis, thus not speaking from total ignorance.

All I want in this matter is for my favorite operating system to grow up, become a modern OS with all this entails. That isn’t trolling, that’s evolution of a good idea, the very productive RISC OS WIMP. It’s the stuff beneath, the Core and RM’s that are lagging far behind in general development. I truly hope you all can see that, now. Started this thread to see if it could contribute to that end, with possible benefits for 32-bit RISC OS as well.

I note that you have ignored the substantive content of my comment. Virtualisation is a fully “grown up” approach (c.f. Windows subsystem for linux). As a user, you would not be able to perceive the difference. If the desktop and look and feel is all that you are interesting in preserving, emulation is a very satisfactory solution. You have provided no counter-argument against that approach.

If it is more than just preserving the desktop and look and feel that you are interested in, what is it?

“thus not speaking from total ignorance.” fine, but you also need to be able to listen to those with genuine expertise and experience (not particularly referring to myself there – but there are others here who are very experienced experts) and not ignore what they say.

RISCOS will never be a modern OS – it simply isn’t commercially viable – the market for it would be miniscule. That doesn’t mean it doesn’t have a viable future, I think it may do, but obviously not as a direct competitor to Windows/MacOS or linux etc.

Desktop publishing is something that RISC OS is still very strong at indeed and, apart from programming, it’s my main use of RISC OS since nearly 30 years. Professional typographers are still surprised when they see what I can achieve with a seemingly simple program like OvationPro in conjunction with the OS. Switching to 64 bit however won’t improve that productivity at all. Better connectivity would (SMB3, USB3, Wifi, modern browser), which I am far more impatiently waiting for than the laborious switch to 64 bit.

Hi Sveinung,

You are of course entitled to your forthright opinions on the necessity for RISCOS to be 64-bit in order for it to have a future. I’m just not entirely sure how useful it is to repeat them quite so often and quite so vociferously given that many of the current user-base seem perfectly happy that RISCOS survives in any form at all, a feat which itself requires a lot of effort by a small group of passionate people. And then there’s the small matter of the collosal effort to achive a 64-bit OS that will kill off all existing apps in the process.

It feels a bit like turning up at a classic car club every week to loudly insist that the cars have no future unless they’re adapted to run Formula 1 engines: it would be practically impossible to achieve, ruin all the fun and you’ve told us already…

This debate has highlighted the potential benefits of virtualisation though, for me at least.

There’s a difference between Classic and very under-developed – a categorical difference.

Also, legacy software can run at adequate speed under emulation with little finger-drumming so that’s no argument against going 64-bit since this will give RISC OS all modern amenities, more than covering any perceived loss. And Acorn Computers Ltd. wrote RISC OS in assembler to squeeze every iota of performance from the (now considered) rather pedestrian ARM2 CPU – putting it in amber development-wise in the process.

It’s pretty obvious that rewritten in C, RISC OS will step out of the amber deadlock and be compiled into both 32 and 64-bit. It’ll take time and money, and be on par with other operating systems in capabilities, probably beat them hands down in sheer speed, for emulated legacy software too. And be ready when 128-bit CPUs become the norm.

Clinging limpet-like to the past doesn’t guarantee a future.

“Also, legacy software can run at adequate speed under emulation with little finger-drumming so that’s no argument against going 64-bit since this will give RISC OS all modern amenities”

err, no. going 64 bit has a high development cost which emulation doesn’t, so if legacy software (and that is pretty much all we have) can run at reasonable speed, that is an argument against going 64-bit as the emulator is already satisfactory.

For modern applications, I have already pointed out they can be written as native applications which only present the interface via RISCOS.

" It’ll take time and money,"

yes, huge amounts of time and money that nobody is able/willing to invest when we can still get what we need from emulation

“and be on par with other operating systems in capabilities,”

that is just absurd. The development time and money that has gone into those operating systems is huge, and it is hubris to think that the riscos community is able to do better on volunteer time and negligible budget.

Note these discussions are sapping volunteer time and energy – I could be working on !tabby or the IDE I was writing for RISC OS. If you really want 64-bit RISC OS then your approach is counter productive. I’ll leave it there.

And Acorn Computers Ltd. wrote RISC OS in assembler to squeeze every iota of performance from the (now considered) rather pedestrian ARM2 CPU

Are you sure about that? I’d have to spend time that I don’t have searching the forum archives to confirm, but I seem to recall one of the people who wrote Arthur (“RISC OS 1”) in assembler stating that the decision to do it that way was because there wasn’t a usable compiler available for the system at the time when it had to be done.

No need for searching archives: exactly that, Steve. I’m sure both Paul and I have mentioned it several times.

And 37 years later, the C compiler still doesn’t produce ROM-able PIC. [Try *RMFaster FileInfo for a laugh.]

Aside: It could have been worse – Acorn insisted that we write it all in Acorn Extended Modula-2 (“We’re still doing drivers ;-)”). Acorn lost the use of M2 to Olivetti in 1988 I remember (Yup. ¹) so AAsm and the PC emulator had to be rewritten in C.

¹ https://www.chiark.greenend.org.uk/~theom/riscos/docs/Modula2ARX.txt

Note these discussions are sapping volunteer time and energy – I could be working on !tabby or the IDE I was writing for RISC OS

Definitely.

Do what you like doing, rather than what someone else pushes you to do.
Unless they are paying you enough to merit sole use of that time, and even then, make sure the job you’re paid to do is one you like doing.

to loudly insist that the cars have no future unless they’re adapted to run Formula 1 engines:

While the rest of the world is looking to go electric.

no argument against going 64-bit since this will give RISC OS all modern amenities, more than covering any perceived loss.

To bring some of the ridiculousness of this discussion into the harsh light of day, can you all please mentally translate all references to “64 bit” into x86-64.

Yes, x86.

It has sixteen registers (though the first eight have weird names for hysterical raisins), INT and SYSCALL… so it’s potentially just as viable a destination as 64 bit ARM. Which isn’t, in case it’s been missed the first dozen times, like the 26 or 32 bit ARM that we know from the history of RISC OS.

It’ll take time and money,

Much more of both than you could imagine, and for what, because…

and be on par with other operating systems in capabilities

…this is just nonsense. Not only do (select) other operating systems often come with binary blobs from the chip manufacturer to allow a mainstream OS (such as Linux and/or Android) to make best use of the available hardware; that stuff that is open source has legions of developers working on the many various projects. Do you have any idea of how many people are involved in making Linux do it’s thing?

Simply porting RISC OS to x86-64 (remember, translate it into this to get a better idea of what we’re up against) will not make magic happen. What you’ll end up with is a version of the OS that is fundamentally incompatible with current software (unless, maybe, it’s 100% written in BASIC and the API hasn’t changed in any way) that still has all of the architectural problems of the current (because fixing that would necessitate a vast overhaul of the API) and still won’t have support for half of the on-board devices, never mind luxuries like USB streaming video (e.g. a €10 webcam).

probably beat them hands down in sheer speed

Doubtful. The reason these systems are ‘slow’ is because they sanitise their inputs, check and enforce memory access rights, and so on. If this shiny new magical OS does the same thing (as it well should), then that’ll take time too.

Clinging limpet-like to the past doesn’t guarantee a future.

Neither does squeezing your eyes shut and saying I wish I wish I wish IwishIwishIwishIwish…

Note these discussions are sapping volunteer time and energy

Only for those bored enough to actually read this rubbish. ;)
Might I suggest a streaming radio station of your preferred genre, a nice cup of tea, and closing the browser window?

I’ll leave it there.

Probably for the best. Me too.

“The reason these systems are ‘slow’ is because they …, check and enforce memory access rights, and so on.”

The thing I like about RISC OS is that it doesn’t have those things, which makes it an OS where you can learn about hardware and hack about a bit with things (e.g. self-modifying code), but which is still fairly civilised. Good fit for the Raspberry PI. That would be lost if it became a “modern” OS.

Youtube rather than radio, but there was tea. ;o)

Hacking, fiddling, and frobbing is one thing. Watching the OS randomly stiff “because something” is quite another.
Any rewrite of the OS (even an imaginary one) must implement sane inter process protection and absolutely never allow itself to get into a state where the kernel can’t say “oi! you!” and terminate whatever is misbehaving with extreme prejudice.

Things like user mode apps able to access, manipulate, and change system memory is an abomination these days. As is the kernel happily handing privileges to whatever via a simple OS call. Plus the fact that oh so very much module code runs in SVC mode. And… it’s a long list of woe.

Tea good. 🫖☕

Never had a Linux kernel panic, Rick?

“Watching the OS randomly stiff “because something” is quite another.”.

Indeed, but I have linux for when I am concerned about that. I can’t see RISC OS ever competing with that. Even back in the day I did most of my programming under unix and X.

I’ll still have my Jupiter Ace for hardware hacking though – thankfully nobody is advocating updating that to 64-bit ;o)

Never had a Linux kernel panic, Rick?

Once, when it got itself in a twist trying to load something from a LiveCD.
But then, I don’t really “use” Linux. It sits inside embedded devices that just quietly get on with things.

On the other hand, yesterday my Pi froze when I went to search for something in Zap (F4, enter text, press Enter, oops) and on Friday it just froze up and I’m not entirely sure why but I’m looking at ShareFS as that’s what I was using.
I’ve even had Paint trigger a cascading error that killed everything before getting stuck in an abort loop.

It probably depends upon what you’re doing. Maybe it’s fine if you use Edit? (Zap is a bunch of modules, maybe a fair amount of that runs in supervisor mode and/or dumps workspace around the RMA) The thing is, RISC OS is quite easy to upset, in part due to its internal architecture. That lovely freedom to do what you want comes at the cost of “oh crap” if other stuff misbehaves.

Case in point – Pinboard2 or Freeway dying hard when the IPv6 SLAAC went boobies-in-the-air (because of how the error trickled up until something caught it, something entirely unrelated).

At least, with RISC OS 5, I don’t ever see that pile of nested fails when MessageTrans kicks the bucket and takes out everything. That happened semi-frequently on the RiscPC.

And, no, don’t mention Windows. 98SE was rock solid for me, and the only problems with XP are down to poorly written third party drivers (so I just don’t use the device and all is well). XP hasn’t been booted in ages, I shit down to hibernation, and wake it up from the dormancy.

thankfully nobody is advocating updating that to 64-bit ;o)

Is there such a thing as a 64 bit Z80? ;)

“Using open source libraries to jazz up RISC OS 32-bit (and the Fata Morgana 64-bit version) re. USB, WiFi, etc. was the starting point of this topic. Drifted off a bit, have we? Since it’s out of the question for practical reasons or because of certain tea-addled synapses? Judge is out there, smoking “tea”. We coffee achievers are doing just peachy. :P

Wonder what RISC OS would be now, if Acorn Computers Ltd. were still in business – can’t imagine they’d let RISC OS drift further and further apart from the Arm architectures they created (and for which they were killed) to the degree that the latest version doesn’t even support a 32-bit mode. The multi-core 64-bit Arm-world is a far cry from this architecture’s humble beginnings; 4 MIPS is peanuts to Arm CPU’s performance today.

And their best GPU’s leave VIDC far behind, able to do realtime raytracing etc. – that’s what 32-bit RISC OS is missing out on, and much more. Like written earlier, RISC OS is the most (for DTP/illustration) productive OS I’ve ever used, and I’d like to use it again, fully utilizing the CPU on my Rock 4 C+ single-board computer. From feedback thus far the term “flying pigs” is descriptive of the likelihood for this ever happening.

s there such a thing as a 64 bit Z80? ;)

Mutations of the 80 —> 8000 and then —> 80000 got it as far as 32 bit

Never had a Linux kernel panic?

Never seen that one. On the other, I stopped counting the number of time Raspbian stopped reacting to keyboard input and mouse clicks.

and I’d like to use it again,

Do it.

fully utilizing the CPU on my Rock 4 C+ single-board computer. From feedback thus far the term “flying pigs” is descriptive of the likelihood for this ever happening.

And you’re wrong. The RK3399 is now supported, so your board could be too (even if the Pi4 will be faster, so where is the point?).

The Pinebook Pro is a fully supported RK3399 laptop. WiFi (2024), multicore, GPU acceleration would be nice additions, but I guess it will depend on how much money RComp can make selling this computer.

I have one, do you?
And it does the job. Flying fast.
Question: did you ever use RISC OS 5 on modern hardware?

Nota, about “use open source libs to speed up development”: thanks, that’s exactly what we did for many components. And what is coming for the next Internet+USB stacks. It just takes years, as porting a full stack is not as simple as typing make on your Linux console.

That isn’t trolling, that’s evolution of a good idea, the very productive RISC OS WIMP.

Really? You know that the GUIs most people use today are mainly windowsless ones? (Android, iOS, web). How will you drag and drop an icon to the filer on a Phone with a windowsless GUI?

Anyway, the next step is not 128bit processors, but IA. And all GUI will become irrevelant here (OK: let’s say “much less important”).

could be working on !tabby

Oh yes please :)