Enhancing CDFaker to support CD audio

In my attempts to take over the 1st CD-ROM, I changed CDFaker to identify all physical CD’s on init and then force and respond to CD_Identify when an image is mounted, but CDFSDriver continued to use the original driver associated with the CD. I then attempted to RMReInit CDFSDriver as it forces a rescan of the soft drivers, but that didn’t work either.

Possibly you were caught out by the driver search order? You’d need to make sure CDFaker is the first driver that CDFSDriver tries calling.

Essentially I need to hot plug between the actual soft driver and CDFaker, ideally without reinitialising the CDFS module stack every time an image is mounted/dismounted.

I think an acceptable compromise would be to have a utility/script kills off the CD stack and then reinitialise it with CDFaker as the only driver. And then another one to put it back to how it was before (although “putting it back” might be a bit tricky if some of the modules were soft-loaded)

Well-written software should be capable of running from any CD drive, it’s only poor/buggy software which assumes drive 0 which is causing the problem. If a user decides they want to run that buggy software they can easily run the script beforehand to set up CDFaker correctly (or it could be part of the ADFFS boot script for the game). Compared to some of the other stuff ADFFS does to the system to get games running, this is nothing!

What do you think the best strategy is for claiming a SCSI ID when there’s no physical CD, given the chance a SCSI drive might be hot plugged? Should I simply give the user the option to set a specific SCSI ID to use?

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)

However, with the older versions of CDFS which start their search from bus 0, this won’t help you make sure CDFaker gets assigned drive zero.

CDFaker currently supports up to 8 fake drives, HOMM2 needs at least 2 to install, unless I implement a way to swap images when the filesystem takes control of the machine with an “insert this CD” prompt, multiple SCSI ID’s for each fake drive are required.

The “Please insert disc” logic can be customised by OS_UpCall 1/2/4. So you could try implementing an upcall handler within CDFaker which detects when a request is being made to swap the currently mounted image and either let the user manually select a new one or check a pre-configured list.

you were caught out by the driver search order? You’d need to make sure CDFaker is the first driver that CDFSDriver tries calling.

Indeed, but I couldn’t think of a way of reordering the Modules. Even if I did, it then becomes reliant on the Module order being the deciding factor, which could well change in the future give CDFS was never publicly documented.

an acceptable compromise would be to have a utility/script kills off the CD stack and then reinitialise it with CDFaker as the only driver.

That might work, provided soft drivers follow the convention of having “CDFSSoft” on the front of their title – which would appear is an unwritten rule going by the CDFSDevice source code. In fact, I’ve modified CDFaker accordingly so its handled by CDFSDriver.

Well-written software should be capable of running from any CD drive, it’s only poor/buggy software which assumes drive 0 which is causing the problem.

As with floppy drives, the games I’ve tested that use CD music (HOMM2 and Ankh) assume drive 0 to be the one your using. The HOMM2 installer supports multiple drives, but the game itself reports something along the lines of “Red Book not supported” if drive 0 doesn’t contain the music CD (on my physical RiscPC, haven’t tested on other platforms)

If a user decides they want to run [a game] they can easily run the script beforehand to set up CDFaker correctly

At the moment, neither HOMM2 or Ankh will play CD music on a physical machine with an existing CDROM, as CDFaker can’t take over drive 0. I’ve successfully tested them under emulation, so I’m happy the BIN/CUE and SharedSound side of things are working as expected. So, yes CDFaker could stay as is and provide an additional fake CDROM with a means to take over drive 0 when forced, but personally I’d prefer CDFaker to take over the physical drive in the same way ADFFS does.

(or it could be part of the ADFFS boot script for the game). Compared to some of the other stuff ADFFS does to the system to get games running, this is nothing!

What are you inferring :)

As of 2.62 ADFFS doesn’t alter the system (ie alter BASIC), its purely a compatibility layer that sits between the game and the OS and provides 1772/IOC/VIDC20/MEMC emulation. Admittedly the JIT does directly alter L2PT, which I’m not proud about, but the legal means to do it corrupt the page flags (well, did at the time but may have subsequently been fixed.)

I’m keeping this separate from ADFFS as it’s a bespoke bit of software that I took over the sourcecode and development of a few years back. I’ve neglected it until now, but with ADFFS nearing complete coverage of all non-Wimp based games that I have, I figured I’d look at CDROM emulation and in-game CD Audio.

Once I’m happy it does everything I need, I’ll consider bundling/integrating it with ADFFS, but may well add a bespoke image format so I can distribute the few games available on CD once the project has permission. I have author permission for a few, but am awaiting a response from publishers. Some are also in the queue to be made ARMv7 compatible.

if CDFaker was to stick to card 3 then it would only conflict if you had 4 SCSI cards fitted

In that case, I’ll change the auto selection to only use card 3 and will add environment variables to allow a forced override – just in case.

The “Please insert disc” logic can be customised by OS_UpCall 1/2/4. So you could try implementing an upcall handler within CDFaker which detects when a request is being made to swap the currently mounted image and either let the user manually select a new one or check a pre-configured list.

It’s a neat idea and I did look at it for ADFFS, but quickly found most software had bespoke disc detection. Aren’t UpCall handlers application specific though? Are all UpCall handlers called regardless of which app is currently paged in?

That might would work, provided soft drivers follow the convention of having “CDFSSoft” on the front of their title – which would appear is an unwritten rule going by the CDFSDevice source code.

Ugh, I didn’t realise that CDFSDriver reinitialises any running CD modules when it starts up (and uses the unknown SWI vector to allow the CD_Register / CD_Unregister SWIs to be handled!)

So, yes CDFaker could stay as is and provide an additional fake CDROM with a means to take over drive 0 when forced, but personally I’d prefer CDFaker to take over the physical drive in the same way ADFFS does.

I think the key thing would be to make the behaviour optional. My opinion is that CDFaker should add a virtual CD drive, it shouldn’t take over your real one.

Aren’t UpCall handlers application specific though? Are all UpCall handlers called regardless of which app is currently paged in?

Yeah, UpCall handlers are app-specific, and like other environment handlers only the handler for the current app will be invoked. But the SWI is vectored via UpCallV (with the upcall handler only being invoked if the vector isn’t claimed), so assuming nothing else intercepts the vector you should be able to implement your logic within that.

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. I.e. if the reserved field is zero, it’s a SCSI drive, but if the reserved field is non-zero then it’s a non-SCSI drive. The value of the reserved field could indicate the CDFSDriver drive number, and if the SCSI ID was set to &FF then that should reduce the chances of code which tries using direct SCSI commands accidentally interacting with a real SCSI device (for extra safety, CDFSDriver could be allocated a SCSI ID from SCSISwitch, ensuring that nothing else can conflict with that ID).

I am a little behind on the thread as I was offline for a while due to some works on the house.

As Jon probably understood in the meantime, addressing in CD SWIs is defined block in block numbers (a block is 2352 bytes i.e. 1/75 of a second worth of audio) and the first track for CD_EnquireTrack hasthe number 1.

CD can/may be played from 3 different ways from DigitalCD (see Choices window section Drivers → CDFS):
- CD_ReadAudio, the DiskSample module calls this SWI to read the data in a buffer and plays it through SharedSound/SoundDMA.
- CD_PlayAudio, DigitalCD specifies the start & end blocks (in logical mode) to play and the drive outputs the sound on its I2S or Jack output.
- CD_PLayTrack, DigitalCD the start & end tracks to play.

The *Play command which worked in your test correspond to the CD_PlayTrack SWI.

For CD_PlayAudio, a common issue in CDFSSoftXXX modules was a discrepency of 150 blocks (2 seconds) compared to other SWIs like the CD_EnquireAddress (the SWI used to read the position) which causes DigitalCD to think when mapped against the start block of each track that it does not play the correct track.

Here is a little test program I used to test this by playing the start of a track and showing the actual position returned by CD_EnquireAddress. You can modify like 40 to specify the drive, track. The last variable Nudge% specifies a number of blocks (0 for correct CDFSSoftXXX modules, 150 for faulty CDFSSoftXXX modules) to add to the addresses given to CD_PlayAudio.

CDTest

a common issue in CDFSSoftXXX modules was a discrepency of 150 blocks (2 seconds)

I believe the discrepancy is correct as audio in the TOC starts at LBA 0, which is actually PBA 150 due to the 2 sec lead-in specified for CD-DA. CD_PlayAudio offsets should be 150 lower than what you receive from CD_EnquireAddress.

This can quickly be confirmed by using something like cdrecord on Linux or IsoBuster on Windows to analyse the TOC; the first track will start at LBA 0 / PBA 150 / 00:02:00.

It is correct for there to be a 150 block offset (CD_ConvertToLBA / CD_ConvertToMSF use the rule that LBA 0 == MSF 0 == PBA 150). But it wouldn’t surprise me if some drivers didn’t apply the offset correctly for all situations.

It is correct for there to be a 150 block offset (CD_ConvertToLBA / CD_ConvertToMSF use the rule that LBA 0 == MSF 0 == PBA 150). But it wouldn’t surprise me if some drivers didn’t apply the offset correctly for all situations.

That was the case on my RiscPC where the IDE drive worked fine while the SCSI one had the problem. Since I presume Atapi/Scsi commands work actually use PBA mode, I don’t understand why the conversions are handled by the SoftXXX modules instead of letting the CDDriver module perform the conversion and talk to the SoftXXX modules in PBA mode.

I’ve made a test release of CDFaker 1.02 available for download on the JASPP dev forum.

There are *Configure options to control the audio buffer size and read-ahead, although from the testing I’ve done on a Pi3 with SD, altering the buffer size or read-ahead make little difference to mouse/app stutter introduced when data is read from media. It’s possible there may be a difference when run on SSD or spindle based HD’s.

I’m not aware of any CD imaging software for RISCOS which will create BIN/CUE files, so you will need to use another OS, with appropriate software such as IMGBurn etc. to create the BIN and CUE files.

Maybe I could quickly knock up such a CD imaging software for the “easy” cases (i.e. mixed mode, pure data or pure audio CDs). Perhaps after the CDVDBurn release I am currently working on.

Thanks for this update. However, no luck with Quake. I’ve set the file types as documented (A79 and FFD) and have mounted the image. If I click the :0 icon then I can see the files on there, but when I run the game I don’t get any music. Any ideas? Do I need to do something special to enable music output?

If I try to use RISC OS’ built-in CD player then I get the error “Soft-load driver does not support this CD_ SWI”. I’m running on a Pi 3 with the 23-Oct-17 ROM.

no luck with Quake

I only have the original RiscPC release to test, so can’t check to see what it’s doing on the PI release. Your other issue however implies the problem is possibly elsewhere.

If I try to use RISC OS’ built-in CD player then I get the error “Soft-load driver does not support this CD_ SWI”. I’m running on a Pi 3 with the 23-Oct-17 ROM.

Does it detail which CD_ SWI is not supported? To my knowledge (just double checked the nightly HardDisk4) RISCOS doesn’t have a built in CD player, are you sure it’s not a 3rd party app you’re using? What’s the name of the app, I’ll test on my Pi3.

Some CD player software doesn’t actually ask the drive to play the track, but instead reads the raw data. Not that it really matters, but it does mean it’s the player playing the track and not CDFaker emulating CD-Audio. I believe !DigitalCD falls into that category.

I only have the original RiscPC release to test, so can’t check to see what it’s doing on the PI release.

I’m using the old Windows CD (actually the CUE/BIN pair supplied in the download from gog.com) because the Pi version doesn’t include any music.

Does it detail which CD_ SWI is not supported?

It does not, although a cursory glance of the CDFSDriver source indicates that it might be CD_Supported.

To my knowledge (just double checked the nightly HardDisk4) RISCOS doesn’t have a built in CD player, are you sure it’s not a 3rd party app your using?

It’s built-in; you menu-click on the CD drive icon and choose Player.

Some CD player software doesn’t actually ask the drive to play the track, but instead reads the raw data. Not that it really matters, but it does mean it’s the player playing the track and not CDFaker emulating CD-Audio.

It’s not even getting as far as opening the Player window so I’m not sure whether or not that’s the problem.

It’s built-in; you menu-click on the CD drive icon and choose Player.

So it does, I’ve never noticed that before. I’ll look the the source code and try to figure out what it’s doing.

I’ll look the the source code and try to figure out what it’s doing.

It appears to be a bug in CDFSFiler which doesn’t check CD_Supported before calling CD_GetAudioParams.

Working around that by stubbing that SWI, there’s another issue as it only ever reports No disc which is being caused by V being set by the CD_AudioStatus call a few lines earlier.

EDIT: Reinitialising CDFSFiler gets music working – it won’t know the SCSI ID of the fake device at boot.

I don’t believe it’s possible to get the inbuilt player in RISCOS to work if CDFaker is loaded after CDFSFiler is initialised, as CDFSFiler reads the SCSI ID before CDFaker has loaded and allocated a SCSI ID to the fake device. The only workaround is to load CDFaker in PreDesk.

If you want to try this, CDFaker v1.03 is available for download which should be loaded from PreDesk

Thanks for investigating. Excellent service! :)

I should have some free time tonight so I’ll try it then.

I can confirm that Player now works. Thanks again!

Unfortunately it didn’t fix Quake, but I suspect that it could be an issue with Quake itself rather than CDFaker. I’ll ask R-Comp about it.

Quoting Jeffrey:

Well-written software should be capable of running from any CD drive, it’s only poor/buggy software which assumes drive 0 which is causing the problem.

This occurs with HoMM2 and Ankh when there’s a physical CDROM present, so it’s possible Quake might also be assuming the first device contains the CD. This release of CDFaker does not take over the physical device so CD-Audio will fail if the software doesn’t look for the device containing the CD. In the case of the Pi, provided there’s no physical CDROM attached, HoMM2 and Ankh do play CD-Audio.

I tried the original RiscPC release of Quake under RedSquirrel, which did appear to play CD-Audio on the title page – I didn’t play the game to test further. I do not have the latest release of Quake for the Pi, so am unable to test specifically on a Pi to see what’s happening.

I see a couple of references to USB in this thread so I might as well ask: Are USB CD drives supposed to work (without CDFaker)? I connected a drive, rebooted, and it reports that there’s no disc in the drive. Selecting Eject from the menu does nothing. The drive does show up under *USBDevices.

Is this supposed to work or am I barking up the wrong tree?

I have an Asus SDRW-08D2S-U external USB optical drive connected to an RPi 2 running RC15 with High Vector ROM and it works fine. It shows under *USBDevices as “USB 2.0 External Mass Storage Device”. I can read the contents of data CDs, eject button also works without problem. The only thing which is not working for me is playing audio CDs with the built-in player.

From my experience, CD/DVD devices eat quite a lot of power (comparing to flash drives for example). It can be not so much a software issue, but the PSU may be not strong enough, or the USB port does not provide enough current for the drive.

My drive has its own power supply. I’ve actually tried two different ones; a no-name case that takes a plain SATA drive, and a Microsoft-branded one intended for use with an Xbox (but it also works fine on Windows and MacOS). I wonder why they’re not working with the Pi.

I’m going to try Raspbian (assuming I can figure out how to use it!) to see whether it’s software or hardware. [Edit: Works fine. I’ll do some research and might post a new thread if I can’t figure it out.]

I see a couple of references to USB in this thread so I might as well ask: Are USB CD drives supposed to work (without CDFaker)?

Yes – although some drives do have problems that I haven’t resolved yet (see last paragraph)

It might be worth checking that your drive appears under *devices (which lists the detected SCSI devices) – since it needs to be recognised as a SCSI device for the CD driver (CDFSSoftSCSI) to see it.

The only thing which is not working for me is playing audio CDs with the built-in player.

The problem there is that the CD player expects the CD/SCSI “play audio” command to work, which causes the drive to output the audio signal via the drive’s dedicated audio connector. Which is a problem for USB-attached devices since that connector either won’t exist or won’t be connected to anything.

Having the CPU manually read and play the audio tracks would fix it, but I’m not sure how we’d handle the logic that decides whether hardware or software playback should be used (we’d probably want support for manual configuration, but it would be good if the system could take a reasonable guess as well)

Three things to check wrt USB CD drives:

• does it show in *USBDevices (which means: the USB stack has detected the device at all)?
• Then, does it show in *devices (which means: it has been recognized as a SCSI-like mass storage device by SCSIdriver)?
• Then, does it show in *-cdfs-cddevices (which means: it has been recognized by CDFS as a supported CD-type device)?

The problem there is that the CD player expects the CD/SCSI “play audio” command to work, which causes the drive to output the audio signal via the drive’s dedicated audio connector. Which is a problem for USB-attached devices since that connector either won’t exist or won’t be connected to anything.

Somehow I can play regular audio CDs with the same external usb drive on my Mac… I suspect that it “rips” audio tracks on the fly and then streams them through speakers, as if it was any other digital audio stream. I don’t know if it’s done by the OS or the player, though.

As you were – I’d removed CDFaker from PreDesk but I forgot about the copy in Utilities that was set to load on boot…

The drive works fine without CDFaker running (although as noted above/expected, doesn’t play music).