Hi Jim,
> 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. Yes, but was is busy with improving UHDD instead, as hinted earlier today: The new version will support all sizes from 5 MB up with full features, as opposed to requiring larger caches for some features before, or multiple-of-5-MB sizes. It also will be smaller on disk, making UIDE more obsolete. A relatively exotic feature to reserve "low XMS" for games which are unable to use XMS > 16 MB will be dropped, but I think HIMEM already has a command line option to reserve XMS 2 in that way, letting only XMS 3 prefer "high" XMS? Jack has shared another important warning: RayeR has seen BIOS / hardware combinations where UHDD has to be loaded after HIMEM, before EMM386 and outside UMB. Broken UMB DMA or VDS support, I guess? So it is good that the docs now present this workaround. Of course this will not be possible with JEMMEX at all, because there is no "after HIMEM, before EMM386" moment with when you use JEMMEX. Another FreeDOS work-around from Jack: If you use the HMA option /H of his drivers, you have to load them via DEVLOAD in autoexec, because the FreeDOS HMA allocation offerings while config sys is running are incompatible: They would not allow the drivers to acquire HMA space. Some final performance remarks: XHDD has a /P option to keep more metadata in DOS RAM instead of XMS, which uses more DOS RAM, but is slightly faster. UHDD does not have that option. Making int 15.87 faster while JEMM386 is active would improve speed: MS EMM386 is faster, in spite of JEMM386 supporting vm86 VME as far as I remember? An item for a Japeth-wishlist :-) Still, I would prefer MS EMM386 style I/O traps first, because various Sound Blaster emulators need those. To get back to the "read UPC code" function: Jack is not convinced that this would be useful and I can see in online forums that users can simply select the UPC they want to burn, so it seems odd that copy protected games would just rely on UPC. I suggest that somebody performs my suggested experiment first: Test whether blocking the OAKCDROM "read UPC code" function will result in breaking copy protected games with similar symptoms compared to testing those games with UDVD2. Regards, Eric _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
