A tiny little update coming soon

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 🙁

CDVDBurn 3 now available – order now!

I finally decided that the current state of development of CDVDBurn 3 is “good enough” for the first release. The hubersn Software website https://www.hubersn-software.com/ has been updated accordingly, you can look at the new CDVDBurn 3 product page, or alternatively the press release.

It is always difficult to decide when such a state is reached. The very nature of software is that it is never perfect. You can always improve the UI/UX further. You can always improve the documentation. And the website. And add yet more drives to the compatibility list. And test some more drive/OS/machine combination. And optimize the performance further. Anyone who tells you that a piece of software is “perfect” is probably lying.

Now that the release is out of the way, I will continue to improve CDVDBurn 3, and provide free upgrades to users for the foreseeable future.

Things that are not really in a state where I’d like them to be include the new manual (long-time users might remember that CDVDBurn never had a “proper” manual, it came with the CDBurn manual and a DVD addendum). The Upgrader application that will be needed to provide the downloadable upgrades is not ready yet. And I am currently analysing why the Samsung SH-224 drive (widely used in ARMX6 and Titanium systems) will not write Audio CDs, ending with a “SCSI Timeout” error. This was a finding of two of my beta testers, so I bought a drive off eBay (they are no longer available as new) and received it today.

At least, I have already written some text for support pages for CDVDBurn 3 users: the ever-important list of currently supported writers, and the start of the hopefully ever-improving FAQ.

CDVDBurn 3 – Drives, Drives, Drives

One of the most important things to get right before the release of CDVDBurn 3 is drive compatibility. In an ideal world, CDVDBurn 3 would “just work” with all drives available past, present and future. Unfortunately, experience tells us that this will not happen, unless I get very very lucky.

So to make the best of the limited resources I have (both financially in buying drives and enough time to test them extensively), I somehow had to make compromises. So I identified three groups of potential CDVDBurn 3 users that have to be catered for.

Group 1: users who already have a drive, e.g. because they already own a USB drive for their PC or because they bought a complete system like the ARMiniX, the ARMX6 or the TiMachine that are usually delivered with a CD/DVD writer.

Group 2: users who are prepared to buy a new drive and want to know which they should go for. So CDVDBurn 3 needs good compatibility with drives available to buy now.

Group 3: CDVDBurn customers who want to keep using the drive they have always used with previous versions of CDBurn or CDVDBurn.

To be honest, for the first release of CDVDBurn 3, group 3 will not be the focus group. CDVDBurn 3 will (at least initially) not come with compatibility for RiscPC-age stuff like IDE writers connected to a Simtec IDE podule, or SCSI writers connected to a Castle SCSI podule. However, IYONIX IDE support is thought to be still intact and working. I think this is not a major loss, because the old version of CDVDBurn will keep on working, and you can still enjoy some of the new features of CDVDBurn 3 like the Extractor.

After many tests and a lot of work on the driver code to get a reasonable amount of drives working, the current “CDVDBurn 3 drive compatibility matrix” looks like that:

Drive IF Style CDFS Audio read Extractor Data CD Audio CD TAO Audio CD DAO DVD-R DVD-RW DVD+R DVD+RW DVD-RAM BD-R BD-RE
Asus ZenDrive U7M USB Slimline OK OK OK OK OK OK OK OK OK OK OK
LG GP57ES40 USB Slimline OK OK OK OK OK OK OK OK OK OK OK
LiteOn EBAU108-01 USB Slimline OK OK OK OK OK OK OK OK OK OK
Samsung BD-DVDW SE-506 USB Slimline OK OK OK OK OK OK OK OK OK OK OK OK OK
Asus BW-16D1H-U Pro USB External OK OK OK OK OK OK OK OK OK OK OK OK OK
LG BE16NU50 USB External OK OK OK OK OK OK OK OK OK OK OK OK OK
Asus BW-16D1HT Silent S-ATA Internal OK OK OK OK OK OK OK OK OK OK OK OK OK
LG BH16NS55 S-ATA Internal OK OK OK OK OK OK OK OK OK OK OK OK OK
LG BH16NS40 S-ATA Internal OK OK OK OK OK OK OK OK OK OK OK OK OK

As you can see, nearly every type of medium is listed separately – this is because the code to write those different media is also different. One exception is CD-R and CD-RW, which is identical, so you only see “CD” in the table row headers.

So, if you are a user in my group 2, which drive should you buy? It depends on a lot of things. Should it be an external drive (style “Slimline” and “External” would match here), i.e. connected to USB, or an internal drive (native S-ATA on the Titanium, or via the inbuilt S-ATA-USB adapter on the ARMX6)? Should it be a drive capable or reading and writing BD media (more expensive), or is a DVD writer sufficient (cheaper)? At the end of the day, it also matters which drive is actually available from the dealer of your choice. My gut feeling is that the drives labelled “External” are less problematic than their “Slimline” cousins, because they are not powered via USB, but with their own PSU. But they are a lot more spacey. My recommendation for “Slimline”-type drives is to always connect them via a powered USB hub. An USB3 hub will (currently, because of lacking RISC OS support) not make your drive faster, but their power supply is usually a lot stronger, so if you can afford one go for it.

If you are a user in my group 1, just connect the drive you already have to your RISC OS machine and first of all check if it works fine as a CD and DVD reader via CDFS. Then, you would check the exact drive name in a taskwindow with the command

*devices

if it is connected via USB or with the command

*satadevices

if it is connected via S-ATA on your Titanium. Keep in mind that what is sold as “Samsung” calls itself “TSSTcorp” (“Toshiba Samsung Storage Technology”), and “LG” drives identify themselves as “HL-DT-ST” (“Hitachi-LG DaTa STorage”).

If you find that drive (or a slight variation of it – sometimes, different case colours result in different names, like with the LG GP57ES40 from the table above which is the silver colour, the same drive is also available in black as GP57EB40 and in white as GP57EW40 – you should be safe and CDVDBurn 3 will work finde with your drive. If you have a drive that is not listed above, please contact me and we will work out a way to analyze your drive before you actually buy a licence. From my current knowledge, I would expect that nearly every LG and Asus drive should work flawlessly with CDVDBurn 3.

Currently, there are known problems with a range of Samsung (TSSTcorp) drives, especially with Audio Disc-at-once writing mode. I will try to get that fixed, but no promises. When I get the time, the table above will also show drives that I know don’t work perfectly, with indications where they fail.

Developing CDVDBurn 3 – Ready For Test

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.

Developing CDVDBurn 3 – Finally…Success!

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.

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

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”.

Blog.init.2

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.

Navigation