CREEPINGNET'S WORLD
VooDoo DooDoo Dookie Kooky
The Tough Task of Getting Ultima VII Running on Legacy Hardware
Dealing with DOS And Ultima 7's Insane Memory Manager
aka. Insane Memory Experiments
It's a well known fact that Ultima VII: The Black Gate, and Ultima VII Part 2: Serpent's Isle, are two of the hardest DOS games to get running on the face of the frickin' earth! The reason for this is the notorious and infamous "VooDoo" Memory manager that allowed a 386 DX/486 DX computer to process the sheer insane amount of data these games going over 10MB in size require to generate an open sandbox world in such detail back in the early 1990's.

This makes Ultima 7 a royal PITA on actual hardware for a lot of people, because the games were designed in a time when people were trying to cram all this crap on a 250MB HDD, on 4-8MB of RAM, and a 256K VGA Card, and asking a 386/486 PC with that little resources to process an entire open world with a day-night cycle, NPCs dependant on that day-night cycle, with their own activities, and the ability to manipulate almost any object, go almost anywhere, and not have to transition to a separate map (ie Ultima V and older) to do so, is a tall task for a Pre-Pentium computer.


The Original Issue
Originally, in 1991, Ultima VII: The Black Gate, and in 1992, Ultima VII: Serpent's Isle, were released in a time when 386 and 486 PC's were considered the *norm*. These machines typically contained paltry 80MB-528MB HDDs, a tiny 2MB-16MB of RAM, most without a CD-ROM (Multimedia computers were a premium), and ran MS-DOS, a 16-bit, single user, single-tasking operating system running on single-core CPUs without hyperthreading, out-of-order execution (OOE), or any other fancy things save for a few new instructions over the 286 and 8086 that came before them. Windows was an option for people who "did not know how to use a DOS PC" and not the *norm*, and was only up to version 3.1 by the time the second game came out.

AS such, Origin Systems had to manage to cram one ginormous "Super Chunk" worldmap with hundreds of NPCs with their own schedules, a day and night cycle, a virtue system, a battle system that took place on the main map, and to make it look nice enough to make ULtima VI: The False Prophet look "old", they needed to bump up a LOT of things about the interface. This included "paperdolls" for your weapons and armor in the second release (Serpent's Isle), an inventory system based entirely off of point-n-click with the graphical elements fully usable by the player, including complex tasks such as operating an entire kitchen with ingredients to cook food, or the same to create and cast spells. While it may seem *quaint* now this was a heaping FUCKTON of things for a early 1990's PC to be asked to do.

And obviously, all this stuff consumes a LOT of Memory - to run Ultima VII, either entry, you had to have a 386 DX based computer, with at least 4 Megabytes of RAM, at least 16 Megabytes of hard disk space for the game itself, and you needed a sound card (SoundBlaster, Adlib, Gravis UltraSound - to name a few) to have ANY sound. This is a tremendous leap from Ultima VII which ran (very slowly) on an original IBM PC with 640K RAM, used a keyboard interface still, and still did all of the sound effects from the internal speaker (with the soundcard playing music through Adlib usually). Now we have a compelte game, with sound samples of the Guardian taunting the Avatar, that fits on a modern HDD, and needs tons of RAM to work well. So to achieve this, Ultima VII uses a special Memory Manager - VooDoo.
The VoodDoo Memory Manager Explained
The VooDoo memory manager that used one of the 386+ operating modes that was seldom used - Flat Model Memory mode or "Unreal Mode". Normally, most Memory Managers leveraged the 386's "Protected Mode" to run on top of DOS, VooDoo used a 16-bit memory model.

VooDoo's major failing is it's a royal PITA to set up to work properly, and is a product of it's time in the early 1990's. It required most people to need special CONFIG.SYS and AUTOEXEC.BAT settings to get enough free lower 640K DOS base memory to start the game. And at that time, that was assuming the computer was running MS-DOS 5/6/6.1/6.21/6.22 - so it does not act properly with ALL types/versions of DOS, most especially FreeDOS, which it's notorious for having issues with.

So that's the focus of this page, getting Ultima VII Working on ANY DOS system.
Other Methods - why not DOSbox, a Virtual Machine, or Exult?
Of course, I'm fully aware of the alternative ways to get this game to run on other operating systems.

Exult - The most popular is the Windows based engine "Exult". This basically replaces the whole original engine, and updates it somewhat with some more user-options than offered in Ultima VII originally. It also allows easy access and higher quality music. However, I've found the experience playing with Exult drastically different from the experience playing on original hardware or even a Virtual Machine. I would highly reccommend this for most people running this game in modern Windows or Linux.

DOSbox - Another popular way of running Ultima VII is in DOSBox. DOSBox can be configured to be a VGA machine with more than 4MB of RAM, with no EMS, and XMS enabled, and it will allow Ultima VII to run as intended.

Virtual Machine - Virtual Machines, such as Oracles VirtualBox, can allow you to build a virtual machine, including a MS-DOS 6.22 machine compatible with Ultima VII that functions as intended. Thing is, almost everything on this page STILL applies, ie if you install FreeDOS vs. MS-DOS vs. DR-DOS.

Actual Hardware in Windows XP/2K or 95/98/Me - There's another set of utilities available via the internet called U7RUN and U7XP - which allow Ultima VII to be run natively in Windows 2000/XP/95/98/Millennium Edition - like a native Windows Application. It runs pretty much as it does in DOS, but without all the hardware fiddling. This is what I use on my vintage Windows machines to run it.

Actual Hardware - in DOS - Then there's the traditional method of running Ultima VII - installing it to a MS-DOS computer, then setting up the boot options to work with MS-DOS, usually setting Files and buffers to 40, removing EMS if installed (EMM386.EXE), installing your mouse driver, and HIMEM.SYS - which works great.

However, this page explores my experiments in getting the game running in FreeDOS 1.2 or 1.3. Which has been a long run of Experiments.
Running U7 in FreeDOS
The first problem is FreeDOS is a CLONE of DOS, not an actual DOS product. It's like the difference between AT&T SCO UNIX and Linux Mint - one is a commercial software product with some secret sauce and proprietary things inside it, the other a more modernized non-commercial, open-source CLONE of Unix that has some of it's own unique character traits due to deviations intended to avoid issues with patents, copyrights, or be considered illegal reverse engineering, likely for the two reasons stated. So they function differently.

Firsrt and foremost, FreeDOS uses a completley different command interpreter. MS-DOS uses COMMAND.COM, FreeDOS uses FREECOM.EXE - which is the open source command-interpreter. It's what gives you the X:\> prompt, and what inteprets Kernel level commands to the O/S.

Next, and more importantly, the MEMORY MANAGERS are different. There's HIMEMX.EXE - which is a HIMEM.SYS replacement that allows access to XMS, but is incompatible with VooDoo. What I have noticed is running with the same minimal setup in freeDOS as you would in MS-DOS, causes Ultima VII to see the WRONG amount of free base memory. I have had numbers in the lower 640K as high as 606K Free - more than enough (I've seen Serpent's Isle ask for as high as 597K of Base RAM Free). Usually this is met with an error message like error freecom.c "You need 547,698 bytes of base memory to run Ultima 7/Serpent's Isle, you only have 457,696". Then you look and see MORE memory than it says it needs free in Base Memory. This is likely because HIMEMX is using some more advanced functionality than HIMEM.SYS did, and maybe even has some sort of buffer or some sort of block-off-of-access to that RAM. Or maybe, INTRO.EXE or MAINMENU.EXE don't quite understand what's going on.

JEMMEX.EXE seems to be a combination XMS/EMS memory manager. This one is easily found because it either crashes the system, or causes it to complain in the installer saying "Something has put your computer in Protected Mode, please remove any Memory Managers". So this is 100% incompatible, and it's kind of obvious because what else has EMM - ie Expanded Memory Managemnt, aka EMS - that's right the dreaded EMM386.EXE that we used to use in DOS for LIMS Compliant Memory Management in the days of the 286 and early 386.

However, I thnk some of the compatibility is also the Command Interpreter, because I've had times where I tried regular HIMEM.SYS From DOS, and found that I get similar issues with that as I do with HIMEMX. So I think it's a FreeDOS Compatibility issue.

One Workaround I have successfuly done is, bypassing the entire ULTIMA7.EXE File. The reason we would bypass this, is because it's just s stub that kicks off INTRO.EXE and MAINMENU.EXE. INTRO.EXE is the opening sequence of the game - the butterfly, PC desk, and weird Alice in Wonderland psychadelic intro with the Guardian's monologue in "The Black Gate", and the Sailing beginning with Richard Garriot doing the voice acting of Lord British in "Serpent's Isle". Apparently, Mainmenu.exe is called to do the memory check - as that's the EXE listed in the memory errors. So if we need to hack the executable, that's likely the first place to look.

The main game executable is U7.EXE for Ultima VII: The Black Gate, and Serpent's Isle is SI.EXE. However, starting these RAW without any command line options will cause them to say "PLEASE TYPE ULTIMA7/SERPENT TO PLAY ULTIMA VII/SERPENT'S ISLE" upon launch. So we can't jus simply jump to the game like we used to with GAME.EXE in Ultima VI: The False Prophet (which was a shortcut to your last savegame).

I found this trick on tool-assisted speedrun forum here. Apparently, these executiables (U7.EXE and SI.EXE) have command line switches that enable them to run without checking that it was kicked off via ULTIMA7.EXE/SERPENT.EXE. Basically using the command parameters c150 and p to allow the base Executable to run.....so basically, if you want a working boot configuration in FreeDOS.....however, I could be wrong, and this could be the walking speed....more on that later.

The thread suggested possibly hacking the INTRO.EXE and MAINMENU.EXE files to bypass the RAM check. This will be something we explore later once I put Hexpose on the computer and decide to do some digging in the file (once I do some research to find out what to look for where Command Line Switches or a Memory cHeck would be kept).

That said, I was able to create a batch file that bypasses this issue by launching the respective EXEs in their main folders with those parameters...however, I found out the c150 might be why the game crashes later on, and isn't needed. If there's one thing I know about tinkering with vintage computers for a long time, a lot of us get too nervous around unknowns. I was able to successfully launch the game with "U7 p" or "SI p".

That said, I'm not 100% sure - YET - what is going on here. First off, there is a possible chance these are launching without the memory check and it's running VooDoo on top of FreeDOS just fine. The other possible thing is I'm bypassing VooDoo entirely - which would also make sense if the memory check was in Intro or Mainmenu - and those were used to launch the game and the memory manager (when it would actually be needed, I doubt a menu and a slide show with full motion 8-bit video and audio really needs that much RAM).

Secondly, if these command line parameters exist, what other ones do? I know there is also a "Debug Mode" cheat that involves putting in SI or U7 and then -ABCDE and then holding the "Alt" key and pressing "255" on the numeric keypad to launch it in debug mode, allowing map editing.

Ultima VII: The Black Gate ran fine, and actually it felt like I was running it on Exult on my old GEM Pentium III - on a 486 DX4-100 - as far as speed goes. The PC was hardly having to work at all to run, and I actually had some issues with the Avatar, Iolo, and Spark running around like they just had a massive binge on a Keurig. That said, on one of my installs, I got the name "Jonathan" or "Christopher" instead of my usual character of "Mad-Mike" - meaning we have a default player maybe? My copy is from the Ultima Collection CD so I doublt that's someone's actual savegame (unless it's a placeholder).

Ultima VII: Serpent's ISle, by comparison, was a little slower, and it felt like it was working harder to function, which would explain the higher DOS memory requirement on this one possibly. Basically, default name, launched through the Teleportation Storm, all my companions gone, and then got asked the DRM questions. But it was a hair more sluggish than U7 was. So maybe this one makes more use of VooDoo than the other game does?