CD-R for data transfer - any peculiarity?

[chrisrot]

Hi,

I have a question concerning burning CD-Roms for data transfer to my RiscPC.
I got a RiscPC with 4.02-ROMs from ebay some time ago and after recapping it I want to do a clean install of Risc OS 4.02. Unfortunately, the RiscPC came without any media.
I managed to find a 4.02 installation CD image and burned it to a CD-R. With this CD I could reinstall RiscOS 4.02 on an empty harddisk and access every file on the CD.
However, when I burn additional programs on Linux/Windows-PC to CD-R I'm not able to read this CD on my RiscPC. When I insert the CD into the drive I can list the root directory, but when I try to copy something to the harddisk I get an 'Empty CDROM drive'-error. I tried different types of drives without success, one Sony CDU5211 (which was installed in the RPC), a Plexwriter 40 and a Plextor DVD PX-716A. With the Sony I can transfer a bit when I click on Retry several times.
The strange thing is, that the 4.02 installation CD works in all drives.

My guess is that I make some mistakes while burning the CD. Is there a trick when burning CDs for RiscOS?

[IanJeffray]

additional programs

I think that may be the key. Memory is pretty hazy here, but I think CDFS only handles a single session. WSS's CDROMFS (CJE still selling) could do more - including multisession and Joilet. If you're stuck with using CDR to transfer, try either "closing" the disc after burning, or prepare an ISO9660 image separately, then burn that to the CD.

[wiggy]

Another possibility is that some systems (notably Windows) default to writing CD's in UDF rather than ISO9660 filesystem. That's the one they invented for DVD's, and is better aimed at adding more files on the end of a disc (which is basically a kludge in ISO9660 using multiple "sessions", with the filesystem tables in the later ones pointing back into the earlier ones). And Windows' built-in burner isn't particularly keen on "closing" a disc, either.

While UDF was supposed to have some compatibility with ISO9660, it's only partial - and probably only should be expected to work on a closed disc.


One other bit of weirdness that might be involved (also an issue on some versions of linux): with an unclosed disc, the data is likely to end abruptly, rather than on a sensible block boundary. With an OS that buffers the CD, it is likely to try to "read ahead" over the end of the data - resulting in errors from the drive. Most ISO9660 filesystem generators pad the end with empty space to mitigate this (or have an option to do so), but not all. Try turning the buffering off (I can't remember offhand if this is on the desktop menu or only a *Configure option - sorry) and see if that helps.

[IanJeffray]

Another possibility is that some systems (notably Windows) default to writing CD's in UDF rather than ISO9660 filesystem.

CDROMFS does UDF too.

[chrisrot]

Thank you all for the useful hints.

I think that may be the key. Memory is pretty hazy here, but I think CDFS only handles a single session.

Even if I didn't put the additional programs on the same CD-R but on a new one this pointed me in the right direction.
I changed the write mode to Disk at Once, which make sure that session will be closed. Also I disabled all UDF-stuff with the option "DOS compatibility" in k3b (Linux cdburner for KDE).
With these two options I can create CDs which I can later read on my RiscPC with 4.02.

Fun fact: I purchased the upgrade to 4.39. After installing it, I can also read the CDs which produced errors under 4.02.