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

<looks at page>

Black Beauty Genuine 16.1 TB Mare

With that much storage, I really hope it’s a USB3 capable horse.

I’m not a programmer, but a user who’d like to see and use a modern version of the most productive operating system he’s ever used.

That productivity comes from the existing software base. Many of those key applications can’t be recompiled for 64-bit, either because they are in assembler, or the sources have been lost. Just recompiling would still rely on the 32-bit SWIs.

If it doesn’t support that existing software, then the existing user base would be lost, and without their advocacy, there aren’t likely to be many new users.

So a 64-bit RISC OS would have to support (almost?) all the existing SWIs, and the existing WIMP appearance and functionality. It might also need other system interfaces – callbacks, vectors…

It would also need a 32-bit emulator.

That would probably require shims on the 64-bit equivalents supporting the 32-bit ones, or if the processor is sufficiently different that the new interfaces could not be equivalent, then more of a compatability layer.

That’s on top of porting the actual OS.

There’s little money available to pay programmers, and I guess about 5 volunteers currently able to do this sort of work, and less with the time and eneergy to tackle it.

Maybe it’s time to stockpile pi4’s.

Maybe it’s time to stockpile pi4’s.

Exactly.

So a 64-bit RISC OS would have to support (almost?) all the existing SWIs, and the existing WIMP appearance and functionality. It might also need other system interfaces – callbacks, vectors…

I’m with you on the existing WIMP appearance and functionality, but I think programmers are flexible enough that new code can work with new and more flexible APIs that make it easier to write (and port) multi-processing programs.

Frankly, the need to write modules for anything other than device drivers is not the greatest idea.

but I think programmers are flexible enough that new code can work with new and more flexible APIs that make it easier to write (and port) multi-processing programs.

True enough. However I’m aware that people are using software that’s no longer supported, and I’m thinking about what might be involved in, for example, updating Paint if the graphics SWIs changed significantly.

I think programmers are flexible enough that

I think one of the reasons that the Desk library had very little addition is because it tried too hard to fix issues in DeskLib regarding it not playing well with other stuff (like OSLib) due to name clashes, as well as greatly improving type safety.

But this required extensive changes to existing code just to get to the exact same position as the programs we’re currently in.
So many people didn’t bother and stuck with DeskLib.

Changes are good if they bring new features. Having to make changes just to stay still, bye bye.

if the graphics SWIs changed significantly.

Reality suggests that this isn’t going to be a bridge that’ll be crossed any time soon.

Plus, if a compatibility layer can’t fake the existing API, it’s pretty much failed it’s only job.

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

Just to drift a little off-topic, I was having a catch-up with a chap who used to be quite well known in the RISC OS scene in the 90s (I won’t name him just in case!).

We both came to the same conclusion. Sure, RISC OS looks primitive now, but back in 1988 (when RO2 came out) it was streets ahead of the competition. (Windows 2.0? GEM? Anyone?) When RO3 came out in 1992-ish, again, it left everything else standing for usability, and was a helluva lot more stable than, say Win3.1.

Then everything went wrong. Acorn kind of stopped developing the OS. RO3.5 appeared to be just a few updates to make things work on the new RiscPC hardware. RO3.6 was bug fixes for RO3.5. RO3.7 was patches to RO3.6 to make it work on the StrongARM. 3.71 included support for the hardware FP on the A7000+. Other than that… nothing. Nothing changed, nothing improved.

By the end of Acorn in 1998, they were still flogging an OS that, whilst state-of-the-art in 1988, needed some serious updates to remain current.

What was so annoying is that there were two landmark points when the OS could have been “fixed” and modernised. Bearing in mind that ‘fixing’ some of the issues would potentially break some software that wasn’t written to guidelines… the first opportunity was when the RiscPC was launched in 1994 (if memory serves). New hardware was probably going to break some older software anyway, which would need updating.

Then again two years later in 1996 when the StrongARM upgrade was released. The split-cache architecture of the StrongARM (and a mandatory OS upgrade) was going to break some software which would need updating anyway.

Potentially it could also be argued that when RISC OS 3 came out then changes could have been made, as certain things (if I recall) would break from RO2 where apps hadn’t been written according to Acorn’s guidelines.

This isn’t a dig at Acorn. Other vendors made similar cock-ups back in the 90s. Using the Wintel world as an example, how much software broke when moving from the DOS-based Win9x (95 / 98 / ME) to the NT-based WinXP and newer? Many applications assumed that they could save their configuration into the application folder (which was also a RO issue); suddenly there’s ACLs in play and non-admin users can’t write to the program folder – an issue that I also hit repeatedly on RISC OS when trying to run applications over the network from a read-only ShareFS (or AppFS) share.

I think we all agree that a modern OS requires, at the very least:

• Separation of user spaces
• Privilege levels (at the very least ‘normal’ and ‘admin’ level)
• Isolation of application memory
• Access control at file system level

Of course much RO software was written in BASIC. Whilst BBC BASIC V was particularly good, the interpreter of course runs as a module, and hence the whole of BASIC runs in SVC mode – meaning that one bogus system call can completely stiff the machine. (Anyone tried typing !8=0 in BASIC?) Whilst there were some patches made to BASIC that traps zero-page writes, the rest of the interpreter still runs in SVC mode rather than USR mode, ‘conveniently’ bypassing memory protection.

TL;DR – Whilst RISC OS was far ahead of its competitors in 1988, Acorn stood still, everyone else caught up and overtook them.

the whole of BASIC runs in SVC mode

I think you’ll find that it doesn’t, and never has. Modules can run as USR mode applications. But being in USR mode doesn’t stop issuing SWIs to go and stiff the machine on your behalf.

Anyone tried typing !8=0 in BASIC?

I just tried it on a Raspberry Pi 4 running RISC OS 5.28: “Internal error: abort on data transfer at &FC1B3214”. I was able to quit BASIC and re-enter the desktop without incident.

This is – of course – because the Raspberry Pi build of RISC OS is “high-vector”: were you to try it on a low-vector build it would crash the machine.

Sure, RISC OS looks primitive now,

Yeah, mom used to tell me she knew I was using RISC OS because it was the old fashioned looking one.

but back in 1988 (when RO2 came out) it was streets ahead of the competition.

Perhaps because it was one of the first to bother redefining the palette for shades of grey rather than just using every default colour like the UI was drawn with magic marker.

Acorn kind of stopped developing the OS.

Yup. It seems to me that the big change was 2 → 3, and from then on it was maintenance.
Instead there were things like Browse (when we already had Fresco and Oregano) and the Java runtime that I don’t think I’ve ever managed to have anything run on. Plus, of course, the network stack (if you recall, DCI2 → DCI4).
But not a lot to the core OS.

the first opportunity was when the RiscPC was launched in 1994

With a vibrant market and lots of interest, that’s when they should have embraced 32 bit.

Many applications assumed that

It still happens now, people don’t always bother with Choices: vs Choices$Write.
(I’m sure I’m guilty too, somewhere…)

the interpreter of course runs as a module, and hence the whole of BASIC runs in SVC mode

As others have pointed out, the Run entry is one of the few that isn’t a privileged mode.

one bogus system call can completely stiff the machine. (Anyone tried typing !8=0 in BASIC?)

Nothing to do with BASIC. Three lines of code knocked together in Zap and run as an executable will have the same effect on susceptible systems.

the interpreter still runs in SVC mode rather than USR mode, ‘conveniently’ bypassing memory protection.

Rubbish. I don’t recall whether it was the A5000 or the RiscPC, but I had a utility to make page zero read only in USR mode. My first test was exactly what you posted, and it threw an exception.

You can get regular user mode BASIC to effectively stiff the machine if you call a SWI to do it with bogus input (I’d imagine anything that writes to a buffer with the buffer being &0), again on susceptible systems.
Or, one that works on anything, just call the IntOff SWI. ;)

I think we all agree that a modern OS requires, at the very least:
Separation of user spaces
Privilege levels (at the very least ?normal? and ?admin? level)
Isolation of application memory
Access control at file system level

That being the case, maybe the best (only?) option is for RISC OS to run as an application on top of a modern OS. AIUI, this is the thinking behind Timothy Baldwin’s port.

Speaking personally, I realize that I’m using the computer equivalent of this:
https://bestsellingcarsblog.com/1990/01/uk-1989-ford-escort-leader-sierra-and-fiesta-follow/
for most of my daily computing, but the RISC OS GUI still seems to be more flexible and intuitive than contemporary OSes. I’ve tried Linux, use Windows daily and have a passing familiarity with MacOS. They’re /not/ the same!

By the end of Acorn in 1998, they were still flogging an OS that, whilst state-of-the-art in 1988, needed some serious updates to remain current.

I doubt that it was state of the art 1988. First betas of NeXTSTEP were already available in 1988, with general release in 1989. A lot of other 4.3BSD-based stuff also. Only parts of the UI of RISC OS could ever be considered “state of the art”.

I also believe that, at every point in time, Acorn could have done something similar to Apple (MacOS-68k to MacOS-PowerPC to MacOS X) and Microsoft (DOS/Win 3.1 to Win 95 to Win 2000) to develop things further with radical breaking changes while keeping reasonable levels of backward compatibility. This is “just” a matter of resources. And that’s the basic problem throughout Acorn’s history: lack of resources, and on top of that spreading them to many different projects (RISCiX, STBs, NCs…). There was an interesting ROUGOL talk by Mike Stephens explaining how RISC OS 3.7 was developed for StrongARM compatibility. It was mainly one guy doing the hardware and another guy patching up the OS.

In the end, I don’t even think that it was an OS issue all the way. It was always a hardware/software issue. When the hardware was powerful enough (probably only 1987-1990) to justify the price, there was not enough software. When software development gathered up speed, it was let down by expensive underpowered hardware (1991-1996). When the StrongARM finally allowed a bit of CPU speed catchup, it was already far too late because the ground work was never done (development tools, standard libs, availability of modern programming languages). It was the whole ecosystem that failed, not the OS alone. So when suddenly quite powerful extremely cheap hardware became available (RPi), the OS and the software were already 20 years behind the state of the art, and all possible niches had already been taken by the competition (read: Linux).

It was an ultra-souped-up BBC Micro – hardly state-of-the-art though – with a pretty nice desktop environment on top by end 1988. Options to do much more were constrained not only by lack of resources that were applied to the project, but the requirement to have floppy-only low-memory systems.

Only parts of the UI of RISC OS could ever be considered “state of the art”.

The anti-aliasing font rendering system. Could at least spot differences between serif and sans serif at 6pt on the screen giving state-of-the-art WYSIWYG.

Speaking of which, where on Earth is the Detyna/EFF font catalog? That’s a multi-lingual gem truly worth preserving. Especially if RISC OS for phones (and anything else 64-bit..) shall hope to be globally available. ;P

Speaking of which, where on Earth is the Detyna/EFF font catalog?

Edward died a few years ago, and I am fairly sure that the EFF stuff is no longer available since then.

That’s a multi-lingual gem truly worth preserving.

It is certainly worth preserving because of the interesting history. Nowadays, it is useless. Font technology moved on in the past 30 years.

Especially if RISC OS for phones (and anything else 64-bit..) shall hope to be globally available. ;P

Start implementing full Unicode support and supporting modern font formats in RISC OS now. Doesn’t need to be 64bit initially at all, it can even be a model for how to transform parts of RISC OS to 21st century technology. FreeType, Harfbuzz, full UTF8 capabilities, provide new APIs, and provide a compatibility layer for the software using the FontManager SWIs.

Doing this will also give you an idea of the amount of work needed to halfway-modernize RISC OS. No matter if 32bit or 64bit.

Doing this will also give you an idea of the amount of work needed

This is where we need our resident font expert (nemo) to wander by and point out that there’s a lot more to simple right-to-left formatting than just right aligning the text (Netsurf gets Hebrew comically wrong).
Chinese goes right to left in columns down the screen.
So can Japanese, when it isn’t going left to right like English. And note that how punctuation is written depends upon how the text is flowing and it’s perfectly normal to have both ways on the same page (happens a lot in magazines).
Oh, and for the east Asian languages, one can have Ruby characters to aid reading.
Arabic varies how things are written depending on whether that sound is the beginning, middle, or end of a word. I think there might be an Indian language like that?
And, of course, the one nemo liked to point out (Farsi?) that is written with a sloping baseline.

When you’re looking at eight bit character sets, you can concern yourself with trivia like inter-character kerning to get fl looking like a single ligature and “To” having less space as you can tuck the ‘o’ under the ‘T’.
But introduce Unicode and the world’s languages, and it’s immediately clear that FontManager isn’t up to the job.

Many many years ago (about 2010?), I was able to drop the file “鬼束ちひろ – 声.mp3” (name assigned under Windows XP) into my Creative Zen media player, and it just worked. Copying the file to Android or iPad Mini, still called “鬼束ちひろ – 声.mp3”.
Under RISC OS? If I recall, the file appeared as “????? - ?.mp3” via a network share (not sure which side messed it up), and utter gibberish when on a USB key.

Hell, we don’t even have a font manager capable of substitution so you can see this text as normal, probably Homerton, with “на хуй Путін” looking like Cyrillic inline with it. You’ll see it in Netsurf because Netsurf jumps through hoops to make it work (rufl), but FontManager just uses the currently selected font and character set options and that’s it.

How much work is involved in correctly drawing text on the screen? This has hopefully given an idea of the sorts of issues involved. I’m not sure that it would make sense to write a new FontManager (or, worse, attempt to fix up the one we have). Probably better to see what’s already been written elsewhere and if it could be adapted.

Once you’ve sorted text output, there’s always text input. Enjoy the intricacies of a Chinese or Japanese IME where one may spell out words in Latin, kana, or something else and it’ll try to pick the correct ideogram to use (with pop-up options because of readings meaning the some sounds may have several possible ideograms available).

This isn’t even looking at the kernel or filing systems. It’s simply input and output of text. Because if you want a world class OS, it must have world class language support, or your potential largest markets (India and all of Eastern Asia) will simply ignore it in favour of home grown things that work in a natural way rather than a “created by a westerner that doesn’t understand our language” way.

The goal is to maintain it to contemporary (CPU/GPU) technology. It’s so advanced that legacy software can be run in software at more than adequate speed in a well-known GUI. It doesn’t need to sell its soul, so to speak, to be a separate OS/platform – even in 64-bit form.

[!8=0]

I just tried it on a Raspberry Pi 4 running RISC OS 5.28: “Internal error: abort on data transfer at &FC1B3214”. I was able to quit BASIC and re-enter the desktop without incident.

Yes, I believe it was fixed on RISC OS 3.8. I forget the exact details, I vaguely remember someone saying that one of the last things Acorn did when developing 3.8 was to make page zero write-protected from BASIC.

[Replying to Rick now…]

I don’t recall whether it was the A5000 or the RiscPC, but I had a utility to make page zero read only in USR mode. My first test was exactly what you posted, and it threw an exception.

My memory is a little hazy on the inner workings of RISC OS, I must admit. It’s been over two decades since I actually used it regularly, and probably about 25 years since I did any serious development on it.

I distinctly recall someone saying (possibly on Fidonet – that’s dating things!) that the reason memory protection didn’t work from BASIC was because BASIC ran as a module and was thus in SVC mode rather than USR mode. This was on pre-RiscPC hardware. If that’s not the case then either my source is wrong (I think it was someone from Acorn) or that only applied to pre-RiscPC machines.

Disclaimer though – entirely from memory, from approximately a quarter of a century ago!

it’s perfectly normal to have both ways on the same page

Before I retired, I watched one of my Israeli colleagues writing up his log book. Right to left, of course, until he came to write a number. Leave a space, write the number left to right, then continue writing beyond the left side of the number.

Presumably, stuff like that, when stored in a computer file, would be stored in the order that the characters were written. Rendering that is OK for a word processor file, since control characters can be added; but is it possible and reasonable for a text editor to render sensibly a plain text file with such content?

India and all of Eastern Asia) will simply ignore it in favour of home grown things that work in a natural way rather than a “created by a westerner that doesn’t understand our language” way.

Sadly, that’s not (yet? probably never) true of India – because almost the whole of the IT workforce there is from the educated middle class, educated in English medium and while they’re fluent in spoken conversational Hindi (or whatever else), their knowledge of written Hindi is mostly rather perfunctory. There used to be Hindi typewriters, with a keyboard layout that made sense to native Hindi speakers who knew the script well – which I recreated for RISCOS back in the day when IKHG worked – but a crappy “phonetic” QWERTY keyboard is all you’ll get on computers in India nowadays, and unicode’s weird handling of the Hindi character set, that bears little relationship to how traditional Indian typography worked. Which suits Indians educated in English medium when they lower themselves to using their native language, but does a horrible disservice to it.

I can’t speak for other Indian languages, but I suspect the situation is similar.

Yes, I believe it was fixed on RISC OS 3.8. I forget the exact details, I vaguely remember someone saying that one of the last things Acorn did when developing 3.8 was to make page zero write-protected from BASIC.

If that really was the case, it rather swiftly got forgotten. Both RISC OS 4.02 and RISC OS 4.39 crash when presented with !8=0 from the BASIC command line.

As I mentioned before, RISC OS 5 uses a completely different approach (moving processor vectors and zero page – the so called “high-vector” builds) which doesn’t involve any changes to BASIC.

Right to left, of course, until he came to write a number. Leave a space, write the number left to right, then continue writing beyond the left side of the number.

Why does your Israeli friend not write it all from right to left? Remember that it is Europeans who write numbers backward. From a mathematical point of view it is more natural to write the least significant digit first (little endian style). Which is why the least significant digit is at the right, at least for Arabs (well, Israel was not there then). Afterwards, from the thirteenth century onwards, along come Europeans who write in the other direction, and hence use a big-endian style for numbers. It is we that have it backwards, not they.

Of course, Bhaskara might have seen my comment differently ;)

If that really was the case, it rather swiftly got forgotten. Both RISC OS 4.02 and RISC OS 4.39 crash when presented with !8=0 from the BASIC command line.

It may not have been 3.8 then. I’m sure I remember typing !8=0 on a post-Acorn release of RISC OS (4.something, possibly with a softload) into a BASIC prompt in a taskwindow at one of the shows. Rather than freezing the machine and requiring a hard reset, it threw an address exception.

It was certainly fixed at some point so that BASIC couldn’t stomp over zero page. Like I said, nearly a quarter of a century since doing any major RISC OS development and my memory is a little hazy.

Yeah, mom used to tell me she knew I was using RISC OS because it was the old fashioned looking one.

3.5 onwards (and 3.1 with NewLook) actually looked pretty decent at the time.

I installed RPCEmu the other day on my new laptop though. Both versions, the 3.7 and the ROD/32-bit edition. First problem with 3.7 is that the screen memory is limited to 2MB, even in emulation (can that be patched if you want to run 3.7 for compatibility emulation?) so running full-screen 1920×1080 at 24bpp just wasn’t possible. (Works with the RO 5.x in the ROD edition though.)

Things I noticed immediately:

• No decent web browser (don’t say Otter!)
• No ODBC connectivity
• No Wi-Fi support (not a problem in emulation of course, the host’s wi-fi can bridge)
• No proper multitasking – everything locks when you load an application or when an application is busy

The only reason we didn’t complain about the last point at the time is because all other OSs other than big expensive Unix system (except Amiga OS) also used co-operative multitasking. It wasn’t until Win95 came along that there was some attempt to bring proper pre-emptive task switching to the PC desktop (and it wasn’t until WinNT that they actually got it right in the Microsoft world).

I still look back on RISC OS with some fond memories though. Still had the best version of BASIC (for the time) by a long way.

There used to be Hindi typewriters, with a keyboard layout that made sense to native Hindi speakers who knew the script well – which I recreated for RISCOS back in the day when IKHG worked – but a crappy “phonetic” QWERTY keyboard is all you’ll get on computers in India nowadays, and unicode’s weird handling of the Hindi character set, that bears little relationship to how traditional Indian typography worked.

Mr. Semmens, would you happen to know if this lack of functionality/bug is unique to the RISC OS implementation or valid for Unicode in general? And what it will take to fix it? It’s important because India is the second biggest market on the planet so if 64-bit “RISC OS for phones” ever happens (with all that entails..), proper localization is a must both for the user interface and the printed user manual.

In this context I repeat the question, does anyone know the fate of (R.I.P.) Edward Detyna and The Electronic Font Foundry’s massive catalog of over 1300 fonts for over 60 languages? Getting this on the market again will not just mean extremely much for RISC OS-based DTP/publishing potential but also the hypothetical enormous Asian market for “RISC OS for phones” for which it’s a must (given proper Unicode support). Shouldn’t be too tricky to supply appropriate keyboard layouts, too.

Rather long canvas to bleach, all this..