Sun, 10 May 2026 22:05:30 +0000
Yes and i’ve been running the SpriteRender Module since, no issues :) Really good work
RISC OS Build environment release 0.3.477Sun, 10 May 2026 19:46:00 +0000
Hiya,
I released the latest RISC OS Build Environment last night on Docker Hub – https://hub.docker.com/repository/docker/gerph/riscos-….
There are a lot of changes in there, many dealing with the AI Agent skills and the like (new skills are up on the agents repository as well, although they’re dependent on the build environment; https://github.com/gerph/riscos-agent-skills).
One thing that might be useful is the riscos-cport tool which attempts to set up a POSIX style source ready to be worked on for RISC OS. It’s only a starting point, but it may be useful to some people.
Changelist summary…
This summarises the changes between v0.3.408 and v0.3.476, covering commits from 2026-04-08 to 2026-05-09.
AGENTS.md file, allowing personal guidance to persist across projects.ai agentsmd command to easily edit the user’s personal agent guidance.--continue and resume --last support for Codex, Gemini, and Qwen.ai skills (and its alias skill) to install, open, and show skill content.writing-pymodules: Developing Python modules for RISC OS Pyromaniac.using-tooltesters: Running automated tests with riscos-tooltester.designing-modules: Best practices for RISC OS module architecture.riscos-filesystem: Guidance on RISC OS-specific filesystem conventions.allocating-resources: Procedures for registering allocations with RISC OS Open.using-libgcontext: Using the GContext library for graphics output.using-libasm: Utilizing assembly routines in C projects.porting-to-riscos-c: Assisting with porting existing C projects to RISC OS.ai skills list to support -v for descriptions and more detailed information.writing-cmodules, using-cmhg, writing-prminxml, and writing-assembly with more examples and updated guidance.riscos-cport tool to automate parts of the process of porting C projects to RISC OS.indent tool, configured to format RISC OS sources according to project standards.riscos-clitransform tool to riscos-transformcli for consistency.nano-colour support for improved syntax highlighting when viewing files with less.riscos-help with new version and changelog commands for better environment awareness.offset elements, and revision ordering.AGENTS.md file with better guidance on preserving file content and understanding search paths.rootenv to version 1.29.100, addressing a fix for ZM modules.riscos-build-run related to command-line architecture shortcuts.Sun, 10 May 2026 18:28:26 +0000
A good day today.
Selected sprite colouring is improved, the 64-bit build has been added in, and a module created which has SWIs that you can call to do the operations we’re exposing. Pretty nice.
I’ve marked the component as functional now in the RISC OS 64 status pages (https://github.com/gerph/riscos64-status/wiki/Module_W…), and flagged all the completed sections. There’s only a little bit more, but that’s not too significant and can be looked at later. The module’s also released so anyone wanting to try it out can see how it works, etc.
Next week, I’ll be starting putting together the icon rendering. Now, Icon rendering is quite involved – https://github.com/gerph/riscos64-status/wiki/Module_W… shows the many different things we need to do.
And if you look at the post I did a year or so back (https://www.riscosopen.org/forum/forums/5/topics/18886) you can see the ways in which the icons vary. It’s going to be fun.
Basically, we’ll be taking GContext, TextRendering and SpriteRendering and putting them together with some more logic to make general icon rendering. I’ll be demonstrating more of the RISC OS Build Environment’s use, and how the whole system can be made to work in a very powerful way with modern tools. Hopefully, anyhow. As you know, sometimes things go wrong – but that’s what we’re going to try doing!
PDrivers.Sun, 10 May 2026 15:50:36 +0000
Is it interesting or useful to try to compile with the DDE, therefore 32bit version
I’ve compiled 32-bit versions of the modules, just not with the DDE: https://github.com/pwombwell/PDrivers/tree/main/build
But see my comment about *rmkill, etc. https://www.riscosopen.org/forum/forums/13/topics/2040…
PDrivers.Sun, 10 May 2026 15:44:48 +0000
You could try exporting the page from netsurf as a drawfile and print from draw.
Ah ha, yes, that seems to work, thanks. And it’s UTF-8.
For Iris, we decided to simply render to sprite and print that.
Interesting. I can’t really think how you could do it properly for PDF or PostScript given you’re presumably using FreeType – maybe add a new software vector(!).
PDrivers.Sun, 10 May 2026 15:15:55 +0000
I’m going to ask a question that may not have its place in this discussion, if it only concerns 64b versions.
Is it interesting or useful to try to compile with the DDE, therefore 32bit version, the C++ source of PrinterDriver?
Sun, 10 May 2026 15:00:02 +0000
I’ll need a lot more to get proper support
C++, the core language, should only need new/delete, and there’s no reason they can’t just call malloc()/free(). Newer versions of C++ let you force alignment which your malloc library might support, or you might need to pad the blocks out.
You’ll probably need to call the constructors/destructors on global objects, and destructors for static objects (eg. “static MyObject foo;” inside a function). I don’t know how that’s done with g++, but it was pretty easy to figure out for Norcroft C++ with the limited documentation from ARM. Newer versions of the SCL do it for you (I had a problem with drlink so disabled it – I don’t actually have any globals as everything inherits from Module).
https://github.com/pwombwell/PDrivers/blob/main/RLib/O…
I suppose exceptions might need more, but I haven’t investigated exceptions in much detail yet. I know modern compilers use what are effectively debug tables to figure out what to destruct (for zero-cost when there’s no exception). Older compilers, including Norcroft C++, insert code to check for exceptions so will be slower in all cases, but shouldn’t need a support library.
The STL (the large C++ library) will need more work, but without exceptions you can’t use much of the STL – which is why I’ve implemented my own Vector class (where vector is what C++ calls a dynamically resizable array), instead of using an STL-like one.
I’d suggest initially enforcing a no-STL rule, and compiling with -fno-exceptions, and perhaps relax that over time.
PDrivers.Sun, 10 May 2026 12:51:17 +0000
@piers For Iris, we decided to simply render to sprite and print that. This had the side benefit of printing exactly what is on screen which is a common issue for printing from browsers. It’s a slightly ugly solution that isn’t always ideal (and doesn’t plumb-in well to the JS-PDF stuff), but gives decent prints which accurately resemble their on-screen counterparts.
Accessing SFTP servers with SecureViewSun, 10 May 2026 12:04:39 +0000
There’s an updated version of SecureView (v0.05alpha) available here.
See the !Help for what’s changed.
PDrivers.Sun, 10 May 2026 11:46:52 +0000
I can’t get netsurf to print using Acorn’s drivers (I wasted hours assuming the ‘redraw error’ was my bug).
You could try exporting the page from netsurf as a drawfile and print from draw.
PDrivers.Sun, 10 May 2026 11:30:14 +0000
(aside, not to distract from the PDrivers discussion hopefully)
Thanks for the suggestion that using C++ with the standard library might ‘just work’… I compiled a small C++ program for RISC OS 64 last night and – after a little bit of fighting – even got it to link and run. I’ll need a lot more to get proper support, but it’s looking promising as it stands. So ta… I had thought it’d be a very uphill struggle to get anything, but it’s been easier than getting the Fortran to the same point.