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.