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
