Long time no post….so I’ll sum up recent and not-so-recent development.

Long story short: there will soon be a small update to CDVDBurn 3 (free for existing CDVDBurn 3 customers), along with the necessary Upgrader application.

It came to my attention that there were specially formatted DVD-RWs (e.g. previously used in Video DVD recorders) that CDVDBurn refused to blank. This is now fixed, and blanking works for all states of media.

There is a shortcoming – not exactly a bug, since it was never an implemented behaviour – when using the Disc Extractor if the format on the CD/DVD/BD is not plain old ISO9660/Joliet, but one of the UDF incarnations. In this case, a rather nasty and unhelpful error message was shown. The new version will properly detect (hopefully all variants of) UDF formats and inform the user that this format can not (yet!) be extracted.

In trying to get certain Samsung DVD writers to successfully write Audio CDs, I added a lot more parameters for specific media in the softloadable driver config. The extended doc will be published along with the new version. A set of default driver configs will be delivered with the update, if you are one of the very few who crafted your own driver config, these need to be amended slightly.

Unfortunately, those problematic Samsung DVD writers will still refuse to properly write Audio CDs (both the old and the new hardware revisions of the SH-224), so it was not the most successful code change in CD(VD)Burn history 🙁

The first Release Candidate has been sent out to my helpful beta testers to widen testing on different drive-machine configurations, especially with drives that I don’t have access to myself. As I mentioned in my earlier post The Testing Challenge CDVDBurn is a bit of a special case concerning a proper testing strategy. Working with a variety of different hardware is always a challenge, and the additional variety of machines and media makes it extra-difficult.

My “point of no return”, i.e. the moment of confidence when a version of a software reaches the “ready for test” state was when I did a final test run of all media types (CD-R, CD-RW – both Audio and Data, DVD-R, DVD-RW, DVD+R, DVD+RW, DVD-RAM) on the three newest drives I have. Lite-On EBAU108-01 (this drive unfortunately does not support DVD-RAM, but has the lowest price point), Asus ZenDrive U7M and LG GP57ES40 – all of them quite cheap (20€ to 35€) and of the slimline USB type which get their power exclusively via USB, which allows easy external connection to all target machines from the classic IYONIX to the very latest Raspberry Pi 4 – and everything in between. So all looked good, which meant “Ready For Test”.

While the testers are busily (and hopefully happily!) beavering away, I did some further tests in different scenarios to get a better feeling for overall drive and machine compatibility. The LG BH16NS55 which is inside my ARMX6 (and therefore connected with an S-ATA-USB adapter) works fine. Its older brother, the LG BH16NS40, works fine on the Pi 4 connected with an S-ATA-USB adapter and an external powered USB3 hub (only working in USB 2.0 mode of course!). One of the big external USB Blu-Ray writers, the Asus BW-16D1H-U Pro, successfully wrote several types of media connected to the ARMX6.

Then, I started to get adventurous and resurrected my old IYONIX (RISC OS version flashed: 5.16, that’s 2010 vintage…), put RISC OS 5.28 in softload and connected one of my oldest USB drives that still work, a Samsung DVD writer named SE-S084C (manufactured July 2009) and it wrote a data CD-RW with only one minor problem (eject of disc at the end of the write did not work, but the disc was written OK). A very promising result. To try to extend that streak of luck, I quickly tested the Pioneer DVR-109 IDE writer which is stuck in my IYONIX since perhaps 2007 when I last tried to get it to work properly. And…without hesitation, it burned a DVD-R.

So all in all, it looks fairly good. My original goal was to come up with at least 3 compatible drives – internal S-ATA, external slimline USB, external “big box” USB, if possible all of the Blu-Ray type. “Compatible” in the sense of “works at least with CDFS as a reader and writing CD-R, CD-RW, DVD+R, DVD+RW, DVD-RAM”. Now there are a lot more drives that seem to work faultlessly, and additionally DVD-R and DVD-RW now also work quite reliably.

Of course, the TODO list is not empty yet – all effort has currently been focused on “USB” to cater for all new RISC OS 5 machines since the IYONIX. But it would be nice to also have well-tested IDE support for the IYONIX and S-ATA support for the Titanium. Additionally, there are a few known niggles that make CDVDBurn sometimes a bit confusing especially for the new user without a lot of knowledge about drives, media and their capabilities. The only critical error found to date, a real crash because of a wrongly translated German window template, has already been fixed.

Sometimes, success comes to those who wait.

Sometimes, it helps to pick up a lost cause from 2005.

Sometimes, it helps to re-read the documentation aka “The MMC Standard”. Yes, all six variants.

Sometimes, it helps to think about a problem for more than 15 years.

Sometimes, it helps to come back to develop in programming language A after spending fifteen years almost exclusively developing in programming language B.

Sometimes, it helps to start early in the morning and do one of those classic hardcore coding session until late at night (i.e. until ten minutes ago).

Sometimes, it helps to pre-think possible variants of command sequences with endless combinations, externally configurable of course, just to find out that the very first combination you test works.

Sometimes, it helps to just throw out the old stuff and start from scratch.

I won’t disclose further details – the end result is that I have, for the first time ever, successfully written both DVD-RW and DVD-R media with CDVDBurn. Ironically, it happened on a Blu-Ray writer. You might remember that DVD-RW already worked before, but that was sheer luck and was possible only on very few drives. I am now confident that the new writing routine will work with most drives. The next few days will tell.

Current state of play (unfortunately not for all drives yet, but for many of them):

• Audio CD: check.
• Data CD: check.
• Data DVD-R: check.
• Data DVD-RW: check.
• Data DVD+R: check.
• Data DVD+RW: check.
• Data DVD-RAM: check.

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.