Pyromaniac

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.

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.

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.

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 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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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').

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.

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.

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.

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.

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.

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.

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 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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.

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!