Hi Tom,
>> The main topic of my off-list exchange with Jim was something >> else: Jack not wanting to add UPC read support to UDVD2, being >> upset about Jim hinting at a compatibility problem with UDVD2 >> after my OAKCDROM comparison, where I suspected that Lukas' copy >> protected games might be looking for UPC data, > which is mostly unqualified speculation, but still ... Which is why I want people who found games working with OAKCDROM but not with UDVD2 to run the experiment to test whether UPC matters. UPC can also be called EAN or other names. As far as I have understood some thoughts from Bret on the topic, certain Q-channel frames will contain data which can be interpreted as the "bar code number" of your CD, but because you can simply burn any UPC/EAN/... when you copy CD, that does not qualify as sensible protection against copying. It ONLY forces you to put at most 1 game on 1 copied CD, if all games would use UPC "protection". To test whether UPC features are accessed, my proposed experiment is a binary patch to break the UPC read call in OAKCDROM and see whether that is enough to make the copy protected game refuse to run, as specified in my original OAKCDROM related email here. Of course I could also patch CDRCACHE to intercept UPC access and show whether and which values are read from the real CD (not possible with UDVD2 yet) but also to return arbitrary injected UPC values etc. I think this would be a second step after the much simpler experiment with the binary patch mentioned above shows whether the call is relevant at all. > Jack is absolutely right to refuse to implement UPC > just in case it might be required by some games. Actually people already give negative youtube reviews when they simply have to download extra drivers to make things work, so it would be a bonus to have it in UDVD2 *if* it turns out that it would make a difference for games. >> Which is a problem which has been known for years. Those >> features in his drivers work well, but you can not enjoy >> them on FreeDOS. DEVLOAD can be a workaround in few cases. > that's exactly the point. DEVLOAD does provide a work around > in most (I'd had said 'all') cases. There are two features involved here: First, whether HMA allocation is possible from config sys. That one can be worked around by using DEVLOAD in autoexec, because HMA allocation is possible outside config sys. Some of Jack's drivers can use the HMA so they need less DOS RAM. But SECOND, you can actually get more free DOS memory in the lower 640k by loading more drivers into UMB. To be specific, if your load UMBPCI first, you could even load EMM386 into UMB if FreeDOS would support multiple UMB providers. There also is a clever feature in XMGR which lets you relocate that HIMEM-style driver into UMB by loading a preliminary version in low RAM first, then loading EMM386, then loading a refreshed instance into UMB: DOS=HIGH,UMB DOSDATA=UMB DEVICE=A:\XMGR.SYS /B /N32 DEVICE=A:\JEMM386.EXE DEVICEHIGH=A:\XMGR.SYS If you combine that with loading UMBPCI first and loading JEMM386 high, you may end up having 650k of 640k DOS RAM free or something like that? :-D Of course this is only for EMM386-only JEMM386. JEMMEX is "HIMEM & EMM386 in 1". But be aware that UMBPCI areas may have I/O limitations. Which is why XMGR has yet another option, /W which makes it use the DOS sector scratch workspace buffer instead of UMB, so it can more safely work with data in UMB. Talking about advanced optimizations, UHDD uses many int 15.87 calls, so it would be great if JEMM386 and JEMMEX could speed those up. I guess using VME or PGE options for Japheth's drivers already helps somewhat. The closed source XHDD sibling of UHDD has a /P option to keep the cache metadata in DOS RAM to have fewer int 15.87 calls. Another very nice trick is that loading UHDD *before* EMM386 can solve incompatibilities between BIOS and EMM386, because it takes DMA disk access out of the hands of the (sometimes EMM386-incompatible) BIOS by letting UHDD itself do the disk access. If you want to load UHDD before EMM386, but still want to load it to UMB, you would again want UMBPCI and EMM386 to be used both, but FreeDOS only supports one UMB driver at a time, as far as I remember. Of course, as UMBPCI areas can have I/O problems, this will depend on whether your system is compatible. Talking about compatibility: A bug in certain LiteON CD drives breaks DMA completely. You could disable DMA in UDVD2 with the /UX option, but that will ruin your speed, so do NOT do it unless really necessary. So in short, by having early HMA availability *and* support for multiple UMB providers would give users more flexibility in their memory usage optimizations, although the HMA aspect can be worked around by using DEVLOAD if you are willing to push the start of all involved drivers from config to autoexec. > while true, kernel memory handling at init time is far from > trivial (you may call it contrieved). I know, so I am far from thinking that this would be easy to solve, even for you and Bart who have a lot of hands-on experience and knowledge on those topics in the FreeDOS kernel. Thanks for getting HMA/UMB kernel and DOSDATA to work in the first place, years ago :-) Eric PS: On "changes are mostly the work of others" in kernel and shell, could those please mail this list about their work? _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
