Quick Links

A short history of CD(VD)Burn

Note: this is the history of CD(VD)Burn as I remember it. It is entirely subjective and of course incomplete.

It all started when the prices for CD writers came down at an incredible pace. I bought my first one (a Philips CDD2000) together with two friends in 1996 for 800 DM - nobody could imagine that anyone would ever burn more than a handful of CDs, so three users for one drive seemed to be all that was needed. After all, CD-R media was incredibly expensive (20 DM per piece), and uses were limited (my largest harddisc at this time was 540 MB!) - who in their right mind would want to write an Audio CD for 20 DM which was not even guaranteed to work in most CD players? And which CD players anyway? Discmans were expensive, so I still used a walkman. My car also had a tape-equipped radio. Those were the days...

At roughly the same time, the first CD writing software for RISC OS became available available - CDScribe by EESOX. It was only available as a bundled package together with a drive, and costed well over 1500 DM in Germany. So basically they asked for 700 DM for just the software! And I really didn't need another drive. So I started to look out for some docs on how the command set for CD writers looked like. By coincidence, the only freely available command set description was for the Philips drive I owned - so I started to knock up a quick prototype in good old BBC BASIC to see if my rather non-existent knowledge of the SCSI subsystem would suffice to get a CD written.

It was 1997-07-02 when the first Audio CD was successfully written by a piece of hacked-together BBC BASIC on a Philips CDD2000 connected to a Power-tec SCSI podule. No coasters were produced at all - after the first "simulated write" was going through successfully, I just turned off simulation mode and everything worked just fine. A few hours before that milestone, the prototype was extended to be able to extract audio tracks from Audio CDs, also known as "sampling", a job that only CDSampler was known to be capable of on RISC OS - after all, I needed some audio tracks for testing!

At the same time, I also followed the development of the NetBSD port for the Risc PC. One of its sore points was proper, fast drivers for various SCSI podules - many of the podules were only able to operate at "floppy speed" (less than 100 KB/s). A question posted by Stephen Borrill on 1997-08-01 somehow marks the start of proper CDBurn development - he asked whether it was somehow possible to write a CD with NetBSD, since he did not have software for RISC OS available. My answer that I had appropriate code for RISC OS to write CDs and that I intended to release the code probably as shareware prompted Robin Watts to email me - Robin happened to have a HP4020i drive, which was an OEM variant of my Philips CDD2000, so I offered to send him some prototype code so he could test write CDs on RISC OS.

Robin subsequently proposed to release CDBurn at Acorn World 1997. A good idea, so I evaluated my options. I really didn't want to continue writing hacky BASIC stuff (especially the looming necessity of an ISO9660 formatter frightened me away from a language without proper encapsulation and data structure support), and since I learned to love Ada 95 during some University projects, and a capable Ada compiler was just ported to RISC OS by Pete Burwood, I decided to create the first ever RISC OS WIMP application written in Ada. I still think this was one of my best decisions ever - in the light of extremely limited free time to do development, you really need a compiler and a language to detect most errors without testing.

One problem remained - it seemed very unlikely that I could produce a full ISO9660 compliant formatter in time for the show. So we decided to call the show version 0.99, bundle a port of mkisofs (done by Pete Burwood) with it, and promise a free upgrade to the version with complete ISO image creation. This worked a lot better than expected, and people were happy to buy CDBurn anyway. Fortunately, I was able to keep my promise, and the end of 1997 saw the release of 1.00, the first version which included the CDBurn ISO9660 image formatter.

A new technology called CD-RW was also introduced at the end of 1997, and in January 1998, rudimentary support was built into CDBurn to allow deletion of CD-RW media. At the same time, a new standard was born which was hoped to unify all the competing SCSI command sets used by CD writers until then: MMC, the MultiMedia Command set. However, it soon became clear that there are many ways to read a standard...

In July 1998, a new competitor for CDBurn arrived on the scene - CDBlaze from Cumana (written by Robert Harvey). Feature-wise, it was some way ahead of CDBurn at this time (Joliet support, in-built Joliet-capable CD filing system, multitasking writing operation), but it suffered from three problems - support for the older devices that CDBurn was able to use was not available, it was much more expensive than CDBurn and its user interface was a bit non-RISC OS-y, especially the ISO formatter.

At the end of 1998, CDBurn also gained Joliet image creation capability and was the ideal companion to CDROMFS, a CDFS replacement also sold by Warm Silence Software, which added (amongst other things) Joliet reading capability to RISC OS.

During 1999, it became clear that the CD writing hardware market was changing fast. There were a lot of IDE writers released, and the SCSI writers became rather exotic (and sometimes rather expensive!). So it seemed clear that CDBurn needed IDE capabilities better sooner than later, especially since the competition (CDScribe2 by EESOX) also added IDE capability. Unfortunately, free time was in short supply because I finished University and started a "proper" job in March 1999.

So IDE support surfaced in time for Wakefield 2000. It was not really made easier by the fact that, in contrast to SCSI, Acorn never defined a proper IDE/ATAPI API, so for every API on RISC OS (APDL/MicroDigital, Simtec/RiscStation, Yellowstone, Acorn), a specific implementation had to be done.

IDE support, the "standard" command set (MMC) and the creativity of the manufacturers to interpret it meant that the limitations of our upgrade process became very visible: until then, upgrades could be obtained by sending the CDBurn floppy disc to WSS, or by asking nicely via email. So I decided that it would be a good idea to have an upgrading route available which was not dependent on manual intervention and came up with the idea of an "Upgrader Application" which, using the original !CDBurn application and an upgrade file downloaded from the internet, could produce a new version. So since 2001, users really don't have an excuse for not using the latest version.

2002 was the "year of the IYONIX". Castle approached me a few months before the official launch and asked for a 32bit version of CDBurn that they could bundle with their forthcoming machine. This posed a "small" problem - while the Ada compiler I used was more-or-less capable of churning out 32bit code, the associated run-time which glued the SharedCLibrary together with the Ada RTS was 26bit only. Sources for this were lost a long time ago, and since Pete Burwood had to stop any computer activity around 2000, I had to get competent help to do a machine-code-level conversion of the code.

The list of people who are familiar with Ada, GNAT, the SharedCLibrary and ARM code is rather short - it really has only one entry: Martin W�rthner. In less than two days, Martin did the miracle: a 32bit conversion of all the critical code, which immediately resulted in a 32bit compatible CDBurn which ran just fine on my IYONIX prototype. A special, feature-limited version called CDBurn Lite was created for Castle to allow bundling with the IYONIX, just-in-time for the IYONIX launch in October 2002.

During 2003, apart from stabilising the 32bit version along with the IYONIX IDE transport, the idea of a "softloadable driver" was born. Internally, CDBurn always had a few in-built switches which route to take when different drives were detected. The "softloadable driver" should let the user access all those switches to be able to tinker with non-working drives. In the end, this was not very successfull, since it turned out that nearly all drives worked with one of two basic setups.

May 2004 saw a major change in CDBurn history. Since WSS seemed to have lost interest in the RISC OS market, I decided do start my own company to handle CDBurn sales, hubersn Software. In case you have ever wondered - hubersn was my login name at University, and is composed of my surname and the first and last letter of my forname. Wakefield 2004 saw the very first public presence of hubersn Software.

In 2005, I thought about the forthcoming Wakefield Show and what to sell to people. The logical next step was of course adding DVD writing to the product, and so I asked for beta testers and set up a mailing list for the beta test of DVDBurn (as it was called back then). The first beta was released to testers on 2005-05-12, only capable of writing less than 2 GB and those exclusively to DVD+RW discs. A few days later, DVD+R and DVD-RW was supported successfully, as well as >2GB content. For the Wakefield Show, I decided to change the name to "CDVDBurn" to indicate that it is capable of writing both CDs and DVDs.

2007 saw the addition of two major new features. One is DVD-RAM support - this was surprisingly easy to implement, and really a shame that it wasn't included right from the start. The other feature is something that is best described as "a poor man's CD filing system" - it is basically a combination of CDVDBurn's ISO filer, the "import session" facility and a bit of glue code to give you something that behaves like a proper CD filing system without being one. So I hear you ask "why would I need this?". At the moment, it is most helpful for people who don't have a Joliet-capable CD filing system (either Select CDFS or CDROMFS), whose CD/DVD writer does not work with any softloadbale CDFS driver or who want to read large images (> 2 GB) without writing them first. But it has a lot more potential: access to arbitrary tracks and sessions, access to different volumes (e.g. ISO9660 vs. Joliet), support for other formats (UDF, CSS-DVD). A full filing system would be even better of course, but not something I could implement in my free time - and it would feel a lot like reinventing the wheel (CDFS, CDRFS, CDROMFS).

And that's where we are today. Thank you for reading.