Gerph, November 2025
Good evening. It's been a few years since I talked about RISC OS Pyromaniac here, so things have changed a lot.
What will I talk about?
I'm going to talk about how the project has evolved over the years, from being just a way to test things to providing new ways to develop and test software. I've split this up into a few sections, and there will be a short break between each to talk about the topics I've discussed.
Please feel free to use the chat to ask questions as we go. I will try to pay attention to it and answer anything that comes up as we go.
At the end of the presentation, these slides and a bunch of links to resources will be made available, and I'll take questions.
Let me introduce myself. I'm Charles, previously known as Justin, better known as Gerph. I've done work on RISC OS since the early 90s, patching and porting things, developing RISC OS itself, and most recently creating a new implementation of the OS itself - RISC OS Pyromaniac.
I've always been a strong advocate of moving RISC OS forwards, and the work that I've done over the last few years is a testament to that.
It's been a long time since I talked specifically about RISC OS Pyromaniac.
So what is it?
RISC OS Pyromaniac is intended for testing, debugging, developing and experimenting with RISC OS interfaces. It's not intended for everyday use, but to make the process of developing and prototyping easier.
It's written in the high level language Python. It runs at the command line and within a window on Windows, Linux and macOS.
What does that actually mean?
Well, it means that if you want to write some code and see whether it works, you can do that easily without having to use the RISC OS Classic system. No RPCEmu involved. No physical hardware. You can just run your program and see how it works.
If you want to debug what it's doing, you can easily enable many different options to make it easier to see what's happening. If you want, you can get a disassembly of every instruction that's executed, or trap accesses to memory, or calls to any functions.
That makes it easier to see what's being done and what's going wrong.
If you're considering changing how a part of RISC OS works, you can modify the interfaces to make it work differently. Because RISC OS Pyromaniac is implemented in Python, changing the behaviour is easy. No messing with assembler, rebuilding modules or ROMs, or rebooting.
Because it runs on Windows, Linux or macOS, you can do all this on any modern system you have access to. Or, use the cloud-based build service to test your code automatically every time you make changes.
With RISC OS Pyromaniac, trying things out and ensuring that you have reliable software becomes much easier. Use the tools that you are familiar with - your editors, source control, even A.I. tools if you like - on the platform you are most familiar with. It might not be the most up to date of systems but it allows proper engineering practices to be applied to software development.
Occasionally I am asked, what version of RISC OS the Pyromaniac system implements. The answer is varied - it depends on what you want. The system has more capabilities and integration with modern systems than most versions of RISC OS Classic. It implements some Select features, some RISC OS 5 features. It absolutely depends on what you're trying to test.
If some feature isn't working as expected, or you want to try it differently, then - as mentioned - it's Python, so it's easy to change.
Similarly, there are often comments about what hardware it provides. The answer there is simple. It does not provide any emulation of hardware whatsoever - other than the CPU, and even that is generic. The point is that hardware drivers are the domain of physical hardware and need to be implemented for such systems. If you're writing a hardware driver, you know what you're working to. And integrating with RISC OS is generally much simpler than getting the hardware to work as expected.
Like WINE, RISC OS Pyromaniac is not an emulator. It includes an emulator for the ARM (or AArch64) components, but the operating system is in Python, translating what you're doing to the host system. Or if you want to think of it in more Acorn-like terms, it is similar to 65Host, interfacing the operating system calls to the host system. Or the BBC Micro's Tube, where the system calls are passed to the host system. Or the ARM semi-hosting environment. There are many examples that are similar to the way in which RISC OS Pyromaniac functions.
RISC OS Pyromaniac only provides RISC OS APIs, not hardware access. This means that if you write RISC OS code that doesn't access hardware you will be able to use your code on RISC OS Pyromaniac. Which means just about all software - as only a tiny proportion has any hardware specific component.
It's written in Python, as I mentioned, so integrating other well known tools into the system isn't too hard. The back end is Unicorn - a QEmu-derived emulation system. Unicorn provides the ARM emulation that the system uses. QEmu is one of the most well known platforms, and Unicorn makes the interfaces available programmatically.
This is a simple diagram showing how parts of the system are layered. The emulated code lives up in user space, and can run in modules. Some modules are in Python.
The Kernel and the bulk of the interfaces are in Python. The emulation system - Pyromaniac - is below that, and finally there is the pyro tool that we use to run it.
Why did I want to do this?
I've been working on RISC OS Pyromaniac for over 6 years now. Seriously. One release created per month and November 2025 is release 77. That's a lot of time working on one project. Yes, I enjoy it.
But there is a point beyond just enjoying it. I have always wanted to build things that let other people do things. Operating System development is clearly a big part of enabling others to do things. Initially, I wanted a way to test out my changes to the compiler and modules that I was playing with.
RISC OS Pyromaniac grew and now... well; now it can run games. It powers the online build service. It can run the desktop. It has integration with the host system. And it is extremely in debugging things. It has met my technical needs, and so I'm now using it for those original goals - as a way of testing things and experimenting with RISC OS.
For anyone who hasn't seen RISC OS Pyromaniac running before... I'll do a very quick demo.
What's changed ?
So what's changed with RISC OS Pyromaniac since I presented here?
Lots.
So much so that I'm really not going to go through the changes. It's all described in the change log on the website if you're interested, but the system is a lot more featureful and more robust. It's still not complete, but that's not surprising - RISC OS is a large system.
Since 2022...
And many many more things.
A better question to ask is 'What's driven the changes?'
I've been asking people to try out the system, to iron out the bugs, but there has been very little interest. That has meant that I've had to do things myself. I've ported many random programs, just to see whether the system works. I've written software and tests to check the behaviour.
When a bug is found, I've introduced more tests to ensure that the behaviour does not regress in the future, and so that it's known about. You may remember that the Hexen and Heretic games were released a couple of years ago.
That was largely a challenge to check that the system was working sufficiently to run real games. As part of CI, the game is started and allowed to run for 10 seconds through RISC OS Pyromaniac to provide some smoke tests that show it's actually working.
My GitHub account has quite a few things on it which have exercised the system and become useful. More are still live on my own systems, as they're not really useful to anyone else.
And of course, I demonstrated a lot of the changes in RISC OS Pyromaniac in the 64-bit presentation last year, and of course this presentation is running in RISC OS 64.
But let's move on to those influences that drove the development...
We'll spin back to November 2023. I found a 6502 emulator on GitHub, and I started converting it over to use a Unicorn-like interface. The idea was to make it a little bit easier to work with, and to have interfaces in a similar form so that I could use it like Unicorn.
The original author had got it to the point that it could run BASIC, but I expanded on that and hooked more of the system so that it could interact more with the host. The reason for doing this was because I had this idea that I wanted to prove that RISCOS Pyromaniac could be used for other execution environments than ARM.
And 6502 is quite, quite alien. It could be quite interesting having a 6502 processor executing your code, but all of the operating system parts of it were actually implemented in RISC OS Pyromaniac.
That was the idea anyway. However, it was a little too alien at the time. Registers have different widths. Memory is limited to 64K. Stack is tiny, at just 256 bytes.
Whilst I had thought 'if I can make 6502 work, I can do anything', it turned out that it was harder than I had the energy for, with a full time job as well. As an intermediate step to x64 or AArch64, it didn't work.
I mentioned x64 there. I had the beginnings of a RISC OS x64 demonstration application which shows the rotating cog rendered by Draw. It kinda worked, but I wasn't confident enough with that work to do anything more with it. That was way back in April 2021, and I set it aside because the system wasn't really ready for such changes.
In December 2023, I began reworking the innards of RISC OS Pyromaniac to allow the emulation to be something other than ARM code. Whilst some parts of the system were flexible, and easy to replace their implementation, the emulator was rather core to the system and wasn't as easy to make switchable. The work is still ongoing, but it began to take shape as a system that could use a different architecture.
To help with this, the disassembler was extended. Previously, we could only disassemble ARM code. Obviously in the future, the emulator's tracing would need to be able to disassemble other architectures. The system was updated to allow Thumb to be disassembled. This allowed the SWI Debugger_DisassembleThumb to be implemented.
Shortly afterwards, the AArch64 disassembly was added, and a new SWI call Debugger_DisassembleArch was added to allow arbitrary architectures to be disassembled. At the same time, the Debugger module was also expanded so that it
was aware of, and partially supported, the DebuggerPlus SWIs.
DebuggerPlus was created by Darren Salt, to change the form that the debugger's disassembly produced. Since those SWIs have been defined and used for many years, and I didn't want to clash, I skipped those SWIs. And then I implemented some of them, because... well, why not implement useful things?
Whilst updating the system to support AArch64 it became obvious that the exception registers were going to need an overhaul. The exception registers contain the details from any exception or other event which indicates the machine state at the time of failure.
In the 26-bit-world it had been defined to be 16 words long, one for each register. This was extended to 17 when the 32-bit extensions were created - adding the processor state register's value. For AArch64, it needed to be very different, as registers were a different width, had different names, and could be laid out differently.
I do not like fixing the immediate problem in front of me. If you fix just the issue in front of you, you only address a single instance of a problem. I like to address a class of problems, instead. That means that instead of dealing with just what's in front of me, I try to think about other cases that might be needed in the future. Things that other people might need. This allows much more flexibility for other uses.
Thinking about problems like that does mean that it's easy to over-engineer some things. However, as an operating system architect, I believe it's vital to provide functionality that others can use in ways you've never considered. By addressing the class of problem, you will always have a more generally useful system.
So, when it came to the exception dump area, I had to make it more future proof for other architectures. Instead of just saying "This is how it will be laid out for AArch64", I designed a new OS_PlatformFeatures interface that describes what the layout is. By describing the interface this way, it meant that if I got the layout wrong, I could just change the definition. And if someone decided to implement a 6502, or x64 or RISC-V system, they would merely need to change the layout definition.
It's only one part of the system, but it removes this from the problem scope in the future.
Around this time, Iconbar ran a series of 'advent calendar' screenshots. ROOL submitted a screenshot to show AArch64 code being disassembled by DecAOF. I'm relatively sure that was a fake, as there would be no point in extending the Norcroft toolchain to support AArch64, and certainly not in AOF. But I had a system that was starting to be able to run programs, and could easily disassemble AArch64 to the same level. That felt pretty good.
Anyhow, updating an operating system to function with a different architecture isn't easy, so it took a while to feel comfortable with things working.
It was slow progress, but in June 2024, I finally got the first programs running in AArch64. A small C program that drew a cog using the Draw module and animated it rotating. I intended everything I was doing to be written in C - not using assembler unless absolutely necessary. To get this working, I'd been using the GCC compiler to compile my programs. There was a little bit of hackery and some dumb linker scripts, but an executable AIF file was running.
In July I got the first game running in RISC OS using AArch64 - Chuckie Egg. Michael Foot's conversion of the game to C was relatively easy to make work on RISC OS Pyromaniac. It amuses me that the first game that ran on RISC OS 64 was actually a game from the BBC Micro.
Taking the work from these experiments, I created a new repository - riscos64-simple-applications - in GitHub in which to show off how things work. You'll find the example cog program there. This started to expand into a C library that can be used to run 64-bit RISC OS applications. Having got a C library, it was relatively easy to make my presentation tool work in RISC OS 64.
This was vital to my plans - there was a presentation to ROUGOL in August about 64-bit work, and I have a very strong need to demonstrate something that is a surprise. Finishing the presentation with the fact that the whole presentation was made using RISC OS 64 was key to that. It was very painful to get the ImageFileRender module working - I hadn't added AArch64 support to the module header generator at that time, so the interface was in hand-written assembler. It all came together in time though.
I had hoped that the presentation would spur people to talk about 64-bit and what could be done. It did generate some discussion, but most of the responses boiled down to either 'I'll believe it when it happens', 'Let's see what ROOL do', or 'there's no point if you're not going to support 32-bit applications'. It was a rather depressing result, to be honest. I can understand people being jaded, but after
The 64-bit presentation also included links to all the resources I'd produced to date - the built 64-bit examples, and programs, including a port of Richard Russell's BBC BASIC, the C library and descriptions of all the decisions and technical proposals.
I always do this for my presentations. I try to ensure that I've got sufficient supporting information so that nobody can come back and say that I hadn't done enough. Or that I didn't provide what was needed to come back for more. This presentation is no exception.
If we pop off to my presentation site - talk.riscos.online - and then go to this presentation... you'll see there's the slides for the presentation, the full text of the presentation, and a whole load of links to things that I've talked about or are related to this presentation.
I'm not sure that people care about how much goes in to ensuring that what's being done is distributed, but it matters to me. Each of the presentations has these resources, and the Pyromaniac site includes even more in the form of videos and images through development.
And of course, there are the GitHub repositories where most of the publicly distributed things appear. I believe the more you make available to people, the better the project becomes. There is only so much you can do when you've got a full time job and family, but communication is key to the success of open source projects.
Anyhow, to build all these bits, I had created a Docker image for working with RISC OS builds, as this makes for a better distribution mechanism. The Docker image had most of the 32-bit tools that I use, and so I started creating a variant that included the 64-bit tools as well.
I've offered this around to people, to see if I could get any requests from people wanting to test out the system. Nobody was biting though. The build environment has continued and is more featureful than ever.
In parallel with this, I started doing some live coding - sharing my screen on YouTube for a few hours each week whilst I work on a project. I had decided to create a Debugger module which supported the ARM and AArch64 disassembly, similar to how I'd done with RISC OS Pyromaniac.
Why? Well. I enjoyed watching Matt Godbolt do live coding on this compiler explorer. It was really fascinating watching an expert do things live. I've never felt great about my presenting skills because I don't feel as comfortable in front of a camera. And I wanted to show that creating useful things was possible.
Plus someone, at a meeting a few years back had said that it would be better doing some things as videos. All these things came together when I decided I wanted to show how you created a RISC OS component - the debugger module.
Although that stalled after the 64-bit presentation, I renewed the sessions in 2025, and we now have a reasonable live following, and an increasing number of people who watch offline. I get questions about what is being done, and people point out mistakes. I really hope that seeing these things will encourage others that there were actual things happening, and that they might want to be involved.
I'll give a quick shout out here to Dave Thomas for his suggestions, and my series titles!
These sessions have now produced the Debugger module, the SystemVars module, and I'm currently working on the implementation of templates for the Window Manager.
The Debugger was quite a long project, but it worked really well - I've got a version of the module which works well enough to use in !Zap. That's awesome. This is a screen grab from one of the sessions where I demonstrate the new module working in RISC OS within !Zap.
And doing this also found bugs in the RISC OS Classic Debugger module too, which was helpful.
In December 2024, Iconbar ran their 'advent calendar' screenshots series again.
This year, I submitted quite a few little examples. A christmasy snowman running in BASIC under RISC OS 64, a compilation and disassembly of the same code ROOL had done the previous year, an example of the online RISC OS shell system switching to 64-bit, and a 64-bit port of the original computer game - Adventure.
Here you can see the cloud based RISC OS shell running the 64-bit version of RISC OS, running and disassembling the C code that ROOL had posted.
RISC OS Open announced in early 2025 that they were opening a different class of bounty for work towards making components of RISC OS able to be ported to 64-bit systems.
<step>
At the time I was quite hopeful that this would mean that RISC OS Open would begin to work with the community, encouraging development, discussing plans and coordinating work to advance the operating system on modern systems. I was hopeful that, having discussed the issues, presented possible solutions, and demonstrated a functional version of RISC OS running 64-bit code, that they might wish to discuss what could be done.
When nothing came of that, I decided to push the issue by making a claim for a tiny portion of the work that I'd already done. As I'd been largely producing the system to directly address the issue of experimenting and moving RISC OS around, this seemed to be rather pertinent. If they weren't interested in coming to me, given my background, I would take what I had got to them.
I spent some time putting together a document describing the claim - what has been produced, how it fits into the goals of moonshots, what technical facilities I've provided, and a value on that. All backed up with documents, videos, articles, presentations and open source code to show how this fits together.
ROOL and I had a meeting to discuss this, and I answered their questions about the claim. They stated explicitly that the bounties would not be paid out for things that had already been done. However, they were interested in exploring possibilities and, despite seemingly not having understood how RISC OS Pyromaniac was useful, left with a better understanding. And I, for my part, made offers of the system, build environment and other tools.
It did seem quite positive, and I continued my work towards 64-bit, creating C versions of modules, updating Pyromaniac to 64-bit and doing the live coding to demonstrate how to create modules that ran on 32-bit and 64-bit, replacing the regular RISC OS modules.
At the same time I made sure that I was communicating what I was doing to the community through the ROOL forums (and obviously by publishing to GitHub as well).
This is, I think, the primary place where RISC OS users will be finding out what's being developed, and the best place to engage when things are happening.
But nothing was forthcoming from RISC OS Open about progressing RISC OS, or in producing any plan for how to get there.
If things aren't working, try a different way...
Having made very little progress on involving people, and with ROOL not being involved, I decided to change my approach.
ROOL weren't interested in what I had to offer, and weren't going to offer any guidance on what they wanted to happen. Nobody else was working towards 64-bit, and my technical things weren't making an impact.
I decided to look at what was missing, and why I believe the community wasn't engaged...
Mix and match these in a small community, and I think you have a pretty good definition of a RISC OS user's attitude.
I can't change people, but I can affect their perception of things. As I've said, I want to build things that people use. But to do that, you need to make sure that they know about those things. You need to engage with people when they are involved, and you need to ensure that they have the ability to be able to do things.
What I had been doing was in line with this:
This addresses some of the areas, but it hasn't been enough to reach people. Sometimes even if people see what you're selling, they're not going to be interested. But for the rest, maybe there were areas that I could still improve.
The live coding had been intended to improve my skills in presenting live, and to encourage people to try things, even if they're not their area. There were still some things I could do to try to encourage people who were waiting for something to happen, who were sceptical, or who didn't see any focus.
To try to address this, I expanded my work to include setting out a clearer plan, and to provide regular updates. Maybe this would hit some of the things that are missing in the community, and provide enough encouragement for people to get involved.
Creating RISC OS Pyromaniac had been easy because I knew what I needed to do. However, the work towards RISC OS 64 was different. I couldn't do it all on my own, and I didn't see any need to. But I did have a reasonable idea of what was needed and how it might fit together.
Having a plan can help you to work out how difficult a project is. It can iron out problems before you hit them. It can help others to see how to do things. It can allow you to do things at the right time - not 'putting the cart before the horse', as the saying goes. And it can give you confidence that things are moving - that there is progress and how far you've come.
Creating a plan would meet, or at least contribute to, some of the parts that I saw as problems. And a plan would allow me to see that I was achieving something.
So I started working out a skeleton of a plan. What I've produced isn't a project plan - it doesn't set out everything, and doesn't break down everything or show all the issues that will be encountered. If I were to do that, I'd have one of the best managed RISC OS projects... by about 2030. Instead I've tried to work out how things might be developed, and what phases these could fall into.
The goal of producing the plan (not the goal of the plan itself - maybe that's a little meta, but hear me out!) was to...
That meets some of the things that are missing from the RISC OS 64 work.
And I think that's gone quite well so far. The RISC OS 64 Status Wiki now describes the work needed. I've broken things down into phases. Each phase has something of a focus, and goals, but tries to show progress in other areas. I've defined some terms so that I can talk consistently about the development process. And for some areas, we've got more information about what is involved.
What do I mean by this?
I've said I've defined some terms, so let's give them some meaning. During the development of components and features, it's important to see how you're progressing - and not every component or feature will go the same way.
Original assembler modules. For some components, you'll design it, build some basic functionality, wire it up to an application or module and then test it.
Prototypes and libraries
For others, you only want to get as far as some prototype code, so that you can give it to other developers to do something with. I'm thinking of things like hardware stubs, or common libraries. Making the RISC OS part common means that other people can handle the specific implementations. Consider something like the Filesystem interfaces - making a stub to work with them means that anyone can write a filesystem by just plugging their bits in.
And then there's another path for the components that are already implemented, but need to be made to work in a 64-bit environment.
Here's a diagram that shows the way that each component can be developed, and the stages they go through.
The idea is to track the development process so that we can quantify how much has been done, and to be able to see what needs doing when.
I'm focussing initially on the components of the ROM. I have broken down the components for the ROM into a number of phases as I mentioned.
Let's have a quick delve into the status pages, and I'll give a brief tour.
The main index has links to all the details that have been brought together here. Each phase has a nice percentage, to give a quick overview of where we're up to. As you can see, there's actually a reasonable amount done on phase 1.
So, let's have a quick look at what Phase 1 is made up of...
The definition of the phase is given as a summary on the page. Basically, phase 1 is intended to show people that work is happening and to bring up some of the core modules so that they can be used. You'll remember I mentioned that the question was asked about the version of RISC OS that was being implemented?
Well, I'm choosing to implement the style of modules that were in RISC OS Select - breaking out parts of the kernel into separate components. Why? Because I've already spent the time working out a separation that allows independent components to be implemented without having to build a monolithic kernel.
So we have the Kernel components for system variables, conversions, commands, evaluation and some other parts as separate modules. In the live coding, I implemented the bulk of the SystemVars module. The table here shows how far I expect each component to get within phase 1.
As you can see there are quite a few components. If you've been looking at this before you might be wondering why components like FileSwitch aren't high up on the list in phase 1?
The answer's pretty simple. They don't need to be. We already have a working FileSwitch in 32-bit RISC OS, and RISC OS Pyromaniac supports file access in both 32-bit and 64-bit versions. So we don't need to worry about that right now. By moving other components on, and not being bogged down by that very complex component, we can show progress and get some more varied components working first.
That's one of the advantages of having RISC OS Pyromaniac - we can test out components using the environment even though we don't have the whole system present. It's kinda like how Acorn had the ARM board running as the tube whilst the BBC provided the I/O system.
You may also see that not everything has been specified to be 'complete' within the phase. Again, that's so that we can achieve the phase goals, and progress everything over a longer period.
At the bottom of the page, we've got a chart that shows how far we've progressed with each component. The lighter sections show what we're expecting, the ticks show what has been completed. As you can see by the ticks, a lot of the components have met their expectations.
And for each component there's a breakdown of what it needs to do. Some components, like the WindowManager have been split up into separate sub-components because there's a lot in there. For the live coding, I'm working on template handling - which we can look at here...
As you can see, the current status is that we've got a stub built - actually it's a bit further along than that, but I've not moved the status. And it's intended to be functional by the time we reach phase 4. Phase 4 is where most of the Window Manager is expected to be made to work.
And you can see the various functionality that the component needs to provide. Only one interface has been completed so far, but it's easy to see the parts that need to be made to work.
Almost all the modules have been broken down like this. The bulk of these pages were created automatically - I've got some decoding scripts that process the existing modules and work out what they do, and then describe that functionality. Afterwards, I then fill in more details about details that couldn't be determined automatically.
I'll not go through the other components and phases, but just say that further into the future, the less firm the plans are, and less detail present. Some things might need moving, and many will need refining with more information.
The idea is that hopefully the later phases will have more people than just myself doing the work. I'm hoping that the encouragement will get some people interested in getting involved in working on developing things. Maybe they won't, and if they don't, then at least I'll have tried to do something.
As I've been developing the components - either on my own or as part of the live coding - I've tried to include tests. I really want to be able to show that 64-bit components are working, and avoid issues. Or at least to know where they lie. This status repository is no different in that respect. I've included built versions of the modules and absolutes within the repository, so that people can try them out.
If we look in rm64, we see there are a number of built modules which run in RISC OS 64. How do we know that they run?
If we have a look at the GitHub Actions and locate the 'Test all binaries' job, we can see the results of loading these modules and absolute files. They're tested in both 32-bit and 64-bit RISC OS and report their status. It's a rudimentary test, but each component's repository will have a set of more comprehensive tests.
How do we test things without an OS to run them on?
That's easy - we have an OS to run them on. RISC OS Pyromaniac supports 32-bit and 64-bit and the RISC OS Build service can run both architectures. So we just fire off the module and a test script to the service, and we can get back whether it worked, or whether it crashed.
Because I've already implemented tests for a good amount of RISC OS as part of RISC OS Pyromaniac, these can be reused for the new components. In fact they are used to test the components that I've built so far. In some cases they haven't needed any changes at all.
I've said that we can build 64-bit RISC OS components, but haven't discussed how we build them. Obviously we've got the Norcroft toolchain to build 32-bit components, but there isn't a version of Norcroft that builds 64-bit code.
That's fine because other, far better, solutions exist. It would be insane to make Norcroft build 64-bit code when we can use GCC, CLang, TinyCC or any of the other lesser known systems to build C code. And that's before we consider other languages.
Wrangling GCC to work in a way that operates with RISC OS isn't too hard. Doing so with 64-bit code is a little more tricky. Together with creating a new C library that we can use for RISC OS 64, it's taken quite a few months, but I've built some pretty good tooling. I've been looking for anyone to test this (like the other many things I've built) but haven't had any takers. The build environment uses Docker to let me build software in a simple way. I've set it up so that building for 32-bit and 64-bit is just as simple.
When I say 'simple', I mean that you just give a different parameter to AMU and you get out a 64-bit binary.
Let me give a short demonstration.
Let's fire up a simple terminal, and we'll create a directory for this little project. I wrote a software project creation tool to make creating a program easy - riscos-project. We'll run that. And we'll create some skeleton code.
riscos-project create --name Test --type command --skeleton
We can see that we've created a C file and a Makefile. If we see what's in that file, we can see that it's a very simple program that just prints some messages. Let's build it.
riscos-amu
Ok it's built. How about we run that, just to prove it's working?
pyrodev --common --command aif32.test
Want to see what's in it?
less aif32/Test,ff8
Let's quickly search for the main function... there we are, and you can see that it's printing its messages.
Ok, but I said we can build this as 64-bit. So let's do that.
riscos-amu BUILD64=1
There we are, we have a 64-bit RISC OS binary. Again, let's run it.
pyrodev --64 --command 'aif64.test'
And again, let's see what's in it.
less aif64/Test,ff8
Here you can see the 32-bit AIF header, but it indicates that this is a 64-bit binary. Again, let's search for the main function. And we can see the calls to printf, but this time they're in AArch64.
This is only a small part of the build environment.
I updated a quite old ObjAsm to GNU assembler converter to be able to support most of the ObjAsm functionality. So now you can write AArch64 code in ObjAsm style and have GNU AS assemble it. Not that I expect anyone to use assembler that often, but it's nice to have it available.
What about modules?
I've updated CMunge to handle AArch64 header generation. Let's see that in action, then. Again, riscos-project can be used to build a simple module.
riscos-project create --type cmodule --name Test --skeleton
As you can see, it really is very simple - just printing messages on startup.
less c/module
And we can build it for RISC OS 64.
riscos-amu BUILD64=1
If we look in the 64-bit directory, we'll see the module there...
ls rm64
And of course we can run it - let's start a shell and load the module.
pyrodev --64 --gos
There we are, a C module running in 64-bit.
I've used the build environment in all my live coding, to demonstrate how to use it, and how flexible it can be. Building 64-bit or 32-bit applications without any changes should be the goal, and the build environment allows that. Every now and then I get bitten by the fact that the C compiler doesn't support C99 features, but I'm very used to handling that these days.
Of course, you don't have to use my tooling to build 32-bit and 64-bit components. There's a C library called ArchieSDK, which is intended for building for older systems, but is also capable of building for modern machines as well. I've added support for building the library as 64-bit as well.
You'll find the 32bit version at https://gitlab.com/_targz/archiesdk, and the 64-bit version at https://gitlab.com/gerph/riscos64-archie-sdk/.
I've talked about building C code, which is great, but it's not everything.
I saw that ROOL has released a Fortran compiler for RISC OS. I've no idea who might want to use Fortran on RISC OS, but having more options is always good.
Fortran is not a language I know. I've managed to write Hello World in it. That's about my limit.
program hello
! This is a comment line; it is ignored by the compiler
print *, 'Hello, World!'
end program hello
I spent a little while tinkering with the build environment to ensure that I could actually build Fortran code.
riscos64-fortran -o helloworld,ff8 hw.f90
There are a few long symbol names, but that's purely a warning. We can run the binary...
pyrodev --64 helloworld,ff8
It isn't exciting, or useful, but... well that works, and if you happen to want to use Fortran on RISC OS, it's working on 64-bit as well.
I've not yet spent any time trying to get other languages to cross-compile to RISC OS 64, but I'll no doubt have a play with some in the future.
Whilst cross-compiling is good, it's also important to have languages available for the system itself, so that users can do things. Whilst it's not something I'm focusing on, it's important to ensure that the community can see that it's not just a bare system which you have to bring your own tools to.
I've made a few languages work in RISC OS 64, to varying degrees. These are documented in the status repository, but a quick round up...
_swix interface, so it's actually handy for testing modules in RISC OS 64.And then there's the BBC BASIC implementation that Steve Revill is working on. He's not ready to offer any progress statements, or share it yet, but has been working on it. As we heard at the London show, he's not going to do any more unless he can get paid for it.
Shall we have a quick look at some of the languages?
Let's start with PocketPy.
cd ~/external/ports/pocketpy
cd riscos
pyrodev --64 --gos
appsize 20000k
aif64.pocketpy
print("Hello world")
Let's try Pico C...
cd ../picoc
pyrodev --64 --gos
dir riscos
aif64.picoc -i
printf("Hello world\n");
_swix(2, _IN(0), "Hello world\n");
And Lua?
cd ../lua/riscos
pyrodev --64 --gos
print("Hello world")
os.time()
Anyhow, you get the idea.
All these mean that there are a number of languages that will be available from day 1 to run on a 64-bit version of the OS.
Let's wrap this up, shall we?
I've talked quite a bit about RISC OS Pyromaniac and what this project has evolved into. As you should all know by now, my motivation is to push RISC OS forwards. To encourage the community and make resources as available as possible.
You've heard about what I've been doing. You've heard about where I see problems, and what I have done to try to address them.
I hope this is encouraging to people, and that they will get involved in developing RISC OS for the future. I can only ask people to get involved, and provide the tooling and guidance.
Are you interested in being involved in developing for the future of RISC OS?
Thank you very much, I'll take questions now...