Is RISC OS a 1980s OS?

Doing anything much in BB4W requires extensive use of indirection operators

Just like BASIC on this side of things. But… Doesn’t BBfW support structures?

Creating a WIMP program in BASIC, building the window definitions (no templates) is doable, but it’s something of an exercise in self-flagellation.
Accordingly… https://heyrick.eu/blog/index.php?diary=20151226 :-)

and who never bothered to check what Hindi typewriters looked like…worst of all, Unicode’s treatment of Deva Nagari arose the same way, rather than with any reference to actual Hindi type composition practice.

There’re more than a few eastern Asians who despise Unicode’s lumping of all their squiggles into a “unified CJK” character set.
From their point of view, ït wøüld bë äs ïf thë Lätïn chäräctër sët wäs crëätëd by sømëbødy whø wäs bärëly fämïlïär wïth thë Lätïn chäräctërs änd dëcïdëd thät hävïng än ümläüt øvër thë vøwëls, änd ä släsh thrøügh thë ø wøüld bë süffïcïënt før ëvërybødy. Äll thë rëst ïs jüst ünnëcëssäry rûbbïsh, rïght? :-)

It was worse for the Koreans of course – here’s all your shiny new Unicodes, off you go. Oh wait, we’ve changed our mind, and so in the next version we’re moving them all. It is referred to as the Korean Mess, and is no longer spoken of. Move along. Nothing to see here.

It was worse for the Koreans of course

I quite believe you. I know next to nowt about Korean typography.

The stupidest thing about the Hindi business is that, as far as I can discern, it was actually Indians, native Hindi speakers (but educated in English medium and growing up in a culture more English than Indian) who created this mess.

Yet another old aphorism: Plan to throw one away, because you will.

The Unicode Committee have now got a really good understanding of how they should have done it.

The Unicode Committee have now got a really good understanding of how they should have done it.

I wonder…

Except there is (was) virtual memory if you wanted it. I made heavy use of !Virtualise on the RiscPC. Superfluous under emulation or if you have lots of physical RAM, but in the old days it was the difference between being able to do the job, and not. A superb bit of work by the great Alexander Thoukydides, no longer of this parish (though still in Cambridge I believe), it was released soon after the RiscPC.

And, for those who don’t know, Alex put !Virtualise up on GitHub: https://github.com/thoukydides/riscos-virtualise

I am sure Nemo will start hacking away in a few minutes…

And now for something equally cool, but entriely unrelated: the source code for LayerFS is on SourceForge: https://sourceforge.net/projects/layerfs/

And, for those who don’t know, Alex put !Virtualise up on GitHub: https://github.com/thoukydides/riscos-virtualise

I am sure Nemo will start hacking away in a few minutes…

If I recall correctly that source has been there for a few years now and I’m not sure why this thread would stir Nemo to add another item to his rather long list of things he might like to do. Sometime. Maybe.

Bear in mind that the main use for virtual memory would be to supplement real memory which every machine made this century has an abundance of in RO terms. So, Virtualise-32-bit would only be particularly useful for people running a RISC PC with RO5.x¹ or running an application that needed more than 1GB of memory.
Modifying the assembler portions of the source to take out the 26bit dependent elements (a quick glance suggests thats pretty much just exits from code elements) might be an interesting exercise.

¹ Let’s be honest with ourselves here, a RISC PC running 5.x is a curiosity rather than a main machine. People wanting the full use of a RISC PC would run RO4.x and use a wider set of programs and also have a perfectly viable 26-bit Virtualise already available,

Alex put !Virtualise up on GitHub

I was going to say “there goes my weekend”, but it’s C++… What’s with the weird syntax… TaskList::TaskRecord::~TaskRecord(void) and how does that differ from the previous function (exact same name except no ‘~’)? Too bloody much punctuation in C++ code…

Maybe I’ll just read the assembler bits.

Later:

Good god, the clarity of the commenting. Well done that man!
https://raw.githubusercontent.com/thoukydides/riscos-virtualise/master/src/virtualise.s

If I recall correctly that source has been there for a few years now

Around 4 years.

and I’m not sure why this thread would stir Nemo to add another item to his rather long list of things he might like to do. Sometime. Maybe.

Maybe he already knew, maybe not, maybe he now remembers, I don’t know. I had a quick look at the sources and even I was tempted to give it a go.

Bear in mind that the main use for virtual memory would be to supplement real memory which every machine made this century has an abundance of in RO terms.

Really. Now that is something entirely new. But to be entirely precise, there were IYONIXes and Omegas with less than abundant memory (in my terms), both firmly dated in this century. Then there was the RPi with 256 MiB and the first BeagleBoard revisions with 128 MiB. RiscPC-like amounts of memory.

So, Virtualise-32-bit would only be particularly useful for people running a RISC PC with RO5.×1 or running an application that needed more than 1GB of memory.

Who even thought about producing a 32bitted Virtualise??? Surely if Nemo started hacking around, being firmly in the emulation/26bit camp, a 32bit version would be the last idea?

Now LayerFS on the other hand…not sure if a 32bit version ever existed, but it would be very useful.

Around 4 years.

I was just generalising, it was 3 years (2016 is the revision date in the files)

Who even thought about producing a 32bitted Virtualise???

Since the 26bit version already exists – you’ve pointed out the location of the source should anyone wish to build a copy – then only a 32 bit version would make sense as a new project otherwise your re-inventing the wheel.

I didn’t mention the issue of virtual memory relying on repeated writes to a flash drive or SD.

I am sure Nemo will start hacking away in a few minutes…

Naturally I’ve had that for some time. However…

the source code for LayerFS is on SourceForge

In a case of parallel evolution I wrote the exact same thing, but mine was called MergeFS. Same idea exactly.

I did that as the next stage after I wrote IndexFS, which put the whole directory structure of a CD into a small file and then presented that as an imageFS – so you could apparently have the contents of 100s of CDs on disc, and it was only when you double-clicked on something that it would ask you to insert the specific CD.

The next stage was to merge the various backups with whatever part of the directory structure was still living on disc and present it all as a unified file system. Back when I was producing 100s MBs a week it was very useful. Pointless these days with massive hard discs.

Surely if Nemo started hacking around, being firmly in the emulation/26bit camp, a 32bit version would be the last idea?

Actually I always write agnostic code – everything on my site is 32bit. I am fully supportive of the 32bit world, but not being constrained by actual hardware I don’t have to run 32bit only. It’s like having a perfect Aemulor. For the record, the OS I’m having the most difficulty justifying is RO6 – there’s a massive change to stack handling in there that makes all very-low-level stuff very difficult indeed. WriteReg is everything-but-Six for exactly that reason.

If I were to fiddle with Virtualise I would of course 32bit it… but I have no real motivation to do so and far too many things to complete. So I’m going to undertake to not do it. Please feel free to volunteer, somebody!

Clive pondered

I wonder…

I suspect we are of one mind about that particular triumvirate, but I shall say no more.

Bear in mind that the main use for virtual memory would be to supplement real memory which every machine made this century has an abundance of in RO terms.

Yes and no. I have a (very simple) spreadsheet app that can fill the RPI memory (and still be usable). It would be interesting to use larger than RAM DA and see if it’s still working :)

I didn’t mention the issue of virtual memory relying on repeated writes to a flash drive or SD.

Yes and no. Virtualise could also use a chunk of compressed memory…

But in fact, no need for Virtualise… RISC OS 5 could directly provide a way to generate and use a compressed DA.
Or a DA mapped to disc.

I was going to say “there goes my weekend”, but it’s C++… What’s with the weird syntax… TaskList::TaskRecord::~TaskRecord(void) and how does that differ from the previous function (exact same name except no ‘~’)? Too bloody much punctuation in C++ code…

The destructor for the class (or struct) TaskRecord in the namespace, class or struct TaskList

Or a DA mapped to disc.

Somewhere there’s a module that memory-maps a file into a DA (without having to load it all in). I forget what it’s called, but that is, in effect, the same thing.

I forget what it’s called, but that is, in effect, the same thing.

Yes, but the cool point would be to have “DA mapped to disc bigger than RAM size”.

I think that’s what I said.

That wasn’t so clear :)

I’m sorry I have a cold.

This forum is closed for lunch…

It’s Saturday, everybody is out using fossil fuels to Instagram pictures of themselves attending the climate protests that they drove to.