CDFS wishlist

I’m not sure whether any of these would be bounty-worthy, so I’m making a list here. Also this list is about general CD-related things, rather than just aspects of the CDFS module.

• DVD, HD-DVD & Blu-ray support. Maybe Adrian Lees’ work on Cino can be leveraged here, if he agrees to release the source to the DVD modules.
• Perhaps try merging the CDFSSoftATAPI and CDFSSoftSCSI driver sources, since the ATAPI and SCSI commands are essentially identical.
• Full CD drive autodetection & hot-plugging support. For this to work CDFSDriver may have to stop referring to drives by their SCSI device IDs (with the current system, CDFSSoftATAPI will try to claim any devices for which the SCSI inquiry failed. This will obviously cause problems if a device ID that was free when CDFSSoftATAPI claimed it suddenly gets a real SCSI/USB drive associated with it)
• Give CD_PlayAudio the ability to play audio manually, by reading the data using CD_ReadAudio and using its own sound handler to play it through RISC OS’s sound system. This way any drives without audio output (e.g. most USB attached ones) can still have audio played from them without having to rely on third-party utilities.
• FileCore (or other 100% RISC OS friendly) format for CDs/DVDs

Anything else people can think of?

• UDMA for Iyonix
• ISO images to open like archives (read only.)
• Ability to switch on and off multisession. (Some discs use multisession for copy protection, the original session being standard for CD players.)
• Internal support for 64 file pointers (ready for new api)

Should the UDF support be a separate module?

1. UDF could be used as a cross platform disk format and not just on optical discs. (XP can certainly use it.)

2. If it were a separate module, then it could be released under a different licence to RO5 if needed.

FileCore (or other 100% RISC OS friendly) format for CDs/DVDs.

Do you mean the ability to use a RISC OS specific CD/DVDROM with the same on disc format as a hard disk?

Joliet filenames?

While I think about it: CDFS is the only bit of code using STASH/GRAB macros. I think the following macros should be retired at the earliest opportunity: ADDR/BADDR/DEC/DECS/GRAB/GRABS/INC/INCS/NOP/MULTIPLY/STASH for their general pointlessness or duplication of better macros.
And CallAVector and ExitSWIHandler should be Kernel private.

Throw away CDFS and write a new one?

I think this was done three times already:

• CDRFS by Cumana which came with CDBlaze
• CDROMFS by Ian Fry/WSS
• DVDFS by Adrian Lees for Cino

I think CDROMFS is the most advanced of the pack, so maybe I should talk to Ian if he is willing to open-source it.

Having seperate modules for the different logical formats (ISO9660 with extensions, UDF) is certainly a good idea. This would allow additional format handlers being added later (although I am not sure if we will ever see a new generation of optical discs).

Support for multisession/multivolume discs: this might be handled similarly to harddisc partitions.

The big question is how to structure the driver stuff. I don’t think we should worry about backwards compatibility – supporting the already known SCSI/ATAPI implementations directly is easy enough. So I would throw away the current CDFSDriver/CDFSSoft stuff.

Another idea is to seperate the Audio from the Data stuff. Let’s face it, an Audio CD has very little in common with a Data CD/DVD/Blu-Ray, apart from being a disc. The current CDFS API is horrible partly because it is such an unstructured mix of audio and data relevant SWIs.

I have the API spec for the Acorn CDManager somewhere which was destined to become CDFS3. Does anyone know if there was already code written? The API seemed to be sane last time I looked (although it predates DVD availability).

FileCore (or other 100% RISC OS friendly) format for CDs/DVDs.

Do you mean the ability to use a RISC OS specific CD/DVDROM with the same on disc format as a hard disk?

Not necessarily. Just something that will work properly with RISC OS filenames and file attributes. Maybe UDF would be suitable; I’m not sure how much support it has for storing platform-specific metadata.

WRT Jeffrey’s wishlist, which might be a sensible short term plan (if someone is prepared to try to understand CDFS):

• DVD, HD-DVD & Blu-Ray support: this is already there as long as the logical medium format is ISO9660. The big problem is that CDFS has problems beyond the 4 GB part of a medium. If someone could fix this – great!
• merge of CDFSSoftSCSI and CDFSSoftATAPI: it would be really great if someone could write a SCSISwitcher driver which integrates ATAPI into the SCSI world. Then we would never again need a CDFSSoftATAPI!
• CD drive autodetection and hot plugging: this would also need cooperation from CDFSFiler. Until ATAPI via SCSI is done, I would favour a pragmatic solution like reserving IDs 0..23 to SCSI (and therefore USB) and leaving 24..31 “empty” for other CDFSSoft drivers to claim. I don’t even know how CDFaker works wrt claiming?
• CD_PlayAudio: a possibility to play CD audio via the system audio instead of relying on headphone plugs and analogue audio out drive hardware and correct connections is certainly desirable. However, wouldn’t this be a task for a CD player application rather than CDFS itself?
• RISC OS friendly CD format: I think that the current CDFS extensions for RISC OS use are good enough. I am not aware of any attributes that filecore supports but CDFS doesn’t. And the current way of doing things has the advantage that RISC OS CDs are still cross-plattform compatible. On the other hand, it would be nice if we could ultimately arrive at a “device manager” that hands around logical formats to registered “format handlers” to find out who can handle it. This would automatically allow filecore-formatted CDs.

merge of CDFSSoftSCSI and CDFSSoftATAPI: it would be really great if someone could write a SCSISwitcher driver which integrates ATAPI into the SCSI world. Then we would never again need a CDFSSoftATAPI!

Good idea – maybe that would be the better approach.

CD_PlayAudio: a possibility to play CD audio via the system audio instead of relying on headphone plugs and analogue audio out drive hardware and correct connections is certainly desirable. However, wouldn’t this be a task for a CD player application rather than CDFS itself?

Perhaps. But why place the burden on the application developers? It would just waste their time if they all had to provide their own implementations of the exact same system. Plus users might be left in a situation where CD playback will work in one piece of software but not another, because that piece hadn’t been updated to support software playback.

Also what will happen if/when we add support for DVD audio? If CD_PlayAudio only supported hardware playback then it would create another load of work for application developers.

On the other hand, it would be nice if we could ultimately arrive at a “device manager” that hands around logical formats to registered “format handlers” to find out who can handle it. This would automatically allow filecore-formatted CDs.

Hmm, that sounds like the same scheme that the proposed ‘filing system bounty 2’ is thinking of for non optical media. I wonder if there’s some commonality to be had, ie. hardware drivers at the bottom, physical to logical drive translation, then the on-disc format handler at the top of the pile.

CD_PlayAudio – wouldn’t this be best in a module, to be upgraded in line with Jeffrey’s suggestions, further down the roadmap?

I don’t think we should worry about backwards compatibility

Am I right in thinking that anything that would have a problem with such a change would probably be ancient and have a bigger problem with 32 bit RISC OS, anyway?

Hmm, that sounds like the same scheme that the proposed ‘filing system bounty 2’ is thinking of for non optical media.

Sound like the scope of the bounty needs to be upgraded. (at least to ensure both systems can share components, if it isn’t combined.)

Just for the record, I can confirm the the CDFS 3 (CD Manager) code was present in the prototype RO4 stuff we got back in 1999. At the time, we looked at it to see if it was practical to finish it for OS4, but it was so incomplete, and generally incompatible with what was around at the time, that we decided to just deliver an improved CDFSsoftAtapi with the latest CDFS2 implementation, as that gave a fairly speedy solution, and allowed newer drives to operate as people were used to. Even then, some found that their old drives worked better with the 3.7 ATAPI driver… Back then, you couldn’t win! Unfortunately, whether RISCOS Ltd still have that source, and/or whether portions were used for Select/OS6, I don’t know, so I’m not sure whather it is still around.