5.19 - CD_Get_Parameters

In my CD ripping app I use the oslib call ‘cd_get_parameters’ to find
the maximum speed of the installed CD/DVD drive. This has been fine up
to 5.17 (Sept 25? 2011). However, in 5.19 (24-Jan-12) this call errors
with a message ‘No CD-ROM drive present’. This is on an Iyonix -
haven’t got 5.19 on the ARMini yet.

I am not sure of the full spec of this call – I only have the oslib
headers.

/* -—————————————————————————-

• Function: cd_get_parameters()
  *
• Description: Reads drive setup parameters
  *
• Input: params – value of R0 on entry
• control – value of R7 on entry
  *
• Other notes: Calls SWI 0×41245.
  */

extern os_error *xcd_get_parameters (cd_parameter_block *params,
cd_control_block const *control);
extern void cd_get_parameters (cd_parameter_block *params,
cd_control_block const *control);

Is this call now broken, or has something changed in 5.19?

How are you setting up the cd_control_block? See CDFS_ConvertDriveToDevice in the “OS” StrongHelp manual for how to convert drive numbers to control blocks. As long as you follow that procedure everything should work OK.

The cause of your problems is probably a change I recently made to CDFS. Internally the CD modules identify drives by their SCSI device ID. This is fine for SCSI devices, but causes problems for modules like the ATAPI driver and CDFaker, where (as far as the SCSI stack is concerned) the drives don’t exist. The workaround that the ATAPI & CDFaker modules are using is to simply claim the first SCSI device ID that doesn’t have a SCSI device attached to it. This scheme has worked OK for a while, until I started work on the USB CD driver – not only are USB storage devices exposed to the OS via the SCSI stack, but they’re also hot-pluggable, so may claim or release SCSI device IDs at a moments notice. So if you have the ATAPI or CDFaker modules running and then connect a USB CD drive there’s a good chance CDFS won’t be able to see the drive because the ATAPI/CDFaker modules are intercepting all the communications being sent to that device ID.

Prior to CDFS 2.50, the module was searching for drives by starting at SCSI card 0 and working upwards. But with CDFS 2.50 I changed it so that it starts at card 3 and works down. So now the non-SCSI drivers should almost always be allocated device IDs on card 3 instead of on card 0 (which is where the SCSI stack is most likely to allocate IDs for USB devices). And since the cd_control_block contains the SCSI device ID, if you weren’t setting that up correctly then CDFS would end up trying to talk to a drive which doesn’t exist.

How are you setting up the cd_control_block? See CDFS_ConvertDriveToDevice in the “OS” StrongHelp manual for how to convert drive numbers to control blocks. As long as you follow that procedure everything should work OK.

Thanks for your comments, Jeffrey. Have just compared my code with that StrongHelp manual. It looks as if I am doing things as it should be. I will go through it in more detail tomorrow, and try some extra debugging. It’s not actually causing the app to fail, but I would like to get things as right as I can.

I haven’t checked out the stuff you mention, Chris, but I can report that the latest MusicMan that I have been working on for ARMini is OK on the recent CDFS stuff. However, it doesn’t read the cdspeed (since I’m not convinced that was ever very reliable, based on observational experience) in the manner you describe, so I don’t know what to really say about that.

Just to add to the above.

Under 5.16/5.17 CDFS_ConvertDriveToDevice returns the physical drive number as 0, and all 5 words of the control block are also 0.

Under 5.19, the physical drive number is returned as 24, with the five words of the control block being 0, 3, 0, 0, 0.

Under 5.16/5.17 CD_GetParameters then returns without error, whereas under 5.19 the non-zero control block results in CD_GetParameters returning an error, the parameter block not being filled in (magic numbers on entry are not changed).

All on an Iyonix.

@Andrew
The rest of the CD/CDFS software seems to work ok on the ARMini, i.e. ripping works as expected. However, my ARMini has the 5.17 version as supplied in December, so is the equivalent of the Iyonix on 5.17. Ripping also works on the Iyonix under 5.19, it’s just the GetParameters call that seems to fail.

I’ve just softloaded 5.19 on my Iyonix, and everything seems to be working fine from BASIC. The two ATAPI drives are given physical numbers 24 and 25, corresponding to control blocks 0,3,0,0,0 and 1,3,0,0,0. Calling CD_GetParameters returns without error, and with the parameter block containing the expected values.

What happens if you call the SWI directly? Perhaps there’s some bug in OSLib that’s causing it to incorrectly pass the parameters.

Sorry chaps – I have been raising red herrings. The problem is I am running CDROMFS. If I remove that then there are no errors. Replace CDROMFS and the error comes back. Many apologies for wasting your time Jeffrey. At least I shan’t be tearing at my head any more!

No problem. At least we’ve discovered that CDROMFS might not be happy with my change :-(

Hmmmm. AFAIK, CD_GetParameters is in CDFSdriver and directly hits whatever softloadable driver is registered for the given device. How could CDROMFS mess that up?

Well, CDROMFS comes with a little obey file ‘killCDFS’, which does a RMkill CDFSFiler (not sure how that interacts with this) and then an RMReinit CDROMFS. The reason, presumably, is that the OS CDFSFiler becomes redundant once CDROMFS is running. I will try later on running CDROMFS without running the killCDFS obey file and see what happens.

It is so long ago since I first used CDROMFS, I have forgotten why the above action was recommended. With all the improvements to CD handling, there may be no advantage in running CDROMFS anyway.

Just to confirm: Running 5.19 on Iyonix.

Before running CDROMFS: CD_GetParameters completes normally.

After running CDROMFS: CD_GetParameters returns an error (No CD-ROM drive present). It is not necessary to rmkill the CDFSFiler.

There are still many advantages of CDROMFS compared to CDFS – Joliet, UDF, better ISO9660 compatibility, providing an imagefs for CD images.

There may be other issues with CDROMFS on 5.19. For example, it looks as if CD_DriveStatus does not return the correct status when it is running.

The mapping of logical → physical drive numbers is held within CDFS. Since CDROMFS acts as a replacement to both CDFS and CDFSFiler, it would make sense that CDROMFS contains its own code to scan for CD drives and assign logical numbers to them.

I think the only way the ATAPI driver will switch to using a different physical drive number is if the module is reinitialised; so I’m guessing that before CDROMFS scans for drives it reinitialises some/all of the driver modules? Assuming CDROMFS searches for drives from SCSI card 0 upwards (like CDFS used to), this would then result in the ATAPI driver claiming physical drive 0. And since CDFS doesn’t get told when drivers register/deregister with CDFSdriver, CDFS will still be left thinking the drive is on physical drive 24.

So it would be worth checking to see if the drive responds to a control block of 0,0,0,0,0 after CDROMFS has been loaded, and whether CDROMFS has a ConvertDriveToDevice SWI of its own. Unless I’ve missed something (or CDROMFS is doing something naughty like trapping the CD_* SWIs) I think that’s the only way things could be going wrong.

Also, if it turns out that CDROMFS is reinitialising the ATAPI driver, then a simple workaround for CDFS reporting dodgy physical drive numbers would be to reinitialise CDFS after starting CDROMFS. For most people this should result in both modules arriving at the same drive mapping.

(The situations where it wouldn’t result in the same drive mapping would be if you have two or more drives which are on different SCSI card numbers to each other. CDFS would find the drives OK, but the logical drive numbers they’d be allocated to wouldn’t match the drive numbers CDROMFS is using, due to the two modules scanning the cards in different orders)

So it would be worth checking to see if the drive responds to a control block of 0,0,0,0,0 after CDROMFS has been loaded, and whether CDROMFS has a ConvertDriveToDevice SWI of its own.

I can confirm that, with CDROMFS running, if the control block is reset to all zeros after doing a CDFS_ConvertDriveToDevice, then the subsequent CD_GetParameters does indeed return without error and eg the reported drive speed is then correct.

Looking at the CDROMFS module in Zap, the first entry in the decoding table (after the prefix CDROMFS) is indeed ConvertDriveToDevice.

Also, if it turns out that CDROMFS is reinitialising the ATAPI driver, then a simple workaround for CDFS reporting dodgy physical drive numbers would be to reinitialise CDFS after starting CDROMFS.

Having done the previous tests, I did a simple RMReinit CDFS. Everything (well the SWIs I am testing) now seems back to how it should be, other than that CDFS_ConvertDriveToDevice is now returning a device number of zero, rather than 24.