New Dedicated hardware For RO64 - speculations

My background using RISC OS in a more or less professional way is within Desktop Publishing, using !ArtWorks, Photodesk, Ovation Pro and Impression Publisher

ArtWorks – well, Adobe Illustrater is an equivalent, and far more capable (these days).

Photodesk – have you seen what Photoshop CS6 is capable of?

Ovation Pro – is available for Windows

Impression Publisher – thoroughly beaten by Adobe InDesign. Or even Microsoft Publisher.

Yes, back in 1996 or so, the RISC OS desktop was a far more productive place than Windows. But Windows (and third party applications like Adobe Creative Suite) got better. Far better. And RISC OS stood still.

Windows itself also got better. Whilst everyone was busy bashing Windows 95, 98 and ME, Windows NT4 was coming up the sidelines. Then NT5 (better known as Windows 2000) caught up. When XP came out, M$ made the wise decision to kill off the Win9x product line (including the diabiolically slow WinME) and replace them with XP.

Unfortunately the “XP to replace Win9x” was WinXP Home, which was missing all of the security features that XP Pro had. M$ should just drop the “home” line and have one edition of Windows for all. The problem still persists today; if you buy a new PC it’ll most likely come with Windows 11 Home, which is terrible for a whole lot of reasons that aren’t really relevant to a RISC OS forum, even in Aldershot. The first thing I always do is wipe Win11 Home and install Win11 Pro, apply a sensible security policy and never set my normal account to administrator privilege – if I need admin privileges it’ll prompt me for the password (similar to ‘su’ or ‘sudo’ on a *nix system), do what needs to be done and drop privileges. If Windows had worked like this from the beginning then most of the security issues that have plagued it for years would never have happened.

(Just read Rick M’s reply which seems to have addressed many of the same points.)

Anyway, back on topic. If you want to keep running 32-bit RISC OS apps on an AArch64 system, I’d suggest an emulation layer for the API. The app can then run inside this (similar to WINE) but appear as a normal desktop app.

I do think it would be rather amusing having Netsurf running alongside Firefox or Chromium on the same desktop.

Anyone one know where I can get a Neoverse V1 (or V2) development board for under £6K?

It’s a little more than a Pi 5, but only about the same as an A540 in today’s money inc VAT.

The best dedicated hardware for RO64, at this stage, is the Raspberry Pi 4, followed closely by the Raspberry Pi 5, with the MacBook Pro (Apple Silicon) probably the most desirable* 64-bit hardware (there is a Linux port for this now, so …).

The biggest challenge to RO64 (besides developer time) is the fact that all our tools are 32-bit, and ARMv8 can’t easily switch back and forth.

Even if an (identical in function to RO32) port of RISC OS to 64-bit appeared out of the blue, and even if such a port had really good dynamic recompilation supporting the entire AArch32v8 instruction set … our tools are still all 32-bit.

One way to support future development of RO64 would be to add ‘64-bit functionality’ to native 32-bit tools now. If Zap or StrongEd etc could disassemble A64 code, for example, that would be useful for the future, which will almost certainly involve an emulated A32 CPU running under ARM64 as a stepping stone (and also as a compatibility layer).

I know it was from before our time, but the next line is?

Ah. Yesterday slow I was.

Anyone one know where I can get a Neoverse…

It took me a couple of moments to realise that this wasn’t a moon-on-a-stick request for a new Universe. Or is it simply a variation on that theme? I’m still none the wiser. Today slow perhaps still I am.

For most of what I do in the way of computing the M1 Mac running MacOS is much better than RISCOS. !Draw suits me very well for what it does, !Zap is very good for seeing or editing what’s really inside files at byte or 4-byte word level, and BBC BASIC is very handy for quick small throw-it-together apps to process files in odd ways that none of the other software I’ve got does (or does easily). !Draw’s and BBC BASIC’s advantages are probably purely my familiarity with them; !Zap’s advantage may be more general, I don’t know.

I wonder if Gerfs ARM disasember can handle ARM 64 :-))

Mine can!

Although, currently only (an expanding) subset of it! It is also linked into the Debugger module, so I can disassemble in !Zap (ideally I would select a new assembler mode, but I have the modified and original modules on Pinboard, so I can double click to switch back and fortn between ARM and Aarch64!

Glenn R, the Apple Mac software houses like Adobe cornered the design market decades ago, have had decades to develop their software for a huge customer base, whereas RISC OS graphics software (apart from !ArtWorks) has stood at a virtual standstill, probably because those using RISC OS for pro desktop publishing today number a few dozen at best, hardly a market to support further development.

This is sad, because RISC OS as such is a very productive environment, even lacking the ability to use gigabytes of RAM and (I believe) inability to read large TB harddisks, use multiple CPU cores. This is something which can be fixed with 64-bit RISC OS, and probably be implemented for the 32-bit version too. But since RISC OS today is mostly used by hobbyists as opposed to any business setting, there’s hardly the incentive to do all that work since very few hobbyists would need it/buy it. The result in sum is that to make a living using only RISC OS for desktop publishing is a lost cause.

to make a living using only RISC OS for desktop publishing is a lost cause

Wow. Well done!

That’s why I gave up publishing academic journals (using Impression on RISCOS machines) 27 years ago – and went to write technical manuals (using FrameMaker on Windows machines) at and for ARM instead.

It’s mainly because of the limitations regarding RAM and HD’s, plus lack of software development – the first issue may be fixable, the latter not since the market isn’t there anymore. Takes both to be a “Mac-beater” today. By the lorryload..

ARM’s 64-bit architecture has access to plenty of RAM and HDs, and plenty of software – but it’s not a Mac-beater, it is a Mac. I’m sitting at it right now. It’s exactly what I use for DTP. And accessing this site, usually.

The Pi4 is just next to the Mac. It’s connected to the same keyboard, the same mouse, and the same monitor (actually a TV, but it’s never been used as anything but a monitor). I use the Pi4, running RISCOS, for the things I find it useful for. I don’t try to use it for anything else.

This is something which can be fixed with 64-bit RISC OS,

No, it really isn’t. Because who the eff is going to write world class software for a brand new immature/untested system and a market of maybe that few dozen that don’t already use one of the pro solutions that have existed for decades (thus extremely mature) elsewhere?

Somebody with no people, no money, like the first installment of RISC OS was produced? They kept it simple so why no one being expert at both 1st gen. ARM instruction set and modern C hasn’t done a conversion yet, with no people, no money, is beyond me.

It’s sensible to use ARM chips due to their low power consumption and high performance, suitable for both Desktop and (especially) Laptop computers. The Desktop/WIMP system should be kept as-is due to its user friendliness. It’s everything “beneath” that needs a revival – no limits on addressing RAM or huge harddrives is a good start. And backport it to 32-bit RISC OS, if that’s practical.

They were being paid?

Somebody with no people, no money, like the first installment of RISC OS was produced?

???

being expert at both 1st gen. ARM instruction set and modern C

I was expert at the 1st gen ARM instruction set, but that’s pretty rusty now; I’m not expert at any sort of C and never have been. But if I was the right expert, I could still think of better things to do with my time.

is beyond me

To be perfectly frank, that honestly isn’t very far. I could still think of better things to do with my time – why the mew am I even bothering to reply??

Because who the eff is going to write world class software for a brand new immature/untested system and a market of maybe that few dozen that don’t already use one of the pro solutions that have existed for decades

Consider exactly how long it took for any linux variant to become mainstream, let alone commonly used. And by mainstream, I mean to replace existing solutions, be it servers or desktops.

the Apple Mac software houses like Adobe cornered the design market decades ago, have had decades to develop their software for a huge customer base

To be honest… for the majority of publishing work these days I could probably whip something together using Notepad (or at least Notepad++ or UltraEdit32) and HTML / CSS. Hardly a visual workflow, but the end result is the same. There’s a whole set of CSS attributes targetted specifically at printing.

A contrived example, sure – although I do generally include a set of print styles in the CSS when I’m putting a web site together. Makes sure it looks nice when printed, and also uses more appropriate fonts (Verdana is designed specifically for on-screen use and looks a bit messy when printed, I change the body text font to something like Times or Garamond for print media).

I was always taught as a starting point to use serif for body, sans-serif for headings. Of course nowadays you have so-called ‘hybrid’ fonts like Verdana or Calibri, which have the readability of serif (Times, Trinity, Garamond etc) but the clean lines of sans-serif (Arial, Homerton, Helvetica etc). A good starting point is to specify Verdana for on-screen and Calibri for print.

There’s also been a long-standing argument about what units to use to specify font sizes in CSS. Using pixels allows precision design, but prevents changing the base font size (albeit this isn’t really a problem nowadays as you can do a full page zoom in virtually all browsers). Then there’s ems, and rems (root ems, nothing to do with REM in BASIC). These are great from the end-user’s point but a design nightmare as the size of an em is relative to the parent container. And finally there’s points (standard in typography).

My personal preference is to use pixels (px) for the desktop version of the site and points (pt) for the print and mobile version. Using pixels on mobile is awkward as there’s different ratios for Android phones, Android tablets, iPhones, iPads etc (even different models of iPad) so best to stick with points.

Yay, topic-drift I know, but this is Aldershot.

RISC OS has beautiful WYSIWYG fonts, but missed out on screen color correction for CMYK printing. That made me blue.

That made me blue

From the output of various fantasy artists, it’s a common colour for the species.

Here is a shell for you
Inside you’ll hear a sigh
A foggy lullaby
There is your song from me

probably whip something together using Notepad (or at least Notepad++ or UltraEdit32) and HTML / CSS

So… LaTeX for dummies, then? ;)

Long live WYSIWYG Editors.

And think what a monster Design-Desktop machine, ARM-based, could do running RISC OS (64 of course) editors for creating 2D/3D/Video/Audio art on such a machine.. </Dream Mode OFF>

Absolutely nothing, because nothing exists for either case, and seems unlikely to any time this decade. If it doesn’t exist now, and therefore would run under emulation later, or could be easily ported from some exist open source project, i doubt it ever will.

Compared to other operating systems RISC OS is pretty compact, making small demands on RAM which is what gives it it’s speed. Written in assembler, yes, though would the same functionality written in C, compiled for 64-bit multicore ARM CPUs, be slower? I don’t think so. It’d probably be even faster.

That’s the fate RISC OS deserves, being the first commercial OS developed for the ARM CPU, taking advantage of the tremendous development within the ARM ecosystem since Acorn’s demise, to rise like Phoenix from the ashes and be a new, very fast, very productive system.

That is, provided it has a user-friendly 64-bit capable SDK so new software can be written, old (if written in C) recompiled. It’s actually the use of assembler, both in the operating system and its mostly graphics-oriented software packages, which has frozen the platform at a 1998-level, unable to move forward in a significant way, to attract new users.

What happens if the user base becomes too small to justify production of heavyweight software titles? This is why no significant software titles has been written for RISC OS since Acorn disappeared – the market isn’t there to support it.

To build on what is, keep the WIMP/Desktop look and feel, only aimed at 64-bit systems, can cause a revival for a platform which deserves it, not suffer a slow death for lack of users.

[my emphasis]

Written in assembler, yes, though would the same functionality written in C, compiled for 64-bit multicore ARM CPUs, be slower?

At the risk of wasting too much of my time engaging with a blatant troll…

…anybody who in the mid ’20s wishes to implement a shiny new operating system espousing the best of mid ’80s state of the art…

…is a complete idiot.

There’s a reason every other operating system on earth is arguably slower than RISC OS (on equivalent hardware). It’s because they do a LOT more. If you want to make a shiny new OS, you wouldn’t start from here.

I wrote a lot more, but decided to delete it. Let’s not cloud the main point. If you want to make a shiny new OS, you wouldn’t start from here.

Honestly, go grab a PDF copy of “Operating System Design and Implementation” (yes, the Minix book) and try reading some of it. Then you might understand more the sorts of things that OSs ought to be doing, and better understand why RISC OS doesn’t measure up. If you want to make a shiny new OS, you wouldn’t start from here.

Your 64 bit! 64 bit! 64 bit! is ridiculous. Please, for the love of whatever god you believe in, shut up and get a clue. If you want to make a shiny new OS, you wouldn’t start from here.