Linux Port

I think you’ve got too hung up on the little clip of ChatGPT I did… it was just an easy way to show the equivalence.. which it did a reasonable job on…

The Arm32 & Arm64 instruction sets are deliberately very similar, with the removal of the conditional execution being the largest change (IMHO)

In terms of actual translation, I was thinking about just some C or Python.. not AI…

In general I would say that a proper re-write in C, and proper move to a fully thought out 64-bit RISC OS is much better, not forgetting multi-core, multi-threading
… but let’s face it, we all know that ain’t gonna happen
;)

It’s not the first time it’s been suggested to use ChatGPT to do conversions, as if it were some sort of magical panacea.

we all know that ain’t gonna happen

I suspect that’s true of any such conversion, but I fail entirely to see how it’s easier to write an ARM32 → ARM64 converter than to write an ARM32 → C (or other high level language) converter.

Any such conversion will be less efficient than a careful analysis of what the code is really doing and a rewrite. It’ll generally convert each instruction to one or more instructions, whereas a human analysis and rewrite will often convert groups of several instructions to a smaller group.

Even a one instruction to one or more instructions converter will be a lot more difficult than you seem to think.

Real life examples of why writing stuff in assembler is not a great idea…

Impression → doesn’t even have a 32 bit native version yet, as clever assembler is clever and that makes it a nightmare to port by hand, never mind a machine messing stuff up.

OvationPro → native builds for RISC OS and Windows, and the sources are now available if anybody fancies tackling Linux, MacOS, etc. ;)

Uber example: Linux, available damn near everywhere.

If the proposed future of RISC OS is a translation to a big pile of 64 bit assembler, then count me out.

It’s not the first time it’s been suggested to use ChatGPT to do conversions, as if it were some sort of magical panacea

Yes, but I’m not actually proposing to use ChatGPT for the conversion
- but I just spent a few minutes seeing what sort of job it would do

but, I think I am proposing that some sort of automated translation is possible, especially if the memory model is still 32-bit…
- one reason being how similar Arm32 and Arm64 are, especially at Asm source level… with the extra registers in Arm64 being very helpful…

To be honest, I’ve been sort of inspired by the work on 68K emulation done by Michal Schulz for the Amiga & PiStorm32

https://github.com/michalsc/Emu68

- that’s a JIT compiler that seems to produce very good results
- using very different instruction sets
- and emulating the 32-bit 680×0 on the 64-bit Arm was helped by the extra registers…

Anyway, I started of thinking that if it could be done for the 68K on Arm, then it must be easier to do ditto for Arm32 on Arm64
- but, I guess, Qemu is already doing this?

But as I looked into it, it just seemed that Arm32 & Arm64 were so similar that maybe a more direct approach would work
- especially as the Sources are available…

Anyway, it’s no big deal, it’s just something I might persue for fun and entertainment!
;o)

I suspect that’s true of any such conversion, but I fail entirely to see how it’s easier to write an ARM32 → ARM64 converter than to write an ARM32 → C (or other high level language) converter.

Any such conversion will be less efficient than a careful analysis of what the code is really doing and a rewrite. It’ll generally convert each instruction to one or more instructions, whereas a human analysis and rewrite will often convert groups of several instructions to a smaller group.

Even a one instruction to one or more instructions converter will be a lot more difficult than you seem to think.

You’re probably right
- I’m thinking it needs to be automated, not manual
- one would need to iterate on the translation process until it was capable of translating the vast majority of the Asm code without (or just minimal) manual tweaking…

It would probably also be easy to write it so that it spewed out C code (derived from the assembler), that could then be recompiled into the target..
- but it wouldn’t be very nice looking C…

This is slight aside, and maybe a discussion for a different thread, but when thinking about Extending BBC Basic, and / or converting to C
https://www.riscosopen.org/wiki/documentation/show/Extended%20BBC%20BASIC

Why not just use the BBC Basic for Windows Source code (as the basis) back ported to RISC OS?

What about a SWI_MRS

[Edit]
Is there a simple way to detect which processor is in use – and do

Question
Mrseq etc
Swine_mrs

Any ideas on how to get the sound to work?

- but it wouldn’t be very nice looking C…

And how!!! But at least it would be portable. But even more unmaintainable or developable than the original assembly code.

And how!!! But at least it would be portable. But even more unmaintainable or developable than the original assembly code.

It’s about being able to support 64-bits…

It’s about being able to support 64-bits…

Obviously.

I find it all interesting, but probably not really relevant to me. I’m fairly sure a couple of Pi4s will keep me RISCOSing as long as I’m likely to care, and none of the rest of my family use RISCOS. That said, if RISCOS appears on more modern architectures in a sensible form – that is, not stupidly inefficient and slow, or with functional impairments – I’ll probably change my tune. I’m unlikely to be able to contribute in any useful way to achieving this 8~(

For me, having RISC OS available on RPs meant that it was easy to try – effectively zero cost
- (as you know) with A76s and beyond something is needed to support RISC OS on modern platforms
- otherwise, someone with an RP5 can’t just try it
- they need to buy an RP4 just to try it
- which is ok, but as RP5 become more popular, that will become more of a hurdle

RISC OS on Linux (for example) allows RISC OS to continue on current platforms
- but it’s not really finished and a bit clunky

So there’s a few years for the RISC OS community to get it’s act together and come up with a path forward for RISC OS

Doing a ‘simple’ Arm32 to Arm64 port might provide a way forward whilst the true 64-bit port is accomplished…
- or maybe QEmu is good enough until that happens?

For me, having RISC OS available on RPs meant that it was easy to try – effectively zero cost

A properly packaged emulation solution, for all major platforms, would have achieved the same (and more) and easier and cheaper.

RISC OS on RPi was not exactly user-friendly as a setup/install experience for non-RISC OS users. I wonder how many people tried and failed and just turned away instead of doing as the few that asked here for help.

I thought it was pretty easy – just download and install on SD Card…

I thought it was pretty easy – just download and install on SD Card…

You were lucky.

There were certain points in time where this was not possible, because RPi hardware revisions were not supported. And people got confused that only a small amount of their microSD card actually got used. And no Wifi of course, that comes unexpected for most people trying out OSes. And very little useful software bundled (ROOL distribution) or incompatible with RPi 4 long after its release (ROD distribution). Distributed RPi firmware not being compatible with later revisions. The list goes on. Lack of easy installation option “side by side” with your main RPi OS is also a problem.

Now compare this with a curated package that any old Linux package manager could install and you just start “RISC OS” on your main RPi OS. Or your Linux PC. Or your Mac.

Real hardware is a pain in the *ss. Especially for a very small developer community with no industry sponsors.

I tried it on an RPi 4 and RPi 400, and it was fairly painless from what I remember… I understood the lack of Wifi and limited SD card space…
- I haven’t fired up my RISC OS RPi4 for a while, so I probably need to to remind myself of the pain!

If people want to try on a vanilla Apple M1/M2 then perhaps running Linux in QEmu is the best strategy.
There is a Qemu for Apple M1 that supports openGL and will have the least graphics overhead.
I’m looking into a small writeup and an image file that can run Risc OS.
Ofcourse running asahi Linux and doing the build from scratch is the default way to go. (remember that you will need DDE)

The way it handles the filing system could use some help. Also the way the build process works is not quite ‘out of the box’.
I would love to see CMake and such for the native parts.
The reason that we don’t see much progress is simply because this is a one man’s project that is quite inaccessable for developers.
If the effort was merged with RPCemu (allows hardware support and hostfs) we might have a great solution for native speed in RPCemu and qemu speeds for non Aarch32 systems.

Ofcourse running asahi Linux and doing the build from scratch is the default way to go. (remember that you will need DDE)

You only need the DDE if building RISC OS from source. The binary download includes a pre built ‘rom’.

How does DDT run on Linux?

Indeed, the prebuilt rom is fine to use.
DDT hangs the desktop here. This might be my setup, no idea if others have more luck with that.

It still amazes me how fast !Doom runs. At 2560×1440 it is smooth as butter..
There is a caveat when trying to run !Doom, copy the app first to the ram disk because it won’t work from IXFS.

4K full screen is even nicer. Admittedly !Doom in 4k is a tad laggy but very playable.

RISCOSmark 2.04 (30-Dec-2015) by Richard Spencer 2003
Comparison with RiscPC SA 202MHz running RISC OS 4.02 800x600,256
(HD benchmarks are in kilobytes/sec)

MOS Utilities   5.29 (30 Apr 2021) Git: 1234a4b20
FileSwitch      2.88 (08 Sep 2021)
C Library       6.15 (21 Sep 2022)
FileCore        3.77 (14 Dec 2020)
HAL-based system (Linux HAL PSR Manipulation) tested at Sat,04 Nov 2023.12:46:18
Filing system: IXFS$
Graphics Resoloution: 3840x2160, 16M colours

Test                                                   Benchmark
Processor - Looped instructions (cache)                     5660       3%
Memory - Multiple register transfer                        63154   38983%
Rectangle Copy - Graphics acceleration test                 9007    3721%
Icon Plotting - 16 colour sprite with mask                  9363     468%
Draw Path - Stroke narrow line                             12164     779%
Draw Fill - Plot filled shape                              16572    1135%
HD Read - Block load 8MB file                            5515405  184956%
HD Write - Block save 8MB file                           2903699   95485%
FS Read - Byte stream file in                                501     242%
FS Write - Byte stream file out                              391     203%

Oh and don’t ask me why 3% :-D
This is on a M1 using qemu for running the RISC_OS.IMG binary.

Is it possible to increase the RAM above the default 1GB? If so can this be done via config?