CDFSFiler issues

Tested on a Pi3 using CDFaker 1.02 and a BIN/CUE image of Quake, although any CD-Audio image would probably suffice.

1. get_volume_level calls XCD_GetAudioParms without checking if the driver supports it via CD_Supported
2. updateplaylist possibly also has an issue as I can only get it to read the tracklist by reinitialising the Module

See this post for more detail.

EDIT: Issue 2 is down to the fact CDFSFiler scans the SCSI ID’s once when the Filer icon is initialised. CDFaker adds another device with a new SCSI ID for the drive it takes over, which will now differ from the one CDFSFiler knows – in the case of a machine without a CDROM drive, it possibly doesn’t have a SCSI ID at all for the first CDROM.

Is there a means to inform CDFSFiler that another SCSI device has been added, so it rescans the devices?

Is there a means to inform CDFSFiler that another SCSI device has been added, so it rescans the devices?

*RMReInit CDFSFiler ?

*RMReInit CDFSFiler ?

I was thinking more of SCSI device discovery when a new device is plugged in. A Service broadcast perhaps?

RMReInit of a desktop filer will result in an error if the desktop is running.

get_volume_level calls XCD_GetAudioParms without checking if the driver supports it via CD_Supported

Yes, that does seem to be a genuine issue.

updateplaylist possibly also has an issue as I can only get it to read the tracklist by reinitialising the Module

That one seems a bit more dubious. Are you sure the AudioStatus entry point of your driver was actually being called? (could be that CDFSFiler was trying to talk to the wrong drive). Is there anything in CDFSDriver which could be raising an error after your code returns?

Issue 2 is down to the fact CDFSFiler scans the SCSI ID’s once when the Filer icon is initialised. CDFaker adds another device with a new SCSI ID for the drive it takes over, which will now differ from the one CDFSFiler knows – in the case of a machine without a CDROM drive, it possibly doesn’t have a SCSI ID at all for the first CDROM.

I’m fairly certain things used to “just work”, or maybe there was a workaround (like reiniting a module).

(searches forum)

Possibly fiddling with the drive count in Configure was my workaround. But even then, I don’t remember any problems like that last time I tried using a USB CD drive, which was fairly recent (and should behave broadly the same as CDFaker, in that they’re hot-pluggable). But I could simply be forgetting that after plugging in the drive I reconfigured the system and/or rebooted.

Is there a means to inform CDFSFiler that another SCSI device has been added, so it rescans the devices?

The SCSI stack will announce new devices, but the CD stack doesn’t pay attention to it. And not all CD drivers are SCSI (CDFaker, ATAPI), despite the SCSI-based nature of the CD stack (although under RISC OS 5, it would be possible for non-SCSI drivers to register themselves as SCSI devices – with the caveat that they may need to actually emulate a SCSI CD drive rather than simply implementing the CD API).

One thought I had on a way out of the SCSI ID hell is that we could start making use of the reserved bits in the control block / CDFS_ConvertDriveToDevice output, as described here (although I still think it would be nice if ATAPI devices were exposed as SCSI devices, since ATAPI is, by definition, SCSI over ATA. Then things like ATAPI Zip drives should “just work” – assuming they don’t currently, that is)

I don’t remember CDFS ever being “hotplug compatible”. I always do rmreinit cdfssoft rmreinit cdfsdriver rmreinit cdfs.

The SCSI stack will announce new devices, but the CD stack doesn’t pay attention to it. And not all CD drivers are SCSI (CDFaker, ATAPI), despite the SCSI-based nature of the CD stack

Would it not make sense for CDFSFiler etc to rescan when a new SCSI device is announced? That might have some odd side effects though as the CDROM order might change if one is inserted with an ID lower than the existing CDROM. It would have to dynamically allocate the number of CDROM devices and remove the user setting from Configure.

In the case of CDFaker it’s a virtual SCSI device, so how would I announce it to the SCSI stack when it’s allocated itself a SCSI ID?

Yes, moving to a dynamic system like all the other major filing systems would definitely be good.

In the case of CDFaker it’s a virtual SCSI device, so how would I announce it to the SCSI stack when it’s allocated itself a SCSI ID?

Service_SCSIAttached

The SCSISwitch component (which builds to the SCSIDriver module) is responsible for handing out SCSI device/bus IDs under RISC OS 5. So technically if CDFaker was a virtual SCSI device, it should be registering itself with SCSIDriver and implementing support for the CD SCSI ops, rather than guessing at a safe SCSI ID to use and talking to CDFSDriver directly.

So technically if CDFaker was a virtual SCSI device, it should be registering itself with SCSIDriver and implementing support for the CD SCSI ops, rather than guessing at a safe SCSI ID to use and talking to CDFSDriver directly.

How do ATAPI CDROM get allocated a SCSI ID? Does the ATAPI driver also register with SCSIDriver? If so, I’ll mirror it’s code.

I will look into registering with SCSIDriver, CDFaker of old just grabbed the first free ID it could find. Following our discussion on the subject, I recoded it to follow your suggestion:

SCSISwitch will assign bus/card IDs to drivers starting from zero, so if CDFaker was to stick to card 3 then it would only conflict if you had 4 SCSI cards fitted (or 3 plus some USB devices? I’m not sure offhand if SCSISoftUSB is capable of using multiple bus/card IDs)

To cover all situations, I added an environment variable which specifies either a static ID, or wildcard, to avoid ID conflicts. By default it’s wildcarded to find a free ID on card 3.

How do ATAPI CDROM get allocated a SCSI ID?

They hijack the first ID they see, much like CDFaker used to.

On the one hand, there’s the excuse that the ATAPI driver was written long before SCSISwitch was introduced (so the only SCSI drivers were for real SCSI cards). But on the other hand, the code was written by EESOX, who AIUI are the ones who came up with the CD APIs in the first place!

Maybe the way drive IDs were handled was one of the problems that the mythical CDFS / CDFSDriver 3 was going to fix.

Could the not request a SCSI ID from SCSIDriver? I presume it knows what cards are in the machine, so could hand out ID’s that can’t be present in hardware.

Yes, it could.

There are a lot of things that could be done with the OS, if there were more developers.

You would need a numbering scheme anyway – old-style SCSI is “dynamic” because it is in principle hot-pluggable, but the IDs are fixed (jumpered on the device). If you switch on “true” SCSI devices later, they could collide with IDs previously not known to SCSIDriver.

I guess nobody ever bothered to think about proper solutions with CDFS because CDFS is in so many ways completely broken that a ground-up rewrite is needed. Acorn themselves knew that and scheduled “CDFS 3” for Phoebe. It didn’t happen.

IIRC, CDFSDriver hands out all SCSI IDs (and all LUNs) to interested drivers, so there is no need to claim anything “early”. On the other hand, RISC OS software scanning for SCSI devices often only scans ID 0-7, only few scan 0-31 (in practice only achievable by using four Power-tec SCSI podules). But CDFS uses its own device numbering logic, so CDFSSoftATAPI, CDFaker and friends could be allocated a sensible range beyond standard SCSI IDs.

Service_SCSIAttached

There’s a small error in line 68:

R2 = &18 (2:0.0)

It should be (3:0.0) of course.