Hi Bret,
thanks for clarifying the timeline of different CD sub-channel contents. Regading Tom's suggestion: As I have written several times, to find out whether adding features to UDVD2 is useful, a key question is whether any app USES them. Because I myself have none of those games which are said to work better with OAKCDROM, I need a DOS gamer with a test case. Then, I would assist that gamer in selectively breaking OAKCDROM features by patching the binary until features relevant for the game have been found. This avoids wasting time for adding features to UDVD2 which are not used by any app we know. About your question whether an IOCTL exists to download raw sub-channel data, which could be used for copy protections: As you can see in my 2021-06-08 mail, OAKCDROM supports reading and writing "drive bytes" and "audio control" (volume control, mixer, channel assignment) as well as "error statistics" calls. However, of those, only the audio control calls have a minimal implementation in DOSBOX at all: https://sourceforge.net/p/dosbox/code-0/4167/tree/dosbox/trunk/src/dos/dos_mscdex.cpp As you can see at lines 562-610 of https://sourceforge.net/p/dosbox/code-0/4167/tree/dosbox/trunk/src/dos/cdrom_aspi_win32.cpp reading the UPC would be done by passing the parameters 0x40 (Q-channel) and 2 (UPC) to the SCSI subchannel call, for "track" 0 and swapping nibbles in 8 returned BCD bytes. For comparison, for getting the audio subchannel, parameters would be 0x40 (Q-channel) and 1 (timestamps) also "track" 0, see GetAudioSub() at lines 508-560. As you can see in the MSCDEX API description here: https://gist.github.com/abrasive/7a615e6dde0c1da962f9930cc63ee43d the available IOCTL include: Error statistics, audio channel info, "read drive bytes", device status, return sector size, return volume size, media changed, audio disk info, audio track info, audio q-channel info, audio sub-channel info, UPC code and audio status info. The status simply is a flag you get when reading the sub-channels (see cdrom_aspi_win32). The audio channel info is a 4x4 mixer volume control status, so that does not depend on the contents of your CD medium. The audio disk info tells you the duration of the disk and the range of track numbers. The track info tells you the start time and flags for an audio track. Audio Q-channel info call returns the most recently seen audio timestamp. With "audio sub-channel info", you read 96 bytes per frame of raw sub-channel data (MSB is P, LSB is W) for a selected range of sectors. The "UPC code" call returns 7 and a half bytes of UPC data. Functions to read and write "drive bytes" communicate with the drive, for example for firmware updates. I doubt that those would be suitable for hardware-independent calls for some copy protection scheme. With ioctl output, you get: eject disk, lock or unlock door, reset drive, audio channel control, write device control string and close tray. The device control data again is something which is differs between drives, probably only useful for things such as firmware updates or drive-specific extra features only used by brand-specific support apps. >> Either way, using the UPC for copy protection of games is pretty >> much pointless, because you can easily copy that as well, so I >> still FIRST want to know whether games REALLY rely on that for >> their copy protection scheme. > > Like you, I really doubt that's how they do it. But I suspect > it does have something to do with the sub-channel data. > My problem with Jack in this case is that he has only provided half > a driver -- it doesn't even support all the standard IOCTL functions > it's supposed to. If Jack would just provide a complete IOCTL command > set it would probably work just fine however they implemented the copy > protections scheme. I disagree on that one: For example UDVD2 can report the current head/seek location, while OAKCDROM can not. So drivers naturally differ in their feature set. The set of features supported by UDVD2 is almost complete, so we are only talking about some very specific gaps. You could compare the discussion to one about FreeDOS DBCS support. Calling UDVD2 "half a driver" is quite an pessimistic, I would rather call it a 90% feature-complete driver. Do not insult his driver work by downplaying features. If you compare with ELTORITO, that one (because BIOS calls only give you data sectors) is "MUCH less of a driver" but still works quite well for most use cases. UPC is among the things for which MSCDEX.TXT, also called MSCDEX21.DOC, explicitly specifies what should be done instead if they are NOT supported. Other aspects in this category are interleaving and device control strings. Things which are optional for driveS to support include playing audio and volume control. Interestingly, MSCDEX itself at that time did not support writing to CD/DVD and "drive check", nor multi-extent nor multi-volume files, version numbers, long file names, and so on, all according to the MSCDEX.TXT file. So you may call it only "half" an ISO9660 handler, yet it worked well. So again, yes there are features which could be added, but I want to know FIRST whether anything USES them. Imagine Jack adds UPC to UDVD2 first and after that we find out that the games use "read all sub channel data" (as you, too, have suspected) and do not care about UPC! The call to read ALL-channel sub-channel data is not yet supported in UDVD2, but it might be interesting to write an audio CD player app which uses it to show CD TEXT ;-) Having to rearrange the data (1 bit per channel per byte) into text will be annoying, but it would be the task of the app and not the task of the driver. However, DOSBOX seems to "implement" reading the all-channel sub-channel data by returning only the audio data, so any copy protected games using that would fail in DOSBOX, too. They mix up IOCTL input functions 0x0c and 0x0d semantics? According to MSCDEX.TXT, 0x0c is "audio q-channel info" and 0x0d is "audio sub-channel info", but the latter is not supported at all in DOSBOX while the former calls a function which is CALLED GetSubChannelData but IMPLEMENTS only the audio Q-channel query. Regards, Eric _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
