ROAST :: 2025

Coming back to RISC OS has been interesting. I’ve had to re-learn a number of things, like using the WIMP and, in particular, graphics programming. I hope this article will be the first of a series explaining my learning curve, and hopefully providing some useful programs. It’s fairly basic — in all senses! — but does assume some familiarity with RISC OS and BBC BASIC.

We’ll start with some things you can do when drawing rectangles. While writing the Solar application I wanted to provide some better backgrounds for the graphs. A plain background is easy, of course: just use RECTANGLE FILL with some appropriate colour, like this.

GCOL 0,&ff,&dd,&ff RECTANGLE FILL 0,0,256

…which draws a 256×256 square at the graphics origin. More generally, RECTANGLE accepts both width and height, which can be negative.

First up, we’ll generate a blend between two colours, from the bottom to the top of the rectangle. We’re assuming a full-colour display here, which is necessary for displaying blends with any fidelity. The Solar application graphs are built up by redirecting all graphics output to a sprite, then letting the Wimp handle displaying them on screen; this takes care of any mismatch between the screen and graph colour depths.
[Read more…]

[Updated 5 Dec 2025. Now includes BASIC FPA timings, and text updated. DIV is now included.]

While writing the Gradgrind program (qv) I wondered if it would benefit from running under BASIC64 (or VI), as opposed to BASIC 5 (V). So I ran up a few simple speed tests (and they are simple — don’t take the results as definitive benchmarks). Although the program runs acceptably fast on my setup (a 4té², which is based on a Pi 4b), it uses a fair amount of real arithmetic. The chief difference between the two versions is that BASIC 5 stores reals in 5 bytes, while BASIC64 uses 8 bytes. BASIC64 itself has two variants, VFP using the vector floating point operations available on the Pi’s ARM processor, and FPA using software floating point.

To use each variant:

• basic <file> Runs <file> using BASIC V. This is also the default setup for double-clicking a BASIC file.
• basic64 <file> Runs <file> under BASIC VI, which will select the VFP variant if available, otherwise uses FPA.
• basicvfp <file> Forces the VFP variant, if available.
• basicfpa <file> Forces the FPA variant.

The program to generate these results is available from the Downloads page.

System details:
R-Comp’s 4té² (based on the Raspberry Pi 4b) running RISC OS 5.31 (21-Jul-24) at 1.5Ghz
BBC BASIC V 1.85 (03 Oct 2022)
BBC BASIC VI 1.85 (03 Oct 2022) VFP
BBC BASIC VI 1.85 (03 Oct 2022) FPA

Notes on the tests

• All tests were run in single-tasking mode (not in a task window).
• Each test (other than the WHILE/REPEAT ones) is enclosed in a FOR…NEXT loop, with the index variable running from 1 to 100,000,000. So they are run 100 million times. This was chosen so that an empty loop runs in about 1 second. Other than tests 3, 4 and 6, the index variable is an integer.
• The description specifies what operation is inside the loop.
• All timings are in seconds with centisecond resolution, other than the total time which is in minutes:seconds.
• The “Assignment a%=long…” tests are done because I often use systematic prefixes for variable names, and I wondered if having many variable names with identical prefixes would slow things up. The testing program defines 300 variables called “VeryLongVariableNameWithIncrementingSuffix001%” to “VeryLongVariableNameWithIncrementingSuffix300%”.

Takeaways

• BASIC VI FPA is slow. If you run the test program be prepared to cook and eat your dinner while it shuffles along. And possibly include a nap.
• I’m puzzled why integer operations under BASIC VI FPA are so slow; I wasn’t expecting these to vary much. Addition, subtraction, multiplication and the DIV operator are about 4 times slower than BASIC V. Using / to divide is even worse, 11 times slower. And even simple integer assignments are about 6 times slower.
• Note that using a real variable as the index in a FOR…NEXT loop in BASIC VI FPA is twenty times slower than BASIC V (and over sixty times slower than BASIC VI VFP).
• Don’t use variables after NEXT; it’s three times slower, and they’re very rarely needed. This can make a considerable difference for nested FOR loops.
• I’ve done both “A%=” and “a%=” assignments to check if so-called ‘resident integer variables’ (A% to Z%) still give a speed benefit. But it seems there’s no advantage now to using them.
  Ancient history note: this feature dates back to the Acorn Atom (my first computer back in 1980 — I soldered it together!), when A-Z were the only variables you had (integer only); if you wanted more you had to use arrays (just AA to ZZ) or indirection. BBC BASIC evolved from Atom BASIC — indeed, you could get it on the Atom as an add-on board — and the resident integer variables on the BBC Micro’s original BASIC were a legacy.
• The long variable name tests don’t appear to make much difference. But it turns out that both versions use a fairly sophisticated caching strategy for variable names, so this isn’t really a valid test. I’d be interested to know if the same strategy is used for procedure/function names (which I haven’t tested here).
• Integer maths is pretty much identical between BASIC V and BASIC VI VFP, with the exception of division which is twice as fast in BASIC VI VFP.
• Simple real maths is faster in BASIC VI VFP than BASIC V, by about 25-30%; again, division is twice as fast. It’s interesting that BASIC VI VFP’s real maths operations are slightly faster than their integer equivalents. Of course, different values may give a different result.
• Square root — a common operation — is three times faster in BASIC VI VFP.
• Avoid exponentiation if you can — it’s a very expensive operation, in all versions.
• I was a bit surprised that BASIC VI VFP’s trig functions weren’t better. Although they are, of course, much more accurate.
• Using += and -= to increment/decrement variables gives a small but useful speed increase, particularly under BASIC VI FPA.

Conclusion

No, it wouldn’t really be worth Gradgrind using BASIC VI VFP. For much of the real arithmetic involved I’ve used pre-calculation, and the speed increase would be minimal.

Downloads

Download the program from the Downloads page.

Gradgrind has been updated to 0.92beta, with new features and a number of important bug fixes.

New features include the ability to import/export GIMP palettes, modify palette files in more ways, and an extra display for the palette.

Download directly, or see the Downloads page for full details of the changes.

Gradgrind is a RISC OS program. It will not run under any other OS.

I’ve been adding a display mode to my solar panel analysis program to show the monthly variation in output. It shows the anomaly in percentage terms against the average output for the month. Here are the results for 2012 to May 2025:

Each vertical line represents a month. The very bad result for April 2016 (the line would extend below the graph) is due to the panels being offline for half the month while our roof was replaced. And May 2025 is bad because only the first 10 days are being counted.

It’s interesting to compare this with the following graph, courtesy of the Met Office:

Source:https://www.metoffic … shine-anomaly-graphs
(Select the “Sunshine” option, and “2024” from the drop-down list.)

This shows the sunshine recorded over the whole country for 2024, broken down into regions. Now 2024 was our worst year so far for the panels — it was even worse than 2012, the so-called “year without a summer”.

Look at the 2024 section in the top graph, and note how the only above-average months, coloured orange, were January, June and December. (And even very good results for winter months make very little difference to the yearly figures — we can generate more power in one summer day than the whole of December or January).

Now look at the lower graph, the England results (also in orange). The figures here — remembering they’re for the whole country — are in pretty good agreement, with January and June being the only above-average results in the first half of the year. They disagree about August, which was slightly above average, and December, which was well down for England as a whole. We did better here in Yorkshire, about 9% above average.

About WebP

WebP — capitalised thusly — is a graphics format developed by Google intended as a replacement for JPEG, PNG and GIF formats; most modern browsers can handle WebP images. The format supports both lossy and lossless compression, as well as animation and an alpha channel. WebP files may contain metadata (in ICCP, EXIF or XMP formats) such as a thumbnail image and technical details such as the camera settings used.

WebP was first fully released in 2018, and since then has been getting progressively more widespread on the web. It claims to have various advantages over previous formats, chiefly in reduced file size (though there is criticism regarding fidelity). The following table shows how its usage on the web has been increasing, expressed as the percentage of websites which use the format:

[Source: https://w3techs.com/ … w/image_format/all/y ]

WebP on RISC OS

The WebP format is now fairly well supported on RISC OS, at least for still images. PhotoDesk (3.23) can load and save them, and there are the free stand-alone conversion applications Spr2WebP and WebP2Spr courtesy of Richard Coleman, who did the hard work — see Links section below. It’s also been reported that the RISC OS port of ImageMagick 7 can be used to convert WebP files to and from sprites.

RISC OS web browsers which can render static WebP images include NetSurf and Iris.

Animation support is much more limited. As far as I know no-one has ported Google’s img2webp to RISC OS; this can produce animations from a sequence of still images. There are however various online converters.

On RISC OS, the Iris browser can render animated WebP files, but NetSurf can’t.

WebP files have an official filetype of &a66, with type name WebP. The extension is “filename.webp”, and the details should be included in your mimemap file. To check:

• Open a task window (Ctrl-F12)
• Type:

  mimemap webp

  If you see the message “No MIME mapping found” you need to add it as follows:

• Type:

  filer_run inetdbase:mimemap

• Your system’s mimemap should open in an editor window
• Look for the “image”+”IANA registered” section, and add the following line (the gaps are tabs):

  image/webp	WebP	a66	.webp

• Save the file; the setting will take effect after the next boot

Examples

I’m using a couple of images to demonstrate WebP. The flowers picture is a 1280×1280 detail from a photo taken in Zambia by a Canon Ixus, so originally a JPEG. The screengrab image (732×714, 24-bit RGB) is from my in-progress app for reporting on our solar panel installation. These were saved as sprites (which is lossless, of course), and then converted into various formats using various apps and settings.

NB: The images below (in WebP format — if you can’t see them your browser doesn’t support the format) are not the actual images used, they’ve been resized and are just for reference. You can download the original sprite files in the Links section below.

File sizes for flowers image Format Size (bytes) Sprite 6,553,656 JPEG (90) 346,795 JPEG (75) 190,146 WebP (Photo) 105,760 WebP (Lossless) 1,632,468 PNG (Paint/Spr2Png) 2,112,447 PNG (PhotoDeskA) 6,566,686 PNG (PhotoDeskB) 3,053,488	File sizes for screengrab image Format Size (bytes) Sprite 2,090,648 JPEG (90) 164,906 JPEG (75) 117,820 WebP (Picture) 45,638 WebP (Drawing) 47,360 PNG (Paint/Spr2Png) 73,579 PNG (PhotoDeskA) 2,095,393 PNG (PhotoDeskB) 117,389

The WebP conversions were done with Spr2Webp, using the settings of Photo and Lossless (for the flowers) and Picture and Drawing (the screengrab). You can also use PhotoDesk, but this uses the same code as Spr2Web so the sizes are pretty much identical. Lossless takes longer (but you’ll usually only need to do it once).

The JPEGs were done with Paint, with the quality settings in parentheses.

The PNGs of the flowers are provided for interest only, as you wouldn’t normally save a photo in this format. Paint and Spr2Png produce identical output, with compression set to 9 in both cases. Paint uses RISC OS’ internal PNG library, while Spr2Png has its own converter.

Of more interest are the PNG entries for PhotoDesk. The first, labelled “PhotoDeskA”, uses the default settings when saving a PNG from PhotoDesk, and they are actually larger than the sprite, possibly due to being interlaced. The second (”PhotoDeskB”) has the settings tweaked. This isn’t straightforward, as the save box doesn’t include any options to change parameters. You have to shift-click on the !PhotoDesk app to open it, then on “Resources”, then on “Formats”, then shift-click on “!3PNG”. Open the directory “Options”, then load “spr2png” which should contain just the text “-ia” (without the quotes). Change this to “-ia9” — the “9” increases compression — and save. Doing this improves the compression markedly, though still not as good as Spr2Png. You could probably improve things more by modifying the options; PhotoDesk’s PNG library is very similar to that used by Spr2Png. Or more simply, as PhotoDesk appears to perform negative compression on PNGs, save as a sprite and drop the icon on Spr2Png. Or load it into Paint and save as a PNG from there.

Summary

It’s quite hard to see much visual difference between these images, with the exception of the JPEG (75) version of the screengrab, where artefacts are visible in colour transitions.

For photographs, WebP in Photo mode is the most efficient, for both lossy (JPEG equivalent) and lossless transmission/storage.

For line drawings or screengrabs use WebP with Picture or Drawing presets.

If you need maximum portability under RISC OS, especially legacy versions, JPEG and PNG are still the best options.

Links

WebP on Google, on Wikipedia
Richard Coleman’s conversion apps (webp2spr, spr2webp and webpinfo, along with desktop front ends)
Darren Salt’s Spr2Png and Png2Spr apps
PhotoDesk is available via the !Store app
Example images as used above (4Mb zipped sprites)

The Gradgrind palette editor for RISC OS has been updated, with a minor bug fix for hex display of colour values.

Download link: Gradgrind 0.91 beta (326k)

We’ve had solar panels for nearly 14 years now, and the output has been reported daily on our site. The page is currently generated by a Python program running on a Raspberry Pi (a Pi400 at the moment), but I’ve been working on a version running under RISC OS, using BBC BASIC. Here are some samples of the output:

It’s unfinished as yet, but work continues slowly…

Introduction

As the Met Office is discontinuing their DataPoint service in late 2025, we’ve recently been converting our weather forecasts page to use DataHub, the replacement service. This provides forecasts in GeoJSON format, and gives much more information and better global coverage than DataPoint did. Here we’ll describe how to access the forecasts from a Raspberry Pi, using Python.

Registering

Like DataPoint, DataHub is mostly free for non-commercial and non-bulk usage. Various types of data are available, and we’re using the global spot 3-hour site-specific forecast. This is free providing you access it fewer than 360 times per day.
DataHub requires you to register, whereupon you’ll be given an api-key. This is a string of characters, and is very long! Over 1600 characters, in our case. Store this somewhere secure and safe.

Getting some data

[Read more…]

Gradgrind is a palette generator which takes particular care to create smooth blends between colours. The palettes are generated by curve-fitting rather than linear interpolation (using Catmull-Rom splines, if you’re interested), and can be created and saved as script files as well as edited interactively.

It can create greyscale palettes, which can be particularly useful when loaded into PhotoDesk and used as displacement maps or effect gradients. PhotoDesk can only generate linear blends, which can give visible artefacts, discontinuities and banding.

The program comes with full documentation and example gradient scripts.

Gradgrind is a RISC OS program. It will not run under any other OS.

This is a beta version, 0.90. It was written and developed under RISC OS 5.31. Prior versions of the OS may work; feedback is appreciated.

Download link: Gradgrind 0.90 beta (325k)