This is an interesting analysis and comparison between Oak Technology's OAKCDROM (proprietary) and Jack's UDVD2 (free with sources).
Have you shared this with Jack? I think he would want to see this so he can improve compatibility in his driver. On Mon, Jun 7, 2021 at 9:10 PM Eric Auer <e.a...@jpberlin.de> wrote: > > > Hi gamers and coders, in particular Lukas :-) > > Wondering why some (copy protected?) games work with OAKCDROM > but not with UDVD2, I checked which differences exist between > the two. I also found a relevant DOSBOX code snippet, assuming > that DOSBOX cares more about game compatibility. Things which > are not supported in UDVD2, but are supported in OAKCDROM are: > > *driver functions* > > Driver function 3 IOCTL IN and 0x0c IOCTL OUT both have > various sub-functions, but some are not supported in UDVD2 > while others are not supported in DOSBOX. As I assume that > DOSBOX is good with games, functions which ARE supported > in DOSBOX and OAKCDROM, but not in UDVD2, are most likely > candidates for game copy protection compatibility issues. > > Driver function 7 flush (DOSBOX does not support this either) > > Driver functions 0x0d and 0x0e (open or close driver: > DOSBOX ignores this, just as UDVD2 does, no problem) > > Driver functions 0x80, 0x82 and 0x83 (0x81 is reserved) do > differ a bit, but within specs: 0x83 read long prefetch is > synonymous to SEEK (0x83) in UDVD2, while it actually behaves > as READ LONG (0x80) in DOSBOX and in OAKCDROM, all three are > different from each other (no idea what exactly they do). > > Interestingly, neither OAKCDROM nor UDVD2 support WRITING > to CD/DVD, neither with nor without verify (0x86 and 0x87) > but users of "DOSCDROAST" are probably the only ones who > notice that? Also, both drivers support play, stop and > resume audio (0x84, 0x85 and 0x88) which is great :-) > > *differences for IOCTL support* > > IOCTL OUT function 3 "audio control" (volume control?) > > IOCTL IN function 4 "audio control" (volume control?) > In DOSBOX, you can read with the latter what you wrote > with the former. > > IOCTL OUT function 4 "write bytes" (not supported in DOSBOX > either, so this is apparently not relevant for games?) > > IOCTL IN function 1 "head location" seems to be supported > in UDVD2 and DOSBOX but not OAKCDROM, but I might have > messed up my probing for that one. > > IOCTL IN function 3 "error statistics" is not supported > in UDVD2, but DOSBOX does not support it either > > IOCTL IN function 5 "read bytes" is supported by neither > UDVD2 nor DOSBOX, so probably not relevant for games > > IOCTL IN function 0x0d "subchannel info" is not supported > by UDVD2 and there seems to be a *bug* in DOSBOX because > it seems to mix up the function and 0x0c "Q-channel info"? > > IOCTL IN function 0x0e "read UPC/EAN code" is not supported > by UDVD2 and seems to be an obvious choice for doing some > minimal copy protection check in games? > > *background* > > I have used the UDVD2.ASM sources, an OAKCDROM binary > and the following two web references for my comparison: > > MSCDEX text, describing the driver API: > https://gist.github.com/abrasive/7a615e6dde0c1da962f9930cc63ee43d > > DOSBOX implementation, for comparison: > https://sourceforge.net/p/dosbox/code-0/4167/tree/dosbox/trunk/src/dos/dos_mscdex.cpp > > *conclusion* > > If you ask me, *READ UPC CODE* (IOCTL IN function 0x0e) would > be an interesting candidate to check for DOS game compatibility. > > *other thoughts* > > Audio volume control calls do not seem relevant and as far > as opening or closing the driver, reading and writing drive > control bytes or reading error statistics are concerned: > > Those are not supported by DOSBOX EITHER, so if that would > break games, DOSBOX users might have already mentioned it? > > Which of the two allowed styles "read long prefetch" does > should not matter, as long as the driver does consistently > whatever it does. I think some flag also announces that. > > Note that checking the audio playback "cursor" location is > usually done by reading the Q-channel, not head location, > but it is great that UDVD2 implements both :-) Checking the > head location can give useful "seek" progress info, I think. > > *proposed game experiment* > > I suggest the following experiment: If your OAKCDROM has > md5sum 7ed28c4b926dae81a4e9ccf1f5378f64 then changing the > bytes at offset 0x281 from 0xd6 0x04 to 0xf5 0x05 should > deliberately "break" the "read upc code" function, so if > that keeps everything else working, BUT breaks the copy > protected games, then my theory would be correct and it > might help to implement that one more function in UDVD2. > > In DOSBOX, this function returns 1 attribute byte, 8 UPC > bytes and a 0 byte. We can return ten 0 bytes on failure. > > Regards, Eric > > PS: Note that OAKCDROM has exe style relocations, so you > have to use a hex editor, not debug, to change the 2 bytes. > > PPS: The ELTORITO driver, of course, does not support any > audio and similar functions and does not implement several > other functions which are available in the other drivers. > _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
