VOGONS


First post, by vvbee

User metadata
Rank Oldbie
Rank
Oldbie

U7DCP - Ultima VII DOS Cache Patch. Stops Ultima VII: The Black Gate aka. Ultima 7 from enabling CPU cache on launch.
https://www.youtube.com/watch?v=a2tyyWk766s - the game running on a 1.4 GHz CPU no worries.

Note that U7DCP comes as is, no guarantees, no warranty, and it may or may not work as intended. See the readme before use.
http://tarpeeksihyvaesoft.com/soft

Last edited by vvbee on 2018-06-01, 19:30. Edited 3 times in total.

Reply 1 of 14, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

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 😉

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 3 of 14, by vvbee

User metadata
Rank Oldbie
Rank
Oldbie

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.

Last edited by vvbee on 2017-10-24, 05:45. Edited 1 time in total.

Reply 4 of 14, by keropi

User metadata
Rank l33t++
Rank
l33t++

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

🎵 🎧 PCMIDI MPU , OrpheusII , Action Rewind , Megacard and 🎶GoldLib soundcard website

Reply 5 of 14, by vladstamate

User metadata
Rank Oldbie
Rank
Oldbie

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).

YouTube channel: https://www.youtube.com/channel/UC7HbC_nq8t1S9l7qGYL0mTA
Collection: http://www.digiloguemuseum.com/index.html
Emulator: https://sites.google.com/site/capex86/
Raytracer: https://sites.google.com/site/opaqueraytracer/

Reply 6 of 14, by vvbee

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 7 of 14, by vladstamate

User metadata
Rank Oldbie
Rank
Oldbie
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! 😀

YouTube channel: https://www.youtube.com/channel/UC7HbC_nq8t1S9l7qGYL0mTA
Collection: http://www.digiloguemuseum.com/index.html
Emulator: https://sites.google.com/site/capex86/
Raytracer: https://sites.google.com/site/opaqueraytracer/

Reply 8 of 14, by vvbee

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 9 of 14, by vvbee

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 10 of 14, by vvbee

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 11 of 14, by cde

User metadata
Rank Member
Rank
Member

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.