Would asking for a patch for Ultima VII Pt 1 be too much? 😀

appiah4 wrote on 2025-06-03, 13:58:

Would asking for a patch for Ultima VII Pt 1 be too much? 😀

I'd have to do some research for that. Didn't even realize that game didn't have speed throttling. I do have a 486DX/33 on-hand here, which it sounds like is the "target" CPU for that game. I'm in no rush to do it, but it's definitely possible. It's going to be... interesting trying to debug the game though. The weird custom memory manager they did makes it incompatible with Virtual 8086 mode, and therefore SoftICE, so I'd probably have to do a lot of it blind, which doesn't sound fun.

appiah4 wrote on 2025-06-03, 13:58:

Would asking for a patch for Ultima VII Pt 1 be too much? 😀

There is a patch for that game already.
Ultima VII Frame Limiter Patch

vetz wrote on 2025-06-03, 14:27:

appiah4 wrote on 2025-06-03, 13:58:

Would asking for a patch for Ultima VII Pt 1 be too much? 😀

There is a patch for that game already.
Ultima VII Frame Limiter Patch

Perfect! Saves me the hassle 😀

DivByZero wrote on 2025-06-03, 13:44:

I currently consider this patch a work in progress. Like SM2, this patch currently only patches gameplay, but not all the other bits of animation that doesn't have speed limiting in there, like the intro, people talking, pre-mission launch screen, etc, which weren't ever fixed in SM2 either (and are still a problem in Wing Commander 2 I believe). I may continue working on this patch and fix that issue too. I also haven't completed wrapping this patch into a python script to apply to any version of the game, like I've done for my previous patches. I'm short on time the last few days though, so in the interests of expediency I'm putting this patch out here in its current form, which is simply a patched WC.EXE binary of the F3.1 release. I hope to make it scripted and fix additional speed issues in the coming weeks, depending on how much time I get.

Anyway, that's about it. Let me know if there are any questions or issues. I'll make edits to this main post as updates are available for this patch.

This is pretty much amazing, believe me these efforts are very much appreciated. I think i'll hold on posting this on Wing Commander CIC, as you mentioned, you'll have it scripted for a patch that works on other game versions. I think that is the ideal situation. If you continue to work on the patch, the better, if not the most important thing is always the gameplay. Just make sure you don't burn yourself out. Other times you might get on a roll and keep pressing. That happened to me with patching Tandy games.

These patches are great, people would look away from certain systems like Pentium II's because you couldn't get a decent slowdown steady scaling with those. I believe Wing Commander to be one of the games that would put people off from them.

DivByZero. I really appreciate you taking on this challenge! Have been wanting a patch for this game for some time. I hope you're able to finish it to also include all parts of the game.

If you need another challenge, then you have Test Drive III, probably the game most notorious for running way to fast on anything newer than a quick 386. Timberwolf made a whole Youtube video on his efforts: https://www.youtube.com/watch?v=V0uyOea182s

Thanks for creating patches like this!

It continues to baffle me how there are very old games (even from the early DOS era) that continue to work flawlessly on systems that came on the market decades later, simply because the programmers used proper timing and delay logic based on the Interrupt Service Routines of the legacy PC BIOS, instead of hard-coded delay loops that were tuned to work only on hardware released in a specific narrow period in history.

And then there are games like Wing Commander, and even later games like Descent, that are unplayable on newer systems, due to sloppy programming. I wonder how feasible it would be to create patches for all these problematic games. I guess that a delay loop generally takes up less instructions than something that invokes these ISRs, so it would not be easy to simply patch those routines in place, right? Or maybe it's not so bad?

And maybe also include the invocation of HLT instructions in such patches, so those games don't unnecessarily use 100% of a CPU core on modern systems when they run?

vetz wrote on 2025-06-04, 09:16:

If you need another challenge, then you have Test Drive III, probably the game most notorious for running way to fast on anything newer than a quick 386. Timberwolf made a whole Youtube video on his efforts: https://www.youtube.com/watch?v=V0uyOea182s

Actually even a quick 386 like 40MHz or even 33 run Test Drive III like effin´roadkill. The game seems to run best on a 386 SX-16. Probably even a 386 25 is already too fast.

Out of the top of my head these are the most notorious:

Aces of the Pacific (flight controls become weird)
Bubble Ghost
Knights of the Sky
Test Drive III
Ultima 6 (don't remember if there's a patch for this)
Warcraft 1 and 2 (scrolling on the map is very fast, but not impossible to play)
X-Com UFO Defense aka UFO:Enemy Unknown

But let's give DivByZero time and patience to actually finish up what he needs to. Wing Commander fix is specially great because even slowing down the game was a mixed bag. Inevitably, whle playing you were either too fast or too slow, depending on the number of objects on the screen.

carlostex wrote on 2025-06-04, 10:30:

Actually even a quick 386 like 40MHz or even 33 run Test Drive III like effin´roadkill. The game seems to run best on a 386 SX-16. Probably even a 386 25 is already too fast.

You're right, thanks for clarifying!

carlostex wrote on 2025-06-04, 10:30:

Warcraft 1 and 2 (scrolling on the map is very fast, but not impossible to play)

For Warcraft 1, isn't this fixed in this patch? WarCraft: Refurbished (unofficial MS-DOS patch)

Python script version of the patch is available now, and I've updated the original post. Only tested on version F3.1, but it should work on anything now. Let me know how you go.

digger wrote on 2025-06-04, 10:12:

Thanks for creating patches like this! […]
Show full quote

Thanks for creating patches like this!

It continues to baffle me how there are very old games (even from the early DOS era) that continue to work flawlessly on systems that came on the market decades later, simply because the programmers used proper timing and delay logic based on the Interrupt Service Routines of the legacy PC BIOS, instead of hard-coded delay loops that were tuned to work only on hardware released in a specific narrow period in history.

And then there are games like Wing Commander, and even later games like Descent, that are unplayable on newer systems, due to sloppy programming. I wonder how feasible it would be to create patches for all these problematic games. I guess that a delay loop generally takes up less instructions than something that invokes these ISRs, so it would not be easy to simply patch those routines in place, right? Or maybe it's not so bad?

And maybe also include the invocation of HLT instructions in such patches, so those games don't unnecessarily use 100% of a CPU core on modern systems when they run?

As a career programmer, my unvarnished opinion is it's just plain lazy/sloppy programming, and inexcusable past the 286 era. I can understand minor things missed because they didn't trigger any noticeable issues at the time, like animation sequences in the Police Quest 2 intro, or mouse movement in Warcraft. Overall execution speed of the main game loop though, in the 386 era, the developers working on this knew it was a major problem and chose to ignore it. Not good. Now they may well have reasoned, "no system today can play this quite as fast as we want anyway, and adding in timing checks would make the game a bit slower, so we won't add them in", but if they thought that I still believe it's lazy/sloppy programming, as a quick "profiling" of execution speed on the system could be used to deactivate timing checks on slower systems, eliminating any timing penalties, while still making the game able to be run properly on hardware released 2-3 years after release (or possibly even current high-end hardware of the day). The only conclusion I can come to is that they simply didn't care about what happened to the game once they got it past launch. If they wanted to cut corners and rush it to market, at least do the right thing and come back and patch it after release.

Now making the game not use 100% CPU isn't possible without making the game incompatible with DOS/period correct hardware (unless there's a feature there I'm not aware of), but as for how feasible it is to patch existing games with timing code that didn't originally have any, well it's very feasible, very much doable, but it requires a combination in a person of:
1. A high degree of technical knowledge in arcane systems
2. The drive and desire to spend the time to figure out the changes required
3. An obsessive enough personality to be willing to do the tedious work of cramming new code into pre-compiled binaries, with a lack of much/any real tooling to help with that process.
4. Far too much time on your hands

This change took me about 4 hours to do, and another 8 hours to patch up into a fancy script to automate it, but I'm coming from a pretty high base to start with. I've been reverse engineering old code for 30 years, literally. I've been a career programmer since I was out of school. I've written my own emulators from scratch. This little project is actually my diversion from other projects I probably should be working on right now, like Pioneer LaserActive emulation I've got mostly done, and raw CD EFM decoding I've got working and need to clean up/iterate on the capture hardware for. Anyone else can do this kind of patching work too, it doesn't need all that experience, but even at 12 hours, I found this patch a bit tedious. The main thing is drive and time. I'm not sure I have enough of either to go down the rabbit hole of patching a dozen other games out there, but Wing Commander 1 was in my list of games to have working on my little 486 time capsule, so I had enough motivation to do this one. All it was though was me sitting down and using SoftICE, IDA Pro, a hex editor, and x86 assembly/machine code reference materials. Anyone else could learn to use the tools and do the same thing. Anyone working on this kind of stuff is self-taught, it's just a matter of diving in and giving it a go.

vetz wrote on 2025-06-04, 10:34:

For Warcraft 1, isn't this fixed in this patch? WarCraft: Refurbished (unofficial MS-DOS patch)

Interesting i missed that somehow.

DivByZero wrote on 2025-06-04, 13:37:

Python script version of the patch is available now, and I've updated the original post. Only tested on version F3.1, but it should work on anything now. Let me know how you go.

Awesome i'll try that with my version, which is not F3.1 if i'm not mistaken.

Ctrl+V during mission I believe it was will display the version if you need to check it

DivByZero wrote on 2025-06-04, 14:21:

Ctrl+V during mission I believe it was will display the version if you need to check it

Turns out my game was F3.1 all along. I do have other versions, one floppy version that reports VER 32.5. File date is 19-09-1990. That's dd-MM-yyyy time format.

Trying to patch this 32.5 version reports:

1Checking WC.EXE
2Failed to locate target code

There's also 32.6 dated 27/09/1990. This one also:

1Checking WC.EXE
2Failed to locate target code

These are the versions i have and could identify at the moment. Seems like the patch is only working on F3.1. If you need the exe files for the other versions let me know.

Is it possible to release ips or delta patch?

carlostex wrote on 2025-06-04, 17:35:

Turns out my game was F3.1 all along. I do have other versions, one floppy version that reports VER 32.5. File date is 19-09-199 […]
Show full quote

DivByZero wrote on 2025-06-04, 14:21:

Ctrl+V during mission I believe it was will display the version if you need to check it

Turns out my game was F3.1 all along. I do have other versions, one floppy version that reports VER 32.5. File date is 19-09-1990. That's dd-MM-yyyy time format.

Trying to patch this 32.5 version reports:

Copy code to clipboard

1Checking WC.EXE
2Failed to locate target code

There's also 32.6 dated 27/09/1990. This one also:

Copy code to clipboard

1Checking WC.EXE
2Failed to locate target code

These are the versions i have and could identify at the moment. Seems like the patch is only working on F3.1. If you need the exe files for the other versions let me know.

Thanks for testing, I'll pull down some other versions and see what's happening. If they haven't compressed the exe file on floppy releases, it's almost certainly the debug function I'm overwriting. I'd assumed it was there and unchanged from earlier versions, but it's possible it was a later addition or had changes made to it. If I can identify an alternate routine to inject code into, or add detection for alternate revisions of the target routine, I can fix it for those other versions.

KainXVIII wrote on 2025-06-04, 18:54:

Is it possible to release ips or delta patch?

Not really for this one I'm afraid, unless I really do want to make hand-rolled patches for each revision. This patch has to do a lot of soft matching and adjustments to code in order to work. It's written to deal with things being relocated in data and code segments on subsequent compilation, and recalculates offsets and adjusts everything accordingly, while patching the relocation table at the start of the file. A simple match-and-replace patch won't cut it if I want to get away with one script for everything, and I really don't have time to hand-roll patches for each revision, or hunt them all down.

carlostex wrote on 2025-06-04, 17:35:

Turns out my game was F3.1 all along. I do have other versions, one floppy version that reports VER 32.5. File date is 19-09-199 […]
Show full quote

DivByZero wrote on 2025-06-04, 14:21:

Ctrl+V during mission I believe it was will display the version if you need to check it

Turns out my game was F3.1 all along. I do have other versions, one floppy version that reports VER 32.5. File date is 19-09-1990. That's dd-MM-yyyy time format.

Trying to patch this 32.5 version reports:

Copy code to clipboard

1Checking WC.EXE
2Failed to locate target code

There's also 32.6 dated 27/09/1990. This one also:

Copy code to clipboard

1Checking WC.EXE
2Failed to locate target code

These are the versions i have and could identify at the moment. Seems like the patch is only working on F3.1. If you need the exe files for the other versions let me know.

Ok, NOW it'll work for other versions. There were two offsets I'd incorrectly matched as exact values, when they needed to be tolerant of relocations. I've updated the script in the original post. Tested against B2.3, 2.6, 3.1, F3.1, and F3.2.

DivByZero wrote on 2025-06-04, 22:41:

Ok, NOW it'll work for other versions. There were two offsets I'd incorrectly matched as exact values, when they needed to be tolerant of relocations. I've updated the script in the original post. Tested against B2.3, 2.6, 3.1, F3.1, and F3.2.

Ah so in those other versions what i thought to be a 3 is actually a B. I thought F3.1 was the last version, so apparently there's a F3.2.

EDIT: Tested the python script with other versions and it worked on all of them!! BRAVO!!!