arm64

Risc OS has resiliently persevered over many years to provide a suitable platform for creativity, which involves necessary support and maintenance. Technology moves fast, and there are still many enthusiasts like myself passionate to explore new avenues to express and share their fresh ongoing ideas, through this hobbyist outlet so superbly provided here.

So, no matter what stage of know-how we`re each at, there is a wealth of opportunity and resouces, both social and personal, to draw from to take this exciting technology further, that arm64 opens a door of adventure and even continuity for. The Raspberry Pi seems more suitable for younger schoolgoing mainly, as indicated by 1 GB fixed memory, whereas an alternative platform like Pine A64 caters for all ages evenly.

Nothing less than USB3 (which is tricky apparently in terms of graphics ability), gigabit ethernet, full hd and minimum of 2 GB memory upgradeable to 4, is ideal to grow with and from. Risc OS can do with a total rewrite from scratch as 64-bit, without dependence on porting, for absolutely new software like games even, using an innovative graphical language like Scratch or a new project one, while 32-bit holds the fort separately in the meantime, with the human software spirit providing precedence and cohesion.

Have been looking further into related platform boards, and the Rock Pi 4 SBC (Single Board Computer) has it all, including the A option of no wifi to suit preferences of some of us wanting to reduce radiation, plus upgradeability of memory to 4 GB, that a local South African distributor is looking at importing still, along with obtaining a hopefully reasonable price for. The point which I saw raised elsewhere is to have an independent platform that can be capably used for any development and programming without requiring a separate and conventional workstation running Windows, MacOS nor even Linux/Unix/BSD.

The Rock Pi 4A micro board has a USB3 and another for OTG (data and devices) plus USB2 times 2, Gigabit Ethernet, takes 2 amp power supply, between 1 and 4 GB DDR4 memory, and has an 8-core Rockchip processor, while being a similar size to the Raspberry Pi 3-series, all requiring newly written drivers and CPU instruction set. Of course, for wifi lovers, the 4B model suits you, so can broadly have our cake and scoff it.

Maybe the audacity to tackle a Risc Rom and OS build will strike an assistive chord with manufacturers (in return for let`s say, some software programming expertise) to offer a reasonably affordable price with more than enough coding info to enable enjoyable and productive development of a complete modern fun arm64 computer running all Risc software, the difference here being that we have 1. passion and love for technology, and 2. plenty of resources, that liberates us to achieve something worthwhile like this.

This Rockchip RK3399 is pretty much the latest CPU release and seems set for fair longevity and continuity of architecture to base an evolving Risc OS for the present and LTS future.

The Rock Pi (Rockchip-based) and the Pine64 (Allwinner-based) seem like an ambitious porting target without clear advantages against say IGEPv5 or BeagleBoard-X15 (OMAP5-based, for which a port already exists and which is still firmly in 32bit land).

I don’t buy into the “1 GiB RAM is for younger schoolgoing mainly” and “serious use demands 2-4 GiB RAM” argument – in a RISC OS context, even 512 MiB is plenty.

Risc OS can do with a total rewrite from scratch as 64-bit

Now that sounds more like a trolling attempt.

Let’s call the newly rewritten version of RISC OS “RISC OS II”.

Risc OS can do with a total rewrite from scratch as 64-bit, without dependence on porting, for absolutely new software like games even, using an innovative graphical language like Scratch or a new project

Wait, is that saying RISC OS should be rewritten in Scratch!?!?

Risc OS can do with a total rewrite from scratch as 64-bit

I agree that one day, this will need to happen to some degree, or RISC OS will be stuck within emulation. The first move is to replace key parts of the OS that are currently in Arm with C versions (taking some opportunities to modernise at the same time). We’ve started in that direction in some of our bounties. Once the majority of RISC OS is written in C, moving it across to the 64-bit architecture becomes a more manageable job. Whether there’s enough manpower available to do all of this is quite another matter.

The first move is to replace key parts of the OS that are currently in Arm with C versions (taking some opportunities to modernise at the same time)

I agree the OS needs rewriting in C if it’s going to become a “mainstream” OS, at some point we also need to figure out a replacement for CLib that’s compliant with modern CPU…if we retain a soft-loadable C library and don’t switch to DLL that is.

At what point however does RISCOS become something else? What makes RISCOS great is the access to bare metal and complete lack of security, allowing things that you could never do on a mainstream OS.

To Stefan: An ideal board on balance for now is the Rock Pi 4, based on it`s similarity to, yet necessary advanced features over, the Raspberry Pi 3, according to available models as a screenshot, at a likely reasonable cost to be confirmed.

The idea is to retain the current minimal 32-bit mainly Raspberry Pi direction for Risc OS as normal while concurrently proceeding with exploring new ways to create 64-bit code, preferably without emulation even, using raw binary, so as to build a totally new system without dependence on any other borrowed software, from the ground up, as the only original approach, and in other words, side-stepping all our regular available tools to get in touch with pure raw binary, from which to create all new boot code and tools like emulators and languages from hereon.

Means going back and forwards to new basics and reinventing our wheel, now isn`t that awesomely exciting, as a hobby project, being translated into and expressing new ways of doing and enjoying things, and so providing continuity of concepts as a priority over just continuing porting of older software. What is there to lose with so much variety and capacity available to have fresh fun with.

And Steffen, the 1 to 4 GB memory range is to allow for possible optional ramdrives and other unconventional extended use of memory for faster processing of programs and data. Yes, you are spot on about how much less is necessary compared to bloated Windows situations and recommendations. Just looking forward with spare capacity to play with, that makes the additional expense worthwhile and useful. Thanks for your intelligent and objective insight.

To Patrick M: calling it Risc OS II, brilliant and perfect, mate !!!!!!!!!

To Steve R: The object is to move forward for the fun of progress as an adventure, so let`s align ourselves with a new language like Rust that advances on C and that`s presently used to write Redox in, all pure 64-bit already, and resulting in a shorter and more satisfying learning curve, with the immediate implementation of a totally graphical operating system and language based on pictures of everything that clicking of mice or fingers alone will suffice for, represented in simple context by Scratch language, yet taken far further, right from the outset. Your input is well-appreciated and admired, Steve.

And to Jon A: Love what you say and your positive curiosity and perspectives.

Turning this back into a timeless hobby venture leaves no care in the world about competition nor effort nor obligation to anyone, nor an issue of sufficient manpower, since there are no expectations, and this is a journey of love that anyone wholehearted can participate and share in as pure democracy, and look how human initiative and inspiration stepped in for Linus from others building up 32-bit Linux in the early 90`s, that never ceases and is as constant as a rock in human nature especially when rising to new heights of interest and challenge.

The whole art in getting this absolutely right is to minimise the main elements right down to single unified ideal. This way, synergy kicks in to make the ride stimulating and fulfilling.

In the first paragraph, meant To Steffen, not Stefan, so excuse the typo.

a totally graphical operating operating system

Excuse me if I float a little closer to the earth. What made RISC OS so special was that it treated the GUI as an essential component, not just something tacked on to a commandline. It was designed a single-user OS, so that the OS’s reaction to user input could have highest priority. It is this immediacy and consistency of response that makes it feel so pleasant compared to certain other OSs. However, it was designed with a single-core CPU in mind, and I believe that would-be RISC OS designers will need to put their thinking caps on when it comes to extending the RISC OS feel to multi-core CPUs.

There was a RISC OS browser, whose name I have long forgotten, that gave the user an option for lazy loading of graphics. It would display a webpage with empty frames for where it guessed the graphics would go (if the IMG tags had no height/width attributes it would not know the precise dimensions to allocate until the actual graphics file arrived). The user could then click on an empty frame to force an immediate download of the graphic. The difficulty with this is that the user may not know how relevant the information contained in the graphics will be to what she intends to do with the webpage – e.g. click on BUY ME buttons.

This is an example of a more general user-interaction problem. On a multi-core system the loading of the graphics files might well be relegated to other cores. For the user to be properly in command she needs some control over the prioritization policies to be used by the OS for delegation of subtasks. Is the subtask urgent or something that can be left for later. User interaction may be needed to decide. I do not think GUI design has addressed this issue, but I would be glad to be corrected.

The object is to move forward for the fun of progress as an adventure, so let`s align ourselves with a new language like Rust that advances on C and that`s presently used to write Redox in, all pure 64-bit already,

I’m so glad to see someone volunteering their services (and much time) to rewrite the OS from scratch (with largely the same API of course otherwise it wouldn’t be RISC OS).

When you have a board just drop another line here and I’m sure the experienced hands at breaking boards writing HAL/kernel code for the 32 bit boards will be chipping in with helpful hints.

To GavinW: Wow, thanks for that info. There is generally need for command line input, especially for tweaking and programming in languages and for shell instructions, yet the time is right and here to radically change all that to total graphics for everything without ever requiring a keyboard, whether touch screen or not, through providing graphical alphabetic sets on screen and / or designing a new keyboard for a different form of input towards a style of gaming controls moving shapes and patterns around singly or in combination, and is the essential reason to undo and replace the current approach, to one of manipulation of images as the norm, and thereby giving recognition and extended life to the wonderful gaming machines and traditions from the past whether Commodore 64 or Amiga right up to XBox and Playstation as the main thrust for computing technology, that accommodates business functionality, in that order and not the other way round…..

…..in true recognition of the universal fact that business feeds off hobbyists as a rule, and that would cause the creation of a new 64-bit platform to be completely viable and valuable and cherishable, while providing an outlet for a broad range of human activities and pleasures in new possible ways. Yes, you`re so right about exploring multicores, like for performing more functions simultaneously in new ways.

To Steve P: Shifting the goal posts changes the nature of the game and activity to a new high level of involvement and indulgence and participation, intended and anticipated to be no more about trial and error but logical meaningful fun vastly differently, and way beyond any present perception of “different day, same complications” thru the perfect way that we freely express our choice to create a better world for all. There is no room nor need for having to grit one`s teeth or break any backs negatively speaking anymore, cos we`re taking charge of our destiny to have our cake and eat it positively as the norm for enjoying life through our hobby here and other ways satisfying our personal balance and higher aspirations fully.

Jon:

if it’s going to become a “mainstream” OS […] and complete lack of security

There’s your #1 reason RISC OS won’t become a mainstream OS. That’s not to say RISC OS cannot carve out a niche for itself (consider – a Pi Zero costs the same as one of those Arduino boards and can run a full OS with BASIC…) making positive points out of the things that would normally be negative. No security to speak of? Great, like you say, loads of access to the nuts and bolts!

At what point however does RISCOS become something else?

When the API fundamentally changes. Nobody is going to care what language the Wimp is actually written in so long as it works as documented. However when it becomes APCS compliant, called through a mechanism other than SWIs… well, there’s the old orange and the new pear…

John:

An ideal board on balance for now is the Rock Pi 4,

RISC OS is not Linux. RISC OS does not look like Linux, run like Linux, nor use Linux bits.

For that reason, a good board for RISC OS has approximately zero to do with what features are available (SATA, USB3, etc etc) and everything to do with the quality of the documentation.

ARM boards are typically designed to work with Linux and/or Android, and this is achieved by using a standard build of the OS along with a vendor supplied “binary blob” that contains the low level drivers appropriate for the board.
We can’t make use of that, it’s for Linux (or Android). For RISC OS, we need documentation of a sufficient degree of quality that the information is there to permit a driver to be written.
Go look up the technical reference manual for the Texas Instruments OMAP3 (as in the Beagle family). If I remember correctly, it’s around three thousand pages. And that doesn’t cover the GPU, the OMAP helper chip, or the other peripheral bits.
Most of these ARM boards have abysmal documentation. The Pi’s is pretty poor with bits scattered all over the internet. At least in that case, we epic cheated. ;-)

Every so often somebody comes along and points out a hot new ARM board that would be great for RISC OS. But if nobody can tell us the memory location and meaning of each individual bit that needs to be set or cleared at system boot just to get the hardware to a stable state for starting the OS proper, then the board isn’t suitable for RISC OS.

So step 1 is “identify a good board”, but step 2 must be “assess quality of technical documentation”.

and in other words, side-stepping all our regular available tools to get in touch with pure raw binary, from which to create all new boot code

Isn’t that basically a hypervisor? I’m not familiar with the Pi 3’s behaviour (maybe Jeffrey can tell me if this is feasible), but it may be possible on a machine like the Pi 3 to initially start with a 64 bit hypervisor. This will switch a core to 32 bit and start RISC OS as normal, but allow for (an)other core(s) to remain in 64 bit mode for running 64 bit code. Not sure how you’d control a 64 bit core from a 32 bit OS, mind you. ;-)

And Steffen, the 1 to 4 GB memory range is to allow for possible optional ramdrives and other unconventional extended use of memory for faster processing of programs and data.

Get to know RISC OS. You’ll really discover that pretty much the only unconventional extended use of memory is running the Otter browser (all those shared libraries!). I have my Pi running the development environment, NetSurf, the usual stuff I have loaded, and… um… 950 megabytes free.

The RAMdisc is limited to half a gigabyte because the format applied is the old (512MB max) one.

new language like Rust that advances on C

We’d first need a functional compiler. Rust sounds “okay” from the brief look I just had. Familiar enough to C, only (hopefully) without the icky bits nor the crazy that C++ introduced.

all pure 64-bit already

Small note: Whether or not it’s 64 bit ought to be irrelevant when you’re using a higher level language. Example? My OvHTML translator for (simple) HTML (3.2 era) to OvationPro documents. There’s one that runs on RISC OS and one that runs on Windows (as a command line filter). The RISC OS version has a bunch of UI setup things that the Windows one lacks. The core of the program that does the actual translation is the same code.

As such, a high level language version of RISC OS might be able to be compiled for 32 bit ARM, 64 bit ARM, MIPS, x86, or whatever. Your mileage will vary in practice, as RISC OS’ API is extremely tied to the ARM processor (~8 registers available for passing parameters to/from SWIs) that may be problematic on other architecture, but you get the point – the high level code “is” and the compiler makes it 32 bit, 64 bit, or whatever.

with the immediate implementation of a totally graphical operating system

…which is what RISC OS has been since 1987. The original Archimedes came supplied with a three button mouse back in 1987, which was quite a rarity in its day: Windows 3.1 did not yet exist, and even when it did the mouse was optional – this is very obvious through the degree of control that Windows offers via keyboard alone. I don’t know if later (Win 8, Win 10) versions are similar, but on the older ones you could use F10 or Alt to go to the menus, Alt-F4 to close the application, Alt-Space to open the window movement choices, and so on.
RISC OS never had keyboard options like that, as the mouse was a standard feature. We have a command line, quite a nice one. We can run singletasking programs. But much of the time the user will be in the Desktop. It’s a module, somewhat abstracted from the kernel (as the Pico version demonstrates, what with not having the Wimp) but that’s because of the modular RISC OS design philosophy. The low level filing system support is a module too, as is the floating point emulator, and, well, everything…

RISC OS is a graphical operating system.

and share in as pure democracy, and look how human initiative and inspiration stepped in for Linus from others building up 32-bit Linux in the early 90`s

That’s because Linux isn’t a pure democracy – Linus is still in charge of the kernel (and you’ll certainly know it if you try submitting crappy code!), and properly “Linux” is the kernel (and Richard Stallman would like it if we call it GNU/Linux but nobody except his followers ever does). The rest of the system are projects of wildly varying quality (some like apache are solid and reliable, some are horridly poor) that run on Linux.

It’s worth noting a few observations:

• Solid software that runs on Linux (or is Linux itself) is commerically funded. A lot of the less impressive software turns out to be somebody’s pet project that they abandoned when they got bored of it. (okay, we’re probably all guilty of that, it’s human nature)
• The idea that many contributors makes better code is a myth because many contributors cause many conflicts that need to be resolved (and this takes away from legitimate development time). This is human nature.
• There’s no such thing as pure democracy. The closest we have is, perhaps, Wikipedia. But anybody who has run into an asshole that likes reverting any change to their “preferred page” (even if the original content is demonstrably wrong) will realise that it’s really anarchy posing as democracy (sort of like Brexit, then).
• Of course, all of this presupposes that there are other contributors. That big OpenSSL problem arose due to a minor typo by one of the developers, and the other developer didn’t notice the mistake…

This way, synergy kicks in to make the ride stimulating and fulfilling.

I tend to find I’m more stimulated when I cock it up. Because just churning out code is a little boring. It’s much better to look at a bit of code that “surely works” but clearly doesn’t. There’s a nice sense of satisfaction for uncovering the bug and nailing it to the wall. And all along the way, many opportunities for learning and enhancing previous knowledge.

One of my “quirks” is that I demand a zero-messages build process. I won’t claim to be a great coder, actually I’m kind of winging it when it comes to that TCP/IP stack stuff (oh for a simple “fetch this” module in RISC OS as standard!), but when my project is built, I expect to see no throwback window appear. No errors, no warnings, nothing.
And I don’t cheat and turn all the warnings off.
I consider it that if the compiler queries the code, the code is wrong even if it works.

Experience has also taught me to comment profusely. What makes total perfect sense right now as I have the function churning around in my mind may look like gibberish created by a drunken cat sleeping on the keyboard in three years time. I comment a lot so the behaviour is, hopefully, clear and explained. It is important to remember that when you are writing code, you have TWO audiences – the compiler, and the human that’s going to be reading it in the future.

Gavin:

There was a RISC OS browser, whose name I have long forgotten, that gave the user an option for lazy loading of graphics.

Wasn’t that one of Fresco’s many options? Back in the days when images were useful more often than not, and never ever a blue thumb…

I do not think GUI design has addressed this issue, but I would be glad to be corrected.

Just off the top of my head, I think modern systems tend to work by spreading work around the available cores with the aim of balancing the load to maximise processing. So in your example, the browser decides (upon some metric – local or third party, for instance) whether or not to display the image. It will create a thread to fetch the image, then a thread to decode it. The operating system will assign threads to hardware in a manner most suitable. Whether or not a task is urgent or less important is handled by priority level. Generally everything runs with a “normal” priority, which means the OS treats everything equally. Some tasks (such as DVD ripping) can be given lower priorities which mean the task will run slower but be less of a hog to the system. It’s a balancing act, you want a slower DVD rip if you’re using the system, but if you toddle off to make dinner you’ll benefit from instructing the software to prioritise itself as “high” or “above average”, so the machine will favour it (favour equals faster).

Windows (XP etc), of course, will let you assign a task with a “real time” priority. I do NOT recommend you try, as the task will gain a higher priority than the rest of Windows. You’ll probably spend many minutes trying to undo that, as Windows will devote pretty much ALL of its time to that one task, at the expense of not even responding to user inputs in any sort of timely manner. [I know, I tried]

It isn’t the job of the OS to decide what is and isn’t important, its job is to run the tasks/threads using whatever model of fairness is implemented. In RISC OS, being co-operative, the model is simple: don’t be an ass.

It’s also not wise to give a user too much obvious control here. It does exist in Windows (Ctrl-Alt-Del and the list of processes will have a way to specify preferred core and priority level) but it isn’t made a big deal of. Why? Because you’ll run into users who think everything is a priority. Everything should be done yesterday.
40 tasks running at “high” priority is likely little different to 40 tasks running at “normal” priority…

John again:

XBox and Playstation as the main thrust for computing technology, that accommodates business functionality

I have a Playstation 2 in front of me. Please name one thing it does that is even remotely relevant to business functionality. I mean, it comes with a composite video cable and joysticks and calls itself “play station”. It’s unashamedly for games.

There is no room nor need for having to grit one`s teeth or break any backs negatively speaking anymore, cos we`re taking charge of our destiny to have our cake and eat it positively as the norm for enjoying life through our hobby here and other ways satisfying our personal balance and higher aspirations fully.

Ho Ho. Lifted from somebody’s hymn sheet, methinks. All it lacks is a background of koax, koax, brekekexit, koax, koax .

Lifted from somebody’s hymn sheet, methinks.

I wonder, before Brexit, how many non-English people (and maybe a bunch of English ones) even knew that phrase about eating cake?

Oh, and I mentioned about a drunken cat… Look up a song on YouTube by Hoyt Axton called Della and the Dealer (it’s country, as in old fashioned country not the early Taylor Swift stuff).
Great lyric: The Dealer had a knife, and the dog had a gun, and the cat had a shot of Rye…
(the song puts it into context)

I wonder, before Brexit, how many non-English people (and maybe a bunch of English ones) even knew that phrase about eating cake?

Good point. In Aldershot I could give rein to my hypertrophied verbal lobe without guilt. Now seeing that we have the words twaddle, piffle, muddle, rubble etc it is surprising that we have sibling and not sibbling. My guess, off the top of my head, is that sibling might once have been selfing – perhaps the new word selfie will revive it?

An ideal board on balance for now is the Rock Pi 4, based on it`s similarity to, yet necessary advanced features over, the Raspberry Pi 3, according to available models as a screenshot, at a likely reasonable cost to be confirmed.

It has the same form factor than the Raspberry Pi B+/2 B/3 B(). And here ends the similarity. If you want a low-cost solution, you already have the Pi 3B, which is reasonably fast, has a reasonble amount of memory and you can tinker with 64bit already despite being able to run bog-standard RISC OS. Now.

If you need something vastly more powerful, look at the BeagleBoard-X15. A port of RISC OS should be comparatively easy (OMAP5 being already supported in Titanium and IGEPv5), it has a seriously fast CPU, a lot of RAM, enough flash memory on board for RISC OS and a lot more, and even S-ATA and PCIe. And USB3 of course.

On balance, it looks the the Rock Pi 4 is just “yet another ARM SBC” with no features in sight to make it a really interesting RISC OS porting target. But as you know, the RISC OS source is open, so start your porting project today! On the other hand, developing some of the much-needed software would probably be more important. How about a Wifi stack, a Bluetooth stack, an LLVM compiler, an exFAT filing system, OpenJDK or even Chromium? If you have too much free time, I assure you that I can come up with new useful project ideas faster than you can develop ’em :-)

Make it easier to re/write parts of RO in other languages and it may be possible to transition at least to aarch64 in some manner. Ie some added interfaces to smooth out the bumps. OSLib really goes a long way, but perhaps the concept could be extended a little.

I keep thinking about the whole aarch64 thing. I know I’ve read a lot of discussion on here about the subject. I also think about RO Linux how it can still run a lot of software.
Rather what I keep thinking about is SWIs. How they could at least be a gateway to aarch64. If I were talking Linux-ese I’d say aarch64 kernel, aarch32 userland. Of course that’s not quite where the split happens in RO but I’m sure people get what I’m saying. RO is SWI driven, so there’s a nice place for aarch64 to get it’s foot in.

Could RISC OS be re-constructed in such a way as that it remains a single-core OS (nothing but RISC OS runs in the first core), but that it assigns apps and threads to the other cores, so you get the functionality of the full CPU, but RISC OS is still essentially operating the same way as before?

if it’s going to become a “mainstream” OS […] and complete lack of security

There’s your #1 reason RISC OS won’t become a mainstream OS.

I was being ironic, RISCOS can never become a mainstream OS. That’s not to say you couldn’t rewrite the OS from scratch with something that looks like RISCOS that’s secure and multithreaded from ground up; but then it wouldn’t be RISCOS, just another minor “mainstream” OS.

With modern core speeds, we could now afford to take the hit of converting the OS kernel to C (and multithread it), I’m definitely an advocate for that. CLib/APCS needs to be shown the exit though, there’s way too many issues such as stack frames that aren’t ARMv7 compliant (yes, they do work on current ARMv7’s, but rely on deprecated features still working), direct linking to CLib in the OS, inability to update CLib once the OS is reliant on it, no threading etc.

The Pi’s is pretty poor with bits scattered all over the internet. At least in that case, we epic cheated. ;-)

In what way is having someone interested in RISC OS being involved with the board design an epic cheat?
On those grounds large numbers of the boards around are epic cheats for Linux/android.

Not sure how you’d control a 64 bit core from a 32 bit OS, mind you. ;-)

Send it “letters” :)

Windows 3.1 did not yet exist, and even when it did the mouse was optional – this is very obvious through the degree of control that Windows offers via keyboard alone.

I recall being “introduced to the concept of a GUI” by a work colleague pushing the idea of Windows 3.1, he was somewhat erm, gobsmacked when I happily used the mouse he hadn’t yet mastered. I then informed him I’d been using a GUI based system, as opposed to a GUI bolted on a command line, for quite a while.

I don’t know if later (Win 8, Win 10) versions are similar, but on the older ones you could use F10 or Alt to go to the menus, Alt-F4 to close the application, Alt-Space to open the window movement choices, and so on.

Quite a few if you check MS help pages which are easily found by using your favourite search engine.

RISC OS never had keyboard options like that

“Never had” in the past tense. Martin’s QuickFiler has been around for quite a while, there’s some in the Filer in RO5.2x that mean Martin has to put in a detect method and then mute those when QF is on that version of RO. Hell, there’s even one shortcut key that doesn’t get announced in the mouse menus (unless someone fixed the messages file recently and I didn’t notice)

One of my “quirks” is that I demand a zero-messages build process. I won’t claim to be a great coder, actually I’m kind of winging it when it comes to that TCP/IP stack stuff (oh for a simple “fetch this” module in RISC OS as standard!), but when my project is built, I expect to see no throwback window appear. No errors, no warnings, nothing.
And I don’t cheat and turn all the warnings off.

In my dabblings I turn all warnings ON.
Actually I start with it quiet-ish and then when the dumb ass mistakes are gone I repeat with the most verbose to see what more minor stupidity I created.

It’s unashamedly for games.

I’ve always viewed that stuff as being a funding system for remote warmongering development.

Surely this should be over in Aldershot.

@Jared:

Could RISC OS be re-constructed in such a way as that it remains a single-core OS (nothing but RISC OS runs in the first core), but that it assigns apps and threads to the other cores, so you get the functionality of the full CPU, but RISC OS is still essentially operating the same way as before?

Yes.
More expansively, if you check the postings Jeffrey has done over the past year-ish you will find that to be the general thread of the comments that without major changes most of the OS is going to sit on one core and those major changes might well break all the existing software.

For a newbie like myself since joining the site yesterday morning, tapping into techno this way is fantastic, and allowing us to bring some lingering ideas together into a single concept for a new 64-bit OS as, lets say, Risc OS II (thanks to Patrick M) that is free for everyone, in the true spirit of simple love for computing in many various forms. Thank you for such informative and thought-provoking comments for us all.

A perspective of a new OS for Risc here brings a common goal into play that personal differences of opinion only make more interesting and inspiring. Times are changing and moving on and forward, from which so much knowledge and wisdom flows for our broad benefit and sheer pleasure being an appreciated part of. Concensus and resolution as the norm underlies the potential to bring out our utter best in perfection.

Steffen H and Rick M both correctly question the issue of platform. The Rock Pi 4 is simply an arbitrary choice to begin using as a rough model, that contains a number of super facilities to roughly match a functionally equivalent mainboard in the standard average IBM-compatible pc, hardware-wise first, that`s all, and yet which is modern in the sense of lower power and reasonably high capacities and speed all round, and hopefully sufficiently economical, versatile and well-documented, to perform independent development around and with.

As has been highlighted, there is potential to explore and extend the predominating graphical abilities already incorporated in the current 32-bit Risc OS for the possible newer 64-bit ARM64 Risc OS. Furthermore, the prescence of multi-cores opens up new possibilities for handling processes simultaneously in innovative and effective ways. If “Mainstream” implies commerciality, then Risc OS II is not and will never pretend to be, yet is likely to inspire others in a diversity of fields who hobbyists naturally take the lead to uplift and educate and entertain as absolute role models for technology, harmony and synergy all together, in society.

Rick M`s reference to hypervisor about binary bootup code is terrific and definitely appealing. As for a language, the choice of a recent one beyond even C like Rust is purely a precedent, while the choice of 64-bit satisfies compatibility purposes initially mainly, with further advantages likely emerging onwards. And as for this being a democratic process, we are able to show politicians how it`s wholeheartedly achieved through combining resilient resourceful passion for and empathy in our craft creatively.

Get ready for surprises, as insistence on perfect code is naturally shortcut and minimised as far as necessity for error and checking precautions is concerned, and based on the intelligence and accuracy of all code written and implemented right from the beginning. Hardware and technology work and performs for us humans in the normal satisfying way that we never become subservient in the reverse for them, otherwise the system immediately needs restructuring and/or substituting, for which development caters positively.

For Rick M: earlier comment about computer technology accommodating business simply gives recognition to older (example Commodore64) and newer (eg XBox and Playstation) gaming devices providing the impetus for progress specifically, that business follows and imitates predictably and generally, afterwards……

In what way is having someone interested in RISC OS being involved with the board design an epic cheat?

Because it allows for access to a level of documentation not publicly available. Given the sort of information available on the Pi family, if it had been designed and created by some sort of Chinese consortium, do you think RISC OS would be able to run on it?

Your answer, should you not realise it is a rhetorical question, is in how many boards based upon Allwinner chips are officially supported by RISC OS.

In general, no detailed technical documentation equals no chance to for RISC OS on that device…

I then informed him I’d been using a GUI based system, as opposed to a GUI bolted on a command line, for quite a while.

Hehe, I mentioned on my blog somewhere that I was using Ovation in a GUI while others were using WordPerfect and the like under MS-DOS.
Hell, my friend was using some sort of text editor under Amiga Workbench at the same time, so those little minority systems got the idea. The big behemoth that was “the PC” had to wait…

Quite a few if you check “MS help pages”:

I have no inclination to roam around looking for help and info for an operating system I don’t use. I’m still using XP, I know the keypresses it supports. ;-)

RISC OS never had keyboard options like that

“Never had” in the past tense.

Keyboard support in specific applications is not systemwide keyboard support.

Please open an editor window, any editor window at all. Enter the text “Hello world”. Make the window about half its current size and push it towards the right side of the screen. Then open the menu and select the option to save the file and save it as “$.RickIsAGit”.
Do all of that without touching the mouse once and then we’ll talk about keyboard support.

In my dabblings I turn all warnings ON.

The options to the compiler are to suppress warnings and/or errors. This I assume that with none of those, the messages are enabled. I always want it verbose, try to code to zero-messages from the outset, not as a retrofit.

There are a couple of less useful ones that I don’t switch on. They’re available as a Feature: “-fmo” will turn on a warning for obsolete K&R style function declarations (I don’t do that), and “-fv” will report unused declarations including those from the standard headers".

I’ve always viewed that stuff as being a funding system for remote warmongering development.

Given the likes of Call of Duty and World of Warfare, it could even be covert military training and assessment. Over to Aldershot if you’re willing to make a reindeer-shaped festive tin foil hat. ;-)

without major changes most of the OS is going to sit on one core and those major changes might well break all the existing software

The problem here is that RISC OS is based around single user single process single processor. There are numerous things that are not reentrant, and RISC OS has quite the habit of killing interrupts when it is doing “tricky stuff”. None of that flies on a multicore system.

Though, to be fair to RISC OS, it was originally developed when 4MB was an orgasmic amount of memory (and a price to match), harddiscs were measured in TENS of megabytes, and the early PC cards had their own memory on-board (because the podule is slow) so it ran pretty much independently of the host system.
I have one in an antistatic bag someplace, but Google’s faster: http://www.computinghistory.org.uk/userdata/images/large/42/51/product-84251.jpg
(don’t think mine has a 387 co-pro)

Anyway, where was I? Oh yes – RISC OS was born in a time when the idea of multiple processors meant plug in systems that used the main computer like some sort of terminal – showing screen output and passing back keyboard/mouse activity. The idea of multiple processors on the same piece of silicon was unknown. Hell, the idea of a System On A Chip was not yet commonplace, but then you could have told that from the fact that the ARM chipset was four large lumps of silicon – one being the processor, one being the video controller, one controlling memory, and the last one handling the I/O world. It wouldn’t be until the ARM250 that we’d see an integrated version, an idea that would come around again later with the ARM7500. So, yeah, multiple core processors was a far off luxury, about as “impossible” in the days when RISC OS was originally created as was needing more than 64MB addressing space…

lets say, Risc OS II

RISC OS 2 was released in 1987. This that we’re working on now is RISC OS 5. Or RISC OS V if you like roman numbers.
Just sayin’……

Times are changing and moving on and forward,

Didn’t Dylan write a song about that?

that contains a number of super facilities to roughly match a functionally equivalent mainboard in the standard average IBM-compatible pc

Yeah – about that… The specification for the IBM PC is a 4.77MHz 8088 with ISA expansion, up to 640KB onboard memory (but usually 256KB) using 200ns DRAM, with an optional 8087 maths processor, a weird UART that can only manage 9600 baud flat out (but offers two serial ports), no standard parallel ports, a full height 360KB 5.25 inch floppy drive and an optional 720KB 3.5" floppy drive, a cramped 83 key keyboard, and a 10 or 20MB ST-506 (read: slow as molasses in January) harddisc if you coughed up wads of wonga. Video was either MDA (cheap models) or CGA (pricier models). The keyboard lead, however, is specified as being six feet long (that’s about two metres) so it’s long enough to allow you to take the keyboard and smash it across the head of an annoying work collegue…
The IBM AT expanded this with an 80286 processor running at 6 or 8MHz, 16 bit ISA, 512KB memory as standard with a maximum of 16MB, 150ns DRAM, an 80286 maths co-pro running about half the speed of the processor, a better serial chip that still managed to max out at 9600 baud (because early x86 latency when using BIOS functions was beyond a joke), we get a parallel port (sometimes) and a clock, 1.2MB 5.25" floppy drives with optional 1.44MB 3.5" drives, a 20 or 30MB harddisc that’s still ST-506 and still a piece of frozen poop. At least the keyboard looks like a standard keyboard…

And… that’s about when IBM ceased having much in the way of influence over the specifications of PCs. It’s Intel and Microsoft that defined specifications from that point on, either explicitly (like the PC98 and PC2001 specs), or implicitly by “will Windows run on it?”.
People may still refer to such machines as an IBM compatible PC in order to remove doubt (an Apple iMac using the PowerPC processor is a “PC”), but anything to do with IBM is a dated anachronism and a story almost as funny as the one where Microsoft completely missed “The Internet” and when they realised it was a thing, tried to embrace it on their own control freak style which led to The Browser Wars. This eventually ended up with Mozilla failing as a commercial concern (due to Explorer being bundled into Windows, and vast numbers of people thinking that “the blue e” was the internet. But Mozilla had the last laugh. They took sweet revenge by giving away their work. The main result was the Firefox browser and, well, in these modern days of Safari, Chrome, Webkit, etc – where’s Internet Explorer now? Or the more recent one (Edge?)? Microsoft is still chundering along but they don’t own the Internet and with the increasing reliability and availability of Linux plus the mass switch to tablets for many of the functions people used to use desktop machines for, there’s less of a “need” for Microsoft in the world. That’s not to say that there’s no place for Windows, there is – but it’s not like it was around the turn of the millennium.

hardware-wise first, that`s all, and yet which is modern in the sense of lower power and reasonably high capacities and speed all round

There are many nice ARM boards available now. When I first got back online (circa 2009), the choice was mostly something in the Beagle family, or a much more expensive board (the Beagle had the advantage of good documentation and RISC OS support). Then along came a group of people who planned to make a dirt cheap ARM board that looked like a chunky USB key (like those MP3 players you used to be able to get). Well, the form factor didn’t turn out but the price did, and this demonstrated that a functional ARM board with a lower-end-of-two-digits price tag wasn’t a fantasy. That it’s now a GB quad core 64 bit capable device is, frankly, rather mind blowing. And following on the success of the Pi are ALL manner of inexpensive ARM boards, many of which include some sort of “Pi” pun in their name.

If you want Linux or Android, you’re spoiled for choice.

However for RISC OS, you’ll find our needs are… a little different. We don’t actually need a 2GHz quad core processor in order to respond to the user in a timely manner. The entire OS ROM image runs to around 5MB. That’s LESS than the QT5 GUI alone (never mind the numerous widgets and add-ons).