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.

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