Developing CDVDBurn 3 – The Testing Challenge

CDVDBurn 3 (and before that, CDBurn and CDVDBurn) basically has two really complex parts: the ISO9660/Joliet image creation stuff (maybe along with the pseudo-filer that tries really hard to mimic the RISC OS filer), and the part that controls the actual hardware we ultimately want to use – the writer. While the ISO9660 formatter is mainly unchanged since Joliet extensions had been added back in 1999, the driver code to control the writer is in constant change, mainly because the available hardware changes all the time, and you wouldn’t possibly believe how one can interpret a standard in creative ways.

So what are the current challenges when developing a piece of software like CDVDBurn 3 that contains such an ever-changing low-level layer trying to talk to also ever-changing hardware? There is only one real challenge: testing.

There are basically three dimensions of variation that currently need to be covered by testing: machines, drives and media types. I say “currently”, because of course I plan to fully support S-ATA on Titanium while retaining IDE compatibility with the IYONIX pc and possibly adding the Risc PC to the mix, which would be the fourth dimension, but I have decided to focus on USB-only for the first release of CDVDBurn 3.

Talking of machines, my current testing happens on ARMX6, Titanium, Raspberry Pi B+ and Raspberry Pi 4 – so RISC OS 5 on everything from “Low End” to “High End”. Available for further quick regression tests are IYONIX pc, Risc PC, Raspberry Pi Zero, Raspberry Pi 2, Raspberry Pi 3 B and B+, BeagleBoard-xM and PandaBoard ES.

Talking of drives, my current testing focuses on Samsung and LG drives, both BD and DVD writer variants, both in S-ATA-USB-adapted form (like used usually inside the ARMX6, but can also externally be connected to all USB 2.0-capable machines) and in the typical “slimline USB” form. Three different Samsung drives are tested concurrently, as well as three LG drives and one Asus drive thrown into the mix. I also did some tests with Pioneer drives, but they did not work out-of-the-box with CDFS, so I put them onto the todo list instead of investing much time to get to the bottom of this problem.

Talking of media, as I explained elsewhere, the DVD media types are all different and hence need to be tested separately. So it is CD-R/RW (mainly CD-RW with the odd CD-R thrown in when I feel like it), DVD+R, DVD+RW, DVD-RAM and DVD-RW for the DVD writers and additionally BD-R and BD-RE for the BD writers. And don’t forget the double layer variants. There is quite a stack of cakeboxes currently surrounding my desk.

If you calculate your way through the combinatorics, you begin to see the problem. Every drive, every media type, on every machine? That won’t work out unless I hire a bunch of professional testers. So it boils down to test one drive on one machine with all media types, and then doing cross-checks for extra security. So far, I can report that the main difference to be seen from the different machines is of course the performance aspect. For example, the ARMX6 will far outrun the possible writing speed of a Raspberry Pi operating from a slow microSD card. There are slight variations in error reporting from the USB part, but that seems manageable.

Currently, I use a mixture of RISC OS 5.24, late 5.27 nightly builds and the brand-new 5.28 to do the tests, and I am happy to say that RISC OS itself does not seem to introduce an additional problematic dimension to the equation. Phew, and knock on wood.

When doing the tests, it is essential to run them concurrently on the different machines to maximize efficiency. A meaningful test runs at least 5 minutes to put enough data onto whatever medium tested, and this is followed by a close inspection of the logfile which usually runs to between 4 MiB and 8 MiB of text. If there are unexpected errors in the log (and yes, there is such a thing as an “expected error” due to drive and bus variations unfortunately), it means changing the code ever so slightly to not risk invalidating all the testing so far. The “read” part has to be verified too, both via CDFS and via the new Disc Extractor facility as well as grabbing audio tracks.

With testing, the important thing is “focus”. Therefore, as explained above, I am restricting myself to test USB drives. Once I have a working version out, I’ll get into IDE/S-ATA testing on Titanium and IYONIX, as well as possibly the Risc PC if I can still find a drive that won’t overload the PSU. On the Risc PC however, things start to get interesting again: internal IDE, one of the various IDE podules, maybe SCSI podules with the help of an IDE-SCSI-bridge…you see, the “Testing Challenge” never ends.

Developing CDVDBurn 3 – Restart

Every experienced developer will eventually tell you the same thing – that the really hard task is not to develop some random piece of software, but to develop it in a way that it is long-lasting, extendable and still maintainable over several years. That it is stable yet easy to change. That is stays “soft”, as one wise developer once told me.

With CDVDBurn 3, there were some special additional challenges along the way. The codebase started its existence in 1996, nearly 25 years ago. It was a somewhat rushed port from a lump of BBC BASIC (the original CDBurn prototype) into a procedurally structured piece of Ada 95 code. The “toolkit” for the WIMP stuff is a very simple thin binding with procedures and functions barely above SWI level.

While I am still happy that I chose Ada to develop CDBurn and now CDVDBurn 3, it poses additional challenges. The compiler – based on GCC – is firmly in the 26bit camp and is one of those applcations that are not entirely happy running under Aemulor. And the code it produces has some restictions – you can only use very basic Ada features if you want the code to run on ARMv5 (IYONIX), ARMv7 (Cortex-A7/8/9/15) or even ARMv8 (e.g. Cortex-A72). Forget representation clauses. Forget tagged types. Forget significant parts of the runtime.

So restarting development of some codebase that is nearing its 25th birthday and that hasn’t been touched seriously in more than 10 years poses various challenges. Simple ones like “where am I going to compile this” (I moved from the Risc PC to Virtual-RPC and now to RPCEmu for all 26bit computing a long time ago, and the Ada development environment was still intact). Harder ones like “which is the latest sources that I built those three betas in 2017 from when S-ATA support for Titanium was added”. Decisions like “should the way the sources go into VCS be changed”. Or “should I start refactoring significant parts of the code, or only those parts that I am likely to change”. And of course working out how to test that code in an efficient manner on many platforms in parallel – if your average test (“write that DVD”) takes 15 minutes, you better had a few machines and drives available along with a good idea how to collect the test results.

The good news is that I still know my way around inside the code, although memory gets a bit light on the details. Amusingly, mostly on details I changed later on, while the initial details from 1996/1997 are still remembered well. So most of the time I am reading old code instead of writing new code, but that’s the nature of software development if you are in the “product” business.

The most difficult part is to remember and strictly follow the “minimum viable product” principle. Every developer likes to start new stuff, coding cool new features. But the most important thing for CDVDBurn 3 is currently to “finish”. Round the rough edges. Make more drives work. Finish previously half-baked features, or make them temporarily inaccessible if they are not ready for prime time yet.

CDVDBurn 3 – Features

Below is a rundown of the major new features in CDVDBurn 3 compared to the original CDVDBurn.

Ready for the new RISC OS machines

CDVDBurn 3 is compatible with all the new RISC OS 5 machines including but probably not limited to

  • Raspberry Pi Zero/1/2/3/4
  • ARMX6/mini.m/Wandboard
  • TiMachine/Titan/RapidO Ti/Titanium
  • RapidO Ig/IGEPv5
  • ARMini/BIK/BeagleBoard
  • ARMiniX/PIK/PandaRo/PandaBoard

This especially means that CDVDBurn 3 will run just fine on the latest ARMv8 platforms like the Raspberry Pi 4.

Much of the testing was done on RISC OS 5.24 and – on the RPi 4 – on a late development version of RISC OS 5.27, so chances are good that the recently released 5.28 won’t create any unforseen problems.

Ready for USB

While USB for optical drives like CD/DVD/BD writers works on RISC OS via the SCSI route, it took quite a few changes in CDVDBurn 3 to achieve acceptable compatibility with various drives. Thanks to the various performance enhancements over the years on the RISC OS side, CDVDBurn 3 can now operate via USB 2.0 in a much better way than it was previously possible e.g. with IDE on a Risc PC.

Ready for new media types

When CDVDBurn was first released, the various DVD formats were king, typically providing 4.7 GiB of capacity. Nowadays, many modern drives support writing the new BD-R (writable) and BD-RE (re-writable) media, starting with as much as 25 GiB capacity on a single disc. As an extra bonus, DVD-RAM is now officially supported.

Ready for modern drives

When CDBurn appeared, there was no uniform standard available that governed the command set to drive CD writers. A bit later, the MMC standard was invented – more than 20 years ago. However, with the appearance of ever more advanced technology like the various DVD media types and of course BD, new MMC standards appeared on a regular fashion, with MMC6 being the latest and greatest standard. Those standards are not 100% backwards compatible, and modern drives implement something in between MMC2 and MMC6. CDVDBurn 3 has been extensively tested on various devices to ensure good compatibility across the board. There are still drives that work in a not-exactly-optimal fashion, information on preferred drives will be published as soon as possible.

Problems with CDFS? CDVDBurn 3 might be the solution!

For a long time, choosing the right drive for RISC OS was difficult because the typical CDFSSoftXXX drivers had not very good compatibility across the board. While this has significantly improved both on the USB and the ATAPI side of things, the new CDVDBurn 3 comes with a new feature named the “Disc Extractor”. This feature leverages existing CDVDBurn code like the ISO filer and multisession import capability to provide a filer-like view on Disc data – ISO9660, Joliet, Rockridge Naming Extensions, all supported. Drives are accessed directly, circumventing all problems caused by incompatible CDFS drivers. Data can be extracted with the usual drag&drop from the filer-like view directly onto your harddisc.

As an extra bonus, the “Disc Extractor” can directly use the “large” image format CDVDBurn had to introduce to work around the RISC OS filesize limit. You no longer need CDFaker to access any disc images, just use CDVDBurn 3.

CDVDBurn 3 – The Plan

I am currently working on a major update for CDVDBurn, which I cunningly named “CDVDBurn 3” – the original CDBurn was “1”, its successor CDVDBurn was “2”, and so the new version is now “3”.

Version numbering issues aside, here are the important points.

CDVDBurn 3 will run on all modern RISC OS 5 platforms, from the Raspberry Pi (all models!) to the ARMX6 and the Titanium. This means compatibility up to and including ARMv8 (e.g. Raspberry Pi 4). While support for USB-connected drives was the focus of development and testing – mainly because all new platforms have USB capabilities – there is also preliminary support for S-ATA on Titanium.

CDVDBurn 3 supports many modern drives, compatibility got a lot better than with previous versions. Writing Audio CDs in Disc-at-once mode is now also much more compatible than ever before. Additionally to the well-known CD and DVD features, CDVDBurn 3 adds support for BD-R and BD-RE media, currently allowing for 25 GiB on one disc. Hopefully, the even larger media like BD-R DL and BD-R XL will also get supported soon.

An interesting new feature is the “Disc Extractor” which provides users with a CDFS alternative to access ISO9660-formatted CDs, DVDs and BDs. Joliet extensions as well as Rockridge Naming Extensions are also supported. ISO images can be read directly, even the “large” CDVDBurn image format. So if CDFS and its drivers does not like your drive, there’s now a new hope!

CDVDBurn 3 will be a chargeable upgrade, the price is currently intended to be 25 UKP for an upgrade from the old CDVDBurn. New licences for the full version will be available for around 50 UKP, a significant reduction on the last CDVDBurn price of 65 UKP.

Hopefully, CDVDBurn 3 will be available soon. Soon as in “a few weeks”, not in “a few years”.


Only one year after coming up with the idea of having a hubersn Software specific blog, I have re-started CDVDBurn development with an aim to release “CDVDBurn 3” this year.

I will use this blog both as a development diary (category “CDVDBurn Development”) and for product information (category “CDVDBurn”), not going too far into the boring details, but mentioning some interesting things I encounter during my attempt to bring CDVDBurn up-to-date for a new release.

For other RISCOSy things in German language, you might want to read my private RISC OS blog.