CDFS wishlist
Jeffrey Lee (213) 6048 posts |
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.
Anything else people can think of? |
Jess Hampshire (158) 865 posts |
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.
Do you mean the ability to use a RISC OS specific CD/DVDROM with the same on disc format as a hard disk? |
Sprow (202) 1155 posts |
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. |
Steffen Huber (91) 1949 posts |
Throw away CDFS and write a new one? I think this was done three times already:
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). |
Jeffrey Lee (213) 6048 posts |
FileCore (or other 100% RISC OS friendly) format for CDs/DVDs. 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. |
Steffen Huber (91) 1949 posts |
WRT Jeffrey’s wishlist, which might be a sensible short term plan (if someone is prepared to try to understand CDFS):
|
Jeffrey Lee (213) 6048 posts |
Good idea – maybe that would be the better approach.
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. |
Sprow (202) 1155 posts |
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. |
Jess Hampshire (158) 865 posts |
CD_PlayAudio – wouldn’t this be best in a module, to be upgraded in line with Jeffrey’s suggestions, further down the roadmap?
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?
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.) |
Andrew Rawnsley (492) 1443 posts |
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. |