Drobe :: The archives
About Drobe | Contact | RSS | Twitter | Tech docs | Downloads | BBC Micro

CDVDBurn to support DVD-RAM

Published: 25th Feb 2007, 01:17:47 | Permalink | Printable

Hard disc-like DVD writing prototyped

Steffen Huber at a Wakefield showCDVDBurn developer Steffen Huber has succeeded in writing to a DVD-RAM disc using RISC OS - and has even considered implementing Blu-ray support too. Steffen said he hopes to build the DVD-RAM write support into a future release of disc authoring package CDVDBurn, and is set to release a beta version for punters to test drive.

His prototype code was tested on a recent Lite-On device (SHM-165H6S), and the disc was read back on his Iyonix with the standard CDFS driver.

DVD-RAM, compared to DVD+RW and DVD-RW, is thought to be more suitable for backing up and archiving data from computers - it's known to be a more reliable medium, and is laid out in sectors like a hard disc. It is also more suited to the slower writing speeds achievable on RISC OS-powered hardware, and can be overwritten at least 100,000 times, compared to 1,000 times for DVD+RW.

The downside, said Steffen, is that only a few devices can read and write DVD-RAM discs. The capacity of DVD-RAM discs ranges typically from 2.58GB to 9.4GB.

Hubersn software's Steffen, pictured, said: "I have finally managed to successfully prototype DVD-RAM writing. This will be integrated into CDVDBurn in due course and made available in a public beta version.

"Obviously you'll need a drive that is DVD-RAM capable in the first place, which somehow limits the usefulness of this new feature for many existing customers.

"I also had a look into Blu-ray writing. Judging by what is written in the MMC5 standard, it seems rather complicated to handle. It also looks like current drives will only be available as S-ATA variants."

Steffen reports that he has also worked on a new universal soft-loadable CDFS driver for all RISC OS machines and modern ATAPI drives that are physically compatible. He said he grew tired of working around bugs in the various different flavours of CDFS available, and hopes to have a basic working version of his module ready for the Wakefield show in May. This is hoped to be free for current and future CDVDBurn users, and a small charge for everyone else.

He has also developed a data extraction tool for CD and DVD discs, a number of bug fixes for CDVDBurn, a verify utility for freshly-written discs, and a firmware upgrade tool for various devices.


Hubersn Software website Steffen's original email

Previous: Create drawfiles from BASIC with DrawAid
Next: South West show reports and photos


Viewing threaded comments | View comments unthreaded, listed by date | Skip to the end

This sounds really good. I must get a DVD writer in my iyo and upgrade.

Is the CDFS driver the lower level one (CDFSsoft_Atapi) or the higher level driver or both?

The DVDRAM support sounds really interesting, would formatting the media as an ADFS volume be possible? (Though I guess this would be outside the scope of CDVDburn.)

 is a RISC OS Userjess on 25/2/07 10:21AM
[ Reply | Permalink | Report ]

So what are the DVD's I stick in the DVD player attached to te TV to watch films etc?

 is a RISC OS UserAW on 25/2/07 2:30PM
[ Reply | Permalink | Report ]

AW: They are normally called video dvd's. See [link] for more info. Gosh, I actually found that in about 5 secs...

I was hearing very little since the CDVDBurn launch, so it's quite refreshing to hear Steffen has been busy. I look forward to the new CDFS driver. It may be a wild guess, but perhaps Steffen can benefit from some of the CinoDVD developments made by Adrian Lees?

 is a RISC OS UserhEgelia on 25/2/07 3:10PM
[ Reply | Permalink | Report ]

Well I didn't see DVD-Video listed on the link provided so I thought it might represent on or more of those formats on the page.

 is a RISC OS UserAW on 25/2/07 3:22PM
[ Reply | Permalink | Report ]

I don't think making DVD-videos is possible, or likely in the near future with CDVDburn.

However, many recent DVD player will play mpegs, mp3 and DivX files from standard CD and DVD ROMs.

This works fine with CDBurn (as would be expected).

 is a RISC OS Userjess on 25/2/07 3:41PM
[ Reply | Permalink | Report ]

The Update that Steffen is considering to finally help us get rid of that more or less bad CDFS is a very welcome one!

 is a RISC OS Userhzn on 25/2/07 5:55PM
[ Reply | Permalink | Report ]

The phrase "harddisc-like DVD writing" is a bit misleading. I have not implemented a filecore filing system for DVD-RAM, but have added a specific writing method inside CDVDBurn for DVD-RAM writing just like DVD+R, DVD-RW and DVD+RW before. So your written DVD-RAM will be read by standard CDFS and contains whatever CD/DVD format you chose for your image (usually ISO9660+Joliet).

If someone wants to implement a filecore fs for DVD-RAM, please contact me - writing to DVD-RAM is really (comparatively) easy, the only stumbling block would be the 2048 bytes/sector size which is not supported natively by filecore.

 is a RISC OS Userhubersn on 26/2/07 12:19PM
[ Reply | Permalink | Report ]

Full marks Steffen !

DVD-RAM is actually a rather more suitable standard for storing data than either DVD+/-RW (in part because it *can* be written up to 100,000 (divide that by about 100 for the others....)). It also natively supports data error detection and correction (part of the reason DVD-RAM appears slower is that it *verifies* after each write - so that an x5 DVD-RAM appears to run at 2.5x). The others (+/-RW)[*] don't bother - it's up to the implementer to do the leg work.

On PC's it's possible to read/write a DVD-RAM like a removable hard disk - using UDF. Speed wise they'd "feel" faster than a hard disk on a RISC PC - although formatting them takes an age.... Given a proper DVD-RAM filecore there's no reason why using "drag and drop" writing to DVD-RAM would not be possible.

Again well done Steffen !

[*] Actually Microsoft's Mount Rainer format supporting drives does verify (+RW) - if you find one take a photo of it - they're as rare as hens teeth.....

 is a RISC OS UserAMS on 26/2/07 1:25PM
[ Reply | Permalink | Report ]

Very impressed by this. Thanks Steffen for all your hard work to make this possible.


 is a RISC OS Usernx on 26/2/07 3:35PM
[ Reply | Permalink | Report ]

AMS: "Actually Microsoft's Mount Rainer format"

Microsoft's? Showing your bias again, AMS! ;-)

Actually, I wondered whether someone would mention Mount Rainier. Apparently, various drives support it, but people making operating systems don't seem to be interested: there are some tools for Linux for formatting the discs but no-one seems to be interested in making them work portably, so they stay outside all the distros, even though the kernel support has supposedly been present for years. At some point I'll dig out a CD-RW disc and see if it all works on my supposedly CD-MRW-capable drive.

But getting round to my point, since Mount Rainier is based on UDF, and since DVD filesystems are supposedly UDF (for typical computing applications), can't DVD+/-RW discs be handled like hard disks, too? In other words, do you really need DVD-RAM stuff for such trickery?

 is a RISC OS Userguestx on 26/2/07 5:20PM
[ Reply | Permalink | Report ]

guestx: Since we don't have UDF support (limited read support available via CDROMFS), it is a bit theoretical to talk about MtRainier usage, and to be honest the whole "incremental writing" stuff since the first CD-R is a bit of a mess, and firmware competence is - erm - varying. The problems in incremental writing are always the last that get fixed, since only few users seem to be interested.

The nice thing about DVD-RAM is its automatic defect management. The software is always presented a continuously writable array of sectors, and the drive in cooperation with the medium does the hard work to map out physically damaged sectors - therefore, even direct filecore or whatever FS usage is feasible. DVD+RW does not provide this, and you have to worry about its "16 sectors always written at once" behaviour and its "no more than 1000 writes on every 16 sector block" problem - UDF therefore tries to spread its writes over the whole surface, constantly moving around its directory data etc. DVD-RW is even more complicated due to its limited "direct overwrite" capability - just read the MMC5 standard to get an idea about it. Its complexity however is easily surpassed by BluRay...

I stopped worrying about UDF when the 1.50 spec came out which was incredibly complex - writing an UDF for RISC OS from scratch seems to be an impossible thing given the limited developer time available. The only sensible approach would be to port the Linux UDF stuff. Any takers?

 is a RISC OS Userhubersn on 26/2/07 6:45PM
[ Reply | Permalink | Report ]

hEgelia: the one extremely interesting thing happening in the Cino project (at least for my usage ;-)) was the UDMAing of ATAPI access in ADFS. Unfortunately, Adrian seems to have spent a lot of time creating the DVDFS (duplicating what CDROMFS already provides) and the MPEG2 decoding stuff (too slow for full speed playback) which is - now that development seems to have stopped - basically a lost cause. I really hope Adrian will be here in a minute and correct me...

 is a RISC OS Userhubersn on 26/2/07 7:01PM
[ Reply | Permalink | Report ]

guestx wrote>"Microsoft's? Showing your bias again, AMS! ;)

Nah probably a bad case of cynicism on my part (what with Mt Rainier being in Washington State not that far from Seattle - and home of you know who....).

Steffen wrote>"I stopped worrying about UDF when the 1.50 spec came out which was incredibly complex "

Agreed. But here's the thing, UDF is really only needed if you *want* your disk to be readable directly on any other machine. But for *our* purposes might it be sufficient to use a *different* (less obstuse) filesystem (e.g., son of filecore or the like). Yes it might mean the thing can't be directly read on anything else - but either we can (a). Provide a means to convert it to "vanilla" ISO-9660 with Joillet extensions so others can read it or (b). Make the filesystem specification *publically* available (or even the source if one is in a "giving" mood) and that would mean others could accept and read disks from us.

 is a RISC OS UserAMS on 27/2/07 12:18AM
[ Reply | Permalink | Report ]

Windows XP lets you treat DVD RAM discs just like any old disc. It does this using the native FAT file system. The result is disc access that is slow and discs that are unreliable. My guess is that this is due to FAT repeatedly updating the disc directory - OK on magnetic media not good on optical.

The UDF on the other hand is designed to minimise disc writes. To use that on XP you need something like InCD supplied with Nero. In my experience DVD RAM is then a much happier experience.

 is a RISC OS UserDavidPilling on 27/2/07 12:25PM
[ Reply | Permalink | Report ]

I have just uploaded the beta version of CDVDBurn with DVD-RAM support enabled to the hubersn Software website. It is provided via the usual "Upgrader" mechanism - check the CDVDBurn docs if you have forgotten how to upgrade (it has been a long time...)

 is a RISC OS Userhubersn on 28/2/07 1:08AM
[ Reply | Permalink | Report ]

At work recently we went through the pain of trying to write files to DVD-RAM on one of Linux's native formats. It was desperately slow - absolutely untenable for our application. The solution was to write much bigger blocks to the disc. I think the killer was the seek times, which are dire for CD/DVD drives compared to hard drives.

Initialising, writing and reading ADFS formats shouldn't be too difficult, and I feel tempted to have a go - but any normal use would soon exceed 100k writes to the map sectors, so it would be of limited usefulness.

UDF should be the way to go, but there are a couple of problems: (1) the spec is extremely difficult to understand (I did try a while ago); (2) the word out there is that there are very few correct implementations. (2) may be a consequence of (1).

A group of us maybe could crack this, given the will and a few correctly formatted UDF discs with some data on them. Lots of messages to discuss it, lots of experiments... any takers?

 is a RISC OS Userdavehigton on 3/3/07 8:18PM
[ Reply | Permalink | Report ]

Stating the obvious, but is there not a Linux implementation of UDF that can be used as a reference?

 is a RISC OS UserDavidPilling on 6/3/07 6:17PM
[ Reply | Permalink | Report ]

In reply to David Pilling:

There is a Linux implementation of UDF. I'm sure it can be used as a reference. But this isn't an easy process, is it? The two main difficulties I see are: (1) RISC OS has different interfaces at both ends (i.e. to the upper level and to the hardware); (2) it requires understanding a large body of someone else's code. I don't know about you, but I always have difficulties reading someone else's C or C++.

I would like to be more than lukewarm about it - really I would.

 is a RISC OS Userdavehigton on 8/3/07 8:37AM
[ Reply | Permalink | Report ]

Please login before posting a comment. Use the form on the right to do so or create a free account.

Search the archives

Today's featured article

  • BBC4's Micro Men: an interview and review
    Ahead of tonight's Micro Men programme, which charts the rivalry between Sir Clive Sinclair and Acorn Computers in the early 1980s, drobe.co.uk spoke to the film's producer, Andrea Cornwell, to find out more about the show - and now you can read our review of the film
     Discuss this. Published: 8 Oct 2009

  • Random article

  • USB in latest RISC OS 5 source release
    Third batch of code available from ROOL and CTL
     3 comments, latest by hzn on 29/2/08 11:17AM. Published: 22 Feb 2008

  • Useful links

    News and media:

    Top developers:
    RISCOS LtdRISC OS OpenMW SoftwareR-CompAdvantage SixVirtualAcorn

    CJE MicrosAPDLCastlea4X-AmpleLiquid SiliconWebmonster


    RISCOS.org.ukRISCOS.orgRISCOS.infoFilebaseChris Why's Acorn/RISC OS collectionNetSurf

    Non-RISC OS:
    The RegisterThe InquirerApple InsiderBBC NewsSky NewsGoogle Newsxkcddiodesign

    © 1999-2009 The Drobe Team. Some rights reserved, click here for more information
    Powered by MiniDrobeCMS, based on J4U | Statistics
    "We accept Drobe likes to be [controversial], no problem there - but a sinister pattern has appeared over the past year or so"
    Page generated in 0.1896 seconds.