Pyromaniac

Examples

Example files

During the course of development, I produced a number of examples of the tool in use. Some of these are provided here. They are at varying stages of the development of Pyromaniac, although the version number and release date appear on some which may help to identify when they are from.

2020 examples

Building the RISC OS Kernel on macOS

[Asciinema!]
(Asciinema)
An example of the cross-compiling tools running within my CI environment.
This shows the build running for the RISC OS Kernel, on macOS. The process of building is split up into stages:
  • determine what is being built from CI
  • setup up the environment variables for this build
  • download and extract the tools needed for the build (from Artifactory)
  • run the riscos-amu build
  • archive the results
  • upload the archive to Artifactory (when requested)

Running BASIC on macOS

[Asciinema!]
(Asciinema)
BASIC running a few commands very early on.
This demonstrates that SWI calls work, and that the system knows about a few memory regions.

Running BASIC with modules

[Asciinema!]
(Asciinema)
BASIC a month later, with modules present, system banner, and the beginnings of networking.
We now have some more modules working, as well as the Shared C Library. Network works to the point that we can send packets. Quite a few *-commands work now. Console output is converted from Latin-1 to UTF-8 before output.

ANSIText coloured output

[Asciinema!]
(Asciinema)
ANSIText, converting RISC OS VDU sequences to ANSI terminal sequences.
The RISC OS colour selection operations are translated by the 'ansitext' implementation into terminal control codes.

Freeway works

[Asciinema!]
(Asciinema)
Freeway is now running and is able to communicate with its counterpart on another virtualised system.
Here, the system is running on a machine called 'Laputa'. By the time the *FWShow command is issued, Freeway has broadcast its information to other machines on the network and received responses. The command shows that the system has received the registration from the remote machine 'WinRPCEmu' (a RISC OS system running under RPCEmu on Windows). Although it's not visible here, the RPCEmu system happily sees the registration from 'Laputa' as well.
There's a gap in the recording which wasn't intentional - I didn't really need to pause for the module to work.

Snake in a console window

[Asciinema!]
(Asciinema)
ANSIText works well enough to be able to play Snake from INPUT magazine.
Cursor movement is now translated properly into the terminal control codes by the ANSIText VDU implementation. The program was only slightly modified to run on RISC OS - the original program was designed for a BBC.

OS_GBPB through sed

[Asciinema!]
(Asciinema)
OS_GBPB works, and C programs run.
Being able to run 'sed' means that the multi-byte file operations are working well enough that the C library can read buffered files properly. It's not an amazing demonstration, but it shows that the C library is now working well enough to be useful.

TWIN called from BASIC

[Asciinema!]
(Asciinema)
TWIN runs from within BASIC.
'TWIN' is a BASIC command which invokes the TWIN module to edit the BASIC program. Pyromaniac has its own implementation of TWIN which is incredibly simple - it just invokes a host command on the file, and then waits for it to return.
You'll find the source to the TWIN module in the example code on this page.

CLI aliases

[Asciinema!]
(Asciinema)
Aliases work at the command line.
Aliases are expanded from the system variables, and have to support the same abbreviation rules that the regular commands do. These are shown to work here - and the fact that aliases containing multiple commands are executed, too.

Tracing execution

[Asciinema!]
(Asciinema)
Using the tracing functions to trace the execution of a utility.
This demonstrates that the instruction tracing works - it's also showing how some of the instructions used to appear - LDM instead of LDMIA, LSR instead of MOV ..., LSR. These are Capstone's disassembly features.

Lots of modules

[Asciinema!]
(Asciinema)
One of the early attempts to just throw as many modules as possible at the system.
There are 217 modules present, although the first few are from Pyromaniac itself and many reported errors on initialisation.

Early example of JFPatch

[Asciinema!]
(Asciinema)
An early example of JFPatch running inside a docker container.
With Pyromaniac and JFPatch in a docker container, it's possible to put together a simple command line which is able to run Pyromaniac inside the container, with the current directory mounted, and then invoke JFPatch on the file that was supplied. Effectively allowing JFPatch to be run from macOS command line.

Network connections

[Asciinema!]
(Asciinema)
Network interface enumeration, and network connections using IPv4 and IPv6 work.
Demonstrates the mapping of the host interfaces to those that can be used by RISC OS. The stack provides IPv4 and IPv6 access to the system. The ifconfig tool was modified slightly to add support for reading the information about the IPv6 addresses - and to use SIOCGIFCONF better. The test command has some hard-coded IPv4 and IPv6 addresses in it which it will communicate with - at present there is not Resolver support for IPv6 addresses.

RAMFS and low-vector watches

[Asciinema!]
(Asciinema)
RAMFS initialisation, showing that it worked, but it did access the low vector area, triggering the watchpoints.
This example demonstrates loading FileSwitch, FileCore and RAMFS modules and then resizing the RAM disc to have some memory set aside. In doing so, it triggers a bug in FileSwitch, caused by the register for the special field being dereferenced even though it was invalid. This bug was fixed using the reported information.

Faking Git

[Asciinema!]
(Asciinema)
Experiments with running the host git tool through the Host command can make it look like you're running the command directly.
The command line shows exactly what commands are being used ('*PyromaniacHostCommand ...') but it looks like you're running git on RISC OS. Kinda. The git command is using the terminal control sequences, which the PyromaniacHostCommand implementation turns into the relevant VDU control codes on RISC OS to change colours. The VDU implementation is ANSIText, which then converts those VDU control codes back to the correct terminal control sequences. Thus, the colour that was output by the host git command changes the RISC OS state, and is then output in the right way for the terminal to have colour. The later PyromaniacGit module provides similar operation but is even more integrated to hide the host system.

ErrorCancel module

[Asciinema!]
(Asciinema)
Rick Murray's ErrorCancel module waits for an error box to turn and then clears it by pressing Escape.
It works with the Pyromaniac implementation of the error box. The Pyromaniac error box actually has a few implementations - one that does nothing, one that outputs the message to the screen like you see here, and one that uses the Python EasyGUI package to give you a desktop error box.

CObey crash

[Asciinema!]
(Asciinema)
Julie Stamp's COBey module running under Pyromaniac.
I tested it with Pyromaniac and Fortify and found that it freed the stack underneath it - triggering a Pyromaniac exception report. It's actually not that exciting, but it's useful to see that an exception in real code (not just tests) can be traced through Pyromaniac.

Drawfile rendering

[Image]
(Video)
15 year old Drawfile being drawn.
My brother and I draw a replica of the 'More Than Meets The Eye' album cover, back when we were at school. The Pyromanic Draw renderer copes just fine with it. The video shows the image being built up. There is some significant banding as this is rendered in a 256 colour mode. Although Cairo is actually using 24bit, Pyromaniac is only using the 256 colours from the standard palette.,

BootMenu

[Image]
(Video)
BootMenu working with FontManager.
RISC OS Boot menu running on Pyromaniac using a very heavily hacked together Pyromaniac FontManager. After this work, the FontManager was significantly reworked, but this was one of the first applications demonstrated to work with the FontManager.

Wimp experiment

[Image]
(Full size image)
Very hacky and experimental opening of windows through the Wimp.
An experimental Pyromaniac Window Manager is able to load template files, and open windows. The icons aren't right - the only flags for icons that are supported are the border and the alignment.
Demonstrates that the windows can be created, although you can't do anything with them and it is only CreateWindow/OpenWindow that work right now. Alphabet is honoured in the text strings, though.

MacOS application

[Image]
(Video)
The macOS application demonstrates the graphics UI and input.
Pyromaniac running as a macOS application, running an old maze game from INPUT magazine.
Demonstrates the VDU23 characters, and uses INKEY$() to input characters with a delay. Also shows a vertical off-by one error in the rendering in places.

Font_Paint, showing UTF-8

[Image]
(Full size image)
A BASIC program to plot a string in a given encoding.
Demonstrates that the encoding selection is working, and is able to show a UTF-8 character.

Font_Paint, with macOS fonts

[Image]
(Video)
Listing the RISC OS font (taken from the host).
A Video showing the rendering of all the fonts known to the FontManager, using a small BASIC program.
This was run on macOS, so all the macOS fonts, and extra ones that I have installed, are shown here. Some fonts are not very useful, and just appear as boxes.

Rendering with the classic Draw module

[Image]
(Full size image)
Classic Draw module renders a DrawFile with some glitches.
An old DrawFile, showing the 'Center Parcs' logo, being rendered by the Classic Draw module, with the Pyromaniac graphics implementation configured to be SVG.
When the Draw module renders its shapes, it uses the horizontal line routine. This call only takes a pair of x-coordinates and a y-coordinate and draws a line between them. When used with the SVG renderer, however, we can see h-line in operation.
The large horizontal lines are an artifact of the Pyromaniac rendering - Draw produces very large x-coordinates when a shape goes off the screen. So much so that when Pyromaniac processed it, they became negative, which caused that ugly line.

Running on Windows

[Image]
(Full size image)
Using CrossOver, a Wine derivative for macOS, Pyromaniac runs as a Windows application.
It's not a very exciting demonstration, other than that it functions. It is amusing that this is running RISC OS by emulating the system calls through Python and wxWidgets, which was built for Windows and is communicating with macOS through emulated Windows interfaces.

Font rendering with Pyromaniac

[Image]
(Full size image)
Font_ScanString works well enough to wrap text.
Using my ancient 'bubble' library to render some text into a region. The text is sized using Font_ScanString to wrap it into the space supplied. The bubble is rendered using Draw_Stroke and Draw_Fill.

Font rendering with classic FontManager

[Image]
(Full size image)
Classic FontManager doesn't look quite so nice without anti-aliasing.
The same code, but this time using the Classic FontManager. Because we don't support sprites at present, this was rendered with the FontMax settings set to 0. Interestingly it shows up a problem with the prior image - the font selected here is oblique. It should have been oblique in the prior example; this was an early bug.

JPEG_PlotTransformed

[Image]
(Full size image)
A JPEG, being rendered with a call to JPEG_PlotTransformed.
The transformation matrix is not a simple scaling, and thus produces the skew effect you see. The Classic SpriteExtend does not support transformed JPEGs, but because the Cairo rendering system just plots what it's been given with whatever matrix you supply, rendering an image at an angle isn't a big deal.

Classic Wimp with Pyromaniac fonts

[Image]
(Full size image)
Displaying an error message with the Classic Window Manager.
This is about all that the Classic Window Manager can do. The Pyromaniac FontManager is in use, which is why there are two squares before the text strings. The Window Manager uses the control codes for 'select font' and the font number at the start of the strings, and Pyromaniac's FontManager doesn't handle those control codes yet.

Classic Hourglass

[Image]
(Video)
Using the Classic hourglass module with Pyromaniac.
Demonstrates the pointer shape programming and the hourglass shape.
The hourglass is very large because that's the size of the desktop pointer on my machine. You may notice that the active point isn't set correctly in this video; the setting wasn't working in WxWidgets when I recorded this.

BBC Game Explode

[Image]
(Video)
A game I wrote for the BBC, back when I was 16.
The 'AI' convincingly beats me.
Demonstrates the use of VDU 23 programmed characters again, and keyboard input using INKEY() negative numbers. Italic text achieved by reading the character definitions, shifting bits and reprogramming.

First tune through WaveSynth

[Sound]
(Audio)
The first working tune played through WaveSynth.
The sound system ('SOUND', handled by SoundChannels) usually plays sound through MIDI in Pyromaniac. However, in an experimental branch, the sound system can play sound using the PCM system, by loading the SoundChannels module and whatever voices are required. When this first started working, the example 'Hall Of The Mountain King' program was used to test that it worked as well as the MIDI version.
The sound isn't quite right; there's an annoying clicking in it, which is caused by the sample buffer not having a length which is a multiple of 4. I didn't realise that this was a requirement at the time, but I was very pleased that the first time I tried playing a tune it came out recognisably, and in the right pitch. The repeated note at the end would have been a sustain on the BBC, but doesn't have that effect on RISC OS.
The current version of the experimental branch plays this smoothly without glitches.
This was actually the second time I'd tried to play the tune - the first time was horribly distorted. I'd got the mu-law-to-linear conversion wrong - the values for 16bit sound are -32768 to 32767, but I was mapping to -65536 to 65535, which meant that they clipped and distorted really badly.

Application: On macOS

[Image]
(Full size image) MacOS 10.14 is the primary development environment for RISC OS Pyromaniac. The screenshot just shows the application runs, together with the terminal which launched the application.

Application: On Windows (via Wine, on macOS)

[Image]
(Full size image) Although Windows development environments are available for VMs, largely testing is done though CrossOver (a Wine derived product). Although there will always be some edge cases where the VM with real Windows is necessary, it is simpler to run tests under the Wine environment.
This has the interesting result that RISC OS interfaces are implemented in Python, which runs on a Python compiled for Windows, but which uses interfaces implemented for macOS.

Application: On Linux (via VNC to a local docker image, on macOS)

[Image]
(Full size image) Running on Linux in desktop in this image is achieved by connecting to a VNC session which is exporting the Linux desktop from a Docker container. The docker container is running the RISC OS Pyromaniac application, but the docker console works just like native.
This is as convoluted as the Windows example, because this is running on macOS. macOS implements Docker by running a Virtual Machine to run the Linux OS underneath. So actually we have RISC OS implemented in Python, executing in a container on Linux, which has been virtualised on a macOS machine to make it look like a native command line tool.

2021 examples

WindowManager runs with Iconbar

[Image]
(Full size image)
Early test of the WindowManager with iconbar working.

A simple BASIC application runs and creates an icon on the iconbar. The text in the icon is meant to be 'Test' but the FontManager is not stripping the control codes and therefore is including some squares where they appear. It's also visible outside the icon's bounds, showing how the graphics window isn't enforced yet.

Just getting a BASIC application to start as the only application was a challenge. The WindowManager happily takes away all its memory, leaving the system in a very bad state. A small update to the WindowManager code was necessary to not destroy the application that was running.

Filer window opens, unsorted

[Image]
(Full size image)
Filer works but isn't sorting files.

The Filer has managed to read the entire directory but hasn't sorted the resulting files, so they're in a random order. This is because the OSSWIs module which provides OS_HeapSort isn't loaded.

Although the window furniture has been drawn, the font that's being used is still the Homerton equivalent. So instead of using the WIMPSymbol characters, we have some odd characters in place of the back, toggle size and scroll buttons.

Filer window opens, sorted

[Image]
(Full size image)
Filer works and is now sorting properly.

Merely loading the OSSWIs module was all that was needed to get the window sorted properly. The FontManager has also been updated to strip the control codes. This at least makes the text more readable, and the window furniture less noisy - although it's still wrong.

MessageTrans_MakeMenus works

[Image]
(Full size image)
Pinboard creates its menus using MessageTrans.

The implementation of MessageTrans_MakeMenus meant that some of the desktop applications could begin to work. Here, Pinboard's menu is clearly working and icons hare shaded appropriately. The submenu icons don't appear because they would be sprites, which aren't implemented yet.

It's also possible to see the extra test on the iconbar - the icons that are created now truncate at the edge of the icon. This means that the graphics window is used when they're drawn.

TaskManager runs and can show custom acknowledgements

[Image]
(Full size image)
Pyromaniac's acknowledgements service works.

TaskManager has started, and although it's not visible on the Iconbar because sprites aren't supported, the window redraws properly and the acknowledgements window is working. Pyromaniac itself responds to the service request for the acknowledgement information alongside the response from TaskManager.

In the TaskManager itself it's possible to see that the areas for the Font cache and the RAM disc are greyed out, because the dynamic areas don't exist on this system. Similarly the 'Applications (free)' is greyed out because there is no free pool.

Sprites begin working in the desktop

[Image]
(Full size image)
Sprites are rendered for the tools and icons.

This was one of the earliest sprite renderings that started working. Most of the sprites are using the standard palette for the mode they were defined in, rather than their own palettes. This is why the furniture icons appear in reds, greens and yellows - they're defined in a 16 colour mode which has primary colours in its default palette. The sprite should be using a more greyscale palette.

It's also possible to see that the sprite mask isn't supported yet. The areas that should be masked in the Filer icons have random colours showing through.

Sprites are now using the correct palette

[Image]
(Full size image)
Window furniture now comes out in greys.

The pixel translation tables are now being used properly with the sprite's own palette being used correctly.

Also visible is the TaskManager menu, which has a square where the 'shift' up arrow should be. Without the ability to switch to a different font, it isn't rendered properly. The RISC OS Select text in the information window is also just using the regular font. The control characters that would select a bigger, bold font, are just being stripped - they're not honoured yet.

Sprite masks are working, and alpha sprites

[Image]
(Full size image)
Filer icons are now masked and the submenus and ticks work.

The Filer icons are masked, and they can be seen to not have any rogue colours showing through. The same is true for the !Draw application on the desktop. The submenu icon and the tick icon are both alpha channel sprites, with their edges blending to the background they are on.

The shadow under the pencil really should have been turned into an alpho channel mask at like 50% or something to make it look better on the Pinboard, but that wasnever done in the Select times.

The top menu icon is where the pointer is over. Floating over a menu item should highlight it, but the redraw doesn't work properly at the moment - it's meant to use EOR plotting, but that isn't supported.

Using the desktop video (January 2021)

[Image]
(Video)
Some desktop modules working as a video.

The video is recorded through the built in Cairo frame recording system. This is approximately the speed it therefore ran at. There is a lot of debug going on in the background which is slowing down the operations.

That said, Pinboard's background redraws quickly, and the TaskManager is reasonable in its redraw. All the actions are being triggered by key presses. The test application has a poll idle handler which checks for keys held down and starts different actions based on that.

The Filer, for example, has its window opened by a key press, as there are no iconbar filers to click on. The start of the Pinboard and TaskManager was also triggered by a key press at the start of the video.

Changing the Filer display mode to 'small icons' shows up a problem with the font rendering in the window. There are actually multiple bugs. The highlighted icon sets some flags that the Filer doesn't like which prevent it rendering the following text properly, and in any case the background for that text isn't rendered at all. When deselected, it looks ok.

Various other interfaces are exposed here - the OS_ConvertFixedFileSize SWI produced the file sizes, the OS_FSControl SWI calls to convert the filetype to a name is used for the regular files in the directory. And the OS_ConvertStandardDateAndTime calls show the dates.

The demo goes all the way through to the shutdown banner and then turns the machine off, at which point the video obviously stops.

Comparison of Font_Paint with RISC OS Classic

[Image]
(Full size image)
RPCEmu (left) and Pyromaniac (right) show the same ouptut.

Getting a working control code parse was tricky. The fonts were always going to be slightly different, but getting the effects produced to do the same thing as Classic was quite important. Here we can see the same test program run on both RPCEmu running RISCOS Classic, and Pyromaniac using its native font system.

The only significant difference is how far the fonts are justified which is entirely down to the different metrics used by the native sans serif font compared to the Homerton font.

FontManager's correct control code parser

[Image]
(Full size image)
Re-written control code parser works very well to keep the same style.

The re-written parser can now handle everything you throw at it, including the underlined text with inter-character spacing.

RailPro runs with correct colours

[Image]
(Full size image)
RailPro had problems with colours early on, but not here.

Many of the early tests of RailPro had problems with the background colours and some of the text colour selection was very poor. Here, though the colours have come out right and the game is looking pretty much how you would expect. It's even been playable enough that I've got 2 trains into their platforms.

*ScreenSave very nearly works

[Image]
(Full size image)
Comparing a screen saved by Pyromaniac to one loaded in RISC OS Classic.

RPCEmu is on the left, showing a previously saved screen in !Paint. Pyromaniac is on the right, showing what it should look like. There are also lines of sprite rendering debug output shown in the top right.

Although it's only possible to save the screen from Pyromaniac when there is a bitmap buffer to be able to save from, that will commonly be the case. However, it is still necessary to convert from the 24bit colour used by Cairo to the format used by the RISC OS mode. In this example the upper rows of sprites have failed the save properly.

The reason they didn't save the top two rows of cogs properly is in how they were plotted. The lower 2 example rows plot the cogs with regular plot operations, but the upper two use 50% transparency. Because that means that the colours Cairo has used in the frame buffer from that blend aren't exactly those in the palette, the colour number has been set to 0 - black. This was easily fixed by searching for the closest colour when saving.

Floating keyboard LEDs window

[Image]
(Video)
Debugging the LEDs window on shows they almost work.

I wanted to make sure that the keyboard LED state was being passed around properly - mostly just for consistency. A simple window in WxWidgets can show the state of these icons with a little light. This means passing it through the RISC OS KeyV status notifications, and then picking it up to display in the interface.

This video shows the caps lock key being pressed and the light coming on. It then shows what happens when you press the scroll lock key - it flashes up the brightness control on macOS! But Caps lock works, and the debug shows the keys being pressed and the status updated.

The three LEDs are Caps Lock, Scroll Lock and Num Lock. However in WxWidgets on macOS only the Caps Lock is triggerable.

As an aside you can also see the text cursor flashing in this example.

Filling the screen with tiled cogs

[Image]
(Full size image)
Plotting tiled sprites is much more efficient.

The tiled sprite plotting means only doing a single plot call which then fills the graphics window with the sprite. It might be a little hard to see, but in the bottom left there are two red squares. These show the top right and bottom left corners of the place where the single plot was placed.

Desktop background sprite now tiles

[Image]
(Full size image)
The WindowManager uses the tiled sprite plotting for the background image.

The primary reason for creating the tiled plotting sprite call was so that the WindowManager could more efficiently fill the background. This had originated in the work that was done by John Kortink on ViewFinder. He has patched the tiled plotting for the WindowManager to make rendering much faster. As it shouldn't be necessary to patch the system to trap the operation, the new OS_SpriteOp call for tiling was added.

Desktop tiling, but in a 16 million colour mode

[Image]
(Full size image)
Same as above, but this time in 16 million colours.

Using the desktop video (July 2021)

[Image]
(Video)
Entering the desktop to demonstrate modules.

This video demonstrates entering and using the desktop from boot. Unlike the earlier video, there is no BASIC application to load modules and start operations. Instead we're using the proper Desktop module and tasks are starting in the normal way.

The desktop is started with a *Desktop -file command to run some predefined commands to set up some system variables and configure Pinboard. The usual desktop banner appears relatively quickly. The banner itself is a Squash'd sprite which is decompressed to be drawn. This uses the Pyromaniac Squash module to decompress much faster than it would with the ARM version.

Clock and a Filer window are shown. The clock is coming out wrongly - the hands don't look right. I'm not sure what's up with them, but it's almost certainly related to one of the graphics operations being wrong. It's not been high on my list to fix just yet. The hands also leave trails because the inversion system doesn't work in this version.

As before, TaskManager shows the system is working, and we can see the Select text in the information window is now correctly sized. Menus still don't invert their selections properly when you float over them though.

Shutdown still works, but the final shutdown banner has a sprite in it.

Breakdown of the tests (July 2021)

[Image]
(Full size image)
Charting the areas that the test system covers.

To ensure that I have visibility of the areas which are exercised by the tests, each test file has markers which show what they are intended to tests. These markers are useful for manually checking what the tests are, but largely they're so that my tool can build this chart.

The chart groups the tests into the different test classes and types, and shows the system and the component within the system which is exercised. In theory it should be easy to spot any areas that have no testing because they aren't even listed.

In practice however, spotting that something isn't in a list is hard. And similarly, trying to categorise what's actually being tested in a given case isn't always easy. For example, there's no 'Networking' system listed, because the tests that exercise it are listed under 'Extension modules'. That's probably a bad categorisation because 'Extension modules' isn't a part of the system (except in the sense of 'can we use them, and that's under 'modules').

Pyromaniac hourglass with a percentage and bar

[Image]
(Video)
Hourglass implementation now provides feedback on percentages through a number and bar.

The video shows the hourglass percentage works with the built in module. This has caused the hourglass itself to be a little smaller because the standard pointer implementation does not allow pointers larger than 32 pixels.

The text is actually a little small for real use - it only works well for me because the pointer is configured larger on the host system.

FontManager menus for the standard fonts

[Image]
(Full size image)
FontManager_ListFonts can now create a menu.

The Font menus created by FontManager are created by the same interface that enumerates fonts. The manner in which it is created is a little awkward as there are two sets of buffers - one for the menu data and one for the indirected string data. These are constructed separately.

The Classic FontManager actually creates a larger block than it needs to. It sets aside space for the submenus on fonts that only have one top level item, and never removes it. This results in some menus requiring more space than they need to. The Pyromaniac FontManager doesn't do this, so the space will be smaller. Nobody will care because the difference will be pretty minor.

FontManager menus for all the host fonts

[Image]
(Full size image)
Host fonts are given mostly sensible names but sometimes there just isn't the information needed.

The large list of fonts on my macOS system are converted to RISC OS names. Sometimes that means they look nice and other times they're not quite so friendly.

Here we can see that the Optima font has pretty sensible names, but the Novarese font above it has variants that aren't given as nice names.

FontManager menus work in !Draw

[Image]
(Full size image)
Having selected Novarese, !Draw shows the font menu in situ.

The !Draw application can use the Font menus that have been created. Font_DecodeMenu works as well, allowing the Novarese Italic font to be selected here. The ticks aren't being displayed properly on the menu at this point, and the font is not being sized properly by !Draw.

Draw rotates text

[Image]
(Full size image)
Draw can rotate the text.

Plot actions partially work in menus

[Image]
(Full size image)
Menus invert the entries as you float over them.

The plot actions only work for the EOR and inversion operations, but they're not the same as on RISC OS Classic because the colours in the paletted modes don't invert the same way due to the actual display being 24 bit. It's good enough for these menus.

Edit with fonts in colour

[Image]
(Full size image)
The Font selection and rendering works in Edit.

Draw colour selection

[Image]
(Full size image)
ColourPicker works with Draw to allow shapes to be filled..

Paint loads sprite files

[Image]
(Full size image)
Sprites can be rendered scaled in Paint and the colours work properly.

Maestro loads and renders tunes

[Image]
(Full size image)
Maestro's redraw is almost entirely sprites.

Maestro takes a noticeable time to load files because it reads individual bytes using OS_BGet, which makes it much slower than if it had read data through a buffer. But once running, it's pretty responsive.

Maestro plays 'It's a long way to Tipperary'

[Image]
(Video)
Redraw and scheduled notes all working.

Maestro's playback scrolls with the music, so that it keeps time with what's being played. Because the redraw itself takes time this can mean that it could fall behind if the redraw took longer than a bar. But for this, and many other files, it plays just fine.

Desktop rendered as an SVG

[Image]
(Full size image)
Cairo renders to a vector just as easily as to a bitmap.

Using an SVG as the rendering system isn't the most practical of systems, but it's surprisingly effective here. The SVG it produces will never be especially efficient as sprites will be repeated and lines will be drawn as individual paths. But the result is still a vector - zoom in and your fonts are still font-y.

The Great Escape (image)

[Image]
(Full size image)
Reverse engineered Spectrum game ported to RISC OS, running on macOS.

David Thomas' reverse engineered version of The Great Escape runs well on RISC OS Classic. Here it's running on RISC OS Pyromaniac. It's a little slow in places, but generally it seems pretty reasonable. It is rather impressive to me that it works this well. I did have to implement the TimerMod module so that it would run at all, but it's really nice to see a game running.

The Great Escape (video)

[Image]
(Video)
"Video or it didn't happen!" cried the masses.

The video starts from the machine booting. We open the release of The Great Escape and run it. It starts up really easily and you can set the keys. In the video I demonstrate that I can walk outside relatively easily, and then demonstrate that I don't know what I'm doing and get caught by the guards.

Using the menu, we can go to full screen, which works just fine. And then return to the desktop.

Using the desktop video (October 2021)

[Image]
(Video)
Desktop is pretty much working for simple things.

This video shows the state of the desktop. It demonstrates Edit running and being used to input text. It shows Draw rendering a complex DrawFile - slowly because Draw uses FP operations for its transformations.

We have MineHunt showing that a desktop game with lots of sprites works. The Great Escape runs and it is briefly shown being played. Fireworkz is started up, and loads fine. Trying to create a document gives an error - there's something up in the handling of the heap, but it's non-fatal here.

Once the document is opened in Fireworkz, some text is entered. The redraw of the fonts appears to be overlaid - probably because of the anti-aliasing being a blended effect, which it isn't expecting. The caret also redraws a little wrongly - something about the plot actions must be wrong.

There are a couple of extra redraws of the ruler and buttons that seem odd, but they are probably related more to the application than to RISC OS Pyromaniac. The italic font and size selection works just fine.

Finally we shut down - and the heap error turns up again.

ColourTrans HSV conversion works

[Image]
(Full size image)
Pinboard uses the HSV option on its gradient backdrop.

The ColourTrans HSV conversion SWIs are used by Pinboard to allow the rainbow effect on the backdrop. Usually you wouldn't use it with quite this brightness - it's a little garish.

Display manager shows the built in graphics modes

[Image]
(Full size image)
Graphics modes are enumerated from the numbered modes in Display Manager.

On RISC OS Classic the modes that are available are provided by the ScreenModes module, using a simple service. It's not the best interface but it works well enough. RISC OS Pyromaniac can provide results through this service which are taken from the numbered screen modes.

As there are no (practical) hardware restrictions in place on the system, there's no need to worry about the amount of 'memory' used by the modes, or their bandwidth requirements. In any case the memory is never RISC OS memory.

RISC OS Pyromaniac also supports reporting a single display device through the multi-display interface. Display Manager can show this as well, although it's not visible here.

Full system demo video (2021)

[Image]
(Video)
Presentation of the Desktop, showing the changes to Pyromaniac in 2021.

The 2021 presentation to ROUGOL included a system demonstation. The presentation overran and I had to cut part of the demo out. The full presentation of that demonstation has been recorded and can be viewed separately here.

Documentation: Comparison of documentation styles

[pdf]
Download

PDF showing the different styles of manuals that Acorn produced over the years, and similar styles generated by the PRM-in-XML transformation process. This gallery is itself created through PRM-in-XML.

[zip]
Download

Zip archive of the source and generated HTML for the comparison gallery.

Documentation: Example PRM-in-XML document

[pdf]
Download

PDF generated from parts of the PRM-in-XML project, for a sample of the parts of the networking system.

Documentation: Example PRM-in-XML document (RISC OS 2 style)

[pdf]
Download

PDF generated from parts of the PRM-in-XML project, for a sample of the parts of the networking system. This time, using the RISC OS 2 style variant.

2022 examples

Jan Vibe's Diamond Tree

[Image]
(Video)
Constructing a tree made of diamond shaped coloured blocks

My recordings of the Jan Vibe archive were quite pretty. Their testing produced a lot of fixes for the VDU and graphics system. This diamond tree is one of my favourite pictures.

[Image]
(Full size image)
Creating vector images is just as easy

Although RISC OS Pyromaniac can display the results as bitmaps, it can also save as vector images. This image was part way through the rendering of the tree, but saved as a vector art SVG instead of a bitmap.

Integration with the macOS Finder

[Image]
(Video)
Finder integration allows programs to be run from the host system

The macOS finder offers the option to extend the menus with 'quick actions'. These are automation jobs which can process files by running programs. In this case, the BBC BASIC program is being run inside Pyromaniac from just a menu selection.

Unicorn 2 works

[Image]
(Video)
Making Unicorn 2 work was a little fraught

The improved Unicorn engine that was produced by their developers initially had a lot of problems with processor mode changes. As this happens a lot in RISC OS, this was a big deal. With a lot of back and forth, it now works with RISC OS Pyromaniac, well enough that the desktop applications run.

Information about the running system

[Image]
(Full size image)
The first of many data tables

Being able to see the running state of the system is very useful in a diagnostic tool. One of the first of the data tables that the WxWidgets UI can display was the modules information window, which lists all the modules we can have present and their details.

[Image]
(Full size image)
Many more data tables are available

There are now many different types of information that are accessible through the 'View' menu in the WxWidgets UI. These allow you to see how the system is functioning whilst it runs.

[Image]
(Full size image)
Even allowing unicode

The AMBs (application memory blocks) data table here shows that we can include unicode characters to indicate the state of the information being represeneted too.

Interactivity in the UI

[Image]
(Full size image)
Initial OS_Confirm dialogue

Although OS_Confirm isn't used often, it is nice to have it appear as a native dialogue box, rather than purely being isolated to the RISC OS display. It makes the system more like an integrated application.

[Image]
(Video)
Demonstrating Wimp_ReportError and OS_Confirm dialogues

The Wimp_ReportError dialogue is also able to be presented as a separate external dialogue, rather than being isolated to the RISC OS display window. The video shows both the confirmation and error box being used, alongside RPCEmu showing the same dialogue box.

[Image]
(Video)
Editing text files, too!

The Twin module offers a '*Edit' command, which can edit files using a configurable editor. In the WxWidgets UI, that cane be a host dialogue which lets the file be modified before returning it to the system.

[Image]
(Video)
Requesting input from the user for Git authentication

Although RISC OS doesn't itself have a direct interface for getting input from the user, except through OS_ReadLine, this is needed for the operations performed by the Git tool to authenticate the user. An integration to allow this interaction means that it is more like a regular application when you need to log in.

Examining the system memory

[Image]
(Full size image)
Module and Dynamic Area memory dumps

In addition to the data tables mentioned above, the WxWidgets UI allows you to see the contents of memory in modules and dynamic areas. These views can break down the data as bytes, half-words, words, or by disassembly.

[Image]
(Video)
Demonstrating the views on the memory

The video shows how to see the contents of a module and dynamic area through the menus. It then shows the view on to the NVRAM, and demonstrates the help in the status bar which shows what the NVRAM data means.

[Image]
(Full size image)
Comparison between Zap and RISC OS Pyromaniac

The dissasembly format in RISC OS Pyromaniac is styled to look similar to how the disassembly looked in !Zap - which is where I came from on RISC OS. Comparing the two side by side shows that they really are quite similar.

Coloured disassembly at the command line

[Image]
(Full size image)
*MemoryI can colour its output

With the implementation of the coloured output in the UI, it seemed like a nice extension to allow the command line disassembly to use this colouring as well. The *MemoryI command can display the colour if you set a system variable.

FS explorer in WxWidgets

[Image]
(Video)
Demonstrating the FS explorer

The FS explorer in WxWidgets is intended to make it easier to examine the content of the filesystem from the host system. The explorer has a lot of the facilities you would expect of the RISC OS Filer, but is implemented purely through calls to the system request system.

The video shows browsing for files, the memory dump and text displays of their contents, and the different types of display that can be shown in the Explorer.

[Image]
(Video)
Creating directories and deleting files are supported

Although the file contents cannot be modified, new directories can be created, and files deleted from the interface.

[Image]
(Full size image)
Comparing the Filer to FS explorer

Placing the Filer and FS explorer alongside one another shows some of the differences and similarities. Although they won't be the same in terms of the applications, as we don't handle the !Sprites files, the style of the window and menus is very close.

Resizing the UI

[Image]
(Video)
Resizing the UI window

The video demonstrates the way that the WxWidgets UI window can be resized. The configuration here retains the aspect ratio of the display, and works in different modes just like you might expect.

[Image]
(Full size image)
RISC OS full screen on macOS

With the ability to scale the display arbitrarily, it is now possible to run RISC OS Pyromaniac in full screen. This makes the system seem a lot more 'real', although it is still just another application on the system.

[Image]
(Full size image)
RISC OS The Great Escape full screen

Obviously when run full screen, the ZX Spectrum game The Great Escape looks odd on a macBook.

[Image]
(Full size image)
We can try out silly modes

Although the reszing of the UI didn't directly make it possible to have large modes, it did fix a number of minor issues with using them. This image shows a 2200x2600 mode using EX0 EY0, spanning across multiple monitors to make it look more impressive than it is.

In reality you can have any size of mode you care for in RISC OS Pyromaniac, so this isn't actually that special. But it does look fun.

GTK and WxWidgets comparison

[Image]
(Full size image)
Different UIs aren't that different

Although the WxWidgets UI is more functional than the GTK version, they still look very similar - and now they support changing the border colour which is obviouly very important.

Old UtilityModule behaviour

[Image]
(Full size image)
Deleting the UtilityModule is Foolish

On older versions of RISC OS it was possible to trigger an error message if you tried to kill the UtilityModule. Later versions of the system caused this message to not be visible, but it still has a bit of nostalgia. The option to report this message is present in RISC OS Pyromaniac, although it doesn't really have much effect as the UtilityModule only provides the *GOS command.

Statistics on interfaces

[Image]
(Full size image)
FS: What files did we access?

Being able to see what files were accessed by the system is very useful for debugging what's going wrong with a program. Having statistics to show how many accesses were performed can also help with the performance of the system. When the FS statistics are enabled it is a lot easier to see what's going when the system exits.

[Image]
(Full size image)
Tickers: Who is doing stuff?

The ticker system also has statistics available to it, together with a mechanism for listing the currently active ticker handlers.

OvationPro in the desktop

[Image]
(Video)
OvationPro needed very few fixes to work

David Pilling released OvationPro for free, so I tried it out to see if there were things that needed fixing. Surprisingly, it worked without much fixing.

Desktop rendered as a PDF

[pdf]
Download
Cairo renders to a document just as easily as to a bitmap.

Just as it is possible to render to a SVG using the Cairo system, it is also possible to render to a PDF. Whilst SVG isn't great as a rendering medium for an operating system, a PDF is even more strange.

'Simple' IIC and GPIO devices

[Image]
(Video)
IIC driven 2-line LCD diplay

Long ago, I created a small LCD display for AMPlayer, so I was interested in driving a simple display from Pyromaniac. It required writing a more functional IIC module, and writing a small amount of code, but it's still quite easy to do.

[Image]
(Video)
GPIO to drive addressable RGB lights

Addressable RGB lights are common these days, and being able to drive them isn't hard. However, if you have to first write the GPIO interface to drive them, then the driver, then the program, it takes a little longer. Fortunately, the BASIC code to control the Blinkt lights here is pretty simple.

[Image]
(Video)
GPIO to drive a 7-segment display

7-segment displays are really old hat. But they can be driven through the GPIO interface relatively easily.

[Image]
(Full size image)
GPIO to drive an 8x8 matrix

The matrix driven here is actually using another 7-segment display controller, but instead of being aligned as digits, the segments are just regular LEDs in a matrix, so you can produce pretty patterns.

[Image]
(Full size image)
GPIO to drive multiple 8x8 matrixes

The controller for the 8x8 matrix can actually handle multiple matrixes, by chaining them together. The code has to be slightly different, but it's not too much more complex.

[Image]
(Video)
GPIO exposed as UI gadgets

Being able to see the GPIO as it changes is sometimes useful. Probably not that often, but still it's an extra option. The WxWidgets implementation for GPIO lets you see the pins as they change, and update the inputs by clicking them.

Graphics implementation using an OLED display

[Image]
(Full size image)
First images of the SSD1306 display

The SSD1306 OLED display is a little I²C display which has a resolution of 128x64. A graphics implementation in RISC OS Pyromaniac means you can use it as a regular display. If the mode you select is much bigger than the display, it will just truncate the output, but otherwise it works just fine. This image is one of the first that was created by the graphics implementation.

[Image]
(Video)
SSD1306 with a working cursor

The flashing cursor makes the display look a lot more like a regular display. It's quite responsive when using interactively.

[Image]
(Video)
SSD1306 with an animated clock

A little BASIC program that draws a clock shows how well it works - there's a shimmer because the refresh of the camera and the display are slightly off.

[Image]
(Video)
SSD1306 with rotated display

The display driver can flip and invert the contents of the display before sending the data to the device, which means that it can be used in portrait as well as landscape. It may not be quite so useful like that, but you can, which is the point.

[Image]
(Full size image)
Accidentally running two devices at once

I left two devices connected to the I²C bus by accident. By a happy coincidence, they didn't interfere with one another and I ended up with the same image on both displays!

Graphics implementation using Turing Screen

[Image]
(Video)
3.5" 'Turing Smart Screen' IPS display

The 'Turing Smart Screen' is a serial based display. It's not amazingly fast, but it works quite well for displaying text. To make the rear facing light work, the graphics border colour is used to control the colour.

Graphics implementation using a 21x7 LED display

[Image]
(Video)
USB 'Dream Cheeky' LED message board

I bought the 'Dream Cheeky' LED message board so that I could use it as a notice about system events at work. It wasn't very useful as it is so small, but it was fun to play with at the time. Digging it out to use with Pyromaniac, it is even more obvious how unuseful it is. But it does work as a graphics implementations.

Graphics implementation using the console

[Image]
(Video)
The ANSI frame device is not so terrible

The 'ansi' console frame device is a graphics implementation that uses the console output to show the graphics display, with one pixel being represented by one character. This meants you need to scale the font down a lot, but it does work.

ADC experiments

[Image]
(Video)
BASIC ADVAL through the MCP2221

The MCP2221 that I use for my I²C and GPIO tests also supports an ADC. My experimental ADC module lets me use this with ADVAL. Here you see a very simple program showing that the analogue from a little thumbstick works as expected.

[Image]
(Video)
BASIC ADVAL in 2D with PCF8591

The PCF8591 is an I²C device which supports ADC. This is it in use with a little example program.

PWM devices

[Image]
(Video)
FanHAT for Raspberry Pi

The FanHAT for the Raspberry Pi is a PCA9685 I²C device that allows the fan's speed to be controlled programatically. Driving it from Pyromaniac with BASIC is pretty easy. It also has a OLED display which RISC OS Pyromaniac supports as well.

[Image]
(Video)
Spiral LEDs for Raspberry Pi

The PiGlow is a Raspberry Pi focused device with 18 coloured LEDs in a spiral. It's really bright! It can be drived by a little bit of BASIC code in RISC OS Pyromaniac.