Can you also attach the tool to your post? Just as a precaution that the patch is available on more than one source!
No way to test since I don't have a retro machine but all things U7 are great 😉

If it's found to be working in general, I'll attach a more final version.

There's an experimental version that patches the game to have cache off only if it had already been turned off, e.g. with setmul. [experimental version removed and made the official version]. In other words, it prevents the game from touching the cache setting at all. If you test it, might as well set up a fresh copy of the game, just in case, though it doesn't matter whether you applied the previous patch or not.

It replaces the game's 'mov eax,1 - mov cr0,eax' with 'mov ebx,cr0 - or bl,1 - mov cr0,ebx'. It also replaces the game's 'xor eax,eax - mov cr0,eax' with 'and bl,0feh - mov cr0,ebx'. It doesn't seem to me that the ebx register is used in the meantime, so it should be fine, but who knows. I also don't know whether the game really wants all the cr0 bits to be 0 at the start. I assume what it's doing here is entering unreal mode, I don't know much about that mode but I don't think it requires anything more than bit 0 of cr0 to be toggled. This experimental version appears to work on my hardware, but whether it has effects later in the game I don't yet know.

interesting, thanks for sharing this!
is also U7 part2 affected by the cache "feature" ?

I think the bits that the game cares about are bit 29 and bit 30 of CR0: not write through and cache disable. By making them 0, they enabling caching and write-through method. They probably also enter in protected mode then set segments with a limit of 4GB and then when they go (write 0 to bit 0 of CR0) out they can linearly access all the memory (using 32bit operands and address).

Is there evidence that the game cares about bits in cr0 apart from the first one? The bit 0 thing could indeed be for the unreal mode thing. Of course, we don't care if the game cares about cache for speed reasons, just whether it cares about it for data correctness.

Not sure about serpent isle, haven't looked into it as of now.

vvbee wrote:

Is there evidence that the game cares about bits in cr0 apart from the first one? The bit 0 thing could indeed be for the unreal mode thing. Of course, we don't care if the game cares about cache for speed reasons, just whether it cares about it for data correctness.

Not sure about serpent isle, haven't looked into it as of now.

Nope, no evidence, as I have not looked at the code yet. This is just based on what bits the game seems to set to 0 based on your code replacement. By using EBX and only ANDing with 0xFE to clear only last byte you are effectively preserving top bits.

Either way your patch probably works so yay! 😀

vladstamate wrote:

Nope, no evidence, as I have not looked at the code yet. This is just based on what bits the game seems to set to 0 based on your code replacement. By using EBX and only ANDing with 0xFE to clear only last byte you are effectively preserving top bits.

I do want to make sure the patch doesn't screw things over, and in what way if it would, hence wanting to double check. You can interpret it as preserving all but the first bit, but also as setting the first bit only. Whether the game's mov eax,1 is a blanket statement for setting the first bit while only minimally bothered about the others or an overarching design need to have more than one flag in a particular state isn't obvious. I think we can assume that it at least wants to set the first bit to prepare to enter unreal mode, the setting of which the patch does for it without clearing the rest of cr0 like the game otherwise would. Well, the first patch forces the cache disable bit, while the experimental second patch only toggles cr0's first bit and doesn't allow anything to touch the cache stuff. There's not plenty of convenient room in the executables to inject more specific bit toggling, so expecting only the first bit to matter is a fair start, but needs testing.

I also have a k6 300 and a pentium 90, I'll test on them unless someone beats me to it. Mind you I can only test with the files from the gog release, which while dated 1992 may not match all other dos releases.

Tried it on the k6 and saw it working. Messed around setting various cpu flags in dosbox and was satisfied enough that the patched game wasn't sensitive to them. Couldn't be bothered to test on the pentium since it's not set up for use, but it's a common enough platform that someone'll chime in if it doesn't work.

I made the experimental patch the only patch, gave it my seal of good enough, and pinned it to the first post.

Source code is up there: https://github.com/leikareipa/u7dcp.

Also, phil's recent video showed that people still aren't too knowledged about this. Get the word out and make the world that much better.

Curious: would Ultima VII actually need to enable unreal mode if HIMEM.SYS is already loaded? Since HIMEM afaik uses unreal mode to access high memory, the game developers could have used HIMEM instead of setting it up on their own.

The link for the precompiled tool with instructions doesn't work. Is it available anywhere?

https://github.com/leikareipa/u7dcp/releases

Thank you!