Who'll do the "da Vinci" workstation, then?

Don’t get me wrong – I really love RISC OS. I’m very happy that it’s been dragged kicking and screaming into the 21st Century. But we have to realise its serious limitations and that some ‘dreams’ are simply beyond scope.

Exactly.

I like having a whizzy little Pi etc. but would happily settle for RPCEmu on Linux (and don’t really care what architecture that’s running on) when the native hardware dies.

And again. Well – almost exactly. I’d rather have a PiEmu on Linux. I gave up my RiscPCs in favour of my first Pi years ago.

PiEmu

That’s more work to be done by that raft of developers that we don’t have, Clive! Just add VFP emulation… How long have we wanted VFPEmulator for old systems?

OK, let’s have a poll. Who is actively writing replacement modules for existing RISC OS assembler components in C?

Not me.

Not me, sort of, actually… well… I don’t know! XD – My DME Project is indeed a set of C and BBC BASIC written components for RO, and some of them are replacing RO pieces, but they are NOT specifically written to live in the RO ROM image (because I personally had enough of that nonsense, I wanted a minimal RO ROM since the end of the 90s that would then boot the Desktop from the HD).

For the RO long term future: I am working (on very rare spare time) on an hypervisor that will be able to run RISC OS IF and WHEN I’ll manage to integrate it with an AArch32-to-AArch64 binary translation library called Mambo.

This is the end of it for me and for a number of reasons, not just related to converting RO from ASM to C, but also related to who’s going to maintain a 32bit RO AND a 64bit one with the unavoidable differences (which means also developers of apps will need to pay attention to both)? C’mon guys, let’s be realistic.

The above can only be solved IF and ONLY IF there would be a lot more developers in the RO scene (both capable or kernel and apps development), which won’t happen any time soon.

The embedded hypervisor approach is “compliant” with what Steve Revill mentioned once in a RISC OS London show (I believe it was the 2020), where he said ROOL wants a RISC OS only approach (so, not RO on Genode or on Linux), hence an embedded Hypervisor fullfil that requirement and the whole thing can be called “RISC OS Next” or “RISC OS X” or whatever! lol

As Stuart mentioned, if I get bored of working on the thing above, I am totally happy with an RPCEmu on a Linux box or even with RISC OS on Linux project or just stock up 32bit Raspberry Pis and use RO on those.

RISC OS – (arguably) never was right and never will be ;-)

Alright. Behind the bike sheds. Bring your weapon of choice… ;)

Who is actively writing replacement modules for existing RISC OS assembler components in C?

Not me. If I was going to write anything in C, I wish I was smart enough to be able to get something out of this negative scanner that is sitting on the desk beside me. It hooks into Windows as a generic USB video device meaning I can skip the awful bundled software, that takes a ~2mpix original and blows it up to ~6mpix by sheer fakery, and instead just grab screenshots using VLC. But this requires having the Big Beast running. Would be nice to run it from a Pi.

Lets dismiss the idea of directly translating existing assembler to C right now,

Having seen an example of the code generated, it was every bit as awful as I was expecting.

Did you notice, by the way, that it not only ignored the debugtm conditional, it seems to think it’s supposed to pass r14 to read the ticker, but doesn’t store the result anywhere.
Anyway, not understanding conditionals means that huge swathes of the code will be translated incorrectly. Chocolate, anyone? (or have I eaten enough?)

but I wonder how hard it would be to get a consensus on such a spec – how much ancient stuff can be junked?

Depends what you want. If you want “RISC OS but in C”, then do it piecemeal as is currently happening because it’s a waste of time given that even written in C it’ll be heavily tied to the ARM26/32 processor behaviour so will be somewhere between “bloody nightmare” and “not possible” to port to another processor. ¹.

If you want “Like RISC OS, but modern and decent”, then pretty much the entire API needs to be shown the door. This is where money is required as volunteer efforts likely aren’t up to inventing an entirely new OS.

(and don’t really care what architecture that’s running on)

Ditto. If RISC OS lives on through emulation, my only three requirements are:

• It’s power efficient
• It boots and goes straight to RISC OS, so the host is just what it’s running on
• We don’t end up with a shitty filesystem with logic from the 70s like case sensitive filenames

A pessimist is rarely disappointed.

It’s why I’m a born cynic. I get the elation when proven wrong and something actually works, without the depression when it doesn’t because, well, that’s just what I expected.

There’s not much :), just a lot of :|

I gave up my RiscPCs in favour of my first Pi

I gave up my RiscPC in favour of Windows around eighteen odd years ago.

It was the kind gift of a Beagle that brought me back to RISC OS, and the various members of the Pi family (because the Beagle never liked my VGA adaptor) that helped to get stuff done.

Funny thing is, apart from my Photo Editor and the odd DVD rip, I rarely use Windows any more. Can’t justify a desktop PC burning the kilowatt hours like I used to, especially since my computer use has moved more towards consumption than creation, and my phone/tablet does that perfectly well.

How long have we wanted VFPEmulator for old systems?

I’d settle for VFP for new systems, so people writing code in C don’t get screwed by a determined desire to ignore hardware FP and keep on emulating an ancient FP chip.

You know it’s bad when some FP code built with the DDE can have it’s arse handed to it by ABC, of all things.

Just threw together some code as a proof of concept.

DDE with some FP code eight million times – 842 cs
ABC with equivalent code in FPE mode – 2138 cs
ABC exact same code in VFP mode – 146 cs

So even the less efficient ABC compiler runs vastly faster than all the tricks Norcroft knows because it’s using the hardware FP.

¹ Note that I say “another processor”, not AArch64. There should be no reason why a properly done new OS (probably shouldn’t keep calling it RISC OS, it won’t be) would remain tied only to the ARM. Linux shows that it’s quite possible to have an OS that’s more or less entirely processor agnostic. Sure, you’ll need the right apps (an ARM processor isn’t going to run x86 code) but if you’re building them from source…

You know it’s bad when some FP code built with the DDE can have it’s arse handed to it by ABC, of all things.

Would you like a tinker with my VFP support library for Norcroft? See https://www.riscosopen.org/forum/forums/2/topics/3457?page=10#posts-126532 Works best on Pi 4, but good on Pi 3.

I’m about to kick this off again as it would be nice to get a kosher release of Fireworkz using it.

It would appear that 64-bit RISC OS would be an entirely new OS from 32-bit RISC OS since both the ISAs and CPUs/GPUs have changed so much in the meantime, but that’d be “underneath” – the Desktop we all know and love can and must be near totally unchanged since it’s close to perfect.

It’s a far cry from good old VIDC2 to spectacular G715, among other things (thinking of the enormous GFX potential here, the possibilities..). It’ll be like when the Archimedes was launched – not much software to speak of, but (afaik) most of the BBC catalog could be run over emulation . Who says history can’t repeat itself?

The new CPU/GPU SoC combos, existing and upcoming, are orders of magnitude more than anything existing now that RISC OS can run on. My “dream” is that it soon, one day, will. Hardware so good it’d attract established software companies, maybe?

Yeah right, dreams.. What would we be without’em.

PiEmu

That’s more work to be done by that raft of developers that we don’t have, Clive! Just add VFP emulation… How long have we wanted VFPEmulator for old systems?

I know 8~( I really hope my Pi4 lasts a LONG time – in fact, I might mothball a few at some point, if supplies become such that I’m not depriving someone else…

Just threw together some code as a proof of concept.

I’ve done a deeper dive on my blog comparing various different permutations.
https://heyrick.eu/blog/index.php?diary=20221203

Would you like a tinker with my VFP support library for Norcroft?

Not tonight. If anything on my blog is weird or makes no sense, it’s ‘cos I got up at 3am (and started work at 5am). There’s only so far tea and Mars bars can take me. I’m not a teenager any more…

Certainly it’ll be interesting to look at.
(just read through the help file, looks like it should be simple enough to translate the code)

Who says history can’t repeat itself?

It does. Humans never learn. ☹️

Yeah right, dreams.. What would we be without’em.

Sane.

It would appear that 64-bit RISC OS would be an entirely new OS from 32-bit RISC OS since both the ISAs and CPUs/GPUs have changed so much in the meantime, but that’d be “underneath” – the Desktop we all know and love can and must be near totally unchanged since it’s close to perfect.

Why try to create a brand new 64 bit “RISC OS” with a cloned UI on top when you could just put a cloned UI on top of 64 bit ARM linux? Then you’d just need an integrated emulator to run the old software. Updating and polishing ROX and the Linux port are far more realistic goals than creating a brand new operating system. It’d also mean that there would be a community of thousands developing modern software and porting the underlying OS on to new hardware, leaving the handful of RISC OS die hards to concentrate on achievable tasks.

As an approach it’s not far off what Apple did when shifting from Mac OS 9 to Mac OS X. If it was good enough for them and their millions of users, why not us?

If you want “Like RISC OS, but modern and decent”, then pretty much the entire API needs to be shown the door. This is where money is required as volunteer efforts likely aren’t up to inventing an entirely new OS.

Inventing a new OS kernel is relatively easy, getting software to run on it, not so much!

It’s power efficient
It boots and goes straight to RISC OS, so the host is just what it’s running on
We don’t end up with a shitty filesystem with logic from the 70s like case sensitive filenames

Well, I’d keep run from RAM 99.9% of the time; any programs needing ludicrous amounts of memory should indicate that it can be swapped out. The desktop should be entered immediately, there should be support for stderr as well as stdout, and multi-threading. Case sensitive file names aren’t so bad.

Why try to create a brand new 64 bit “RISC OS” with a cloned UI on top when you could just put a cloned UI on top of 64 bit ARM linux?

Since then it’d just be yet another desktop and not an operating system. And I’m not concerned what prism-no-such-agency-Apple-Schnapple is doing whatsoever. They haven’t even come up with their own CPU architecture! Yeah, they bought into Arm Ltd. to get a CPU for their Newton flop, but who invented Arm RISC CPUs? I rest my case there. Just adding that Linux isn’t exactly without bugs, it has hundreds, some serious. A RISC OS rewrite for 64-bit CPUs can benefit from the experience of ~40 years’ accumulated OS development (starting with the Xerox Alto in 1973 – I was 9 back then).

They haven’t even come up with their own CPU architecture!

Go away, troll.

Neither has Microsoft (x86/Intel and a brief play elsewhere), nor Google (Android on ARM), and Apple have been through 68xxx, PowerPC, and then x86 (desktop) and ARM (mobile).

The PowerPC was created by an Apple-IBM-Motorola alliance, so they actually have been involved in creating a processor if not exactly rolling their own.
More recently, Apple has an architecture licence so they can custom design their own ARM silicon (hence, while the core is ARM, the chip and parts of the implementation are specific to Apple; Samsung does likewise).
Microsoft, I understand, is following suit in designing custom ARM silicon.

Why not roll their own processors? Why should they, when something perfectly decent already exists and can be customised to suit their own specific requirements?

And I’m not concerned what prism-no-such-agency-Apple-Schnapple is doing whatsoever.

You should, considering that not only are they the biggest (or one of the biggest) computer companies in the world, but they’re also rather implicated in giving ARM processors the kick-start to be used outside of the miniscule world of Acorn.

Also, what concurrents are doing is rather important elsewhere. Back in the mid ‘90s we RISC OS users benefitted from cheap harddiscs due to Windows’ ever increasing demands of space just to install the OS.
ARM is everywhere, no doubt due largely to Apple and Google adopting it for both of their mobile phones, which together account for such a massive user base and market force that not only did Microsoft’s Windows Phone fail, pretty much anything else is a mere rounding error in comparison. That’s a metric shittonne of ARM chips, and why ARM is worth rather a lot these days. Don’t think Acorn did much there. The ARM guys spun themselves out as a seperate entity as fast as they could and never looked back, while Acorn basically crashed and burned (you did read the Phoebe spec, didn’t you?).

Just adding that Linux isn’t exactly without bugs, it has hundreds, some serious.

Linux has bugs, yes. But the kernel is still relatively stable (do not mix up the Linux kernel with all of the bug-ridden crap on a typical Ubuntu DVD-ROM) which means it is used as a server class operating system is is sufficiently secure as to be hugely implicated (the so-called LAMP setup) in a vast majority of websites and internet services that you see. But since it doesn’t throw it’s toys out of its pram and sulk, you’ll never know.

Now, shall we contrast and compare with RISC OS?

A RISC OS rewrite for 64-bit CPUs can benefit from the experience [blah blah blah]

To quote a guy that was gleefully chewing every bit of scenery in sight: Show me the money.

Sorry Sveinung. I’ve had my suspicions, but this most recent post has confirmed it. You’re a troll, plain and simple.

Stop it. Get a reality check. Or maybe just a clue. Whatever.

*BYE

bug-ridden crap on a typical Ubuntu DVD-ROM

Someone tell the medical equipment manufacturers, please. Fortunately, not my remit. I just have to listen to other people mutter “crap” at intervals.

You’re a troll, plain and simple

Just an old ghost, haunting.

You’re a troll, plain and simple

Just an old ghost, haunting.

Don’t confuse my style of writing with my seriousness as to the topic. Acorn being dissected was bad enough, it shouldn’t result in fanatic 32-bitism with some cockeyed notion of “preserving” Acorn-era technology like an insect in amber. Same with making it into yet another Linux desktop; it wouldn’t make the top 100 on https://distrowatch.com/ and to boot, no longer be an operating system.

No money, no people? What’s new.

Yawn.

Rick wrote:

Depends what you want. If you want “RISC OS but in C”, then do it piecemeal as is currently happening because it’s a waste of time given that even written in C it’ll be heavily tied to the ARM26/32 processor behaviour so will be somewhere between “bloody nightmare” and “not possible” to port to another processor.

Only if that C is a direct conversion from assembler still tied to the low level binary representation of the current code. With a proper conversion to C everything is correctly typed, it is not difficult to move from 32 to 64 bits, with a bit of complication if you still need to support legacy 32 bit APIs at the same time.

It should be noted there is quite a lot of experience in this area from other OS’s written in C which have been ported to just about everything.

Since when did it become trolling when one wishes one’s favorite and most creativity-enabling Operating System to become something more – much more! – than a fading 32-bit anachronism?

Somebody are being categorically confused here.

What would that Be – a 32bit or 64bit Troll :-)

Not been in a USA hospital – by any chance?

I really really want a pony, give me a pony.

RISC OS going 64-bit would increase its chance to survive a bit longer as a minority platform. Once there it can be compiled into ArmV9-architecture (or anything else) to use the latest Arm multicore CPUs, even several CPUs, address hard disks larger than 256GB(!) and arbitrary amounts of RAM. Then it’d really be something, not just a has-been with a tragically lost potential.

Offtopic: Never been to your western colonies. Haven’t had an urge to go there either, except maybe as a Groom Lake tourist. :P

That’s fascinating, but you’re not addressing my lack of a pony.

I’m afraid all the money went into the My Little Pony Abattoir, Peter. That spits out as many bits as are wanted.

I really really want a pony, give me a pony.

Off topic – take it to Aldershot :-)

Off topic – take it to Aldershot :-)

My god, you’re a genius

https://www.preloved.co.uk/classifieds/horses-livestock/horses-ponies/for-sale/aldershot

If only 64bit risc os was as simple.

Heh. That page even has this on it (as seen on my laptop):

Find Pony sale in Greenock – Pony sale – Check this out
Ad
https://uk.shopping.net/search/greenock
▼
Find Pony sale on Shopping.net for Greenock. Results for Pony sale in Greenock. Popular Searches. Find Answers. Internet