The Iconbar

Subscribe to The Iconbar feed The Iconbar
Technology news and views
Updated: 3 hours 43 min ago

The Book of Arcade Games reviews

Fri, 12/14/2018 - 08:36

The Book of Arcade Games was launched at the recent RISC OS London Show.

The 130 page book contains updated and and enhanced listings for 10 of the best Arcade games from the Drag'n'Drop magazine. There is also a introductory guide on how to type in (and Chris was offering the already typed in code to download at the Show).

The Games are all written in BBC BASIC and there is a nice screenshot and description of each before the listing. The type is clear and readable, and the book is spiral bound, so sits flat on your desk. All this makes it very easy to follow the code.

If you are interested in programming RISC OS of just looking for a bit fo fun and nostalgia, I can recommend this book.

You can preview the book online for free and it costs 15 pounds (including postage) from Drag'n'Drop website.

No comments in forum

Categories: RISC OS

What is apache?

Fri, 12/07/2018 - 07:35
With RISC OS switching to the Apache license, here is your brief intro to the world of Apache....

Apache the software program
Apache is a key building block of the Internet. It runs on many of the servers which make up the Internet and allows them to provide the websites you use every day. Its many features include the ability to host multiple websites on a sever, control access and provide security, execute scripts and commands when you access pages, log website activity, and a whole host of other features. You use Apache every day without realising it.

Apache the license
All software has a license which defines what rights you have and what use you can make of a piece of software. For example, most commercial software bans you from trying to dissect it and give it away to your friends.

The Apache License is one of several Open Source licenses. These generally come with free software (as in you do not have to pay for it) which includes the source code. The big difference in Open Source licenses is that some are viral (with the GPL you have to release any software which uses it under the same license so it 'infects' the software) and non-viral (you can use it with other software including commercial software so long as you respect the rules on the original software).

It is possible to release software under more than one license. A nice example is the PDF library Itext, which you can use for free under the AGPL license (requiring you to release your code for free as well with the source code), or buy a commercial version (identical except it comes with a commercial license removing this requirement so you can use in commercial software).

If your aim is to encourage maximum update and usage, you would choose a non-viral license such as the Apache license which is what RISC OS now uses.

If you own the software, you can choose to change the license (as RISC OS Developments has done having acquired RISC OS), but you cannot modify the license on software belonging to someone else).

Apache the foundation

There is also an organisation called the Apache Software foundation which provides a home for a large number of software programs developed under the Apache license. Most of these are technical and you might have heard of them if you are a software developer (ie Ant, Groovy, Hadoop, Maven, Perl) or runs on servers providing Internet services (ie SpamAssassin, Tomcat).

Apache is an organisation of individuals (no Company/Corporate membership option) and anyone can join. It also organises conferences and promotes software development.

Anyone can use the Apache license in the software. This is perfectly acceptable and many other software projects have been doing the same for many years.

If you want your software to be an 'official' Apache project, you also need to follow the apache rules on how software is developed. This lays down a clear methodology and governance.

Many of the software projects which are Apache projects started life outside Apache and have joined by adopting the Apache rules. For the last 2 years, the Java IDE NetBeans has been transitioning to an Apache project (I have had a minor involvement in that giving me a very interesting viewpoint of the Apache foundation).

More details on Open Source licenses at GNU website
Apache website

No comments in forum

Categories: RISC OS

November news

Fri, 11/30/2018 - 07:07
Some things we noticed this month. What did you see?

Elesar finds a way to improve performance on your Titanium machines with free software update.

New stunt drivers game from AmCoG games.

Updated free guide to VirtualRPC in Use available to download.

Review of the new RaspberryPi3 A+ on RISC OS blog.

Elesar update !Prophet to 3.95

No comments in forum

Categories: RISC OS

Drag'n'Drop Summer 2018 edition reviewed

Fri, 11/23/2018 - 08:01

If you want some RISC OS related news, reviews and projects (or still missing the summer days), Then the Summer edition of Drag'n'Drop Magazine is for you.

The magazine is published as a PDF file (so you can read it on any Computer or print it out) and always reminds me of the 1990s era Acorn magazines at their best. The magazine does not assume you have been using RISC OS since the 1990s though, and there is always a beginners page to get you started.

The news section includes information on new hardware, and new commercial and free software. Because can be read online, there are lots of useful website links to follow. There is a games review of Island of the Undead from Amcog Games and an ongoing series on using Schema2.

The bulk of the magazine features code - apps, games, hints and tricks to suit all levels of ability. You can learn about Upscaling and interpolation, type in an play a platform game called Boing, an updated Space Invaders Game, build some more serious applications for desktop and printing. My personal favourite in this edition is the guide to making a glass button.

This month also includes an index at the end for Volume 1-9 of the magazine (which can all be bought in a big back issue edition).

There is a free preview of the magazine to read, and you can buy the magazine directly from the website.

No comments in forum

Categories: RISC OS

PackMan in practice, part 2

Fri, 11/16/2018 - 09:00
As mentioned at the end of part one, this article about creating PackMan packages is going to look at what's necessary to generate distribution index files, ROOL pointer files, and how these tasks can be automated. Towards the end I'll also be taking a look at some options for automating the uploading of the files to your website.

Index files and pointer files

Distribution index files

Distribution index files are the mechanism by which the PackMan app learns about packages - each 'distribution' (i.e. collection of package zip files hosted on a website) is accompanied by an index file. This index file contains information about each package; at first glance it looks like it's just a copy of the RiscPkg.Control file from within the package, but there are actually a handful of extra fields that are included within each 'control record':

  • Size - The size of the zip file
  • MD5Sum - The md5 of the zip file
  • URL - The (relative) URL to the zip file
Additionally, by convention the distribution index file should only list the most recent version of each package. It's also common (but not necessary) for the package files to contain the package version as part of their name, e.g. This way, although the index only lists the most recent version, you can still host the previous versions on your site if you want or need to.ROOL pointer files

For the community distribution that's managed by ROOL, ROOL require package mainteners to provide a 'pointer file' containing a simple list of links/URLs to packages. ROOL's server will then regularly fetch this pointer file, fetch all the (changed) packages, and merge everything into the central distribution index file.What we need is some kind of packaging tool

These rules for distributions, index files, and pointer files mean that the task of preparing package zip files for publishing is too complex to be attempted using simple Obey file or BASIC scripting. OK, if you were only interested in ROOL pointer files you could probably cobble something together without too much effort, but in most cases the use of a 'proper' tool is going to be required.

The good news is that to generate a distribution index file, a tool only needs two bits of information about each package: the URL the package is going to be hosted at, and a copy of the zip file itself. Everything else can be determined by examining the contents of the zip. This means that once you've got such a tool for generating index files, it should be very easy to plug it into your publishing pipeline.

And the even better news is that I've already written a tool - skopt, a.k.a. Some Kind Of Packaging Tool. Currently its feature set is quite small, but since it appears to be the only tool of its kind in the standard PackMan distributions, it's something that's very much needed if the ecosystem is to continue to grow. Additionally, it's built ontop of the same LibPkg library that RiscPkg/PackMan use internally - helping to simplify the code (just a few hundred lines of C++) and ensure consistent behaviour with PackMan itself.Functions

The current version of skopt has three modes of operation:

  • copy - Copy package file(s) from one location to another. However, unlike a simple *Copy command, this will rename the package zip to the 'canonical' form (i.e. It'll also raise an error if it tries to overwrite a package which has the same name but different content (which could indicate that you're trying to publish a new version of a package without increasing the version number).
  • gen-binary-index - Scans a list of folders containing (binary) package zip files and generates the corresponding distribution index file. It assumes that the filenames of the packages within the folders will match the names by which the files will be uploaded to your website. However you can specify per-folder URL prefixes.
  • gen-pointer-file - Scans a list of folders containing binary packages and generates a ROOL pointer file. As with gen-binary-index, it's assumed that the names of the files will match the names used once uploaded, and URL prefixes are applied on a per-folder basis.
Uploading packages

With skopt managing generating the index file(s) (and optionally package file naming), there's only one piece of the puzzle left: how can you upload the packages to your site?

Ignoring the obvious choice of doing it manually, there are at least a few RISC OS-friendly solutions for automation:!FTPc

!FTPc can be driven programmatically by the use of Wimp messages, and comes with a handy BASIC library to simplify usage. So if you have FTP/FTPS access to your web site, only a few lines of BASIC are needed to upload files or folders.scp, sftp

If you have SSH access to the web server, then scp (as included in the OpenSSH PackMan package) may be an easy solution for you.

The OpenSSH package also includes a copy of the sftp command, which is useful if your web site supports SFTP rather than the older FTP & FTPS protocols. sftp can easily be driven from scripts by the use of the -b option, which will read a series of commands from a text file.rsync

rsync (also available via PackMan) is another option for copying files via SSH connections (or via the bespoke rsync protocol).Next time

Uploading binary packages to PackMan distributions is all well and good, but what about the source code? Or what if you want to have regular web pages through which people can also download your software? Stay tuned!

No comments in forum

Categories: RISC OS

GPS becomes Data Logger

Fri, 11/09/2018 - 06:21
At the recent London Show Chris Hall was showing his new Data Logger. Here he gives some info into the new hardware

Version 2.40 of my SatNav software and the compact hardware unit with just an OLED display meant I could stop trying to fix things that were still unfinished. I had full battery management, conditional data logging, robust and error-tolerant data downloading on demand and power management that avoided any SD card corruption.

Where next?

There were things still unfinished: I wanted the unit to be able to use WiFi to transmit data instead of making do with manual downloads to a USB pen drive; I would have liked to remove the code which drives a liquid ink display (Papirus) into a more general purpose module, where it should be, but had never tried writing one. RiscBASIC could compile an application to a module but only at 26 bit. Both these aspirations were therefore not immediate.

It was not long before an idea came to me: as usual it hit me at 0400. Putting detail aside, the unit’s fundamental purpose was to monitor incoming data (GPS data) and selectively log the data along with time and date of receipt. The data could then be downloaded on demand to a USB pen drive in an appropriate format. My university training had strongly counselled me never to press something designed for a specific task into service for a quite different purpose. At least not without careful thought.

The front panel showing the push buttons and the USB socket, as well as the 12-way screw terminal block, which can easily be unplugged.

The idea I got was that I could build a data monitor which would examine a number of input lines and log any state change. The inspiration for this came from my volunteer work on the Severn Valley Railway: we had experienced a few faults on S&T equipment that had proved very difficult to fault find. They were intermittent and on complex equipment where faults would be difficult for the signalman to report in a way that could help us diagnose the problem. Accurate details of exactly what had occurred would help enormously.

Removing the GPS module (which used the serial port to communicate), adding a CJE real time clock module and using the GPIO pins to monitor incoming data would mean that very little in the SatNav programme would need to be altered to fulfil this new purpose.Data Logger

The main purpose of the data logger is to monitor signalling circuits so that a precise sequence of relay operations can be logged. Eight inputs are scanned 1500 times a second and any changes of state are logged. The GPS module has gone, replaced by a simple real time clock card. Otherwise the software is very similar, with changes of state of any one of the eight inputs being the parameter that is being monitored rather than GPS location. The unit is designed to operate for weeks at a time, with regular visits to download data to a USB pen drive simply by pressing the 'ON & INFO' button. Making the device fault tolerant was quite tricky as there is no desktop display to show errors. (A desktop display is being created but no monitor is plugged in.)

The GPIO inputs themselves on the Raspberry Pi used 3.3V logic and had software-controlled pull-up or pull-down resistors. The circuits being monitored used 12V, 24V or 50V and comprised a number of relay contacts in series with a relay coil. Some relays had spare contacts (making them easy to monitor) but some did not, particularly those monitoring track circuits.

The ‘simple’ DC track circuit exploits the hysteresis of the relay so that it falls away at a known voltage and requires a higher voltage to pick up again when the train has gone. Monitoring the single contact provided is the only way which means breaking into signalling circuits without disturbing them.

The signalling circuit shown is a 24V circuit with the fused positive supply (B12fx) on the left and the negative return (N12) on the right. Inputs A to D are ‘active low’ and connected to GPIO pins GP5-GP8 which have, by default, pull-up resistors on chip. Inputs E to H are ‘active high’ and are connected to GPIO pins 17-19 and 23 with pull-down resistors.

That also means being tolerant of relay back EMFs as the relay coil circuit is broken. How resilient the unit will be in service is still unproven.

My first stab at protecting the GPIO 3.3V logic from the 24V signalling supplies and the hundreds of volts that might appear as relay coil circuits are broken. Each input is inactive when open circuit and can be activated in the voltage ranges noted. This gives a choice of +1 to -30V (which includes 0V); -6 to -30V (with a series resistor and excludes 0V) or +6 to +30V. Voltages in the range specified will make the input ‘active’.

Monitoring of the inputs has a ‘test’ mode built in so that holding down certain keys on the keyboard will toggle the measured status of the particular input.


The case itself is made from polycarbonate sheet, cut to several different widths by the supplier that I cut to length with a hacksaw.

The case with printed labels stuck onto the protective film after cutting the ploycarbonate sheets to size.

Most of the breakout circuit board is taken up with the various components needed to protect the GPIO inputs from harmful external voltages but otherwise it is a very similar layout to that used for the GPS unit. Circuitry to control power switching is identical.

Internal wiring. Signal diodes, 1N914, resistors and capacitors should protect the 3.3V level logic from +24V and relay coil back EMFs. Inputs will sink no more than 200µA to avoid disturbing the signalling circuits being monitored.

A side view shows the plug-in screw terminal block which can be connected to the circuits to be monitored using up to 2.5mm2 cable.

Eight inputs plus three voltage-measuring inputs (approx. 0 to 30V with a resolution of 33mV). The terminal block can be unplugged.

All I have to do now is to check for any dry soldered joints!


Power consumption is about 150mA but the unit is designed to operate with an external mains power supply. The internal battery allows it to continue monitoring the signalling circuits for 17 hours after external power is lost. The signalling circuits themselves are also battery backed.

The unit has an ADC board with three spare voltage inputs, allowing any positive voltage to be recorded at any state change.

The OLED display shows the time of day and the status of the eight inputs and the three voltages (plus the supply voltage, which is the battery voltage unless it is being charged by a healthy external supply.

The OLED display shows the time (in GMT) updating once per second on the first line and shows the exact time of the last log entry on the second line with the status of each input as logged. On the line below the letters A to H will appear an ‘X’ if that item is active. The line showing ‘Man Poff’ indicated that the unit was switched on manually with no external power and that was the last change of state (an ‘A’ would mean A went active and ‘a’ inactive). The four voltages are those measured at that time. 3.807V implies 54% battery life. The other voltage inputs are not connected.

An analysis of the sampling shows that the sample interval is about 650µs (pink dots) while ‘lost time’ (for example to update the OLED display - 8cs - or to measure voltages - 5cs) is generally less than 12cs.

The battery should last about 18 hours (at 175mA) and the voltage reading can be used to indicate the battery life remaining, as above.

Routine observations

The OLED display shows the current time and date in Grenwich Mean Time as well as the last occasion (time only, but shown to the nearest hundredth of a second) when one of the eight inputs being monitored changed state. The status of each input (A to H) is also shown.

No inputs are connected so the unit shows the initial condition: manually turned on with no external power supply.


The unit will keep a log of the various inputs monitored (making a new entry at each state change or every 30 minutes) which can be downloaded onto a USB pen drive on demand by inserting a USB pen drive in the USB socket and pressing the ‘ON & INFO’ push button.

Download request at &573EC486
Opening file for day 60 as SCSI::0.$.Lg28-09-2018/csv
Closing file for day 60 length=50173
Writing valid lines from DataLog/csv (length=C457) to
Closing copy file at length=50263
Reopening copy file from 57 to C457
Logfile now truncated to length=C400
When a log is downloaded, the daily log files are written to the pen drive along with a file (shown above ‘LogFile.csv’) which will show detailed information to allow any errors to be followed up.

Pressing the ‘INFO’ button will bring up this screen and show the progress of the download as shown. The ‘ON’ button is used to ensure the messages don’t disappear.

The ‘ON’ button is used to make sure that the messages remain on screen for long enough for the user to read them.

As each day’s log details are downloaded, a progress report is shown.

If the process completes with no errors this screen is shown

Releasing the ‘ON’ button confirms you have read the message.

Logging format

The logging of the inputs uses a ‘CSV’ file, the syntax of which includes the time of each entry and the various parameters being monitored. The logging now looks like the example below.

28-09-2018,11:29:34.71,&573E97E7FF,0,0,0,0,0,0,0,0,4593mV,04.98V, .00V, .00V,Man POn ,0
28-09-2018,11:29:49.57,&573E97EDCD,0,0,1,0,0,0,0,0,4587mV,04.98V, .00V, .00V,C,21675
28-09-2018,11:29:49.84,&573E97EDE8,0,0,0,0,0,0,0,0,4596mV,04.98V, .00V, .00V,c,238
28-09-2018,11:30:52.50,&573E980662,0,0,1,0,0,0,0,0,4593mV,04.98V, .00V, .00V,C,92043
28-09-2018,11:30:52.71,&573E980677,0,0,0,0,0,0,0,0,4596mV,04.98V, .00V, .00V,c,0
28-09-2018,11:31:29.20,&573E9814B8,0,0,1,0,0,0,0,0,4596mV, .00V,05.04V, .00V,C,53452
28-09-2018,11:31:31.42,&573E981596,0,0,0,0,0,0,0,0,4596mV, .00V,05.04V, .00V,c,3104
28-09-2018,11:33:46.94,&573E984A86,0,0,0,0,0,0,0,0,0000mV, 0.00V, 0.00V, 0.00V,Quit,0
A download request will copy a log file for each of the last 60 days for which data are available onto a USB pen drive. It will archive previous days’ log entries as a record of what was extracted. Subsequent downloads will thus still capture full data for the current date. The example above shows log entries created by touching input ‘C’ with a wire connected to 0V with 5V applied to K or L. Times are in GMT.

Performing a log download

Place a USB pen drive in the USB socket, wait a few seconds for the presence of the drive to be recognised by the operating system and then press the ‘ON & INFO’ button. Log entries up to and including the current day will be downloaded, the data for the last 60 days being placed in separate files on the USB stick. Progress of the download will be shown on the OLED display and once reported complete the USB pen drive should be removed and the ‘ON & INFO’ button used to confirm this has been done, as prompted.

If an error message is shown on the OLED display (such as ‘disc drive is empty’) this can be recorded. The date and time at which the download was carried out and the date and time shown on the OLED display should also be recorded (so that any clock drift can be recorded).

A continuous log is stored on the internal 16GB SD card and historical data are archived on completion of any download (in case the pen drive is mislaid) with just the data for the current date retained in the accessible log.

Analysis of the data downloaded

Analysis of the data downloaded will be done in an Excel spreadsheet which will allow any abnormal operation to be examined in detail.


Daily logs are created when a download request is made, with dates, times and circuit activity recorded every 30min or at any change of state.

Power consumption

Although it cannot be seen with only an OLED display, a full desktop is being generated. With no HDMI display connected, power consumption drops from 550mA (excluding the display itself) to about 170mA so it is quite efficient.

Powerboost board

The ‘power booster’ board allows an internal 3.3V Lithium-Polymer battery to produce a 5.2V output and will use an external 5V power source to take over this rôle and charge the internal battery until fully charged. Switching on and off is controlled by an ‘ENABLE’ input.

A blue LED lights if power is being supplied to the computer. With the booster board output disabled, only a minimal current is drawn from the internal battery. A red LED lights if the internal battery becomes discharged below 3.2V (a diode is fitted to disable the output automatically). Fully discharging the internal battery is likely to damage it.

While the internal battery is being charged a yellow LED lights, turning green when it is fully charged. A small current drain to light the green LED to show a full charge seems enough to keep some power banks happy even whilst the unit is otherwise powered down.

This means the external source can be connected and disconnected without affecting the operation of the device except to extend battery life.

Analogue to digitial conversion

The ADC board is the 12 bit ADS 1015, by Adafruit, and it takes about 5cs to check all four voltages. I did try a 16 bit version but it took quite a bit longer to do the same sampling. I had also included the voltage sampling in the same block of code as that examining the eight GPIO pins for any state change. This meant that the unit was sampling at about 10Hz.

I realised that state changes of the GPIO pins needed to be monitored more frequently and voltages only really needed to be recorded at any state change. This improved the data sampling rate to 20Hz.

The next inspiration was that the OLED display was being updated each time there was a state change.

The OLED module keeps a sprite in memory which is updated line by line as text is written to the display drivers. Every so often, the display is updated via the IIC bus, which takes about 12cs.

There seemed no point in updating the OLED display more quickly than the eye could see so I held back updates if the display had been updated in the last 2s. The sampling rate rose to 1500Hz.

The Organic LED Display

The OLED display shows the active/inactive status of the eight inputs under the headings A to H under which an ‘X’ appears if the circuit concerned is active, updating every 30 mins or whenever any of the inputs changes state. The three voltages being monitored are also displayed, updating at the same time. Time and date is also shown, in GMT.

This continuous display allows the set up of the unit to be checked easily and the last recorded state change is displayed along with the precise time (to the nearest hundredth of a second) that it occurred.

Loss of power

Whilst the unit should continue operating in the event of a mains failure, it will shut down if its internal battery becomes exhausted and would, in that event, need to be restarted manually. Before doing so, the fact that mains power has been restored should be confirmed (a yellow or green LED indication on the powerboost board confirms that the internal battery is being charged).

The unit takes about 11s from power on to be functional and the real time clock is able to keep time whilst the unit is switched off by having its own 3V 70mAh coin cell. The unit will continue logging for about 17 hours after power has been removed after which it will shut down.

The ‘OFF’ button allows the unit to be shut down manually. The status of the ‘ON’ and ‘OFF’ buttons is held internally so that it can de determined which button was the last to be pressed.

Battery endurance

The internal rechargeable battery is monitored for state of charge each time any of the eight inputs changes state: it will show either ‘xx%’ (while power is off) or ‘chgng’ (whilst being charged). Below 3.2V it is discharged and the power boost board will force power off. The battery should last for 500 charge/discharge cycles.

If a keyboard, mouse and monitor are connected, then a multi-tasking graphical user interface will be displayed. Power consumption rises from 1W to about 3W with an HDMI display connected (excluding the power that the display itself requires). Direct WiFi access is not yet supported by RISC OS.

Power on/off

The ‘OFF’ button does not switch the unit off directly. Power is removed under software control so that corruption of the SD card, which could occur if power was removed whilst the log was being updated, is avoided.

Pressing the ‘OFF’ button will warn the user before removing power, as shown.

Provided that the unit has been operating for at least six seconds (enough time for the RISC OS desktop to start), the ‘off’ button will pull GPIO 26 low but do nothing else. The software will notice this, complete any logging and then do a system shutdown using the command SYS "TaskManager_Shutdown",162 which will shutdown all applications tidily and restart RISC OS. The effect of this is to update the CMOS ‘last time on’ setting and restart the ROM. As the ROM reinitialises, GPIO 4 becomes high impedance thus removing power.

Software update

A specially prepared USB pen drive may be used to update the software automatically or to extract archived data, but this is not a routine operation.

Silent errors

With a monitor using the HDMI output to display a desktop, any error that might be generated can be recorded, with its line number, and investigated. It is very frustrating to see the software ‘freeze’ and realise that an error message is being displayed but cannot be seen. If you simply plug in an HDMI display at that point, the computer will not send data to it as the HDMI system is not powered up. I therefore added an error display to the OLED drivers.

The finished unit clamps to a steel surface:

The finished unit.

No comments in forum

Categories: RISC OS

October News Headlines

Wed, 10/31/2018 - 12:30
Some things we noticed this month. What did you see?

R-Comp released a 6th version of their Monitor software, offering more screen modes for Titanium.

RISC OS Developments acquire Castle Technology. Expect lots of speculation on the Internet and some hard facts at the London Show.

Interesting article on Reading Manga on RISC OS on RISC OS blog.

The 10th London show. Read our report.

No comments in forum

Categories: RISC OS

RISC OS London Show Report 2018

Sat, 10/27/2018 - 15:30
The 10th London show took place at its regular venue on Saturday 27th October (St Giles Hotel - Feltham, London). It was a warm and sunny autumn day (always a good start). The bridge next to the Show was closed this year which made the journey more complex...

Numbers were up this year and lots of exciting news in the talks. There was a lot of buzz in the air over the Open sourcing of RISC OS.

The show was run as usual by ROUGOL and their army of helpers who did an excellent job of making everything work to time faultlessly.

There is a separate report for the talks and a show in pictures article. In this report we will focus on the stands and the actual event.

There was wide range of stands at the show, summarised below.

RISC OS Open ltd had its usual range of software and nice Titanium video running. Steve Revill was onhand to answer questions about the license changes recently announced.

Sine Nomine were walking people through the options on the new style editor for RiscOSM and answering questions on impact and their other software.

Softrock had its complete range of software, hardware cases for PI and free chocolates.

RPCemu had the latest release running various versions of RISC OS (up to 6) on several different spec PCs

3rd event had a large selection of music keyboards and other hardware for its AMCS sound sequencing software.

There were several stands running games and music on a range of BBC machines. Tricky gaming had some new games, BooBip had some hardware upgrades for BBC machines, ABUG had lots of machines to play with and there was also a Doomsday machine and to play with and also machines from the BBC media preservation project. Rob Coleman had his VideoNuLA card for BBC.

The charity stand had a large collection of stuff to riffle through for a bargain.

Drag'n'Drop has a new book of arcade games listing to add to its growing range which was all available on the stand. The autumn release of the magazine is due 'any day'.

Organizer had an updated version of the software of a stick and the recent 2.28 release. They were again asking for your ideas for new features you would like to see in the software.

Chris Hall had his hardware projects and family tree software. He had some new hardware to provide data logging and give realtime input.

Orpheus were talking about their recent success crowd-sourcing project. Richard Brown also had his RISC OS Developments hat on and able to update visitors on their purchase/relicensing of RISC OS as well as the bounties and Browser project. Sweets were also being given away.

Steve Fryatt had his free software (available on CD) and was showing Cashbook 1.40 (released in April).

Risky Robots had a selection of hardware robots on their stand.

RISC OS bits had the usual selection of interestingly named hardware including some very nice Pi cases.

Aemulor and Geminus were being demoed by Adrian Lees who was also talking about the new hardware acceleration.

Amcog games had their full range on show and were explaining how the software was created and put together.

Both R-Comp and CJE Micro's had their full ranges available. Details on what was new in the talks.

ROUGOL were giving details of upcoming meetings. Richard Brown is talking in November if you want to quiz him on recent events.

Archive were taking orders for the latest compilation and had a selection of recent editions to take away.

Steve Drain was explaining how to setup and use Basault and his other software and hardware projects.

Show in pictures article

No comments in forum

Categories: RISC OS

RISC OS London Show 2018 - Notes from the talks

Sat, 10/27/2018 - 15:05
Here are my notes from the talks. Any mistakes or omissions are mine.

11.30 CJE Micro's
in addition to finishing his house, Chris has lots of RISC OS related stuff to share. Not actively involved but very supportive of license changes. CJE not planning to fork the OS. Mentions of lots of items:-
Interface to use USB mouse with old Archimedes machines.
Econet box which can create a small network for you.
New IDE interfaces for A3000 range machines. You can now use compact flash or SD cards. Also offers a neat way to add a new real-time clock if needed.
PiTop 2 available and running RISC OS. Better keyboard and screen. Good battery life
Hdmi 7inch and 10inch small monitors
More ports for pi zero
44 way ide to sd adapter

12.00 Sine Nomine
Since last year's big launch with contours. Data now available for much of Europe. Demo using Swiss data. Data from NASA released into public domain.
Contour display can be toggled and also configurable (ie range between each contour displayed).
Hillary has been very busy on style editor. Can highlight features from key on map and toggle what is displayed. Will be further enhancements in new releases (ie make it easy to set style on items not shown on map).
Increasing support for Internet services. Flickr now available and others being worked on. Helped by bounties for new modules resulting in new SSL support in RISC OS.
Update from last version to latest is 5 pounds.

14.00 RISC OS Developments
RISC OS has bought Castle IP and releasing software under Apache Open Source license.
Anyone can now use without any commercial restrictions and limits. Aim to increase usage. Already interest from taiwanese company as a result.
RISC OS developments have hired a marketing specialist to promote news.
Richard also revealed secret project from last year was to create a modern browser for RISC OS. Money has been raised. Delay on finding a programmer. None of the money raised for the Browser went on purchasing RISC OS. Browser will not run on Iyonix and older machines.
There is now a website at
Orpheus now have their crowd-funded power supply.

14.45 R-Comp
Recap on new features from Wakefield Show - Doom update, MessengerPro 8. 8.1 new at London Show - now checks email when it starts.
Outlined Impact of purchase of RISC OS. Only companies who bought licenses, RISC OS companies. Transforms view of how many companies see RISC OS in world with lots of ARM devices. Now a viable alternative for companies on global scale to run.

R-Comp working on getting RISC OS running on ARM laptop - one example of how Open sourcing OS. Not yet shipping, but you can express interest.

Demoed compact ARMx6 mini computer.

R-Comp has speeded up screen display on their machines with hardware graphics acceleration. It is a chargeable upgrade.

15.30 RISC OS Open ltd
RISC OS now open source and code now under Apache 2.0 license
3rd most popular license
"Free as in beer"
Not copyleft - less restrictive
Plays nicely with other OS code used in RISC OS already.
Risk code could be forked.
Issue of dev tools - need DDE which is 50 pounds and a barrier.
Currently being discussed inhouse
Need to simplify learning curve for source code.
Still using CVS
Idea of developer workshops and tutorial videos
Parts of code still not open source - binary blobs. 3 modules with no right to publish. Can : 1.Ignore 2.clean-room reimplement. 3. lawyers

In other news.
Back on NOOBS (Raspberry Pi)
Latest releases now on Beagle and Panda
New 5,000 bounty matching for rest of years.
Actively seeking corporate sponsors.
On Todo list:-
publish much clearer and more transparent roadmap
make DDE more accessible
make source more accessible (including CVS problem)
identify key items to migrate from Arm
Push bounties forward
Work with ROD on user experience
Work with third parties on new platforms

1 comment in forum

Categories: RISC OS

RISC OS London Show 2018 - pictures

Sat, 10/27/2018 - 15:00
Here is a selection of pictures to show you what the event was like.....

(Click on the thumbnails for the bigger image)

No comments in forum

Categories: RISC OS

RISC OS source code to be relicensed under the Apache open source license

Mon, 10/22/2018 - 20:40
Hot on the heals of the reveal that RISC OS Developments had acquired Castle Technology and with it the rights to RISC OS 5, more news on the future of RISC OS has emerged this week: RISC OS Developments are working with RISC OS Open to relicense RISC OS under the Apache 2.0 License, a popular and fairly permissive open-source license.

Although some the OS's components were already available under permissive open-source licenses such as the BSD and CDDL licenses, ever since RISC OS Open's inception the primary license has been the Castle License, which came in commercial and non-commercial flavours, neither of which satisfied all of the requirements that the OSI deem necessary in order for the code released under that license to be considered "true" open source. So although the "shared source" Castle License was better than nothing and certainly played a big part in RISC OS's survival post-Iyonix, many people have also felt that it's been holding the platform back. ROOL and ROD hope that by relicensing the OS under this new license, developer and user interest in the OS will increase, and the OS will be kept free to grow and evolve into the next decade and beyond.

More information about what this means for RISC OS and what ROD's and ROOL's plans for the future of RISC OS are will be released at the London Show this weekend.

No comments in forum

Categories: RISC OS

More Acorn Magazine nostalgia

Sat, 10/13/2018 - 11:20
In a previous article, we covered some of the online resources for reading online some of the magazine from past years.

Now you can also enjoy the whole of The Frobnicate collection online. There has also been some lively discussion on the magazines online in the ROOL forums.

There is also some good content (especially technical articles) from ">Acorn User.

And if you want something right to to date, we should see new editions from Archive and Drag'n'Drop around the London show.

No comments in forum

Categories: RISC OS

RISC OS London Show 2018

Fri, 10/05/2018 - 08:00
This year's London Show is due to take place on Saturday the 27th of October, at the usual location of the St. Giles Hotel in Feltham. The show runs from 11 AM to 5 PM, with tickets being £5 at the door (and under-16's free). Exhibitors this year are set to include:If that's not enough, there's also likely to be a full set of theatre presentations, from presenters including CJE, R-Comp, RISC OS Developments, and RISC OS Open.

Be sure to visit the show's website for up-to-the-minute news in the run-up to the show.

No comments in forum

Categories: RISC OS

September News round-up

Fri, 09/28/2018 - 06:57
Some things we noticed this month. What did you see?

Orpheus Internet hits crowdfunding target.

Elesar offering a free 128GB SSD drive promotion with a new Titanium bought before 8th October.

Some packaging confessions and advice on running RISCOS OS directly on Linux The RISC OS Blog.

A video of ARM's 1992 presentation to Apple about the ARM610 - YouTube / Centre for Computing History

Reminder there is a show next month....

No comments in forum

Categories: RISC OS

DDE tools updated to DDE28c

Fri, 09/21/2018 - 06:00
Over the summer, ROOL quietly slipped out another update to their DDE toolset. We saw an update in April and the July release of DDEc is another incremental release.

There are some changes to !C++ and !CC applications and existing users can update just by copying the existing files onto the existing release. New copies on the ROOL store are using the latest release.

While there is no real features, it is really important to see such a critical tool being maintained and updated.

ROOL also mention in their release email the bounty to add ARMv7 inline assembler to the C Compiler. If you are interested in contributing to this bounty, details are here.

No comments in forum

Categories: RISC OS

PackMan in practice

Fri, 09/14/2018 - 08:00
For this first article looking at how to create PackMan/RiscPkg packages, I've decided to use my SunEd program as a guinea pig. Being a simple C application with no dependencies on other packages, it'll be one of the most straightforward things on my site to get working, and one of the easiest for other people to understand.

Read on to discover how to turn simple apps like SunEd into RiscPkg packages, and more importantly, how to automate the process.

Building your first package, the PackIt way

The RiscPkg policy manual is a rather dry document, so the easiest way of getting your first package built is to use the PackIt tool created by Alan Buckley. After loading PackIt, you can simply drag an application to its iconbar icon and up will pop a window to allow you to enter all the extra details that RiscPkg needs to know.

PackIt's package creation wizard

Once everything is filled in correctly, opening the menu and selecting the "Save" option should allow you to save out the resulting package zip file.

PackIt's output

... except that the current version of PackIt seems to save it out with the wrong filetype. No problem, just manually set the type to 'zip' or 'ddc' and things look a lot better:

The actual package content

Pretty simple, isn't it? The !SunEd app has been placed inside an Apps.File directory (mirroring the default install location for the application on the user's hard disc), while the information that was entered into PackIt's wizard has been saved to the RiscPkg.Control and RiscPkg.Copyright files.

The Control and Copyright files

Control is a simple text file containing the package metadata (the structure of which is the subject of much of the RiscPkg policy document), while Copyright is a verbatim copy of the copyright message you entered into PackIt's window.

PackIt's Copyright tab

Now that you have a package built, you can easily test it out by dragging it to PackMan's iconbar icon. PackMan will then go through the usual installation procedure, just as if it was a package you'd selected to install from the Internet.

Loading the package in PackMan

Automating package building

Filling in PackIt's wizard once the first time you create a package for an app is all well and good, but what about when you want to release an update for the package? Entering the information all over again is going to waste your time and introduce the risk of making mistakes.

Most C/C++ developers are already familiar with using makefiles to build their programs. With a bit of effort, it's possible to create makefiles which can also automate creation of the corresponding RiscPkg package.Before

After a brief bit of preparation, the 2003-vintage SunEd sources were tidied up and a simple makefile was written, allowing the application binary to be easily rebuilt on command.

The original SunEd source tree

CFLAGS = -Wall -mpoke-function-name -O2 -mlibscl -mthrowback -static

CC = gcc -c $(CFLAGS) -MMD
LINK = gcc $(CFLAGS)


OBJS = $(addsuffix .o, $(SRCS))

# Output file
!SunEd/!RunImage: $(OBJS)
$(LINK) -o $@ $^ -mlibscl

# Object files
%.o: %.c
$(CC) -MF d/$(basename $@) -o $@ $<

# Dependencies
-include d/*The original SunEd makefile

As a brief overview:

  • c and h contain the source code as you would expect
  • d and o are used for intermediate files: autogenerate dependencies and object files
  • !SunEd is the full app, ready for distribution, and the makefile is only used to rebuild the !RunImage
And after

Rather than bore you with all the intermediate versions, I figured it was best to just jump straight to the final version of the makefile and the adjusted source structure.

The new SunEd source tree

CFLAGS = -Wall -mpoke-function-name -O2 -mlibscl -mthrowback -static

CC = gcc -c $(CFLAGS) -MMD
LINK = gcc $(CFLAGS)

CP = copy


APP = Apps/File/!SunEd

ROAPP = $(subst /,.,$(APP))
OBJS = $(addprefix build/,$(addsuffix .o, $(SRCS)))

# Output file
build/!RunImage: $(OBJS)
$(LINK) -o $@ $^ -mlibscl

# Object files
build/%.o: src/%.c build/dirs
$(CC) -MF build/d/$(subst /,.,$(basename $@)) -o $@ $<

# Pattern rule for injecting version numbers into files
build/%.sed: src/template/% src/Version build/dirs
sed -f src/Version $< > $@

# Explicit dependency needed for generated file build/VersionNum.sed
build/suned.o: build/VersionNum.sed

# Standard clean rule
remove binary/zip
remove source/zip
x wipe build ~CFR~V

# Binary RiscPkg archive build/pkg-dir
remove binary/zip
dir build.pkg
zip -rqI9 ^.^.binary/zip *
dir ^.^

# Source zip archive build/src-mani makefile COPYING
remove source/zip
zip -rqI9 source/zip src makefile COPYING


cdir build
cdir build.o
cdir build.d
create build.dirs

# Double-colon rules execute in the order they're listed. So placing this rule
# here makes sure that the 'build' folder exists prior to the rule below being
# executed.
build/pkg-mani:: build/dirs

# Double-colon rules with no pre-requisites always execute. This allows us to
# make sure that build/pkg-mani is always up-to-date
src/manigen src.pkg build.pkg-mani

# Same system as build/pkg-mani
build/src-mani:: build/dirs
src/manigen src build.src-mani

# Create the package dir ready for zipping
build/pkg-dir: build/pkg-mani build/!RunImage build/Control.sed build/!Help.sed COPYING
# Copy over the static files
x wipe build.pkg ~CFR~V
$(CP) src.pkg build.pkg $(CPOPT)
# Populate the RiscPkg folder
cdir build.pkg.RiscPkg
$(CP) build.Control/sed build.pkg.RiscPkg.Control $(CPOPT)
$(CP) COPYING build.pkg.RiscPkg.Copyright $(CPOPT)
# Populate the app folder
$(CP) build.!Help/sed build.pkg.$(ROAPP).!Help $(CPOPT)
$(CP) build.!RunImage build.pkg.$(ROAPP).!RunImage $(CPOPT)
# Create the dummy file we use to mark the rule as completed
create build.pkg-dir

# Dependencies
-include build/d/*The new SunEd makefile

As you can see, there have been a fair number of changes. Not all of them are strictly necessary for automating package creation (after all, a package is little more than a zip file), but this structure has resulted in a setup that helps to minimise the amount of work I'll need to do when preparing new releases. The setup should also be easily transferrable to the other software I'll be wanting to package.What it does

  • The clean rule reduces things to the state you see above
  • The rule builds a source archive, containing exactly what you see above
  • The rule builds the RiscPkg archive, performing the following operations to get there:
    • A copy of the src.pkg folder is made, in order to provides the initial content of the package zip - essentially, the static files which aren't modified/generated by the build.
    • As you'd expect, the !RunImage file gets built and inserted into the app. But that's not all!
    • The src.Version file is actually a sed script containing the package version number and date:

      s/__RISCOSDATE__/28-Aug-18/gThe src.Version file

      This sed script is applied to src.template.!Help to generate the help file that's included in the package, src.template.Control to generate the RiscPkg.Control file, and src.template.VersionNum. By driving all the version number / date references off of this one file, there won't be any embarrassing situations where a built program will display one version number in one location but another version number in another location.

    • src.template.VersionNum is a C header file, which is used to inject the app version and date into !RunImage.
    • The COPYING file in the root used as the RiscPkg.Copyright file in the package.
  • All the intermediate files will be stored in a build folder, which helps keen the clean and rules simple.
  • Full dependency tracking is used for both the and targets - adding, removing, or changing any of the files in src.pkg (or anywhere else, for will correctly result in the resulting target being rebuilt. This is achieved without introducing any situations where the targets are redundantly built - so a build system which tries to build tens or hundreds of packages won't be slowed down.

There are also a few extra files. The src.notes folder is a collection of notes from my reverse-engineering of the SunBurst save game format, which I've decided to include in the source archive just in case someone finds it useful. But that's not really relevant to this article.

manigen, on the other hand, is relevant. It's a fairly short and straightforward BASIC program, but it plugs a very large hole in make's capabilities: Make can only detect when files change, not directories. If you have a directory, and you want a rule to be executed whenever the contents of that directory changes, you're out of luck. For small projects like SunEd this isn't so bad, but for bigger projects it can be annoying, especially when all you really want to do with the files is archive them in a zip file.

Thus, manigen ("manifest generator") was born. All it does is recursively enumerate the contents of a directory, writing the filenames and metadata (length, load/exec addr, attributes) of all files to a single text file. However, it also compares the new output against the old output, only writing to the file if a change has been detected.


REM Parse command line args
SYS "OS_GetEnv" TO args$
REM First 3 options will (hopefully) be 'BASIC --quit ""'
opt$ = FNgetopt : opt$ = FNgetopt : opt$=FNgetopt
REM Now the actual args
dir$ = FNgetopt
out$ = FNgetopt

DIM result% 1024

IF out%=0 THEN out%=OPENOUT(out$)

IF mod% THEN EXT#out%=PTR#out%
REM Oddity: Truncating a file doesn't modify timestamp
IF mod% THEN SYS "OS_File",9,out$

DEF PROCprocess(dir$)
LOCAL item%
WHILE item%<>-1
SYS "OS_GBPB",10,dir$,result%,1,item%,1024,0 TO ,,,read%,item%
IF read%>0 THEN
WHILE result%?n%<>0
PROCwrite(name$+" "+STR$~(result%!0)+" "+STR$~(result%!4)+" "+STR$~(result%!8)+" "+STR$~(result%!12))
IF result%!16=2 THEN PROCprocess(name$)

DEF FNgetopt
LOCAL opt$
WHILE ASC(args$)>32
opt$ = opt$+LEFT$(args$,1)
args$ = MID$(args$,2)
WHILE ASC(args$)=32
args$ = MID$(args$,2)

IF out%<>0 THEN CLOSE#out%

DEF PROCwrite(a$)
LOCAL b$,off%
IF EOF#out% THEN mod%=TRUE
IF a$<>b$ THEN mod%=TRUE : PTR#out%=off%
IF mod% THEN BPUT#out%,a$

On Unix-like OS's this is the kind of thing you could knock together quite easily using standard commands like find, ls, and diff. But the built-in *Commands on RISC OS aren't really up to that level of complexity (or at least not without the result looking like a jumbled mess), so it's a lot more sensible to go with a short BASIC program instead.

The usage of manigen in the makefile is described in more detail below.Makefile magic

Looking at each section of the makefile in detail:Pattern rules

# Object files
build/%.o: src/%.c build/dirs
$(CC) -MF build/d/$(subst /,.,$(basename $@)) -o $@ $<

The pattern rule used for invoking the C compiler has changed. Output files are placed in the build directory, and input files come from the src directory. The substitution rule is used to remove the directory separators from the filename that's used for the dependency files, so that they'll all be placed directly in build.d. If they were allowed to be placed in subdirectories of build.d, we'd have to create those subdirectories manually, which would be a hassle.

# Pattern rule for injecting version numbers into files
build/%.sed: src/template/% src/Version build/dirs
sed -f src/Version $< > $@

Another pattern rule is used to automate injection of the package version number and date into files: Any file X placed in src.template can have its processed version available as build.X/sed (or build/X.sed as a Unix path). The sed extension is just a convenient way of making sure the rule acts on the right

Both of the above rules are also configured to depend on the build/dirs rule - which is used to make sure the build directory (and critical subdirectories) exist prior to any attempt to place files in there:

cdir build
cdir build.o
cdir build.d
create build.dirs

The file build.dirs is just a dummy file which is used to mark that the rule has been executed.Explicit dependencies

# Explicit dependency needed for generated file build/VersionNum.sed
build/suned.o: build/VersionNum.sed

Although most C dependencies are handled automatically via the -MF compiler flag (and the -include makefile directive), some extra help is needed for build.VersionNum/sed because the file won't exist the first time the compiler tries to access it. By adding it as an explicit dependency, we can make sure it gets generated in time (although it does require some discipline on our part to make sure we keep track of which files reference build.VersionNum/sed)Double-colon rules

# Double-colon rules execute in the order they're listed. So placing this rule
# here makes sure that the 'build' folder exists prior to the rule below being
# executed.
build/pkg-mani:: build/dirs

# Double-colon rules with no pre-requisites always execute. This allows us to
# make sure that build/pkg-mani is always up-to-date
src/manigen src.pkg build.pkg-mani

Double-colon rules. The manigen program solves the problem of telling make when the contents of a directory have changed, but it leaves us with another problem: We need to make sure manigen is invoked whenever the folder we're monitoring appears in a build rule. The solution for this is double-colon rules, because they have two three very useful properties, which are exploited above:

  1. A double-colon rule with no pre-requisites will always execute (whenever it appears in the dependency chain for the current build target(s)). This is the key property which allows us to make sure that manigen is able to do its job.
  2. You can define multiple double-colon rules for the same target.
  3. Double-colon rules are executed in the order they're listed in the makefile. So by having a rule which depends on build/dirs, followed by the rule that depends on nothing, we can make sure that the build/dirs rule is allowed to create the build folder prior to manigen in the second rule writing its manifest into it.
Of course, we could have just used one build/pkg-mani rule which manually creates the build folder every time it's executed. But the two-rule version is less hacky, and that's kind of the point of this exercise.Creating the package directory

This is a fairly lengthy rule which does a few different things, but they're all pretty simple.

# Create the package dir ready for zipping
build/pkg-dir: build/pkg-mani build/!RunImage build/Control.sed build/!Help.sed COPYING
# Copy over the static files
x wipe build.pkg ~CFR~V
$(CP) src.pkg build.pkg $(CPOPT)
# Populate the RiscPkg folder
cdir build.pkg.RiscPkg
$(CP) build.Control/sed build.pkg.RiscPkg.Control $(CPOPT)
$(CP) COPYING build.pkg.RiscPkg.Copyright $(CPOPT)
# Populate the app folder
$(CP) build.!Help/sed build.pkg.$(ROAPP).!Help $(CPOPT)
$(CP) build.!RunImage build.pkg.$(ROAPP).!RunImage $(CPOPT)
# Create the dummy file we use to mark the rule as completed
create build.pkg-dir

Since there are many situations in which the copy command will not copy, I've wrapped up the right options to use in a variable. Care is taken to specify all the options, even those which are set to the right value by default, just in case the makefile is being used on a system which has things configured in an odd manner.

CP = copy

In this case some of the options are redundant, since this rule completely wipes the destination directory before copying over the new files. But for bigger projects it might make sense to build the directory in a piecemeal fashion, where the extra options are needed.

Once the directory is built, the rule can produce the resulting zip file:

# Binary RiscPkg archive build/pkg-dir
remove binary/zip
dir build.pkg
zip -rqI9 ^.^.binary/zip *
dir ^.^

Note that in this case I could have merged the and build/pkg-dir rules together, since build/pkg-dir is only used once. And arguably they should be merged together, just in case I decide to test the app by running the version that's in the build.pkg folder, but it then writes out a log file or something that then accidentally gets included in the zip when I invoke the rule later on.

But, on the other hand, keeping the two rules separate means that it's easy to add a special test rule that copes the contents of build.pkg somewhere else for safe testing of the app. And as mentioned above, for big apps/packages it may also make sense to break down build/pkg-dir into several rules, since wiping the entire directory each time may be a bit inefficient.In closing

With a setup like the above, it's easy to automate building of packages for applications. Next time, I'll be looking at how to automate publishing of packages - generating package index files, generating the pointer file required for having your packages included in ROOL's index, and techniques for actually uploading the necessary files to your website.

No comments in forum

Categories: RISC OS

Orpheus hits crowdfunding target

Tue, 09/11/2018 - 16:26
In July, Orpheus announced their plan to crowdfund their new project.

With their usual modesty, they quietly recently updated their website to say the Company had raised the target figure and work has begun. Excellent news for RISC OS market and for their customers.....

On a personal note, my 6 year old router had issues over the weekend. Richard Brown from Orpheus was on the phone sorting it out at 9am on Saturday morning and helping me to sort out a replacement router asap.....

Orpheus Internet website

No comments in forum

Categories: RISC OS

RISC OS interview with Jerverm Vermeulen

Fri, 09/07/2018 - 05:53
This time, it is our pleasure to interview Jerverm Vermeulen, who has just released a RISC OS remake of the old BBC Micro game Dickie Brickie, which is now free on !Store.

Would you like to introduce yourself?
My name is Jeroen Vermeulen and I’m from The Netherlands. Recently I’ve remade the BBC Micro game Dickie Brickie for RISC OS which is available from the PlingStore.

How long have you been using RISC OS?
I’ve used RISC OS way back in the past and only quite recently came back to it. My experience with RISC OS started when I bought a Acorn A3000 in mid 1990. It was followed up with an A4000 which I used until around 1998. I then left the RISC OS scene. Shortly after the Raspberry Pi was introduced and RISC OS was available for it I started to play around with it again. Nothing too serious until mid last year when I decided to pick up programming again and do programming on RISC OS as well. Before I owned an A3000, me and my brother owned a BBC Micro from around 1985.

What other systems do you use?
Windows 10 PC/laptop, Apple iPad.

What is your current RISC OS setup?
RPI 2B with Pi Zero Desktop and SSD. Next to that I use emulators on Windows 10 like RPCEMU, Arculator, VA5000.

What do you think of the retro scene?
I very much love the RISCOS as well as the BBC Micro retro scene. For RISC OS for example I find it amazing what Jon Abbott has been doing with ADFFS. For the BBC Micro I’m finally able to collect programs I once only could read about and have a play with it. Some of the new software that appears for the BBC Micro is extraordinary and I find it very interesting to follow the forums with people like kieranhj, tricky, sarahwalker, robc to name but a few doing some wonderful things with the machine and making it work under emulation as well.

Do you attend any of the shows and what do you think of them?
No (not yet), but I follow the show reports via sites like Iconbar and Riscository. When available I even watch some of the show’s videos. I like it the reports/videos are online and they do give some valuable extra/background information if you’ve not been there. As well as put some faces with the names you otherwise only read about 😊

What do you use RISC OS for in 2018 and what do you like most about it?
Programming. I very much like the fact that e.g. AMCOG and Drag’nDrop programs are available and sources are “open” and thus can be studied to learn from. This and the AMCOG Dev Kit allows you to do things that normally would cost more time othwerwise. It’s is the reason why I decided to distribute the sources with the Dickie Brickie game as well, just in case…

Retro kind of things like running games and other programs. On my PC I have an application called LaunchBox which allows RISC OS and BBC Micro programs to be run with a click of a button under emulation. Software/Games that once I could only read about in the Acorn magazines of the time I’m now able to run. For some reason especially with the BBC Micro it was hard to get any software where we lived and we had to make do with programming some of it ourselves or get it by typing in from magazine listings. The latter leading me many years later to remake Dickie Brickie. Back in the day it was a lot of work to type it in, but when we ran it we finally got a glimpse what the machine was capable of with the sprites, sound and animations on display.

What is your favourite feature/killer program in RISC OS?
StrongED & StrongHelp, BBC Basic, Netsurf, ADFFS, ArcEm, BeebIt, InfoZip, AMCOG Dev Kit

What would you most like to see in RISC OS in the future?
Just ongoing developments in general like RISC OS Open is doing with some of the foundations of the system.

Favourite (vaguely RISC OS-releated) moan?
Things can always be better of course, but sometimes I’m just amazed that RISC OS is still around and actively used and developed for. For what I want to do with RISC OS currently – mainly programming – and the fact that I’m still (re-)discovering/learning things I don’t have any complaints

Can you tell us about what you are working on in the RISC OS market at the moment?
I have been working on a remake of a bbc micro game Dickie Brickie. I started remaking it using my own code, but when I learned about the AMCOG Dev Kit I switched over and rewrote most of the game. There is a really nice article on the game at the Riscository site.

Any surprises you can't or dates to tease us with?
I’m investigating a next game to program. I quite like the idea of making a platform game, but I’ve some learning to do on how to do that so it could be a while.

Apart from iconbar (obviously) what are your favourite websites?
Riscository, RISC OS Open (Forums), RISCOS Blog, DragDrop, Stardot (Forums) and some recently discovered websites on programming and game development.

What are your interests beyond RISC OS?
Programming and IT in general.

If someone hired you for a month to develop RISC OS software, what would you create?
That’s a tough question… perhaps some updates to Paint.

Any future plans or ideas you can share with us?
I would like to investigate the use of the DDE and C language.

What would you most like Father Christmas to bring you as a present?
Nothing very special comes to mind. But it would be nice if JASPP would be allowed to disctribute some more games and/or games from the past (e.g. 4th Dimension) would be more easily available.

Any questions we forgot to ask you?
No. Thank you very much for the interview!

No comments in forum

Categories: RISC OS

Acorn World at Cambridge computer museum, 8-9th Sept 2018

Sat, 09/01/2018 - 01:55
Acorn World 2018
Sat 8th & Sun 9th September, 10am-5pm
@ The Centre for Computing History, Cambridge

The Acorn & BBC User Group in association with the Centre for Computing History, Cambridge’s premier computer museum, are pleased to announce Acorn World 2018.

This exhibition will feature machines and software from across Acorn’s history and beyond, showing how they started, the innovative systems produced along the way, and the legacy of successful technology they left behind.

There will be a range of Acorn-era computers on display – and in many cases running for visitors to try out for themselves – covering everything from the System 1, through to the iconic RiscPC – which many recognise as the the pinnacle of Acorn’s computer designs – and beyond, including the never-released Phoebe, and a number of rare prototypes. The vintage displays will also include classic magazines, sure to set those nostalgic flames burning, and software which enthralled, entertained, and educated many users – and even inspired some to go into programming themselves.
Some of those classic computers have been given a new lease of life by enthusiastic users, with modern add-ons and other clever innovations – and there will be a number of these on display as well.

The exhibition doesn’t just stop at machines that came directly from the Acorn stable, though – there will also be post-Acorn systems, including the ultra-cheap Raspberry Pi and at the other end of the scale, the ‘slightly pricier’ Titanium – both of which are themselves children of Cambridge.

Tickets are only £8 for adults, £7 for over 60s, and £6 for children. This includes access to all the museum’s exhibits featuring mainframe, mini, home computers and games consoles from the past 50 years, plus the Guinness World Record holding MegaProcessor. This is a fund raising event for the museum to help continue their important work preserving and archiving computing history.

The Centre for Computing History, Rene Court, Coldhams Rd, Cambridge, CB1 3EW

No comments in forum

Categories: RISC OS

August News round-up

Fri, 08/31/2018 - 07:11
Some things we noticed this month. What did you see?

DDE28c update from ROOL.

Prophet Version 3.94 and Font Directory Pro 3.23 now available from Elesar

Orpheus Internet launches a crowdfunding campaign to finance the upgrading of their services. Latest total

It is games month on RISC OS blog!

New 32bit version of Dickie Brickie now on !Store for free.

R-Comp SP12a brings DualMonitor version 5 and lots of RISC OS 5.24 software updates to TiMachine.

The ROOL TCP/IP "phase 1" bounty reaches a major milestone with a beta release of the updated AcornSSL module, supporting the modern TLS protocol instead of the old and insecure SSL protocol.

André Timmermans releases DigitalCD 3.11 and KinoAmp 0.48. The new version of KinoAmp is able to use hardware overlays for improved playback performance on machines and OS versions which support that functionality.

ADFFS 2.68 released. ROOL have also updated their website

IconBar will be running regular articles over the Autumn after a bit of a summer break. We kick off next friday with an interview....

No comments in forum

Categories: RISC OS